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

[Dave Reisner]

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.