Using sha512 instead of md5 on python.org/downloads
Hi, I see md5 checksums at a release download page such as [1]. My idea is to switch to sha512 for a more reliable outcome. I'm no security expert, but AFAK md5 is generally believed to be unsafe, as it was repeatedly proven it can be vulnerable [2]. [1] https://www.python.org/downloads/release/python-371/ [2] https://en.wikipedia.org/wiki/MD5#Security -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok
On Fri, Dec 7, 2018 at 1:40 AM Antoine Pitrou <solipsis@pitrou.net> wrote:
More to the point: you're getting the hash from the same place as the binary. If one is vulnerable to modifications by attackers, both are. So it doesn't matter. The real defense most people are relying on is TLS. -- Devin
Would this change actually help people who need to use FIPS? Other than that this change would only decrease the already very small probability of a corrupted download hashing the same, which isn't a bad thing. If it could make some users' jobs easier, even if it by no means helps guaranteeing the authenticity of the downloaded file, it might be worth considering.
On Fri, 7 Dec 2018 06:49:59 -0800 Devin Jeanpierre <jeanpierreda@gmail.com> wrote:
If the site is vulnerable to modifications, then TLS doesn't help. Again: you must verify the GPG signatures (since they are produced by the release manager's private key, which is *not* stored on the python.org Web site). Regards Antoine.
On Fri, Dec 7, 2018 at 10:48 AM Antoine Pitrou <solipsis@pitrou.net> wrote:
This is missing the point. They were asking why not to use SHA512. The answer is that the hash does not provide any extra security. GPG is separate: even if there was no GPG signature, SHA512 would still not provide any extra security. That's why I said "more to the point". :P Nobody "must" verify the GPG signatures. TLS doesn't protect against everything, but neither does GPG. A naive user might just download a public GPG key from a compromised python.org and use it to verify the compromised release, see everything is "OK", and still be hosed. -- Devin
For this specific purpose, md5 is just as good as a proper hash. But all else being equal, it would still be better to use a proper hash, just so people don't have to go through the whole security analysis to check that. Of course all else isn't equal: switching from md5 to sha-whatever would require someone do the work. Is anyone volunteering? On Fri, Dec 7, 2018, 11:56 Devin Jeanpierre <jeanpierreda@gmail.com wrote:
On Fri, Dec 07, 2018 at 01:25:19PM -0800, Nathaniel Smith wrote:
I don't understand what you are trying to say here about "the whole security analysis" to check "that". What security analysis, and what is "that"? It seems to me that moving to a cryptographically-secure hash would give many people a false sense of security, that just because the hash matched, the download was not only not corrupted, but not compromised as well. For those two purposes: - testing for accidental corruption; - testing for deliberate compromise; md5 and sha512 are precisely equivalent: both are sufficient for the first, and useless for the second. But a crypto-hash can give a false sense of security. The original post in this thread is evidence of that. As such, I don't think we should move to anything stronger than md5. -- Steve
On Fri, Dec 7, 2018 at 3:38 PM Steven D'Aprano <steve@pearwood.info> wrote:
The analysis that people posted in this thread, demonstrating that for the particular purpose at hand, md5 and sha-whatever are equally useful.
If you're worried about giving people a false sense of security, I think it would be more effective to post a prominent notice or link describing how people should interpret the hashes. Maybe some people see md5 and think "ah-hah, this is their way of warning me that the hash is suitable for defending against accidental corruption but not malicious actors", but it must be a small minority :-). (That's certainly not what the OP thought.) Most people will just think we're fools who don't realize or care md5 is broken. Statistically, that's a pretty reasonable guess when you see someone using md5. -n -- Nathaniel J. Smith -- https://vorpus.org <http://vorpus.org>
On Fri, Dec 07, 2018 at 04:35:56PM -0800, Nathaniel Smith wrote:
Okay, so your position is that even though there's no actual increase in security from using sha512, we ought to use it so that people who don't know any better won't complain that we're using a "less secure" hash. Is that accurate? As security theatre goes, I guess its less harmful than most :-) [...]
I want to avoid encouraging a false sense of security. I'm not sure that we ought to extend that further to actively taking on the responsibility of teaching users about this. On the other hand, perhaps threads like this suggest that this is inevitable... on the gripping hand, many users won't read the notice regardless of what we do... How often does this issue come up? I'm not sure it is common enough to bother fixing, but others' judgement on that may differ.
I didn't think they would.
I don't think there's any way to know for sure, but I'd be shocked if "most people" even thought about the issue, or checked the hash, regardless of whether it is sha512, md5 or a CRC checksum. In my experience, browsers and downloaders like wget either download the data correctly, or they make it damn obvious that the download failed. YMMV. As for those who "think we're fools", that's not a reasonable guess by any means. Since we're not fools, and for the purposes we're using the hash there is no difference between md5 and sha512, such a guess would be a classic example of "a little knowledge is dangerous" and "not as clever or well-informed as you think you are" (that's a generic "you", not you personally). If they don't think we're fools for using md5, they'll probably think we're fools for some other reason. -- Steve
We already use SHA256 on PyPI. Many project in the world moving from md5 to SHA256. And at some time, SHA256 can be better than md5. When hash is delivered through other route than content, it's difficult to attack / easy to detect we're under attack. For example, sha256 is written in requirements.txt or Homebrew formula. When hash mismatch is happened, we can detect something go wrong. So it's worth to write stronger hash in such files. And if we use sha256 on download site, it's easy to check hash equality between formula and download site. If it's different, Homebrew or download site is under attack. So I think it's worth enough to moving to stronger and more used hash. (And by this reason, I prefer sha256 to sha512 for now.) -- INADA Naoki <songofacandy@gmail.com>
On Sat, Dec 08, 2018 at 11:05:43AM +0900, INADA Naoki wrote:
How easy is it to use sha256 on the major platforms, compared to md5? On Linux, it is just as easy: [steve@ando ~]$ md5sum x.py 7008dcaa07fd35917474835425c6151a x.py [steve@ando ~]$ sha256sum x.py 6730dbf2b5ea5c874e789a39532b0e544af18fbea3c680880b01c81b773eabe2 x.py but how about Windows and Mac users? Do those platforms provide a sha256 checksum utility? (Maybe we should provide both hashes.) -- Steve
On Windows 10 this works: c:Downloads> certutil -hashfile python-3.7.1-amd64.exe sha512 SHA512 hash of python-3.7.1-amd64.exe: 7dec6362c402b38a9c29b85b204398d7d3fd19509f05279bf713a92abe5b485d4c0c4b175c4edb47f81fd800a599bc2283642a8f0c666edd9e971b5cedf18041 CertUtil: -hashfile command completed successfully. Barry
On Sun, 9 Dec 2018 at 15:13, Barry Scott <barry@barrys-emacs.org> wrote:
In Powershell, there's Get-FileHash python-3.7.1-amd64.exe -Algorithm sha512. The default algorithm is SHA256. On Windows, it's surprisingly often the case that things which traditionally fell under "Windows users probably don't have a tool to do that" are available in Powershell. None of which is that relevant, the fact still remains that no matter what algorithm is used, the hash only has limited value as a security measure. Paul
That’s true, but it does show that switching from MD5 to SHA2 doesn’t make it harder to validate the checksum on major platforms. I don’t have a strong opinion either way, I’m slightly in favour of switching to the same algorithm as used on PyPI to be consistent within these PSF properties. BTW. I wonder how many actually verify these checksums, I personally generally assume that HTTPS downloads are reliable enough and don’t verify checksums unless I do the download in an automation pipeline. Ronald
On Mon, 10 Dec 2018 07:31:44 +0100 Ronald Oussoren via Python-ideas <python-ideas@python.org> wrote:
Ah, the automation use case is a good point in favor of stronger hashes. You may have checked the initial download hash and then use it in a script to make sure later downloads haven't been tempered with. Regards Antoine.
On Sun, Dec 9, 2018 at 10:32 PM Ronald Oussoren via Python-ideas < python-ideas@python.org> wrote:
BTW. I wonder how many actually verify these checksums,
Hardly anyone -- most of us verify the download by trying to use it :-) Which doesn't mean that we shouldn't have it -- but it will indeed make very little difference to the vast majority of users -- and those that do check it are generally pretty sophisticated -- shouldn't be hard to use a different hash algorithm. Though people would have to update their workflows, which could be annoying. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On Fri, Dec 7, 2018 at 3:38 PM Steven D'Aprano <steve@pearwood.info> wrote:
If we switched to sha2+ or listed 8 different hashes at once in the announcement text so that nobody can find the actual link content, we'd stop having people pipe up and complain that we used md5 for something. Less mailing list threads like this one seems like a benefit. :P Debian provides all of the popular FIPS hashes, in side files, so people can use whatever floats their boat for a content integrity check: https://cdimage.debian.org/debian-cd/current/ppc64el/iso-cd/
As to windows and mac providing hashing functions on the command line, nope. assume nothing is provided. On linux my fingers would use "openssl hashname" rather than *sum commands. But none of those are ever required to be installed by anything. The only people who ever check hashes are those who already know what tools to use and how. Some could ironically install the downloaded python and use it to check its own hash. None of that is our problem. -gps
On Fri, Dec 07, 2018 at 08:55:53PM -0800, "Gregory P. Smith" <greg@krypto.org> wrote:
And they protect the hash files by signing them instead of signing CDs/DVDs.
-gps
Oleg. -- Oleg Broytman https://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
On 08/12/2018 05.55, Gregory P. Smith wrote:
By the way it's a common misunderstanding that FIPS forbids MD5 in general. FIPS is more complicated than black and white lists of algorithms. FIPS also takes into account how an algorithm is used. For example and if I recall correctly, AES-GCM is only allowed in network communication protocols but not for persistent storage. Simply speaking: In FIPS mode, MD5 is still allowed in **non-security contexts**. You cannot use MD5 to make any security claims like file integrity. However you are still allowed to use MD5 as non-secure hash function to detect file corruption. The design and documentation must clearly state that you are only guarding against accidental file corruption caused by network or hardware issue, but as protection against a malicious attacker. Christian
Dne 07. 12. 18 v 15:49 Devin Jeanpierre napsal(a):
Yes I really on TLS, no I'm not getting the archive necessarily from python.org. I might get it from a 3rd parrty that claims it's genuine. Such party might be a Linux distro or another package manager (e.g. homebrew). I can of course use GPG to verify it, but for quick check a sha512 sum works for me, while md5 not so much. In Fedora, we use sha512 checksums [1]. In homebrew they use sha256 [2]. [1] https://src.fedoraproject.org/rpms/python3/blob/master/f/sources [2] https://github.com/Homebrew/homebrew-core/blob/master/Formula/python.rb -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok
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.
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 < bernardo@bernardosulzbach.com> escreveu:
-- Marcos Eliziário Santos mobile/whatsapp/telegram: +55(21) 9-8027-0156 skype: marcos.eliziario@gmail.com linked-in : https://www.linkedin.com/in/eliziario/
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.eliziario@gmail.com> escreveu:
-- Marcos Eliziário Santos mobile/whatsapp/telegram: +55(21) 9-8027-0156 skype: marcos.eliziario@gmail.com linked-in : https://www.linkedin.com/in/eliziario/
On Fri, Dec 7, 2018 at 1:40 AM Antoine Pitrou <solipsis@pitrou.net> wrote:
More to the point: you're getting the hash from the same place as the binary. If one is vulnerable to modifications by attackers, both are. So it doesn't matter. The real defense most people are relying on is TLS. -- Devin
Would this change actually help people who need to use FIPS? Other than that this change would only decrease the already very small probability of a corrupted download hashing the same, which isn't a bad thing. If it could make some users' jobs easier, even if it by no means helps guaranteeing the authenticity of the downloaded file, it might be worth considering.
On Fri, 7 Dec 2018 06:49:59 -0800 Devin Jeanpierre <jeanpierreda@gmail.com> wrote:
If the site is vulnerable to modifications, then TLS doesn't help. Again: you must verify the GPG signatures (since they are produced by the release manager's private key, which is *not* stored on the python.org Web site). Regards Antoine.
On Fri, Dec 7, 2018 at 10:48 AM Antoine Pitrou <solipsis@pitrou.net> wrote:
This is missing the point. They were asking why not to use SHA512. The answer is that the hash does not provide any extra security. GPG is separate: even if there was no GPG signature, SHA512 would still not provide any extra security. That's why I said "more to the point". :P Nobody "must" verify the GPG signatures. TLS doesn't protect against everything, but neither does GPG. A naive user might just download a public GPG key from a compromised python.org and use it to verify the compromised release, see everything is "OK", and still be hosed. -- Devin
For this specific purpose, md5 is just as good as a proper hash. But all else being equal, it would still be better to use a proper hash, just so people don't have to go through the whole security analysis to check that. Of course all else isn't equal: switching from md5 to sha-whatever would require someone do the work. Is anyone volunteering? On Fri, Dec 7, 2018, 11:56 Devin Jeanpierre <jeanpierreda@gmail.com wrote:
On Fri, Dec 07, 2018 at 01:25:19PM -0800, Nathaniel Smith wrote:
I don't understand what you are trying to say here about "the whole security analysis" to check "that". What security analysis, and what is "that"? It seems to me that moving to a cryptographically-secure hash would give many people a false sense of security, that just because the hash matched, the download was not only not corrupted, but not compromised as well. For those two purposes: - testing for accidental corruption; - testing for deliberate compromise; md5 and sha512 are precisely equivalent: both are sufficient for the first, and useless for the second. But a crypto-hash can give a false sense of security. The original post in this thread is evidence of that. As such, I don't think we should move to anything stronger than md5. -- Steve
On Fri, Dec 7, 2018 at 3:38 PM Steven D'Aprano <steve@pearwood.info> wrote:
The analysis that people posted in this thread, demonstrating that for the particular purpose at hand, md5 and sha-whatever are equally useful.
If you're worried about giving people a false sense of security, I think it would be more effective to post a prominent notice or link describing how people should interpret the hashes. Maybe some people see md5 and think "ah-hah, this is their way of warning me that the hash is suitable for defending against accidental corruption but not malicious actors", but it must be a small minority :-). (That's certainly not what the OP thought.) Most people will just think we're fools who don't realize or care md5 is broken. Statistically, that's a pretty reasonable guess when you see someone using md5. -n -- Nathaniel J. Smith -- https://vorpus.org <http://vorpus.org>
On Fri, Dec 07, 2018 at 04:35:56PM -0800, Nathaniel Smith wrote:
Okay, so your position is that even though there's no actual increase in security from using sha512, we ought to use it so that people who don't know any better won't complain that we're using a "less secure" hash. Is that accurate? As security theatre goes, I guess its less harmful than most :-) [...]
I want to avoid encouraging a false sense of security. I'm not sure that we ought to extend that further to actively taking on the responsibility of teaching users about this. On the other hand, perhaps threads like this suggest that this is inevitable... on the gripping hand, many users won't read the notice regardless of what we do... How often does this issue come up? I'm not sure it is common enough to bother fixing, but others' judgement on that may differ.
I didn't think they would.
I don't think there's any way to know for sure, but I'd be shocked if "most people" even thought about the issue, or checked the hash, regardless of whether it is sha512, md5 or a CRC checksum. In my experience, browsers and downloaders like wget either download the data correctly, or they make it damn obvious that the download failed. YMMV. As for those who "think we're fools", that's not a reasonable guess by any means. Since we're not fools, and for the purposes we're using the hash there is no difference between md5 and sha512, such a guess would be a classic example of "a little knowledge is dangerous" and "not as clever or well-informed as you think you are" (that's a generic "you", not you personally). If they don't think we're fools for using md5, they'll probably think we're fools for some other reason. -- Steve
We already use SHA256 on PyPI. Many project in the world moving from md5 to SHA256. And at some time, SHA256 can be better than md5. When hash is delivered through other route than content, it's difficult to attack / easy to detect we're under attack. For example, sha256 is written in requirements.txt or Homebrew formula. When hash mismatch is happened, we can detect something go wrong. So it's worth to write stronger hash in such files. And if we use sha256 on download site, it's easy to check hash equality between formula and download site. If it's different, Homebrew or download site is under attack. So I think it's worth enough to moving to stronger and more used hash. (And by this reason, I prefer sha256 to sha512 for now.) -- INADA Naoki <songofacandy@gmail.com>
On Sat, Dec 08, 2018 at 11:05:43AM +0900, INADA Naoki wrote:
How easy is it to use sha256 on the major platforms, compared to md5? On Linux, it is just as easy: [steve@ando ~]$ md5sum x.py 7008dcaa07fd35917474835425c6151a x.py [steve@ando ~]$ sha256sum x.py 6730dbf2b5ea5c874e789a39532b0e544af18fbea3c680880b01c81b773eabe2 x.py but how about Windows and Mac users? Do those platforms provide a sha256 checksum utility? (Maybe we should provide both hashes.) -- Steve
On Windows 10 this works: c:Downloads> certutil -hashfile python-3.7.1-amd64.exe sha512 SHA512 hash of python-3.7.1-amd64.exe: 7dec6362c402b38a9c29b85b204398d7d3fd19509f05279bf713a92abe5b485d4c0c4b175c4edb47f81fd800a599bc2283642a8f0c666edd9e971b5cedf18041 CertUtil: -hashfile command completed successfully. Barry
On Sun, 9 Dec 2018 at 15:13, Barry Scott <barry@barrys-emacs.org> wrote:
In Powershell, there's Get-FileHash python-3.7.1-amd64.exe -Algorithm sha512. The default algorithm is SHA256. On Windows, it's surprisingly often the case that things which traditionally fell under "Windows users probably don't have a tool to do that" are available in Powershell. None of which is that relevant, the fact still remains that no matter what algorithm is used, the hash only has limited value as a security measure. Paul
That’s true, but it does show that switching from MD5 to SHA2 doesn’t make it harder to validate the checksum on major platforms. I don’t have a strong opinion either way, I’m slightly in favour of switching to the same algorithm as used on PyPI to be consistent within these PSF properties. BTW. I wonder how many actually verify these checksums, I personally generally assume that HTTPS downloads are reliable enough and don’t verify checksums unless I do the download in an automation pipeline. Ronald
On Mon, 10 Dec 2018 07:31:44 +0100 Ronald Oussoren via Python-ideas <python-ideas@python.org> wrote:
Ah, the automation use case is a good point in favor of stronger hashes. You may have checked the initial download hash and then use it in a script to make sure later downloads haven't been tempered with. Regards Antoine.
On Sun, Dec 9, 2018 at 10:32 PM Ronald Oussoren via Python-ideas < python-ideas@python.org> wrote:
BTW. I wonder how many actually verify these checksums,
Hardly anyone -- most of us verify the download by trying to use it :-) Which doesn't mean that we shouldn't have it -- but it will indeed make very little difference to the vast majority of users -- and those that do check it are generally pretty sophisticated -- shouldn't be hard to use a different hash algorithm. Though people would have to update their workflows, which could be annoying. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On Fri, Dec 7, 2018 at 3:38 PM Steven D'Aprano <steve@pearwood.info> wrote:
If we switched to sha2+ or listed 8 different hashes at once in the announcement text so that nobody can find the actual link content, we'd stop having people pipe up and complain that we used md5 for something. Less mailing list threads like this one seems like a benefit. :P Debian provides all of the popular FIPS hashes, in side files, so people can use whatever floats their boat for a content integrity check: https://cdimage.debian.org/debian-cd/current/ppc64el/iso-cd/
As to windows and mac providing hashing functions on the command line, nope. assume nothing is provided. On linux my fingers would use "openssl hashname" rather than *sum commands. But none of those are ever required to be installed by anything. The only people who ever check hashes are those who already know what tools to use and how. Some could ironically install the downloaded python and use it to check its own hash. None of that is our problem. -gps
On Fri, Dec 07, 2018 at 08:55:53PM -0800, "Gregory P. Smith" <greg@krypto.org> wrote:
And they protect the hash files by signing them instead of signing CDs/DVDs.
-gps
Oleg. -- Oleg Broytman https://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
On 08/12/2018 05.55, Gregory P. Smith wrote:
By the way it's a common misunderstanding that FIPS forbids MD5 in general. FIPS is more complicated than black and white lists of algorithms. FIPS also takes into account how an algorithm is used. For example and if I recall correctly, AES-GCM is only allowed in network communication protocols but not for persistent storage. Simply speaking: In FIPS mode, MD5 is still allowed in **non-security contexts**. You cannot use MD5 to make any security claims like file integrity. However you are still allowed to use MD5 as non-secure hash function to detect file corruption. The design and documentation must clearly state that you are only guarding against accidental file corruption caused by network or hardware issue, but as protection against a malicious attacker. Christian
Dne 07. 12. 18 v 15:49 Devin Jeanpierre napsal(a):
Yes I really on TLS, no I'm not getting the archive necessarily from python.org. I might get it from a 3rd parrty that claims it's genuine. Such party might be a Linux distro or another package manager (e.g. homebrew). I can of course use GPG to verify it, but for quick check a sha512 sum works for me, while md5 not so much. In Fedora, we use sha512 checksums [1]. In homebrew they use sha256 [2]. [1] https://src.fedoraproject.org/rpms/python3/blob/master/f/sources [2] https://github.com/Homebrew/homebrew-core/blob/master/Formula/python.rb -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok
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.
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 < bernardo@bernardosulzbach.com> escreveu:
-- Marcos Eliziário Santos mobile/whatsapp/telegram: +55(21) 9-8027-0156 skype: marcos.eliziario@gmail.com linked-in : https://www.linkedin.com/in/eliziario/
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.eliziario@gmail.com> escreveu:
-- Marcos Eliziário Santos mobile/whatsapp/telegram: +55(21) 9-8027-0156 skype: marcos.eliziario@gmail.com linked-in : https://www.linkedin.com/in/eliziario/
participants (16)
-
Antoine Pitrou -
Barry Scott -
Bernardo Sulzbach -
Chris Barker -
Christian Heimes -
Devin Jeanpierre -
Gregory P. Smith -
INADA Naoki -
Marcos Eliziario -
Miro Hrončok -
Nathaniel Smith -
Nick Timkovich -
Oleg Broytman -
Paul Moore -
Ronald Oussoren -
Steven D'Aprano