Re: [arch-dev-public] todo list for moving http -> https sources
[2016-10-31 15:19:40 +0100] NicoHood: > I'd also vote for https. It does not hurt to use a secure channel to > download the sources from. It would be great if we as ArchLinux team > could make the first step into that direction. > > Using PGP signatures is another discussion, also the hash algorithm. I > think we should discuss that in another post, appart from https. From my > point of view its highly important to use a strong hash function as its > highly important for the source integrity and not only meant as checksum > for corruption detection. You know HTTPS uses hash functions too, right? And you know they are in many cases much weaker than those GnuPG uses by default, right? -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] todo list for moving http -> https sources
[2016-10-31 10:05:26 -0400] Dave Reisner: > On Sun, Oct 30, 2016 at 04:43:04PM -1000, Gaetan Bisson wrote: > > I agree with Sébastien. We should encourage upstream to digitally sign > > their releases, and verify their authenticity in our PKGBUILDs. > > > > Downloading releases over HTTPS gives a false sense of security: > > everybody knows the CA model is severely broken. In terms of security > > this simply does not compare with OpenPGP... In my view, switching our > > download links to HTTPS is nothing but an annoyance. > > The CA model is broken. http clients have bugs. http servers have bugs. > pgp has bugs. sovereign states might be snooping on connections. None of > these are reasons to avoid an attempt at providing another layer of > security. That's all TLS is and I'm not suggesting it's some panacea. > > Asking every upstream to provide a PGP signature isn't a process which > will scale, and some of them will likely not be interested in doing such > a thing. If an upstream won't provide PGP signatures, do you have > another suggestion as to how we can secure our process of obtaining > upstream sources in a reliable manner? All the nuances in my message were apparently lost on you... I said OpenPGP provides a much higher degree of security than HTTPS, so that's what we should strive to use. Obviously, for cases where digital signatures aren't available, downloading sources over HTTPS is better than nothing. What I argued, however, is that it's not much better than nothing, so we shouldn't become complacent and trust sources just because they came over TLS. Cheers. -- Gaetan
Re: [arch-dev-public] todo list for moving http -> https sources
On Mon, Oct 31, 2016 at 03:33:42PM -0400, Dave Reisner wrote: > On Mon, Oct 31, 2016 at 08:14:32PM +0100, Thomas Bächler wrote: > > Am 31.10.2016 um 15:05 schrieb Dave Reisner: > > > Asking every upstream to provide a PGP signature isn't a process which > > > will scale, > > > > I am against enforcing https for projects which provide signatures. As > > Sebastien pointed out, there are valid reasons against using https and > > it adds no benefit when using signatures. > > IMO, Sebastien didn't really provide any compelling evidence that > switching to https would be an incumberance -- rather, a minor > inconvenience at worst. > > Do you have other reasons to add? I'd be very interested to know why > this is a problem. We already have a large number of sources fetched > over https including several which include gpg signatures. Do you want > to revert those to http? Why or why not? To put some ballpark numbers to this with some simple grep'ing over the PKGBUILD tree and my initial scripting work... - We have 4539 sources fetched over https - 193 of those 4539 sources also include a pgp signature - 2169 more sources could be fetched over https instead of http - 597 of those 2169 sources could include a https-fetched pgp signature > > However, I agree that asking every single author to provide signatures > > is likely infeasible. > > > > > and some of them will likely not be interested in doing such > > > a thing. > > > > Having no interest in signing your work is surely a bad sign. Maybe we > > should look into dropping such software where we can. > > I don't really think you believe this... > > > > If an upstream won't provide PGP signatures, do you have > > > another suggestion as to how we can secure our process of obtaining > > > upstream sources in a reliable manner? > > > > You can't. > > > > We could mirror the sources and sign them ourselves, but that would > > require that we actually audit the sources somehow. > > > > This, too, does not scale, and might even constitute a breach of the > software's license.
Re: [arch-dev-public] todo list for moving http -> https sources
On Mon, Oct 31, 2016 at 08:14:32PM +0100, Thomas Bächler wrote: > Am 31.10.2016 um 15:05 schrieb Dave Reisner: > > Asking every upstream to provide a PGP signature isn't a process which > > will scale, > > I am against enforcing https for projects which provide signatures. As > Sebastien pointed out, there are valid reasons against using https and > it adds no benefit when using signatures. IMO, Sebastien didn't really provide any compelling evidence that switching to https would be an incumberance -- rather, a minor inconvenience at worst. Do you have other reasons to add? I'd be very interested to know why this is a problem. We already have a large number of sources fetched over https including several which include gpg signatures. Do you want to revert those to http? Why or why not? > However, I agree that asking every single author to provide signatures > is likely infeasible. > > > and some of them will likely not be interested in doing such > > a thing. > > Having no interest in signing your work is surely a bad sign. Maybe we > should look into dropping such software where we can. I don't really think you believe this... > > If an upstream won't provide PGP signatures, do you have > > another suggestion as to how we can secure our process of obtaining > > upstream sources in a reliable manner? > > You can't. > > We could mirror the sources and sign them ourselves, but that would > require that we actually audit the sources somehow. > This, too, does not scale, and might even constitute a breach of the software's license.
Re: [arch-dev-public] todo list for moving http -> https sources
Am 31.10.2016 um 15:05 schrieb Dave Reisner: > Asking every upstream to provide a PGP signature isn't a process which > will scale, I am against enforcing https for projects which provide signatures. As Sebastien pointed out, there are valid reasons against using https and it adds no benefit when using signatures. However, I agree that asking every single author to provide signatures is likely infeasible. > and some of them will likely not be interested in doing such > a thing. Having no interest in signing your work is surely a bad sign. Maybe we should look into dropping such software where we can. > If an upstream won't provide PGP signatures, do you have > another suggestion as to how we can secure our process of obtaining > upstream sources in a reliable manner? You can't. We could mirror the sources and sign them ourselves, but that would require that we actually audit the sources somehow. signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] todo list for moving http -> https sources
I'd also vote for https. It does not hurt to use a secure channel to download the sources from. It would be great if we as ArchLinux team could make the first step into that direction. However if you write such a script, it should also check if an https download is available, as not all websites provide https downloads yet (sadly). Using PGP signatures is another discussion, also the hash algorithm. I think we should discuss that in another post, appart from https. From my point of view its highly important to use a strong hash function as its highly important for the source integrity and not only meant as checksum for corruption detection. And as always: more secure does not hurt nowadays Cheers, Nico signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] todo list for moving http -> https sources
On Sun, Oct 30, 2016 at 04:43:04PM -1000, Gaetan Bisson wrote: > [2016-10-31 03:23:48 +0100] Sébastien Luttringer: > > On Sun, 2016-10-30 at 20:55 -0400, Dave Reisner wrote: > > > There's been a sizeable number of bugs filed over the past month or so > > > about changin PKGBUILDs to acquire sources from https rather than http. > > > Rather than continue to flood the bug tracker, would anyone mind if I > > > wrote a script to find instances of this and start a TODO list? This > > > would, of course, be low priority. Even if no one does anything, we at > > > least have a statement of work and can avoid having these "bugs" > > > littered around flyspray. > > > > > > Unless there's strong opposition to this (and I'd be very interested to > > > know why), I'll polish up my automation and create the list. > > > > The few BR that reached me also requested the addition of a .sig. > > 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. > > > > Except the confidentiality of the request, what's the point to force https? > > I agree with Sébastien. We should encourage upstream to digitally sign > their releases, and verify their authenticity in our PKGBUILDs. > > Downloading releases over HTTPS gives a false sense of security: > everybody knows the CA model is severely broken. In terms of security > this simply does not compare with OpenPGP... In my view, switching our > download links to HTTPS is nothing but an annoyance. The CA model is broken. http clients have bugs. http servers have bugs. pgp has bugs. sovereign states might be snooping on connections. None of these are reasons to avoid an attempt at providing another layer of security. That's all TLS is and I'm not suggesting it's some panacea. Asking every upstream to provide a PGP signature isn't a process which will scale, and some of them will likely not be interested in doing such a thing. If an upstream won't provide PGP signatures, do you have another suggestion as to how we can secure our process of obtaining upstream sources in a reliable manner? d
[arch-dev-public] Signoff report for [testing]
=== Signoff report for [testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 2 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 6 fully signed off packages * 47 packages missing signoffs * 2 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == New packages in [testing] in last 24 hours (2 total) == * vim-8.0.0055-1 (i686) * vim-8.0.0055-1 (x86_64) == Incomplete signoffs for [core] (17 total) == * gpgme-1.7.1-2 (i686) 0/1 signoffs * gssproxy-0.5.1-2 (i686) 0/1 signoffs * hdparm-9.50-1 (i686) 0/1 signoffs * libarchive-3.2.2-1 (i686) 0/1 signoffs * libpcap-1.8.1-1 (i686) 0/1 signoffs * libssh2-1.8.0-1 (i686) 0/1 signoffs * nano-2.7.1-1 (i686) 0/1 signoffs * pciutils-3.5.2-1 (i686) 0/1 signoffs * perl-5.24.0-3 (i686) 0/1 signoffs * shadow-4.4-3 (i686) 0/1 signoffs * xfsprogs-4.8.0-1 (i686) 0/1 signoffs * gpgme-1.7.1-2 (x86_64) 1/2 signoffs * gssproxy-0.5.1-2 (x86_64) 0/2 signoffs * libssh2-1.8.0-1 (x86_64) 1/2 signoffs * nano-2.7.1-1 (x86_64) 1/2 signoffs * pciutils-3.5.2-1 (x86_64) 1/2 signoffs * xfsprogs-4.8.0-1 (x86_64) 0/2 signoffs == Incomplete signoffs for [extra] (30 total) == * seabios-1.10.0-2 (any) 0/2 signoffs * ardour-5.4-1 (i686) 0/1 signoffs * kdebase-runtime-16.08.2-3 (i686) 0/1 signoffs * kdepimlibs4-4.14.10-11 (i686) 0/1 signoffs * libbluray-0.9.2-3 (i686) 0/1 signoffs * libglvnd-0.1.1.20161028-1 (i686) 0/1 signoffs * liblangtag-0.6.2-1 (i686) 0/1 signoffs * linux-zen-4.8.5-1 (i686) 0/1 signoffs * lv2-1.14.0-2 (i686) 0/1 signoffs * nasm-2.12.02-1 (i686) 0/1 signoffs * nvidia-375.10-1 (i686) 0/1 signoffs * nvidia-lts-375.10-1 (i686) 0/1 signoffs * nvidia-utils-375.10-2 (i686) 0/1 signoffs * postgresql-9.6.1-2 (i686) 0/1 signoffs * postgresql-old-upgrade-9.5.5-1 (i686) 0/1 signoffs * vim-8.0.0055-1 (i686) 0/1 signoffs * ardour-5.4-1 (x86_64) 0/2 signoffs * kdebase-runtime-16.08.2-3 (x86_64) 0/2 signoffs * kdepimlibs4-4.14.10-11 (x86_64) 0/2 signoffs * libbluray-0.9.2-3 (x86_64) 1/2 signoffs * libglvnd-0.1.1.20161028-1 (x86_64) 0/2 signoffs * liblangtag-0.6.2-1 (x86_64) 0/2 signoffs * linux-zen-4.8.5-1 (x86_64) 1/2 signoffs * lv2-1.14.0-2 (x86_64) 0/2 signoffs * nasm-2.12.02-1 (x86_64) 0/2 signoffs * nvidia-lts-375.10-1 (x86_64) 0/2 signoffs * nvidia-utils-375.10-2 (x86_64) 0/2 signoffs * postgresql-9.6.1-2 (x86_64) 0/2 signoffs * postgresql-old-upgrade-9.5.5-1 (x86_64) 0/2 signoffs * vim-8.0.0055-1 (x86_64) 0/2 signoffs == Completed signoffs (6 total) == * hdparm-9.50-1 (x86_64) * libarchive-3.2.2-1 (x86_64) * libpcap-1.8.1-1 (x86_64) * perl-5.24.0-3 (x86_64) * shadow-4.4-3 (x86_64) * nvidia-375.10-1 (x86_64) == All packages in [testing] for more than 14 days (2 total) == * libbluray-0.9.2-3 (i686), since 2016-05-08 * libbluray-0.9.2-3 (x86_64), since 2016-05-08 == Top five in signoffs in last 24 hours == 1. polyzen - 5 signoffs 2. indrajitr - 5 signoffs 3. jasonwryan - 3 signoffs 4. Irishluck83 - 2 signoffs 5. yan12125 - 2 signoffs
