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...

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

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.

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/

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

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.

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 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

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 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 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

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 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

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

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

...

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 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 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

On 12/16/2016 05:46 PM, Diego Viola via arch-general wrote:

On Sat, Dec 3, 2016 at 3:27 AM, fnodeuser 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 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 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 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 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