Intermittent test failures (on Travis) #308

Closed
bitprophet opened this Issue Apr 14, 2014 · 4 comments

Projects

None yet

2 participants

@bitprophet
Member

Since the Py3 merge we've seen intermittent and different failures on random Travis runs. Will try to document them here to see if a pattern emerges, we've already seen at least one repeat a few times.

It's highly likely this is the fault of the merge and not something specific to Travis, but I've yet to encounter (m)any of them locally. Will need to isolate & run tests in a loop to determine how to debug/prove fix.

  • 462.1 - test_B_generate_dss, AssertionError
  • 400.3 - test_2_client_dsa, AuthenticationFailed
    • Saw this today but already reran that test cell so it's gone now. Definitely same exception, unsure if same test.
    • @offbyone saw this on his laptop as well, but in test_3_multiple_key_files
@bitprophet
Member

@offbyone is getting that auth failure about 1/50 times, and is unable to get it to show up at all under Paramiko 1.12, aka pre Py3 merge. Suspect perhaps random byte generation is occasionally yielding something junky?

@offbyone
Contributor
while python test.py --verbose test_2_client_dsa; do echo ""; done

Pretty simple to run. I can't say I've confirmed that it's not happening in 1.12.3 under Python 2, but I haven't managed to get it to happen there at all.

@offbyone
Contributor

I'm tracking this down with a working repro case on master vs v1.12.3; trying to identify the breaking commit.

@offbyone offbyone added a commit to offbyone/paramiko that referenced this issue Apr 14, 2014
@offbyone offbyone Revert a regression in DSS key generation
A change in f0017b8 caused a random regression in DSS key signing
due to moving the padding on the integers generated by DSA from the left
to the right.

So, for example, if signing the test case string "jerri blank", the
random number might be generated as:

k=703745698612177278239572677252380378525350342103

If so, the signature parts will be:
r=184615963997659989901526712385095827509599268253
s=2682547683721156713440053885014828604195555319

Note the s being shorter.

Prior to f0017b8, s would be right-padded with zeros:
s=268254768372115671344005388501482860419555531900

After, it would be left-padded:
s=002682547683721156713440053885014828604195555319

When converting back to a long, that loses the padding. This change
restores the behaviour.

Fixes #308
ab44a6b
@offbyone offbyone added a commit to offbyone/paramiko that referenced this issue Apr 14, 2014
@offbyone offbyone Revert a regression in DSS key generation
A change in f0017b8 caused a random regression in DSS key signing
due to moving the padding on the integers generated by DSA from the left
to the right.

So, for example, if signing the test case string "jerri blank", the
random number might be generated as:

k=703745698612177278239572677252380378525350342103

If so, the signature parts will be:
r=184615963997659989901526712385095827509599268253
s=2682547683721156713440053885014828604195555319

Note the s being shorter.

Prior to f0017b8, s would be right-padded with zeros:
s=268254768372115671344005388501482860419555531900

After, it would be left-padded:
s=002682547683721156713440053885014828604195555319

When converting back to a long, that loses the padding. This change
restores the behaviour.

Fixes #308
bed4c75
@offbyone
Contributor

Yep, found it. See #309 for the fix.

@bitprophet bitprophet pushed a commit that closed this issue Apr 14, 2014
@offbyone offbyone Revert a regression in DSS key generation
A change in f0017b8 caused a random regression in DSS key signing
due to moving the padding on the integers generated by DSA from the left
to the right.

So, for example, if signing the test case string "jerri blank", the
random number might be generated as:

k=703745698612177278239572677252380378525350342103

If so, the signature parts will be:
r=184615963997659989901526712385095827509599268253
s=2682547683721156713440053885014828604195555319

Note the s being shorter.

Prior to f0017b8, s would be right-padded with zeros:
s=268254768372115671344005388501482860419555531900

After, it would be left-padded:
s=002682547683721156713440053885014828604195555319

When converting back to a long, that loses the padding. This change
restores the behaviour.

Fixes #308
34d03ae
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment