theupdateframework / pep-on-pypi-with-tuf Goto Github PK

Use cases like the one in this PEP (where a consistent view of a changing filesystem are needed) are exactly why storage technologies like "LVM snapshots" exist: http://www.tldp.org/HOWTO/LVM-HOWTO/snapshots_backup.html

This means the PEP needs to make a much stronger case for why it proposes to reinvent snapshot creation at the web application layer rather than simply requiring the use of an appropriate storage layer (like LVM) that supports fast and cheap volume snapshots.

We should close and mark this repo as a read-only archive, no?

Currently, we recommend that hash collisions can somehow be automatically handled. Since cryptographic hash algorithms should make hash collisions extremely unlikely, it is safer and acceptable to simply require the server to report an error.

Currently, a repository re-signed with the same key duplicates the key in root.txt & targets.txt. The tools should detect if the key is the same when signing and simply update the file instead of adding the duplicate key.

In this section:

"Although the merge cost may be amortized over time, this scheme is not conceptually si"

..."si" what, man? Don't leave us hanging there!

As @JustinCappos observed, the unclaimed role keys may as well be offline (but the keys to the delegated unclaimed bin roles will still be online). There is no real security difference (because attackers who compromise the repository can still mess with the delegated unclaimed bin roles), but there is no harm in keeping it offline (at least the attackers cannot add, update or remove a delegated unclaimed bin role).