[arch-dev-public] todo list for moving http -> https sources

[Sébastien Luttringer]

On Sun, 2016-10-30 at 22:47 -0400, Dave Reisner wrote:
> On Mon, Oct 31, 2016 at 03:23:48AM +0100, Sébastien Luttringer wrote:
> > On Sun, 2016-10-30 at 20:55 -0400, Dave Reisner wrote:
> > As I use a transparent http cache at home (2Mb/s bandwidth), so far I only
> > added the signature, and not the https as it breaks the cache.
> 
> This doesn't seem to hold much weight. You're duplicating the source
> tarball now, as it exists (on disk?) in your http cache and in makepkg's
> SRCDEST. I'm not sure I see the benefit to doing this, particularly
> since the caching in SRCDEST is entirely agnostic to the protocol used
> to fetch it.
> 
Over the time, I found a problem using $SRCDEST; it doesn't check if upstream
sources have been modified since. I've been tricked few times, releasing
packages with my local tarballs and not the one available to others.
Maybe it's something which can be improved directly in makepkg.

My point was to explain why I didn't already switched to https on all my
packages, and see if we have a place in our rules for letting this happen, or
if we want enforce the all case.
This, in some way, reduce the choice of the maintainer to select which sources
he prefers.

I didn't bring that as a show stopper for improving the source transport
security.


> > Except the confidentiality of the request, what's the point to force https?
> 
> Security of sources, particularly those which we obtain without any
> upstream verification mechanism such as a checksum or PGP signature.
> Even for those with signatures or checksums, you must consider that
> security is not a binary thing, and is always approached in layers.
> 
I understand security is not binary.

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.
So, even though I a partisan of tls everywhere, I still balanced by the
caching.


Cheers,

-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 793 bytes
Desc: This is a digitally signed message part
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20161101/3f04e18a/attachment.asc>