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/
Attachment:
signature.asc
Description: OpenPGP digital signature
