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
signature.asc
Description: This is a digitally signed message part
