Intermittent test failures (on Travis) #308
Comments
|
@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? |
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. |
|
I'm tracking this down with a working repro case on master vs v1.12.3; trying to identify the breaking commit. |
offbyone
added a commit
to offbyone/paramiko
that referenced
this issue
Apr 14, 2014
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 paramiko#308
offbyone
added a commit
to offbyone/paramiko
that referenced
this issue
Apr 14, 2014
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 paramiko#308
|
Yep, found it. See #309 for the fix. |
dkhapun
pushed a commit
to cyberx-labs/paramiko
that referenced
this issue
Jun 7, 2018
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 paramiko#308
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
test_B_generate_dss,AssertionErrortest_2_client_dsa,AuthenticationFailedtest_3_multiple_key_filesThe text was updated successfully, but these errors were encountered: