[arch-general] Stronger Hashes for PKGBUILDs
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.
Sure they're the same. It is the same underlying technology
you have some studying to do about checksums and message digests.
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.
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.
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.
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.
On 12/15/2016 08:35 PM, fnodeuser wrote:
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.
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.
i will write only about things that are not covered by the previous messages.
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.
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.
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.
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.
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.
copypasta? no one said to copy-paste anything without verifying first.
And, you completely missed my point.
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.
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.
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.
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
On 12/16/2016 06:03 AM, Eli Schwartz via arch-general wrote:
On 12/15/2016 08:35 PM, fnodeuser wrote:
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.
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.
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/
On 16/12/16 11:35, fnodeuser wrote:
"With great power comes great responsibility." -Uncle Ben
I will not have misquotes on this mailing list!
On 12/16/2016 09:59 AM, Levente Polyak wrote:
On 12/16/2016 06:03 AM, Eli Schwartz via arch-general wrote:
On 12/15/2016 08:35 PM, fnodeuser wrote:
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.
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.**
On 16/12/16 21:28, NicoHood wrote:
make sha512 the default
Hey... guess what is still not happening?
participants (5)
-
Allan McRae
-
Eli Schwartz
-
fnodeuser
-
Levente Polyak
-
NicoHood