[arch-general] Stronger Hashes for PKGBUILDs

[Levente Polyak]

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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20161216/f984e279/attachment.asc>