Florian Weimer writes ("Re: buildds: "Authentication warning overridden.""): > In this case, HTTPS should be used to download the packages, together > with proper certificate validation. This has got the added benefit that > passwords aren't sent in the clear (well, unless an error occurs, but > this is a separate issue).
https is a pretty poor protocol because it usually suffers from dreadful key management. In this case it might be workable but for this specialised application it's probably not worth the effort to add https support to apt (indeed, I would suggest that apt ought _not_ get gain https support because that would lead people to use https in the usual way - ie inappropriately). Better would be to arrange for apt's usual signature checking mechanisms to work. I understand that the incoming directory can't be signed with any of the usual keys because that would require a human to make the key available and authorise the signature. But it would perhaps be possible to generate a dedicated key which is used to sign incoming only for the benefit of the buildds, and to install the corresponding public half in the buildds' configs. That would involve providing a Release file for incoming of course. The key could even be automatically changed on a regular basis, with the public half distributed via ssh. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]