[arch-general] Stronger Hashes for PKGBUILDs
https://lists.archlinux.org/pipermail/arch-dev-public/2016-November/028492.h... i have a few things to add to this. the message digests at the download page for the .iso file, must change to sha256 and sha512 ones, or to a sha512 one. if an upstream does not sign the files, does not have https enabled, and/or refuses to take security and privacy seriously, sha512 must be used in the PKGBUILD files. in the cases of upstreams that use md5 and/or sha1 message digests, those will be added in a second ALGOsums= line under the sha512sums= line. if they use md5 and sha1, then sha1sums must be used for the second ALGOsums= line.
if an upstream does not sign the files, does not have https enabled, and/or refuses to take security and privacy seriously, sha512 must be used in the PKGBUILD files.
Then 1) you could argue our using SHA512 is meaningless, but 2) it doesn't matter; we should still be doing the Right™ thing. -Chris Tonkinson
Am 03.12.2016 um 06:27 schrieb fnodeuser:
if an upstream does not sign the files, does not have https enabled, and/or refuses to take security and privacy seriously, sha512 must be used in the PKGBUILD files.
But using and hash value without the possibility to verify the hashed files, adds no security. It provides a false sense of security instead. I agree that we should use a strong hash by default where it makes sense. But in the absense ob effective validation of upstream packages, this is meaningless.
I agree that we should use a strong hash by default where it makes sense. But in the absense ob effective validation of upstream packages, this is meaningless.
It would at least indicate that the source file has been tampered with in some way. Even though there would be no way to know the "correct" checksum.
Am 03.12.2016 um 20:07 schrieb Maxwell Anselm via arch-general:
I agree that we should use a strong hash by default where it makes sense. But in the absense ob effective validation of upstream packages, this is meaningless.
It would at least indicate that the source file has been tampered with in some way. Even though there would be no way to know the "correct" checksum.
You mean the source files that you downloaded and then hashed...
You mean the source files that you downloaded and then hashed...
Yes. If the source files are being modified via a MITM attack (which is trivial if the host uses HTTP) the checksum is still useful.
Am 04.12.2016 um 05:37 schrieb Maxwell Anselm via arch-general:
You mean the source files that you downloaded and then hashed...
Yes. If the source files are being modified via a MITM attack (which is trivial if the host uses HTTP) the checksum is still useful.
The checksum that was created by zou after downloading the compromised source file. I don't see how that is useful. The checksum will always be correct and validate nothing
On 12/05/2016 02:56 PM, sivmu wrote:
Am 04.12.2016 um 05:37 schrieb Maxwell Anselm via arch-general:
You mean the source files that you downloaded and then hashed...
Yes. If the source files are being modified via a MITM attack (which is trivial if the host uses HTTP) the checksum is still useful.
The checksum that was created by zou after downloading the compromised source file.
I don't see how that is useful. The checksum will always be correct and validate nothing
Possibilities 1) MITM attack between end-user and internet. PKGBUILD is downloaded over HTTPS, but source files are downloaded over HTTP. MITM attack cannot manipulate the PKGBUILD, but can fake the sources. AUR maintainer was probably not under the same MITM. ;) 2) Source website hacked. AUR maintainer blindly generates checksums from the compromised source, nothing else matters because everyone is screwed. 3) Source website hacked, after the AUR maintainer generates checksums from the original uncompromised source. ... In cases #1 & #3 (and #3 is only by accident) stronger checksums *will* help. Those are also the cases where it is more likely the maintainer is security-conscious and checks the sources before generating the manually-upgraded-to-sha256-or-higher checksums. ... Context is everything. I am sure many people who read this thread are not aware of the following forum thread in which the matter was extensively discussed: https://bbs.archlinux.org/viewtopic.php?id=217588 Allan has already declared that he will not change the default makepkg.conf, on the grounds that #2 is the most likely scenario for people getting malicious packages. He also wants everyone to know that updpkgsums and makepkg are perfectly okay with maintainers changing the defaults, people who don't know there are defaults to change are probably not your best bet security-wise, and the only real security is either PGP or strong checksums posted by upstream on a second website. Also, that changing the defaults will encourage a false sense of security when people think that checksums have any validity in authentication. Personally, I want the defaults changed because of #1 & #3, but it doesn't seem that will happen *as a matter of principle* so I guess everyone can continue bikeshedding here. Or in arch-dev-public. (Though having a TU take up the fight is indeed somewhat more useful than random users, so who knows?) -- Eli Schwartz
Allan has already declared that he will not change the default makepkg.conf, on the grounds that #2 is the most likely scenario for people getting malicious packages. He also wants everyone to know that updpkgsums and makepkg are perfectly okay with maintainers changing the defaults, people who don't know there are defaults to change are probably not your best bet security-wise, and the only real security is either PGP or strong checksums posted by upstream on a second website. Also, that changing the defaults will encourage a false sense of security when people think that checksums have any validity in authentication.
The only change I can think of would be some way for the PKGBUILD to distinguish between "official" checksums (to defend against all cases) and "unofficial" checksums (to defend against #1 and #3). But that's a matter for arch-dev-public.
Am 05.12.2016 um 21:50 schrieb Eli Schwartz via arch-general:
On 12/05/2016 02:56 PM, sivmu wrote:
Am 04.12.2016 um 05:37 schrieb Maxwell Anselm via arch-general:
You mean the source files that you downloaded and then hashed...
Yes. If the source files are being modified via a MITM attack (which is trivial if the host uses HTTP) the checksum is still useful.
The checksum that was created by zou after downloading the compromised source file.
I don't see how that is useful. The checksum will always be correct and validate nothing
Possibilities
1) MITM attack between end-user and internet. PKGBUILD is downloaded over HTTPS, but source files are downloaded over HTTP. MITM attack cannot manipulate the PKGBUILD, but can fake the sources.
AUR maintainer was probably not under the same MITM. ;)
Why apply this only to AUR? The same is true for the regular repositories, but in that case you only need to MITM the maintainer and the checksums will not help. But yes for AUR this can help.
2) Source website hacked. AUR maintainer blindly generates checksums from the compromised source, nothing else matters because everyone is screwed.
Except if pgp signatures are provided by upstream und used in the PKGBUILD
3) Source website hacked, after the AUR maintainer generates checksums from the original uncompromised source.
This use case is valid.
...
In cases #1 & #3 (and #3 is only by accident) stronger checksums *will* help. Those are also the cases where it is more likely the maintainer is security-conscious and checks the sources before generating the manually-upgraded-to-sha256-or-higher checksums.
...
Context is everything. I am sure many people who read this thread are not aware of the following forum thread in which the matter was extensively discussed: https://bbs.archlinux.org/viewtopic.php?id=217588
Allan has already declared that he will not change the default makepkg.conf, on the grounds that #2 is the most likely scenario for people getting malicious packages. He also wants everyone to know that updpkgsums and makepkg are perfectly okay with maintainers changing the defaults, people who don't know there are defaults to change are probably not your best bet security-wise, and the only real security is either PGP or strong checksums posted by upstream on a second website. Also, that changing the defaults will encourage a false sense of security when people think that checksums have any validity in authentication.
Personally, I want the defaults changed because of #1 & #3, but it doesn't seem that will happen *as a matter of principle* so I guess everyone can continue bikeshedding here. Or in arch-dev-public. (Though having a TU take up the fight is indeed somewhat more useful than random users, so who knows?)
One valid reason to change the default checksum in general to a stronger algo, would be to prevent maintainer from using md5 as a security checksum. It is currently used for error detection during download. But using a strong hash is only really useful when there is a way to verify it. e.g. by pgp signatures or at least checksums on a https site. So if there is a way to verify upstream packages, using md5 inside PKGBUILD is bad. If there is no way to verify the upstream packages, using a stronger hash will provide a false sense of security. And thats what many seem to use it for. Thats partly why Allan won't change the default (if I understood him correctly) I my opinion, the way to solve this is to change the default md5 checksum to a different weaker one, preferably alias it to make sure it is understood as a error detection algorithmus. That way maintainers will understand that there is no verification of upstream packages by default and that they need to take care of that themselfs. The second change needed would be to strongly encourage maintainers to use pgp validation if available or to use strong checksum after getting packages over https. A LOT of packages do not use pgp validation even though upstream provides signatures. That is the real issue here. Let me say this again: everyone who is responsible for arch packages needs to be clearly advised to use all available methods to effectively verify upstream source files. Using a strong hash by default won't do that.
On 12/05/2016 05:25 PM, sivmu wrote:
A LOT of packages do not use pgp validation even though upstream provides signatures. That is the real issue here.
Let me say this again: everyone who is responsible for arch packages needs to be clearly advised to use all available methods to effectively verify upstream source files.
Using a strong hash by default won't do that.
AUR packages, or repo packages? There was a todo list[1] for the repos. For anything in the AUR you should definitely drop a comment on their page. And change the wiki guidelines on packaging standards to mention this. -- Eli Schwartz [1] https://www.archlinux.org/todo/use-gpg-signatures-and-https-sources/
Am 05.12.2016 um 23:45 schrieb Eli Schwartz via arch-general:
On 12/05/2016 05:25 PM, sivmu wrote:
A LOT of packages do not use pgp validation even though upstream provides signatures. That is the real issue here.
Let me say this again: everyone who is responsible for arch packages needs to be clearly advised to use all available methods to effectively verify upstream source files.
Using a strong hash by default won't do that.
AUR packages, or repo packages? There was a todo list[1] for the repos.
For anything in the AUR you should definitely drop a comment on their page. And change the wiki guidelines on packaging standards to mention this.
Wow thanks for the link, I did not kow that yet. That looks awesome.
On 12/05/2016 11:45 PM, Eli Schwartz via arch-general wrote:
On 12/05/2016 05:25 PM, sivmu wrote:
A LOT of packages do not use pgp validation even though upstream provides signatures. That is the real issue here.
Let me say this again: everyone who is responsible for arch packages needs to be clearly advised to use all available methods to effectively verify upstream source files.
Using a strong hash by default won't do that.
AUR packages, or repo packages? There was a todo list[1] for the repos.
For anything in the AUR you should definitely drop a comment on their page. And change the wiki guidelines on packaging standards to mention this.
Yes we really should change the wiki. I once already did, but it got reverted. The argument about false security is somehow valid. People should not think that is replaces a GPG signature. However those people do not care at all, and if they'd use sha512 it can only have positive effects. It does not only (but especially) apply to AUR. But i also had to rebuild some official packages (because of several issues or modifications). And strong hashes would ensure I get the same sources as the maintainer used. So the real solution is to set strong hashes as default to help those who just dont know what is more important. But we also need to explain in which situations and why they are important (wiki). And furthermore people should be encouraged to ask upstream to sign their sources with gpg. I did this with a lot of sources already and I also try to explain it as simple as possible for them. The more people start using GPG, the more those who dont will understand the importance. And this would also solve the hash issue. I got really positive feedback so far and also questions about GPG. People do want to secure their stuff, but they dont know how or dont know how easy it is. Going further I personally will not move any package to [community] unless it provides GPG signatures (excluding arduino as I've already uploaded parts of it). Here is a tutorial how to setup gpg real quick and also a template to ask upstream for GPG signatures. Any contributions appreciated. https://github.com/NicoHood/NicoHood.github.io/wiki/How-to-sign-sources-with... https://github.com/NicoHood/NicoHood.github.io/wiki/GPG-signatures-for-sourc... ~Nico
On 12/03/2016 10:37 PM, Maxwell Anselm via arch-general wrote:
You mean the source files that you downloaded and then hashed...
Yes. If the source files are being modified via a MITM attack (which is trivial if the host uses HTTP) the checksum is still useful.
This sounds a lot like a "solution in search of a problem to fix" and blindly applying any "fix" where it is proveably meaningless really causes credibility (not to mention the Arch KISS philosophy) to take a beating. I'm all for validation and stronger hashes, but applying them in a circumstance where there is no way to validate against any original -- is just bat-shit crazy. -- David C. Rankin, J.D.,P.E.
Grayhatter here, developer of Tox -- The security centered TAV client. No matter what the reason is, NO ONE should be using MD5. We can argue about what hash we want to use, but literally nothing, is better than using MD5. I don't mean MD5 is better than everything else, I mean NOT using a hash, is better than using MD5. The argument that an insecure hash is fine because it doesn't need to be secure, and that PGP is a better replacement; Is a plainly BAD argument. The issue at hand is not, what should we use to verify the authenticity of the packages. The question is, is MD5 an acceptable hashing algorithm? We all know it's not. If given the choice, NO ONE who knows about the SERIOUS issues with MD5 would think it's a reasonable suggestion. Switching to sha256/512 isn't a hard switch `sha{256,512}sum` is in coreutils (a member of base no less). To recap... we have a lot of good reasons to drop MD5 like the broken algo it is. No applicable reasons why need to keep it. So... why haven't we replaced it yet? On Tue, Dec 6, 2016 at 7:37 PM, David C. Rankin < drankinatty@suddenlinkmail.com> wrote:
On 12/03/2016 10:37 PM, Maxwell Anselm via arch-general wrote:
You mean the source files that you downloaded and then hashed...
Yes. If the source files are being modified via a MITM attack (which is trivial if the host uses HTTP) the checksum is still useful.
This sounds a lot like a "solution in search of a problem to fix" and blindly applying any "fix" where it is proveably meaningless really causes credibility (not to mention the Arch KISS philosophy) to take a beating.
I'm all for validation and stronger hashes, but applying them in a circumstance where there is no way to validate against any original -- is just bat-shit crazy.
-- David C. Rankin, J.D.,P.E.
On 07/12/16 19:35, Gregory Mullen wrote:
Grayhatter here, developer of Tox -- The security centered TAV client. No matter what the reason is, NO ONE should be using MD5. We can argue about what hash we want to use, but literally nothing, is better than using MD5. I don't mean MD5 is better than everything else, I mean NOT using a hash, is better than using MD5.
Ignoring "slight" exaggerations...
The argument that an insecure hash is fine because it doesn't need to be secure, and that PGP is a better replacement; Is a plainly BAD argument. The issue at hand is not, what should we use to verify the authenticity of the packages. The question is, is MD5 an acceptable hashing algorithm? We all know it's not. If given the choice, NO ONE who knows about the SERIOUS issues with MD5 would think it's a reasonable suggestion.
Switching to sha256/512 isn't a hard switch `sha{256,512}sum` is in coreutils (a member of base no less).
To recap... we have a lot of good reasons to drop MD5 like the broken algo it is. No applicable reasons why need to keep it. So... why haven't we replaced it yet?
I advocate keeping md5sum as the default because it is broken. If I see someone purely verifying their sources using md5sum in a PKGBUILD (and not pgp signature), I know that they have done nothing to actually verify the source themselves. If sha2sums become default, I now know nothing. Did the maintainer of the PKGBUILD get that checksum from a securely distributed source from upstream? Had the source already been compromised upstream before the PKGBUILD was made? Now I am securely verifying the unknown. But we don't care about that... we just want to feel warm and fuzzy with a false sense of security. A
I advocate keeping md5sum as the default because it is broken. If I see someone purely verifying their sources using md5sum in a PKGBUILD (and not pgp signature), I know that they have done nothing to actually verify the source themselves.
I advocate making the default house construction straw... Said the wolf to the three little pigs. Advocating for MD5 as a "this package is insecure" warning flag makes NO sense at all. Especially when if the package is secure (because the maintainer verified the PGP sig, and then changed to shaXXX) you still no nothing new. But don't say; MD5 is good because I know it's broken, so I know the maintainer didn't do their job? Either validate the PGP keys, or don't. But don't suggest keeping a broken system because... why again? So you can learn nothing?
But we don't care about that... we just want to feel warm and fuzzy with a false sense of security.
No one is suggesting sha*sum replace, and actual security/authentication check. Only that maybe it's not a good idea to use a system we all know is broken. On Wed, Dec 7, 2016 at 1:49 AM, Allan McRae <allan@archlinux.org> wrote:
On 07/12/16 19:35, Gregory Mullen wrote:
Grayhatter here, developer of Tox -- The security centered TAV client. No matter what the reason is, NO ONE should be using MD5. We can argue about what hash we want to use, but literally nothing, is better than using MD5. I don't mean MD5 is better than everything else, I mean NOT using a hash, is better than using MD5.
Ignoring "slight" exaggerations...
The argument that an insecure hash is fine because it doesn't need to be secure, and that PGP is a better replacement; Is a plainly BAD argument. The issue at hand is not, what should we use to verify the authenticity of the packages. The question is, is MD5 an acceptable hashing algorithm? We all know it's not. If given the choice, NO ONE who knows about the SERIOUS issues with MD5 would think it's a reasonable suggestion.
Switching to sha256/512 isn't a hard switch `sha{256,512}sum` is in coreutils (a member of base no less).
To recap... we have a lot of good reasons to drop MD5 like the broken algo it is. No applicable reasons why need to keep it. So... why haven't we replaced it yet?
I advocate keeping md5sum as the default because it is broken. If I see someone purely verifying their sources using md5sum in a PKGBUILD (and not pgp signature), I know that they have done nothing to actually verify the source themselves.
If sha2sums become default, I now know nothing. Did the maintainer of the PKGBUILD get that checksum from a securely distributed source from upstream? Had the source already been compromised upstream before the PKGBUILD was made? Now I am securely verifying the unknown.
But we don't care about that... we just want to feel warm and fuzzy with a false sense of security.
A
On 07/12/16 19:58, Gregory Mullen wrote:
But we don't care about that... we just want to feel warm and fuzzy with a false sense of security.
No one is suggesting sha*sum replace, and actual security/authentication check. Only that maybe it's not a good idea to use a system we all know is broken.
If everyone knows it is broken, upstream will not be providing md5sums to compare against and then and PKGBUILD maintainer that has verified the source files using upstream provided hashes will not use md5sum. All we do by changing away from md5sum as the default is hiding the large number of packages that do nothing to verify upstream source integrity. In fact, I am making CRC the default. A
In fact, I am making CRC the default.
I assume this to be sarcasm. In any case, this may not be a good idea because the younglings will have never heard about it and don't know how insecure it is ;) Cheers, Bennett -- GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96 7808
If the argument left is, I don't want (better checksum) because it's shouldn't be thought of as a security check, and I want a security check. Why can't the requirement be PGP sig's are now required, and we drop the checksum completely? On Wed, Dec 7, 2016 at 2:14 AM, Bennett Piater <bennett@piater.name> wrote:
In fact, I am making CRC the default.
I assume this to be sarcasm. In any case, this may not be a good idea because the younglings will have never heard about it and don't know how insecure it is ;)
Cheers, Bennett
-- GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96 7808
Off-topic for amusement only: PGP checks are not necessarily more secure. Some foolish comments are already deleted at https://aur.archlinux.org/packages/freetype2-infinality/?comments=all Somebody recommended to e.g. use "--skippgpcheck", another reply asked from where I got the information what keyserver to use. Regards, Ralf
On 12/07/2016 11:17 AM, Gregory Mullen wrote:
If the argument left is, I don't want (better checksum) because it's shouldn't be thought of as a security check, and I want a security check.
Why can't the requirement be PGP sig's are now required, and we drop the checksum completely?
Won't work because many upstreams don't provide signatures. Maybe giving a warning ("source authenticity was not verified due to lack of GPG signature") would work? -- GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96 7808
On 07-12-16 11:44, Bennett Piater wrote:
On 12/07/2016 11:17 AM, Gregory Mullen wrote:
If the argument left is, I don't want (better checksum) because it's shouldn't be thought of as a security check, and I want a security check.
Why can't the requirement be PGP sig's are now required, and we drop the checksum completely?
Won't work because many upstreams don't provide signatures. Maybe giving a warning ("source authenticity was not verified due to lack of GPG signature") would work?
I vote to rename all *sums fields in PKGBUILD to : this_is_just_a_checksum_and_does_no_authentication_at_all-xyzsums Would it be possible to focus all this energy on ideas to make things safer instead of wrongly treating checksums as a security feature ? LW
On Wed, 7 Dec 2016 11:44:11 +0100 Bennett Piater <bennett@piater.name> wrote:
Maybe giving a warning ("source authenticity was not verified due to lack of GPG signature") would work?
I find this a great idea. It's transparent, and this way people get frequently reminded about that security issue. Or like sivmu said:
A big fat warning about missing validation should automatically be generated in any package that misses signatures or at least https source downloads.
Regards, Merlin -- Merlin Büge <toni@bluenox07.de>
On 12/07/2016 10:49 AM, Allan McRae wrote:
I advocate keeping md5sum as the default because it is broken. If I see someone purely verifying their sources using md5sum in a PKGBUILD (and not pgp signature), I know that they have done nothing to actually verify the source themselves.
If sha2sums become default, I now know nothing. Did the maintainer of the PKGBUILD get that checksum from a securely distributed source from upstream? Had the source already been compromised upstream before the PKGBUILD was made? Now I am securely verifying the unknown.
But we don't care about that... we just want to feel warm and fuzzy with a false sense of security.
A
You are partly right. For a checksum CRC would be best. Fast and simple, as its meant as checksum, not as a hash. However if we drop the other hashes we loose the whole integrity for those cases that people already explained[1]. We all aggree that md5 as hash is broken. So possibly we should get our point of view into the direction that those hashes are not checksums, but rather integrity checks. Once again: This does not help in the very first place of downloading. But it helps on AUR where multiple users download the files and would get errors on wrong hashes (if the source got modified later or if a MITM occured). In those cases users can compare against the hash of others (maintainer) and at least verify that their source was the same (integrity). Also if you say that you can notice the people who do not care about security by using md5 you can pass the buck to this guy. But this does not solve anything. And on top there are still a LOT package on the official repositories that still use md5/sha1. And I really do not understand why, because those should be aware of the problem. We should not make the problem worse by using CRC. We should carefully understand when the integrity check helps. If if its not meant for integrity, the wiki is wrong, as it calls it integrity not checksum. There is no real valid argument about using lower security standards. Even if people might misunderstand the meaning of the hashes, they do not understand security at all. And those can still be helped with a good explanation of those checks on the wiki with a link to the GPG templates (see below). [1] https://lists.archlinux.org/pipermail/arch-general/2016-December/042737.html On 12/07/2016 11:17 AM, Gregory Mullen wrote:
If the argument left is, I don't want (better checksum) because it's shouldn't be thought of as a security check, and I want a security check.
Why can't the requirement be PGP sig's are now required, and we drop the checksum completely?
That is also what I suggest. If we only move GPG signed Packages to community, the whole situation will improve. A lot more upstream projects will then possibly try to use GPG if they want to make it into our (and possibly also other) distributions. What we need here is more action from the maintainer side. I've linked my templates for contacting upstream about using GPG. With those it would be really easy for them to understand what we need, why and how to accomplish it. We already agreed that we need to use GPG whenever possible, but we should also try to do our best to get upstream to do so. It is really simple. ~Nico
You are partly right. For a checksum CRC would be best. Fast and simple, as its meant as checksum, not as a hash.
You misunderstand something. Every checksum is also a hash (a mapping to another domain), and cryptographic hash functions always produce checksums.
So possibly we should get our point of view into the direction that those hashes are not checksums, but rather integrity checks.
This is wrong. Checksum checks *are* integrity checks. That's what they are. I think you should read up on some terminology because either you misunderstand something very basic, or you confuse others by using words differently from everyone else. Cheers, Bennett -- GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96 7808
Am 07.12.2016 um 10:49 schrieb Allan McRae:
... I advocate keeping md5sum as the default because it is broken. If I see someone purely verifying their sources using md5sum in a PKGBUILD (and not pgp signature), I know that they have done nothing to actually verify the source themselves. ...
That is a very dangerous assumtion. I know for a fact that many maintainers used md5 for verification because it is the default. There are/were maintainers that downloaded the source, verified the pgp signature and generated the md5 checksum to include it in the PKGBUILD (without the pgp signature) md5 is associated with security even though it is broken. People who do not know they can use a different checksum, will assume the arch build system is just that crappy and md5sum it the only available validation. What you associate with md5 is not relevant. Am 07.12.2016 um 11:09 schrieb Allan McRae:
On 07/12/16 19:58, Gregory Mullen wrote:
But we don't care about that... we just want to feel warm and fuzzy with a false sense of security.
No one is suggesting sha*sum replace, and actual security/authentication check. Only that maybe it's not a good idea to use a system we all know is broken.
If everyone knows it is broken, upstream will not be providing md5sums to compare against and then and PKGBUILD maintainer that has verified the source files using upstream provided hashes will not use md5sum.
Again, very dangerous assumtion
All we do by changing away from md5sum as the default is hiding the large number of packages that do nothing to verify upstream source integrity.
In fact, I am making CRC the default.
I hope that is NOT sarcasm. No seriously thats what I had in mind from the start, making sure md5 is not taken as a security thing. Using a line like crc_checksum_NOTFORSECUREVERIFICATION!!! is an even better idea. If you want to know if the package source is verified, why not use the existance of https or pgp signatures in the build file? Do you think any default will keep maintainers from generating sha512 checksums without verifying the sources? A big fat warning about missing validation should automatically be generated in any package that misses signatures or at least https source downloads. And while we are at it I would like to point out that git downloads are used as verification as well and I'm not sure what a crypto expert would say about that.
On 08/12/16 08:51, sivmu wrote:
... I advocate keeping md5sum as the default because it is broken. If I see someone purely verifying their sources using md5sum in a PKGBUILD (and not pgp signature), I know that they have done nothing to actually verify the source themselves. ... That is a very dangerous assumtion. I know for a fact that many
Am 07.12.2016 um 10:49 schrieb Allan McRae: maintainers used md5 for verification because it is the default. There are/were maintainers that downloaded the source, verified the pgp signature and generated the md5 checksum to include it in the PKGBUILD (without the pgp signature)
Idiots... so again using md5sums as the default saves me from people who don't know how to package. A
On Thu, Dec 08, 2016 at 10:34:59AM +1000, Allan McRae wrote:
On 08/12/16 08:51, sivmu wrote:
... I advocate keeping md5sum as the default because it is broken. If I see someone purely verifying their sources using md5sum in a PKGBUILD (and not pgp signature), I know that they have done nothing to actually verify the source themselves. ... That is a very dangerous assumtion. I know for a fact that many
Am 07.12.2016 um 10:49 schrieb Allan McRae: maintainers used md5 for verification because it is the default. There are/were maintainers that downloaded the source, verified the pgp signature and generated the md5 checksum to include it in the PKGBUILD (without the pgp signature)
Idiots... so again using md5sums as the default saves me from people who don't know how to package.
Actually, this might not be so crazy. Sometimes you get a signed sha*sums file instead of signed source, so you don't include the key in validpgpkeys array. For example, when building Firefox, I have to manually verify the sig on SHA512SUMS and then paste the sha512sum into PKGBUILD. But this is because I'm paranoid... I guess one can simply do makepkg -g, hmm. Hence the question, why have this flag at all? And should it be possible to specify an external (signed) hash-file in PKGBUILD? Thx, L. -- Leonid Isaev
Le 08/12/2016 à 01:57, Leonid Isaev a écrit :
On 08/12/16 08:51, sivmu wrote:
... I advocate keeping md5sum as the default because it is broken. If I see someone purely verifying their sources using md5sum in a PKGBUILD (and not pgp signature), I know that they have done nothing to actually verify the source themselves. ... That is a very dangerous assumtion. I know for a fact that many
Am 07.12.2016 um 10:49 schrieb Allan McRae: maintainers used md5 for verification because it is the default. There are/were maintainers that downloaded the source, verified the pgp signature and generated the md5 checksum to include it in the PKGBUILD (without the pgp signature) Idiots... so again using md5sums as the default saves me from people who don't know how to package. Actually, this might not be so crazy. Sometimes you get a signed sha*sums file instead of signed source, so you don't include the key in validpgpkeys array. For example, when building Firefox, I have to manually verify the sig on SHA512SUMS and then paste the sha512sum into PKGBUILD. But this is because I'm
On Thu, Dec 08, 2016 at 10:34:59AM +1000, Allan McRae wrote: paranoid... I guess one can simply do makepkg -g, hmm.
Hence the question, why have this flag at all? And should it be possible to specify an external (signed) hash-file in PKGBUILD?
Thx, L.
What is wrong with adding the sha*sum file and its signature in the source array and then use validpgpkeys? Bruno
On Fri, Dec 09, 2016 at 03:15:34PM +0100, Bruno Pagani wrote:
Le 08/12/2016 à 01:57, Leonid Isaev a écrit :
On 08/12/16 08:51, sivmu wrote:
... I advocate keeping md5sum as the default because it is broken. If I see someone purely verifying their sources using md5sum in a PKGBUILD (and not pgp signature), I know that they have done nothing to actually verify the source themselves. ... That is a very dangerous assumtion. I know for a fact that many
Am 07.12.2016 um 10:49 schrieb Allan McRae: maintainers used md5 for verification because it is the default. There are/were maintainers that downloaded the source, verified the pgp signature and generated the md5 checksum to include it in the PKGBUILD (without the pgp signature) Idiots... so again using md5sums as the default saves me from people who don't know how to package. Actually, this might not be so crazy. Sometimes you get a signed sha*sums file instead of signed source, so you don't include the key in validpgpkeys array. For example, when building Firefox, I have to manually verify the sig on SHA512SUMS and then paste the sha512sum into PKGBUILD. But this is because I'm
On Thu, Dec 08, 2016 at 10:34:59AM +1000, Allan McRae wrote: paranoid... I guess one can simply do makepkg -g, hmm.
Hence the question, why have this flag at all? And should it be possible to specify an external (signed) hash-file in PKGBUILD?
Thx, L.
What is wrong with adding the sha*sum file and its signature in the source array and then use validpgpkeys?
And then what? -- Leonid Isaev
Le 10/12/2016 à 00:30, Leonid Isaev a écrit :
On Fri, Dec 09, 2016 at 03:15:34PM +0100, Bruno Pagani wrote:
Le 08/12/2016 à 01:57, Leonid Isaev a écrit :
On 08/12/16 08:51, sivmu wrote:
> ... > I advocate keeping md5sum as the default because it is broken. If I see > someone purely verifying their sources using md5sum in a PKGBUILD (and > not pgp signature), I know that they have done nothing to actually > verify the source themselves. > ... That is a very dangerous assumtion. I know for a fact that many
Am 07.12.2016 um 10:49 schrieb Allan McRae: maintainers used md5 for verification because it is the default. There are/were maintainers that downloaded the source, verified the pgp signature and generated the md5 checksum to include it in the PKGBUILD (without the pgp signature) Idiots... so again using md5sums as the default saves me from people who don't know how to package. Actually, this might not be so crazy. Sometimes you get a signed sha*sums file instead of signed source, so you don't include the key in validpgpkeys array. For example, when building Firefox, I have to manually verify the sig on SHA512SUMS and then paste the sha512sum into PKGBUILD. But this is because I'm
On Thu, Dec 08, 2016 at 10:34:59AM +1000, Allan McRae wrote: paranoid... I guess one can simply do makepkg -g, hmm.
Hence the question, why have this flag at all? And should it be possible to specify an external (signed) hash-file in PKGBUILD?
Thx, L. What is wrong with adding the sha*sum file and its signature in the source array and then use validpgpkeys? And then what?
Then makepkg would check the sigs on the sha*sum file, and you could either grep the sum from this file to use it in the PKGBUILD automatically (which is done in firefox-nightly-fr, probably not optimally now that I thought about it) or have a function to later verify the sum (don’t like that way, but it’s done in firefox-nightly for instance), or copy it by hand if it is for a stable package (which seems to be your use case). The goal here being that other people using the PKGBUILD get the same GPG verification.
On 12/08/2016 01:34 AM, Allan McRae wrote:
On 08/12/16 08:51, sivmu wrote:
... I advocate keeping md5sum as the default because it is broken. If I see someone purely verifying their sources using md5sum in a PKGBUILD (and not pgp signature), I know that they have done nothing to actually verify the source themselves. ... That is a very dangerous assumtion. I know for a fact that many
Am 07.12.2016 um 10:49 schrieb Allan McRae: maintainers used md5 for verification because it is the default. There are/were maintainers that downloaded the source, verified the pgp signature and generated the md5 checksum to include it in the PKGBUILD (without the pgp signature)
Idiots... so again using md5sums as the default saves me from people who don't know how to package.
A
Calling those idiots is not the way to solve this problem. The fact is that if we use a (strong) hash and multiple people compare their hash against that, we can ensure that everyone downloads the same sources. Setting the default to sha512sums helps in more cases than using md5 as "bad karma" flag does. Did it ever help you that you saw someone using md5? Or wouldn't it be better to guide them into the right direction by a) using sha512sums as default and b) adding a warning when no https and gpg is used? I think we should at least implement those warnings, no matter what hash we use. Our main goal is to have every sources signed with gpg and downloaded by https. Is there any voting system that we have so that we can also democratically vote for stronger hashes? It seems to me that the majority (who spoke up on the list) is for stronger hashes. All technical facts have been said and we should come to a final agreement now. ~Nico
On Thu, 8 Dec 2016 14:52:20 +0100, NicoHood wrote:
Is there any voting system that we have so that we can also democratically vote for stronger hashes?
The Arch developers decide this, not a democratically vote ;).
Is there any voting system that we have so that we can also democratically vote for stronger hashes?
The Arch developers decide this, not a democratically vote ;).
Arch is not a democracy, that has been said many times. -- GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96 7808
On 12/08/2016 03:14 PM, Bennett Piater wrote:
Is there any voting system that we have so that we can also democratically vote for stronger hashes?
The Arch developers decide this, not a democratically vote ;).
Arch is not a democracy, that has been said many times.
That is true and also make sense in some cases. However we somehow need an official statement then, as all facts are given by now. Some TU votes might still help, however I am really glad that so many people raised up their word here. As an alternative if the main devs do not want to make it a general rule we could use the Trusted User Section on AUR to create a proposal about using strong hashes for community. We can then make it a community only rule or also "just" a guideline everyone can follow or not. Everyone who complies to this guideline can mark their package so and others will follow. An official rule would be still better. So let us know what you (devs) think about this finally. ~Nico
On 10/12/16 02:05, NicoHood wrote:
An official rule would be still better. So let us know what you (devs) think about this finally.
Been there, done that...
On Wed, Dec 07, 2016 at 01:58:16AM -0800, Gregory Mullen wrote:
I advocate keeping md5sum as the default because it is broken. If I see someone purely verifying their sources using md5sum in a PKGBUILD (and not pgp signature), I know that they have done nothing to actually verify the source themselves.
I advocate making the default house construction straw... Said the wolf to the three little pigs.
Advocating for MD5 as a "this package is insecure" warning flag makes NO sense at all. Especially when if the package is secure (because the maintainer verified the PGP sig, and then changed to shaXXX) you still no nothing new. But don't say; MD5 is good because I know it's broken, so I know the maintainer didn't do their job?
Either validate the PGP keys, or don't. But don't suggest keeping a broken system because... why again? So you can learn nothing?
I think you misunderstood Allan. What he says is that by default makepkg provides only a protection against broken http links at best. If a maintainer wants security, he must take care of it explicitly. I don't see why this is a bad idea... Cheers, L. -- Leonid Isaev
On 12/03/2016 07:21 PM, sivmu wrote:
Am 03.12.2016 um 06:27 schrieb fnodeuser:
if an upstream does not sign the files, does not have https enabled, and/or refuses to take security and privacy seriously, sha512 must be used in the PKGBUILD files.
But using and hash value without the possibility to verify the hashed files, adds no security. It provides a false sense of security instead.
I agree that we should use a strong hash by default where it makes sense. But in the absense ob effective validation of upstream packages, this is meaningless.
It adds (possible) security for those who want to rebuild the package at a later time or modify the PKGBUILD. It ensures they get the exact same sources as the original publisher. This comes especially into place if you live inside a country where you do not have much freedom online. I also like the suggestion to also sign the ISO files with sha512sums. It would not cause any trouble to add one more hash and a lot more people will be happy. Great idea! I also got a request from AUR: https://aur.archlinux.org/packages/snap-sync/ Those suggestions should be written down somewhere. I agree with this, as I also did a lot of things wrong and the PKGBUILD police (anthraxx) corrected those for me. I think a simple checklist with examples would be nice. This could contain: * Use https whenever possible * Use GPG whenever possible * Ask upstream if they do not use https and gpg yet (with some templates I made) * Use strong hashes * Add a note about the simple devtools chroot build and updpkgsums function * Use unique sources (if you are building in the same source directory) * Mask all variables with quotes * Use .xz sources wherever possible (to speed up downloads on instable/slow connections) * Do not delete users on uninstall * Use an underscore for user variables * https://lists.archlinux.org/pipermail/aur-general/2016-October/032845.html So what do you guys think if we make our implicit standards available somewhere on the wiki. This would make it more transparent on how we build stuff, how TUs should package and give a guideline for AUR maintainers, as they might not know about some details like this. ~Nico
So what do you guys think if we make our implicit standards available somewhere on the wiki. This would make it more transparent on how we build stuff, how TUs should package and give a guideline for AUR maintainers, as they might not know about some details like this.
The best way to get that ball rolling is to just add it somewhere. The maintenance team usually weighs in pretty quickly on the talk pages. Possible pages for the info could be: https://wiki.archlinux.org/index.php/Arch_packaging_standards or https://wiki.archlinux.org/index.php/Arch_User_Repository
On Sat, Dec 3, 2016 at 6:27 AM, fnodeuser <subscription@binkmail.com> wrote:
https://lists.archlinux.org/pipermail/arch-dev-public/2016-November/028492.h...
I would suggest considering TUF - The Update Framework or stealing their signing scheme which withstands all kinds of attack scenarios.
On Sat, Dec 3, 2016 at 3:27 AM, fnodeuser <subscription@binkmail.com> wrote:
https://lists.archlinux.org/pipermail/arch-dev-public/2016-November/028492.h...
i have a few things to add to this.
the message digests at the download page for the .iso file, must change to sha256 and sha512 ones, or to a sha512 one.
if an upstream does not sign the files, does not have https enabled, and/or refuses to take security and privacy seriously, sha512 must be used in the PKGBUILD files.
in the cases of upstreams that use md5 and/or sha1 message digests, those will be added in a second ALGOsums= line under the sha512sums= line. if they use md5 and sha1, then sha1sums must be used for the second ALGOsums= line.
Once again I must say thanks, fnodeuser.
On 12/16/2016 05:46 PM, Diego Viola via arch-general wrote:
On Sat, Dec 3, 2016 at 3:27 AM, fnodeuser <subscription@binkmail.com> wrote:
https://lists.archlinux.org/pipermail/arch-dev-public/2016-November/028492.h...
i have a few things to add to this.
the message digests at the download page for the .iso file, must change to sha256 and sha512 ones, or to a sha512 one.
if an upstream does not sign the files, does not have https enabled, and/or refuses to take security and privacy seriously, sha512 must be used in the PKGBUILD files.
in the cases of upstreams that use md5 and/or sha1 message digests, those will be added in a second ALGOsums= line under the sha512sums= line. if they use md5 and sha1, then sha1sums must be used for the second ALGOsums= line.
Once again I must say thanks, fnodeuser.
Yesterday I wanted to install ArchLinux on someone else computer. He used Windows until now and had no gpg handy yet (it is really annoying to install on windows). So we needed to verify the source otherwise. But there was no real option as md5/sha1 is broken and his internet is too slow to download it again via torrent. We did not install Arch then and I will send him my sha512sum from my computer the next days where I did a torrent download. The ArchLinux website connects via https. His mirror that he used did not (http or ftp). So we had a real problem and there was no way to verify the source properly. Adding sha256 and sha512 would not cause more trouble but would be extremely helpful here. @Allan I think you are responsible for this if I am correct. Would you please be so kind and add sha256 sums to the download page?
On 26/12/16 22:12, NicoHood wrote:
On 12/16/2016 05:46 PM, Diego Viola via arch-general wrote:
On Sat, Dec 3, 2016 at 3:27 AM, fnodeuser <subscription@binkmail.com> wrote:
https://lists.archlinux.org/pipermail/arch-dev-public/2016-November/028492.h...
i have a few things to add to this.
the message digests at the download page for the .iso file, must change to sha256 and sha512 ones, or to a sha512 one.
if an upstream does not sign the files, does not have https enabled, and/or refuses to take security and privacy seriously, sha512 must be used in the PKGBUILD files.
in the cases of upstreams that use md5 and/or sha1 message digests, those will be added in a second ALGOsums= line under the sha512sums= line. if they use md5 and sha1, then sha1sums must be used for the second ALGOsums= line.
Once again I must say thanks, fnodeuser.
Yesterday I wanted to install ArchLinux on someone else computer. He used Windows until now and had no gpg handy yet (it is really annoying to install on windows).
So we needed to verify the source otherwise. But there was no real option as md5/sha1 is broken and his internet is too slow to download it again via torrent. We did not install Arch then and I will send him my sha512sum from my computer the next days where I did a torrent download.
The ArchLinux website connects via https. His mirror that he used did not (http or ftp). So we had a real problem and there was no way to verify the source properly. Adding sha256 and sha512 would not cause more trouble but would be extremely helpful here.
@Allan I think you are responsible for this if I am correct. Would you please be so kind and add sha256 sums to the download page?
I have nothing to do with this. Also, is there even a theoretical case where a joint md5 and sha1 collision has occured?
On 12/26/2016 01:21 PM, Allan McRae wrote:
On 26/12/16 22:12, NicoHood wrote:
On 12/16/2016 05:46 PM, Diego Viola via arch-general wrote:
On Sat, Dec 3, 2016 at 3:27 AM, fnodeuser <subscription@binkmail.com> wrote:
https://lists.archlinux.org/pipermail/arch-dev-public/2016-November/028492.h...
i have a few things to add to this.
the message digests at the download page for the .iso file, must change to sha256 and sha512 ones, or to a sha512 one.
if an upstream does not sign the files, does not have https enabled, and/or refuses to take security and privacy seriously, sha512 must be used in the PKGBUILD files.
in the cases of upstreams that use md5 and/or sha1 message digests, those will be added in a second ALGOsums= line under the sha512sums= line. if they use md5 and sha1, then sha1sums must be used for the second ALGOsums= line.
Once again I must say thanks, fnodeuser.
Yesterday I wanted to install ArchLinux on someone else computer. He used Windows until now and had no gpg handy yet (it is really annoying to install on windows).
So we needed to verify the source otherwise. But there was no real option as md5/sha1 is broken and his internet is too slow to download it again via torrent. We did not install Arch then and I will send him my sha512sum from my computer the next days where I did a torrent download.
The ArchLinux website connects via https. His mirror that he used did not (http or ftp). So we had a real problem and there was no way to verify the source properly. Adding sha256 and sha512 would not cause more trouble but would be extremely helpful here.
@Allan I think you are responsible for this if I am correct. Would you please be so kind and add sha256 sums to the download page?
I have nothing to do with this.
Also, is there even a theoretical case where a joint md5 and sha1 collision has occured?
Oh sorry. ArchLinux wants to KISS, so we should simply add stronger hashes instead of requiring the user to download two tools. Its quite a struggle to find a hash tool for windows anyways. Also the website should state from which person the signature is and which fingerprint it uses. I still could not find this information (otherwise I'd contact this person). Going to add a bugreport instead: https://bugs.archlinux.org/task/52273
On Mon, Dec 26, 2016 at 01:35:23PM +0100, NicoHood wrote:
ArchLinux wants to KISS, so we should simply add stronger hashes instead of requiring the user to download two tools. Its quite a struggle to find a hash tool for windows anyways.
How about Microsoft FCIV [1]? [1] https://www.microsoft.com/en-us/download/details.aspx?id=11533 Cheers, -- Leonid Isaev
On Tue, Dec 27, 2016 at 6:09 PM, Leonid Isaev < leonid.isaev@jila.colorado.edu> wrote:
On Mon, Dec 26, 2016 at 01:35:23PM +0100, NicoHood wrote:
ArchLinux wants to KISS, so we should simply add stronger hashes instead of requiring the user to download two tools. Its quite a struggle to find a hash tool for windows anyways.
How about Microsoft FCIV [1]?
[1] https://www.microsoft.com/en-us/download/details.aspx?id=11533
Builtin Powershell commandlet: Get-FileHash: https://msdn.microsoft.com/en-us/powershell/reference/5.0/microsoft.powershe... Jürgen
Cheers, -- Leonid Isaev
On 12/26/2016 07:35 AM, NicoHood wrote:
Yesterday I wanted to install ArchLinux on someone else computer. He used Windows until now and had no gpg handy yet (it is really annoying to install on windows).
What is wrong with, say, Gpg4win? Okay, it is difficult to *trust* the software without any way of securely proving it itself hasn't been backdoored. Then again, how did *you* initially trust your Linux distribution? But I don't see why it would be especially difficult to *install* on Windows.
So we needed to verify the source otherwise. But there was no real option as md5/sha1 is broken and his internet is too slow to download it again via torrent. We did not install Arch then and I will send him my sha512sum from my computer the next days where I did a torrent download.
I was under the impression that sha1 works just fine, and will for a little while yet. Preimage attacks haven't been suggested to be feasible yet, to my knowledge. Though we should still move off sha1 simply because it is continually weakening and on its last legs (or already broken for some functionality), I am pretty sure your friend is safe...
ArchLinux wants to KISS, so we should simply add stronger hashes instead of requiring the user to download two tools. Its quite a struggle to find a hash tool for windows anyways.
I am not overly familiar with the checksumming landscape in Windows-land, but I could have sworn all the common tools I found back in "the day" were capable of verifying a range of hash functions, much like coreutils as a set is capable of verifying a range of hash functions. Why do you need two tools?
Also the website should state from which person the signature is and which fingerprint it uses. I still could not find this information (otherwise I'd contact this person).
Usually gpg tells you this automagically. :p Anyway, the key already has full trust from pacman-key, if you are verifying from an Arch system... also, the frontpage has a link[1] to the canonical master keys "for all Arch Linux purposes", which is how I initially verified the ISO signature as having a valid trust. (Do take caution to independently verify those signatures e.g. from the owner's personal website.) -- Eli Schwartz [1] https://www.archlinux.org/master-keys/
On 26.12.2016 13:12, NicoHood wrote:
So we needed to verify the source otherwise. But there was no real option as md5/sha1 is broken
I fully agree that using stronger hashes is generally a good idea, but please stop being ridiculous.
and his internet is too slow to download it again via torrent.
If you put your file at the location where the torrent client downloads the file to, it will detect this and check the existing file contents. Also, you know that torrent also uses SHA1 hashes internally, right?
The ArchLinux website connects via https. His mirror that he used did not (http or ftp).
https or not, the mirror admin has full control and can easily change the files. Please stop being pedantic and look at the bigger picture. Then you'd also see that it's much easier for an attacker to target our website and change the hashes there than trying to find an md5/sha1/filesize collision and then getting that file to you via one/all of our mirrors without having access to our servers. There are many trade offs and attack vectors when it comes to security. Don't focus on a single one. You could have improved a lot with all the dedication and time you put into these discussions if you worked on other things with more impact. Florian
participants (19)
-
Allan McRae
-
Bennett Piater
-
Bruno Pagani
-
Carsten Mattner
-
Chris Tonkinson
-
David C. Rankin
-
Diego Viola
-
Eli Schwartz
-
Florian Pritz
-
fnodeuser
-
Gregory Mullen
-
Jürgen Hötzel
-
Leonid Isaev
-
LoneVVolf
-
Maxwell Anselm
-
Merlin Büge
-
NicoHood
-
Ralf Mardorf
-
sivmu