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

Attachment: pgpiffeAQb4KW.pgp
Description: PGP signature

Reply via email to