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
pgpgvMkDOSk3W.pgp
Description: PGP signature
