New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Intermittent test failures (on Travis) #308

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

Comments

Projects
None yet
2 participants
@bitprophet
Member

bitprophet commented Apr 14, 2014

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

This comment has been minimized.

Member

bitprophet commented Apr 14, 2014

@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

This comment has been minimized.

Contributor

offbyone commented Apr 14, 2014

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

This comment has been minimized.

Contributor

offbyone commented Apr 14, 2014

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

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 paramiko#308

offbyone added a commit to offbyone/paramiko that referenced this issue Apr 14, 2014

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 paramiko#308
@offbyone

This comment has been minimized.

Contributor

offbyone commented Apr 14, 2014

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

dkhapun pushed a commit to cyberx-labs/paramiko that referenced this issue Jun 7, 2018

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 paramiko#308
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment