ff8819577b
secure-systems-lab/securesystemslib#288 changes the key generation interface functions in such a way that it is clear if a call opens a blocking prompt, or writes the key unencrypted. To do this two functions are added per key type: - `generate_and_write_*_keypair_with_prompt` - `generate_and_write_unencrypted_*_keypair` The default `generate_and_write_*_keypair` function now only allows encrypted keys and only using a passed password. This respects the principle of secure defaults and least surprise. sslib#288 furthermore adds a protected `_generate_and_write_*_keypair`, which is not exposed publicly because it does not encrypt by default, but is more flexible and thus convenient e.g. to consume all arguments from a key generation command line tool such as 'repo.py'. This commit adds the new public functions to the tuf namespace and adopts their usage accordingly. NOTE regarding repo.py: This commit does not fix any problematic password behavior of 'repo.py' like default passwords, etc. (see #881). It only adopts the sslib#288 changes to maintain the current behvior, plus removing one glaringly obsolete password prompt. NOTE regarding key import: The securesystemslib private key import functions were also changed to no longer auto-prompt for decryption passwords , TUF, however, only exposes custom wrappers (see repository_lib) that do auto-prompt. sslib#288 changes to the prompt texts are nevertheless propagated to tuf and reflected in this commit. Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu> |
||
|---|---|---|
| .. | ||
| client | ||
| keystore | ||
| project | ||
| repository | ||
| generate.py | ||
| generate_project_data.py | ||
| map.json | ||
| README.md | ||
Unit and integration testing
Running the tests
The unit and integration tests can be executed by invoking tox from any
path under the project directory.
$ tox
Or by invoking aggregate_tests.py from the
tests
directory.
$ python aggregate_tests.py
Note: integration tests end in _integration.py.
If you wish to run a particular unit test, navigate to the tests directory and run that specific unit test. For example:
$ python test_updater.py
It it also possible to run the test cases of a unit test. For instance:
$ python -m unittest test_updater.TestMultiRepoUpdater.test_get_one_valid_targetinfo
Setup
The unit and integration tests operate on static metadata available in the repository_data directory. Before running the tests, static metadata is first copied to temporary directories and modified, as needed, by the tests.
The test modules typically spawn HTTP(S) servers that serve metadata and target files for the unit tests. The map file specifies the location of the test repositories and other properties. For specific targets and metadata provided by the tests repositories, please inspect their respective metadata.