[arch-general] Stronger Hashes for PKGBUILDs

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

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

sivmu

2016-12-03 18:21:46 UTC

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

Maxwell Anselm via arch-general

2016-12-03 19:07:10 UTC

Post by sivmu
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.

sivmu

2016-12-03 19:41:17 UTC

Post by sivmu
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...

Maxwell Anselm via arch-general

2016-12-04 04:37:09 UTC

Post by sivmu
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.

sivmu

2016-12-05 19:56:35 UTC

Post by sivmu
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

Eli Schwartz via arch-general

2016-12-05 20:50:39 UTC

Post by sivmu
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

Maxwell Anselm via arch-general

2016-12-05 21:03:32 UTC

Post by Eli Schwartz via arch-general
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.

sivmu

2016-12-05 22:25:14 UTC

Post by sivmu
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

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.

Post by Eli Schwartz via arch-general
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

Post by Eli Schwartz via arch-general
3) Source website hacked, after the AUR maintainer generates checksums
from the original uncompromised source.

This use case is valid.

Post by Eli Schwartz via arch-general
...
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.

Eli Schwartz via arch-general

2016-12-05 22:45:11 UTC

Post by sivmu
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/

sivmu

2016-12-05 22:59:31 UTC

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.

NicoHood

2016-12-06 21:41:16 UTC

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-GPG-in-under-5-minutes
https://github.com/NicoHood/NicoHood.github.io/wiki/GPG-signatures-for-source-validation

~Nico

David C. Rankin

2016-12-07 03:37:51 UTC

Post by sivmu
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.

Gregory Mullen

2016-12-07 09:35:06 UTC

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 <

Post by David C. Rankin

Post by sivmu
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.

Allan McRae

2016-12-07 09:49:31 UTC

Post by Gregory Mullen
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...

Post by Gregory Mullen
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

Gregory Mullen

2016-12-07 09:58:16 UTC

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

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?

Post by Allan McRae
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.

MD5.

Post by Gregory Mullen
I don't mean MD5 is better than everything else, I mean NOT using a hash,
is better than using MD5.

Ignoring "slight" exaggerations...

Post by Gregory Mullen
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

Post by Gregory Mullen
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

Post by Gregory Mullen
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

Allan McRae

2016-12-07 10:09:30 UTC

Post by Allan McRae
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

Bennett Piater

2016-12-07 10:14:29 UTC

Post by Allan McRae
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

Gregory Mullen

2016-12-07 10:17:55 UTC

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?

Post by Bennett Piater

Post by Allan McRae
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

Ralf Mardorf

2016-12-07 10:35:28 UTC

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

Bennett Piater

2016-12-07 10:44:11 UTC

Post by Gregory Mullen
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

LoneVVolf

2016-12-07 12:29:08 UTC

Post by Bennett Piater

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

Merlin Büge

2016-12-07 23:24:09 UTC

On Wed, 7 Dec 2016 11:44:11 +0100

Post by Bennett Piater
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.

Post by Bennett Piater
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 <***@bluenox07.de>

NicoHood

2016-12-07 12:37:44 UTC

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

Post by Allan McRae
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

Bennett Piater

2016-12-07 12:57:22 UTC

Post by NicoHood
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.

Post by NicoHood
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

sivmu

2016-12-07 22:51:10 UTC

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

Post by Allan McRae
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.

Again, very dangerous assumtion

Post by Allan McRae
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.

Allan McRae

2016-12-08 00:34:59 UTC

Idiots... so again using md5sums as the default saves me from people
who don't know how to package.

A

Leonid Isaev

2016-12-08 00:57:44 UTC

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

Bruno Pagani

2016-12-09 14:15:34 UTC

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.

What is wrong with adding the sha*sum file and its signature in the
source array and then use validpgpkeys?

Bruno

Leonid Isaev

2016-12-09 23:30:15 UTC

Post by Bruno Pagani

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.

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

Bruno Pagani

2016-12-11 12:20:05 UTC

Post by Bruno Pagani

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.

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.

NicoHood

2016-12-08 13:52:20 UTC

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

Ralf Mardorf

2016-12-08 14:10:06 UTC

Post by NicoHood
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 ;).

Bennett Piater

2016-12-08 14:14:31 UTC

Post by Ralf Mardorf

Post by NicoHood
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

NicoHood

2016-12-09 16:05:08 UTC

Post by Bennett Piater

Post by Ralf Mardorf

Post by NicoHood
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

Allan McRae

2016-12-09 23:00:36 UTC

Post by NicoHood
An official rule would be still better. So let us know what you (devs)
think about this finally.

Been there, done that...

Leonid Isaev

2016-12-07 22:42:55 UTC

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

NicoHood

2016-12-04 21:44:54 UTC

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

Maxwell Anselm via arch-general

2016-12-05 00:18:26 UTC

Post by NicoHood
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

Carsten Mattner via arch-general

2016-12-03 22:11:02 UTC

Post by fnodeuser
https://lists.archlinux.org/pipermail/arch-dev-public/2016-November/028492.html

I would suggest considering TUF - The Update Framework or stealing their
signing scheme which withstands all kinds of attack scenarios.

fnodeuser

2016-12-08 17:20:44 UTC

checksums and message digests are not the same thing.[1]

checksums are not suitable for integrity verification, and the best (meaning, at the time of writing and for the foreseeable future, most secure),
currently supported cryptographic hash function algorithm (that is sha512 in AL's case), must be used to compute the message digests of the files.

message digests are one of the things that we can and must use for security. not all upstreams have https enabled and not all of them sign their files
with gpg.

it was because of me that the 'Use gpg signatures and https sources' task was added to the todo list.[2][3][4]

these things must be checked by the users also, not only by the package maintainers. i check everything, most of you check nothing. you just do 'pacman
-Syu'.

let us start with firefox's PKGBUILD file for the first example. you are using sha256mds instead of sha512mds. you can see at
https://ftp.mozilla.org/pub/firefox/releases/50.0.2/, that there are 3 files, KEY, SHA512SUMS, and SHA512SUMS.asc. that is one example where you are
using a smaller digest size than upstream, that cannot be verified with the signature. another example is nmap's PKGBUILD file. you continued to use
sha1mds instead of sha512mds.[5]

in Gentoo they use 3 mds and in Debian they use 2 mds (for all packages, regardless of what upstreams do or do not do (in Debian's case they sign the
files containing the mds)).[6][7]

there are a few package maintainers who insist on using and/or are still using only a part of the commit or tag hash. the whole commit or tag hash must
be used, always.

the refusal to future-proof.[8] i talked with the lsof upstream. he told me that he has retired, that he is old, and that he might stop maintaining it.
it is unlikely that he will create a new keypair any time soon and he might never do that.

another bad thing that many AL team members do, is connecting to irc servers without using tls and certificate verification.

that is all for now.

_
[1] https://en.wikipedia.org/wiki/Checksum, https://en.wikipedia.org/wiki/Cryptographic_hash_function
[2] https://bugs.archlinux.org/task/51579
[3] https://lists.archlinux.org/pipermail/arch-dev-public/2016-October/028416.html
[4] https://bugs.archlinux.org/index.php?opened=23845&status[]=, https://bugs.archlinux.org/index.php?opened=23412&status[]=, and
https://bugs.archlinux.org/index.php?opened=23101&status[]=
[5] https://nmap.org/dist/sigs/nmap-7.31.tar.bz2.digest.txt
[6] https://gitweb.gentoo.org/repo/gentoo.git/tree/www-client/firefox/Manifest
[7] https://ftp.acc.umu.se/debian/pool/main/f/firefox/firefox_50.0.2-1.dsc
[8] https://bugs.archlinux.org/task/50482

Eli Schwartz via arch-general

2016-12-08 18:13:40 UTC

Okay, first things first -- what happened to replying in-thread with a
message-id linking together replies?

Oh right, you are once again using disposable, temporary Mailinator
email addresses (via their alternate domains).

Admin note: Please, someone add everything here to the invalid email
domains list, as this is getting annoying:
https://gist.github.com/nocturnalgeek/1b8fa44283314544c487

Post by fnodeuser
checksums and message digests are not the same thing.[1]
checksums are not suitable for integrity verification, and the best
(meaning, at the time of writing and for the foreseeable future, most
secure), currently supported cryptographic hash function algorithm
(that is sha512 in AL's case), must be used to compute the message
digests of the files.
message digests are one of the things that we can and must use for
security. not all upstreams have https enabled and not all of them
sign their files with gpg.

Sure they're the same. It is the same underlying technology, used for
the same purposes (and not just by Arch).

Post by fnodeuser
it was because of me that the 'Use gpg signatures and https sources'
task was added to the todo list.[2][3][4]

Thanks, I guess. Although I cannot help but notice you were rather
aggressive about it. Can't you raise these concerns in a slightly more
polite manner?

Post by fnodeuser
these things must be checked by the users also, not only by the
package maintainers. i check everything, most of you check nothing.
you just do 'pacman -Syu'.

Um, what? `pacman -Syu` does, in fact, check that every package is
signed by a Developer or Trusted User whose key is in archlinux-keyring.

I can hope for the day when the repo database will be signed as well (to
avoid malicious mirror "downgrade"/vulnerability-freezing attacks), but
in the meantime I am still pretty secure.

Unless, of course, you are suggesting that I should have no faith in the
honesty of the Arch Linux Devs/TUs.

Post by fnodeuser
let us start with firefox's PKGBUILD file for the first example. you
are using sha256mds instead of sha512mds. you can see at
https://ftp.mozilla.org/pub/firefox/releases/50.0.2/, that there are
3 files, KEY, SHA512SUMS, and SHA512SUMS.asc. that is one example
where you are using a smaller digest size than upstream, that cannot
be verified with the signature. another example is nmap's PKGBUILD
file. you continued to use sha1mds instead of sha512mds.[5]

sha256sums is plenty secure enough. So I assume the Firefox maintainer
uses that mega-file to validate the download, then uses updpkgsums to
update the current sha256sums rather than using copypasta on Firefox's
SHA512SUMS file.

Would it be nice to use the same checksums? Yes. Am I afraid I am
running malicious Firefox packages? No.

Open a bugreport. Or show us where you brought it to the attention of
the maintainer.

Post by fnodeuser
in Gentoo they use 3 mds and in Debian they use 2 mds (for all
packages, regardless of what upstreams do or do not do (in Debian's
case they sign the files containing the mds)).[6][7]

And in Arch Linux, unlike Gentoo, packages are binary and securely
signed. Signing the sources yourself proves nothing, especially if you
don't even have a mark of trust like being a TU/Dev -- so that is
straight out for the AUR, which is where people other than the
maintainer would benefit from *the maintainer* signing the sources.

Debian does a lot of weird things, like hosting and patching the sources
themselves, I am not surprised they sign the sources themselves.

Post by fnodeuser
there are a few package maintainers who insist on using and/or are
still using only a part of the commit or tag hash. the whole commit
or tag hash must be used, always.

Pointers? Bugreports?

Post by fnodeuser
the refusal to future-proof.[8] i talked with the lsof upstream. he
told me that he has retired, that he is old, and that he might stop
maintaining it. it is unlikely that he will create a new keypair any
time soon and he might never do that.

What? Creating a key is pretty easy.

Arch Linux doesn't even have a gnupg1 package, if you want to blame
someone for the absolute inability to validate that key on Arch Linux
(independent of makepkg) blame the GnuPG developers for dropping support
of insecure and tremendously outdated keys.

The foundational premise of GnuPG here, seems to be that such keys offer
very little security, the kind that isn't worth having.
Why doesn't the lsof developer future-proof himself, with 5 minutes of
effort? If he does so, we will be able to use the signatures!

Post by fnodeuser
another bad thing that many AL team members do, is connecting to irc
servers without using tls and certificate verification.

Assuming they care about being securely identified on IRC. Maybe they do
connect securely when they care about proving their identity for a
specific conversation where it matters.

I will grant you that for common sense alone you might as well connect
securely whenever possible as it doesn't cost anything. But equally, it
doesn't cost anything to *not* do so.

--
Eli Schwartz

fnodeuser

2016-12-16 01:35:37 UTC

hello eli,

you have misread and misunderstood a few things.

reread carefully all the messages about the subject,
and check the links in my second email.

i will write only about things that are not covered by the
previous messages.

Post by Eli Schwartz via arch-general
Sure they're the same. It is the same underlying technology

you have some studying to do about checksums and message digests.

Post by Eli Schwartz via arch-general
Um, what? `pacman -Syu` does, in fact, check that every package is
signed by a Developer or Trusted User whose key is in archlinux-keyring.

what i said is that the users must check the integrity of the sources too.
it is not something that only the package maintainers must do.
the users must check the PKGBUILD files to compare message digests
and key fingerprints.

Post by Eli Schwartz via arch-general
sha256sums is plenty secure enough. So I assume the Firefox maintainer
uses that mega-file to validate the download, then uses updpkgsums to
update the current sha256sums rather than using copypasta on Firefox's
SHA512SUMS file.

no. you will never use less secure than upstream. the best must be used
to future-proof also.

copypasta? no one said to copy-paste anything without verifying first.

Post by Eli Schwartz via arch-general
Arch Linux doesn't even have a gnupg1 package, if you want to blame
someone for the absolute inability to validate that key on Arch Linux
(independent of makepkg) blame the GnuPG developers for dropping support
of insecure and tremendously outdated keys.

it does not matter. he will download it on his own to verify it,
and then he will add the sha512 message digest in the PKGBUILD file
to future-proof it.

Post by Eli Schwartz via arch-general
Assuming they care about being securely identified on IRC. Maybe they do
connect securely when they care about proving their identity for a
specific conversation where it matters.
I will grant you that for common sense alone you might as well connect
securely whenever possible as it doesn't cost anything. But equally, it
doesn't cost anything to *not* do so.

"With great power comes great responsibility."
-Uncle Ben

AL team members must be responsible with their power.
they must follow best security practices.

Eli Schwartz via arch-general

2016-12-16 05:03:36 UTC

Post by fnodeuser
hello eli,
you have misread and misunderstood a few things.

No I haven't. But you've broken the response headers again in your
reply. Using temporary email addresses on the mailing list is incredibly
annoying; if you are that concerned about your privacy, you will be a
lot happier simply unplugging from the internet altogether.

It is kind of dishonest of you. ;) How do I know it is really you who
sent that? Which is kind of ironic, considering the topic of this thread.

/cc Allan, please blacklist this.

Post by fnodeuser
reread carefully all the messages about the subject,
and check the links in my second email.

I did. That's how I formed my initial conclusions.

Post by fnodeuser
i will write only about things that are not covered by the
previous messages.

Post by Eli Schwartz via arch-general
Sure they're the same. It is the same underlying technology

you have some studying to do about checksums and message digests.

You have some studying to do about nitpicking over implementation
details. Especially because your own Wikipedia links agree with me,
although perhaps you just never read the article so you didn't realize.

But since you are determined to ignore common sense, I'll ask you a
question in response: If "checksums are not suitable for integrity
verification", why do you care? MD5, heck CRC, works just as well as
anything else for preventing data corruption, which apparently is all
you think they are good for.

Post by Eli Schwartz via arch-general
Um, what? `pacman -Syu` does, in fact, check that every package is
signed by a Developer or Trusted User whose key is in archlinux-keyring.

You didn't say that. But now that you do say that, I can tell you that
you are wrong.
On no operating system, does anyone care about that. Only as a byproduct
of source-based operating systems, do some (a small minority of) people
even check that whether they care or not.

The maintainers are maintainers because we trust them to be honest. And
if they aren't honest, you are an absolute fool for thinking you can
check the source in order to catch malicous modifications in the
compiled binaries.

no. you will never use less secure than upstream. the best must be used
to future-proof also.

Yes, I will use less secure than upstream. What matters is that the
Firefox maintainer has proven to himself that he isn't releasing
maliciously-modified source code artifacts into the repositories.

Post by fnodeuser
copypasta? no one said to copy-paste anything without verifying first.

And, you completely missed my point.

it does not matter. he will download it on his own to verify it,
and then he will add the sha512 message digest in the PKGBUILD file
to future-proof it.

But "he" hasn't verified anything. That is the whole point, that ancient
key format isn't secure and doesn't authenticate the message source.

Also, there is no way Arch maintainers will install an AUR package just
so they can read insecure keys to satisfy their curiosity about a package.

"With great power comes great responsibility."
-Uncle Ben
AL team members must be responsible with their power.
they must follow best security practices.

All power corrupts. Absolute power corrupts absolutely.

So if we are going with pop culture quotes, let's just be grateful the
Arch maintainers aren't abusing their positions even more than they
already are.

--
Eli Schwartz

Levente Polyak

2016-12-16 08:59:32 UTC

Post by fnodeuser
what i said is that the users must check the integrity of the sources too.
it is not something that only the package maintainers must do.
the users must check the PKGBUILD files to compare message digests
and key fingerprints.

You didn't say that. But now that you do say that, I can tell you that
you are wrong.
On no operating system, does anyone care about that. Only as a byproduct
of source-based operating systems, do some (a small minority of) people
even check that whether they care or not.
The maintainers are maintainers because we trust them to be honest. And
if they aren't honest, you are an absolute fool for thinking you can
check the source in order to catch malicous modifications in the
compiled binaries.

I agree, there is no point why users _must_ check the integrity of
sources too. Essentially that's what a maintainer should do and you need
to trust a maintainer to some degree anyway. That doesn't mean nobody
should, if a particular group of users wants to, they can. But it is
certainly nothing users _must_ do.
In the AUR, it's of cause a bit different as you have much less trust in
an arbitrary maintainer and want to take a look at the PKGBUILD itself
and also figure out if that's really the right upstream.

no. you will never use less secure than upstream. the best must be used
to future-proof also.

Yes, I will use less secure than upstream. What matters is that the
Firefox maintainer has proven to himself that he isn't releasing
maliciously-modified source code artifacts into the repositories.

Well I fully agree sha256 is plenty secure, if one has the resources and
money (while money is resource :P) to maliciously collide sha256, then
its definitively not the weakest point to attack. Also it is true that
what really matters is the maintainer have proven to himself that he
isn't releasing maliciously-modified source code artifacts.

(not something particularly in response to Eli, but more a general
statement:)
While everybody must agree the only way to know if something _at_ the
endpoint is something from the upstream author is only possible via
authentication by a signature, we still have some possibilities if
that's not the case. The concept for such is TOFU [0] (Trust on first
use). To establish some trust from the maintainers point of view. One
could f.e. do what Giancarlo (grazzolini) and also me is doing:
Downloading the source over multiple _different_ routes/locations/hosts
VPN/SSH and compare the results with each other. Additionally this is
also the case where TLS adds something to the equation, it authenticates
the endpoint itself via a "trusted" certificate authority (yes, we all
know that CAs are far away from being perfect). Once the maintainer has
proven to himself that trust was established as good as possible, a
cryptographically secure integrity value will maintain _this_ trust
level over its lifetime whenever the same must be re-fetched (f.e.
rebuilds or AUR).

Reproducible builds [1] will help to maintain trust but it won't serve
as a replacement for a sloppy maintainer. In the beginning it won't even
prevent that a backdoored package may get release, but it will serve to
detect and find such when doing continuous reproducible tests from
independent parties.
At a further point in time one could integrate the RB concept into the
release management or end-user installation process to prevent users
possibly getting a malicious version because of a tampered source
_after_ the upstream endpoint.
For such, you will need something like staging a package until K out of
N reproducibility sign-offs have happened, where N is the amount of
"trustworthy" builders and K is the minimum number of matches out of
this set (to avoid failure just because one builder is down,
malfunctioning or itself compromised). Even this won't be easy, as you
will need to carefully choose a set of independent trustworthy builders
on the developer side. This would be the easy approach from a end-user
point of view, while a power users may want to themselves choose who a
trustworthy builder is. This would lead to the requirement to choose N
and K during installation time, but as partial upgrades are not possible
this will ultimately result in the inability to upgrade at all if the
amount of matches of a single package is below K.

Whatsoever, reproducible builds is a very complex but ongoing topic. I
will bring this up in an independent way as its an independent area for
itself. I just wanted to dump some info about it as sometimes one gets
the feeling certain people think it will magically allow maintainers so
be sloppy :P In fact I'm right _now_ still sitting in Berlin and one day
has passed since the second reproducible builds world summit. In fact
this is something I'm working on in the background and already have
local patches that will soon be tested on the continuous tests
infrastructure Debian is providing us (thanks again).
Feel free to join #archlinux-reproducible on freenode.

cheers,
Levente

[0] https://en.wikipedia.org/wiki/Trust_on_first_use
[1] https://reproducible-builds.org/

NicoHood

2016-12-16 11:28:06 UTC

Post by Levente Polyak

You didn't say that. But now that you do say that, I can tell you that
you are wrong.
On no operating system, does anyone care about that. Only as a byproduct
of source-based operating systems, do some (a small minority of) people
even check that whether they care or not.
The maintainers are maintainers because we trust them to be honest. And
if they aren't honest, you are an absolute fool for thinking you can
check the source in order to catch malicous modifications in the
compiled binaries.

And for those who want to check the sources, strong hashes are
important. We are talking about integrity, not checksums. It was
intended as checksum, fine. But the integrity ability of those hashes is
ALSO highly important, not only the checksum ability. People can check
all sources, not only the final (reproduceable) build.

We all understood that it would not help the risk of downloading
malicious sources in first place (TOFU). But it would help in the other
(already multiple times described) scenarios. And that is what we are
talking about. We are not talking about checksums. And it would not hurt
in any way to make sha512 the default, **we can only benefit from that.**

Allan McRae

2016-12-16 11:36:58 UTC

Post by NicoHood
make sha512 the default

Hey... guess what is still not happening?

Allan McRae

2016-12-16 11:27:21 UTC

Post by fnodeuser
"With great power comes great responsibility."
-Uncle Ben

I will not have misquotes on this mailing list!

Diego Viola via arch-general

2016-12-16 16:46:15 UTC

Post by fnodeuser
https://lists.archlinux.org/pipermail/arch-dev-public/2016-November/028492.html
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.

NicoHood

2016-12-26 12:12:10 UTC

Post by Diego Viola via arch-general

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?

Allan McRae

2016-12-26 12:21:50 UTC

Post by Diego Viola via arch-general

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?

NicoHood

2016-12-26 12:35:23 UTC

Post by Diego Viola via arch-general

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

Leonid Isaev

2016-12-27 17:09:55 UTC

Post by NicoHood
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

Jürgen Hötzel

2016-12-28 18:26:14 UTC

On Tue, Dec 27, 2016 at 6:09 PM, Leonid Isaev <

Post by NicoHood
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.powershell.utility/get-filehash

Jürgen

Post by Leonid Isaev
Cheers,
--
Leonid Isaev

Eli Schwartz via arch-general

2016-12-27 18:37:31 UTC

Post by NicoHood
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.

Post by NicoHood
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...

Post by NicoHood
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?

Post by NicoHood
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/

Florian Pritz via arch-general

2016-12-26 12:59:29 UTC