Fix publishing of coverage results to coveralls.io (+ misc test config updates) #171
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Remove conditional unittest2 import on Python versions below 2.7, because we don't support them.
- Remove tox and coveralls ci-requirements.txt is installed by tox for each tox environment. That means tox must be installed already. And coveralls is used outside of tox - Pin coverage dependency to versions supported by coveralls, which is installed outside of tox, but must be able to read reports generated inside of tox.
- Update dist to xenial - Add a build matrix to run each tox env in a corresponding travis env as per travis/tox best practices. https://docs.travis-ci.com/user/languages/python/#using-tox-as-the-build-script - Remove obsolete dependency installs pip, wheel - Add missing coveralls dependency install - Use "install" instead of "before_script" to install dependencies. Explicitly listing "install" prevents Travis from automatically running `pip install -r requirements.txt`, which is not necessary because most of those requirements are installed again in each tox environment.
This is Python testing convention and allows coverage to correctly record the paths of the source files and left-strip the parts leading to the project directory. This commit also replaces manual test loading with the unittest `discover` function, which adds some path magic, so that tests are actually run over the source code in the project dir. For the sake of simplified test discovery, this commit removes randomization of test module loading. It also does not seem beneficial to just shuffle the test modules and not the test cases or test methods.
|
See most recent Travis builds and corresponding coverage reports on coveralls. The badge on the main README should be updated once this PR is merged and IIUC we will see GitHub status (as in the table at the bottom) in subsequent PRs, because coveralls needs a reference build. |
3 tasks
Coverage used to be configured to omit certain directories while reporting. This commit slightly optimizes coverage to already omit those directories while measuring coverage.
There is no need to create a source distribution and of securesystemslib and install it into each tox test environment, since we use the (not installed) project files by patching the PATH in `aggregate_tests.py`'s `unittest.TestLoader().discover`. This should save some cycles. See uptane/obsolete-reference-implementation@af22701 for detailed background information.
Structure according to succession.
|
Just added a few commits, motivated by changes in uptane/obsolete-reference-implementation#195 |
lukpueh
pushed a commit
to lukpueh/securesystemslib
that referenced
this pull request
Aug 8, 2019
It appears the specification for PKCSv1.5 doesn't say how long should a signature should be (i.e., should we zero-pad the signature or should we use the minimum number of bits required). In this case, signatures generated using gnupg would sometimes be 8*n bits shorter than the public key length, which would result in signatures that fail to verify due to missing leading zeroes (the leading zeroes existed at the bit level however). Zero-left-pad signature objects that do not match the length of the exponent `n` on a gpg rsa public key object before verification.
lukpueh
pushed a commit
to lukpueh/securesystemslib
that referenced
this pull request
Aug 14, 2019
It appears the specification for PKCSv1.5 doesn't say how long should a signature should be (i.e., should we zero-pad the signature or should we use the minimum number of bits required). In this case, signatures generated using gnupg would sometimes be 8*n bits shorter than the public key length, which would result in signatures that fail to verify due to missing leading zeroes (the leading zeroes existed at the bit level however). Zero-left-pad signature objects that do not match the length of the exponent `n` on a gpg rsa public key object before verification.
lukpueh
pushed a commit
to lukpueh/securesystemslib
that referenced
this pull request
Sep 4, 2019
It appears the specification for PKCSv1.5 doesn't say how long should a signature should be (i.e., should we zero-pad the signature or should we use the minimum number of bits required). In this case, signatures generated using gnupg would sometimes be 8*n bits shorter than the public key length, which would result in signatures that fail to verify due to missing leading zeroes (the leading zeroes existed at the bit level however). Zero-left-pad signature objects that do not match the length of the exponent `n` on a gpg rsa public key object before verification.
lukpueh
pushed a commit
to lukpueh/securesystemslib
that referenced
this pull request
Sep 4, 2019
It appears the specification for PKCSv1.5 doesn't say how long should a signature should be (i.e., should we zero-pad the signature or should we use the minimum number of bits required). In this case, signatures generated using gnupg would sometimes be 8*n bits shorter than the public key length, which would result in signatures that fail to verify due to missing leading zeroes (the leading zeroes existed at the bit level however). Zero-left-pad signature objects that do not match the length of the exponent `n` on a gpg rsa public key object before verification.
tanishqjasoria
added a commit
to tanishqjasoria/securesystemslib
that referenced
this pull request
Jan 28, 2020
Keeping the aggregate_test.py file as it was before secure-systems-lab#171, to keep the suppor to skipping test for HSM on Python 2
tanishqjasoria
pushed a commit
to tanishqjasoria/securesystemslib
that referenced
this pull request
Jan 30, 2020
It appears the specification for PKCSv1.5 doesn't say how long should a signature should be (i.e., should we zero-pad the signature or should we use the minimum number of bits required). In this case, signatures generated using gnupg would sometimes be 8*n bits shorter than the public key length, which would result in signatures that fail to verify due to missing leading zeroes (the leading zeroes existed at the bit level however). Zero-left-pad signature objects that do not match the length of the exponent `n` on a gpg rsa public key object before verification.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes issue #:
Motivated by theupdateframework/python-tuf#890
i.a. closes #71
Description of the changes being introduced by the pull request:
See commit messages for details.
Please verify and check that the pull request fulfills the following
requirements: