A Hash is surely useful in the context of locking versions of software packages in Pipfile.lock because we tell us that the code we are downloading has not changed since the first we saw this particular version of the package, but only a signature scheme tell us with a reasonable degree of certainty (though, not absolute) that this particular version of the code came from who it claims to have came from.
If an attacker is able to hijack the github repository from a project and it's website, specially on low activity projects, nothing would prevent them from releasing a rogue version, and people downloading it and using it for some time until the rightful maintainers of said project are able to take back control of it. Signing of course is as secure as the ability of said project maintainers to keep their private keys safe. But while we know that nothing can be made 100% secure, a culture that relies on signatures is inherently more secure than relying only on hashes, no matter how cryptographically strong they may be. Hashes tell us that the code we've download we have is the same as other blob of code stored somewhere that for whatever reasons we trust. PGP tells us that there is a high probability, assuming the private keys haven't been compromised, and that a lot of people agrees that the public key we have came from the right person or organization, that this blob of code came from who it says it came from. Em seg, 10 de dez de 2018 às 13:05, Marcos Eliziario < marcos.elizia...@gmail.com> escreveu: > My two cents. > Automation tools should check the PGP signature. The public keys should be > obtained once via https from an odd number of different trustworthy sources > from a set of well know domains that use DNSSEC. Users should be advised to > check the certificate chain from those domains at the first time those keys > are downloaded and explicitly agree. This is a more secure schema than > simply relying on a checksum that you've got from the same site you've used > to download the code. > Moving from MD5 from SHA obscures this, by making people believe that this > hash should be used for anything more than checking for file corruption. > > Em seg, 10 de dez de 2018 às 12:45, Bernardo Sulzbach < > berna...@bernardosulzbach.com> escreveu: > >> If the discussion gets to which SHA-2 should be used, I would like to >> point out that SHA-512 is not only twice the width of SHA-256 but also >> faster to compute (anecdotally) on most 64-bit platforms. >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas@python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > > > -- > Marcos Eliziário Santos > mobile/whatsapp/telegram: +55(21) 9-8027-0156 > skype: marcos.elizia...@gmail.com > linked-in : https://www.linkedin.com/in/eliziario/ > > -- Marcos Eliziário Santos mobile/whatsapp/telegram: +55(21) 9-8027-0156 skype: marcos.elizia...@gmail.com linked-in : https://www.linkedin.com/in/eliziario/
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
