https://docs.pypi.org/about/security-and-internals/#reporting-security-vulnerabilities
Do not report security issues in public forums or issue trackers.
yeah we wouldn't want people to know about all the security issues with pypi now would we
Discussion
https://docs.pypi.org/about/security-and-internals/#reporting-security-vulnerabilities
Do not report security issues in public forums or issue trackers.
yeah we wouldn't want people to know about all the security issues with pypi now would we
@meejah one thing i found terribly fascinating too is that this is actually a major problem with git itself. there's absolutely no record of where a particular set of objects was fetched from or when that occurred, which is an extremely useful forensic feature in itself. but it's also especially problematic when commits can be easily backdated and when the primary key in the object database is SHA-1
@meejah in my theory of a flexible mirror-friendly filesystem, you use inodes (which are always opaque local indices, and must be translated whenever data is transferred e.g. over a network) as primary keys for file or directory entries. checksums don't need to come into play at all
@meejah one thing that current checksum technology cannot do is share tree structure. if only a single file in a subdirectory is modified, it generates a completely new top-level checksum, which you need to recursively extract from the database in order to forensically investigate. you should be able to describe a stable tree structure in a checksum tree object which can be sent over along with the data itself and can be efficiently patched onto another hash tree to represent changes without having to recompute the entire hash tree from the bottom up
@hipsterelectron Merkle trees, or maybe Prolly trees?
@hipsterelectron paging @shapr is this something prolly trees can do?
@meejah @hipsterelectron the Merkle search tree is almost exactly the same thing as a prolly tree