[aur-general] TU Application: Baptiste Jonglez

[Baptiste Jonglez]

Hi Nicohood,

On Thu, Dec 01, 2016 at 04:23:27PM +0100, NicoHood wrote:
> you do not need to move the packages as fast as possible into
> community. I became TU month ago and arduino is still not in community
> because some issues needed to be solved first. So quality and security
> is more important here.

Agreed.

> About all this https discussion:
> I think we should all confirm with the gpg and https standards we made
> recently (and the string hashes that i suggested) and we should also try
> to increase the quality of AUR in general and especially as TU to advise
> other people to do so too.
> Packaging a secure chat program and being so lazy about https makes me
> wonder.
> 
> I think it'd be good for you to rethink the https (and gpg, hash) topic,
> because (especially) as secure chat messenger packager it'd be extremely
> important to me that you try to achieve the best security as possible.

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.

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.

To avoid repeating the same arguments, I agree with what seblu said on
arch-dev-public:

On Tue, Nov 01, 2016 at 04:03:04PM +0100, Sébastien Luttringer wrote:
> TLS is about security of the transportation of sources, not the security
> of sources themselves, that's why I asked, to know what you had in mind.
> 
> My definition of securing the sources, is a way to trust the sources at
> the build time, no matter the way they were fetched. I want to be sure
> that my sources are "correct" even if I get them by usb key, ftp, rsync
> or even if they were not corrupted locally by a btrfs bug.  And when
> possible, I want to be sure that the server (mirror or not) was not
> compromised (even at the first fetch).
> 
> Keeping that in mind, enforcing tls, doesn't improve much the source
> security.  In fact, it improves only security during the transportation
> of the sources at the cost of the caching.

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.

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.

Baptiste

[1] https://git.lede-project.org/?p=openwrt/source.git;a=blobdiff;f=scripts/download.pl;h=633a4f6f7d;hp=fe27df5e8f;hb=65fad8645d;hpb=5884b43b51
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20161201/c2d347ce/attachment.asc>