Re: [gentoo-dev] Re: ca-certificates PDEPEND

[Brian Harring]

On Mon, Jan 09, 2006 at 05:28:04PM +0100, Andrea Barisani wrote:
> On Mon, Jan 09, 2006 at 05:21:42PM +0100, Jakub Moc wrote:
> >
> > 9.1.2006, 17:12:31, Andrea Barisani wrote:
> >
> > > On Mon, Jan 09, 2006 at 11:08:38AM -0500, solar wrote:
> >
> > >>
> > >> Do you think the PDEPEND of the ca-certs should be tied to a USE= flag?
> > >> If so should it be a 'no*certs' flag or a USE=cacerts ?
> >
> > > USE=cacerts sounds the proper course of action to me.
> >
> > NOT until use-based deps are in place, plzktnxbye!!! Don't break the damned
> > realplayer thing again.
>
> It's the realplayer thing that should be fixed. Can't believe that
> ca-certificates got relatively quiet as a PDEPEND because of that ;).

I bitched for exactly that; we can't mirror their files, and having 
the package non fetch restricted is questionable from a license 
standpoint anyways.

Either way, one thing that *should* be noted here is that this still 
doesn't totally fix the issue for realplayer.  Curl won't honor/use 
the cacerts package for example, so we still have the same bug, just 
different fetcher.

Adding cacerts to the pdepend effectively is expansion of allowed 
SRC_URI targets- right now we require all uri to be on standards ports 
(443, 80) for restricted networks.  Now, via this change, we require 
FETCHCOMMAND to be a binary that supports cacerts.

We also require any https proxy to support/allow cacerts also, if my 
understanding of https proxying is correct.

Finally, this also requires infra to now run with cacerts on for the 
master mirroring box.

Basically... I'm still against this change.  We require fetchers that 
support http, and support the standard chain of trust for https.  I 
don't like changing the restrictions just for a (bluntly) stupid 
upstream that forces downloads through https.

~harring