[aur-general] TU Application: Baptiste Jonglez

[Giancarlo Razzolini]

Em dezembro 1, 2016 20:37 Baptiste Jonglez escreveu:
> 
> You almost sound like I'm opposing all forms of "security" (whatever you
> mean by that).  Of course we should promote the use of TLS and HTTPS on
> the Internet, even though the trust model is flawed and implementations
> are bloated/bugged.

I don't think Nico is saying that you oppose security. And I agree that
the CA model is practically broken. But we have alternatives to improving
the trustworthiness of that model. The recent HPKP RFC is one of those.
There are also preload lists, even though most of the software used to get
the sources do not use them.

> 
> My point is that in the context of packaging, we have different
> requirements than for web browsing.  HTTPS does not provide authenticity
> and integrity of the sources themselves, which is what we are interested
> in.  PGP (preferably) and strong hash algorithms (as a substitute) should
> be used for that.
>

Yes, preferably upstream must provide PGP signed sources. HTTPS only prevent
tampering in transit, which is nice, but it doesn't guarantee you didn't got
tampered software from upstream.

> 
> Besides this issue, I already mentioned another drawback of using HTTPS:
> untrusted certificates (either expired, self-signed, or just signed by an
> untrusted CA) will cause build failure.  This was a real issue for
> OpenWRT, so they switched to using --no-check-certificate in 2010 [1] to
> avoid build failures.  Sources are already validated with a checksum.
>

Well, relying only on checksums is not good enough in my opinion. We know
for a fact that hashing algorithms are built on top of *reasonable* chance
that collisions won't happen. Sure, the space of a SHA256 hash is huge, but
we must not just shrug over it. Because if we, as maintainers do, upstream
will think they don't need to provide signed sources, because hashes are
probably "good enough".

> Anyway, some of my packages do not use HTTPS, and this is indeed mostly
> because of laziness.  I consider this is a low priority task.
> It does not mean that I am fundamentally opposed to the use of HTTPS,
> especially for "big" providers like github which are not very likely to
> have expired certs.
> 
> I had a look at the sources for my AUR packages, and here is the result:
> 
> - 5 fetched over HTTPS
> - 7 fetched over git+https://
> 
> - 5 fetched over HTTP, with no HTTPS available
> - 1 fetched over FTP, with no HTTPS available
> 
> - 5 fetched over HTTP while HTTPS is available (including 1 with a PGP signature)
> - 6 fetched over git:// while git+https:// is available
> 
> So, less than half of them needed to be "fixed".  I just switched to HTTPS
> for 10 out of the 11 fixable packages.  The only remaining one is
> linux-mptcp, because I plan to move it away from git soon anyway.
> 

The one thing I can take away from all this HTTPS or not discussion is
that we as maintainers are specially vulnerable. If we don't use whatever
tools at our disposal to be completely sure we didn't got the right source,
who knows how long those changes will go undetected? Heck, it's hard enough
finding bugs on *open source* software. Finding "intentional" ones on binaries
is harder.

Cheers,
Giancarlo Razzolini
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 870 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20161202/8259f66f/attachment.asc>