If you follow the instructions we provide for our contributors in
docs/CONTRIBUTORS.rst your sys.path (used to search for imports)
will put securesystemlib project directory first and tuf directory
second.
This creates a problem with imports from tuf modules because we can
import the wrong file or on relative imports (as currently we
use in the tests when we import utils), the imports cannot be resolved.
If we change the installation order, then tuf directory will be the
first in the import resolution path and those problems will be fixed.
PS: I want to express my gratitude towards Jussi who helped me find
this problem.
Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
Replace mentions of travis/appveyor with GitHub Actions in
governance (contribution) and readme (badges) documents.
Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>
Use Google style guide with refinements, because the Google style
guide is a comprehensive, well-established style guide that is
mostly based on PEP-8 and was accepted by everyone on the TUF team.
There is no need to replicate these recommendations. However, we do
provide a very slim document with additional refinements, in order
to emphasize on items the we consider especially important, want to
be handled differently, or in one specific way, where the Google
guide would allow multiple.
Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>
Co-authored-by: Joshua Lock <jlock@vmware.com>
Add MADR that justifies why we want to add custom classes for
complex tuf metadata attributes.
Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>
Describe pros of developing TUF 1.0.0 in a subdirectory
of the current implementation against the rest of the options.
Signed-off-by: Teodora Sechkova <tsechkova@vmware.com>
Document the outcome of #1126 to develop TUF 1.0.0
in a subdirectory of the current TUF implementation.
Signed-off-by: Teodora Sechkova <tsechkova@vmware.com>
Update badge URL in readme after migrating from travis-ci.org to
travis-ci.com, due to brownout on the former.
Migration was performed via Travis Web UI:
https://docs.travis-ci.com/user/migrate/open-source-repository-migration
NOTE: This is a quick fix to speed up Travis builds until we switch
to GitHub Actions (#1195)
Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>
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>
Provide additional context to clarify where we expect Python 3.6+ to be used
exclusively (new modules) and link to other discussions around the future of
Python 2.7 supporting code.
Signed-off-by: Joshua Lock <jlock@vmware.com>
In order to make decisions about the code and the design explicit and easier
to reference in future we want to record significant architectural decisions.
This commit introduces docs/adr with a template Architectural Decision Record
and index using the [MADR](https://adr.github.io/madr/) format.
It also adds ADR 0000 to document the decisions to use MADR.
Fixes#1141
Signed-off-by: Joshua Lock <jlock@vmware.com>
* Strongly encourage the reader to use Python 3 for creating release
artefacts
* Recommend cleaning the tuf directory before creating the release
Signed-off-by: Joshua Lock <jlock@vmware.com>
Consistently enclose filenames referred to througout the release process in
backticks to ensure they are rendered in the code style.
Signed-off-by: Joshua Lock <jlock@vmware.com>
Ensure someone following the release process pushes the tag they create
and include a tag message matching the common form, rather than requiring
somebody following the steps to figure out what to enter into their editor
Signed-off-by: Joshua Lock <jlock@vmware.com>
For some reason the first level 3 heading 'Added' was not rendering
correctly. The level 2 heading for 'Fixed' should be level 3.
Signed-off-by: Joshua Lock <jlock@vmware.com>
* Remove reference to deprecated settings
* Mention that the tutorial expects the dependencies and link to
instructions
Signed-off-by: Jussi Kukkonen <jkukkonen@vmware.com>
Lot of changes in 7 lines:
* PyCrypto is no longer an option: remove mention of it
* RSA-PSS wiki page now redirects to a fairly useless stub: replace it
with the RFC (it's not light reading but better than nothing)
* Mention ECDSA
* Remove mention of json for RSA keys: that does not seem to be true
Signed-off-by: Jussi Kukkonen <jkukkonen@vmware.com>
Improve the coding style in TUTORIAL in the case
where absolute path to a file is needed to perform file system
access and at the same time is rejected by Targets methods.
Signed-off-by: Teodora Sechkova <tsechkova@vmware.com>
Replace the absolute paths returned by get_filepaths_in_directory()
in the tutorial with a hard-coded list of relaive filepaths since
add_target(s) and delegate() methods raise excception on absolute
paths.
Remove an obsolete warning about path pattern's location.
Signed-off-by: Teodora Sechkova <tsechkova@vmware.com>
Remove link to incomplete and severely outdated
client_setup_and_repository_example.md in client section of
TUTORIAL.md.
Instead we should link (or move the entire client tutorial part) to
tuf/client/README.md, which is more comprehensive and less outdated
than above document (see #808).
Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>
In tutorial code snippet fix a call to repository.mark_dirty that
passes a non-existing bin role name raising:
"tuf.exceptions.UnknownRoleError: Role name does not exist: 90-7"
Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>
colorama is now an optional dependency for securesystemslib, and so isn't
installed by default. However, the repo script uses colorama and doesn't
handle its absence - add securesystemslib[colors] to ensure colorama is
installed.
Signed-off-by: Joshua Lock <jlock@vmware.com>
* Use suffixed instead of prefixed sub-requirements files to group
them alphabetically in the file tree.
* Layer requirements files akin to the in-toto project
(see in-toto/in-toto#294). The hierarchy is:
- *requirements.in*
tuf runtime requirements, including optional requirements
(pynacl and cyrptography)
- *requirements-pinned.txt*
pinned tuf runtime requirements, including optional
and transitive (1 level deep) requirements and their hashes.
The file is generated semi-automatically using pip-compile
and a bash script (see document header), based off of
requirements.in, combining requirements from all supported
Python versions.
This file should be auto-updated, by e.g. dependabot, and be used
for ci/cd tests, to catch issues with new dependencies.
- *requirements-test.txt*
additional test runtime requirements
- *requirements-tox.txt*
combines requirements.txt, requirements-test.txt and additional
test tools (for linting and coverage), i.e. everything that is
needed in each tox environment to run the tests.
- *requirements-dev.txt*
lists tox for local development and testing, and also
requirements-tox.txt and tuf in editable mode to run
the test suite or individual tests directly.
- *requirements.txt*
requirements-pinned.txt with the hashes of the dependencies
as reported by pip at the time of creating the file.
NOTE: this is not used for testing or dev-install because pip
doesn't allow mixed (with and without hashes) installations.
This file should also be auto-updated, by e.g. dependabot.
* Removes an obsolete version constraint on coverage
Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>
TUF does not reliably mark roles as dirty whose metadata needs
to be re-generated.
Only roles that have changed are marked as dirty, but sometimes
roles metadata needs to be updated, although the role wasn't
changed directly (see #958).
Furthermore, the tutorial assumes at one point that the reader
leaves and re-enter the interpreter session, being forced to reload the
signing keys, roles that later need to be re-written, are marked as
dirty. If the reader does not leave the interpreter, the roles are
not marked as dirty (see #964).
To not confuse the reader with flawed state-keeping, and to never
write an inconsistent repository to disk, the tutorial lets the
reader explicitly mark all roles that need to be re-written as
"dirty".
This can be changed once above issues are fixed.
Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>
Explain and show output of delegate_hashed_bins() function call in
tutorial snippet.
Also update the subsequent comment for better continuity.
Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>
- Ask the reader to ignore a misleading warning about the location of
a delegation path pattern.
The comment may be removed when fixing the warning in
theupdateframework/tuf#963.
- Comment out text that has become obsolete when commenting out
the "Revoke Delegated Role" section (in an earlier commit).
Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>