On Mon, 2014-06-23 at 08:58 +1000, Russell Stuart wrote: > > Well first, AFAIK, there are no mirrors for the BTS... and then > > securing something like BTS with OpenPGP is quite difficult. > There is a straight forward solution to handling BTS messages. You just > DKIM sign them with an appropriate key when they are received. Maybe my understanding of DKIM is too little... but I thought it would be only some technique to verify the authenticity of sender addresses? And as I've said... just signing somehow all the single mails that arrive at the BTS, which could be verified by clients when they read it is not enough. That would allow an attacker to easily filter out single messages... somehow you need to secure the series of all messages,... and also things like negative replies (e.e. "there is no bug for package xyz). And since many people interact with the BTS via web (well at least for reading) you're anyway obliged to support some https solution. > > Given that these services are used more and more for development, I > > think it's more and more important to secure them as far as possible. > 90% of what you want could be achieved with a working version of > Certificate Patrol. Well CP is at first unmaintained and it has many issues... and lacks many features (like telling it exactly which cert and or 1-n CAs to expect for a domain)... Then you have the problem that people don't just access https content via browsers, where one can easily integrate something like CP... they may make use of https in svn, git, etc. So you'd have to write something like CP for all these tools. And even if that would be done... you still have the main problem - and regardless of what you say this won't go away since it's an inherent problem of any strictly hierarchical PKI - that you cannot guarantee full security when you need trust some untrustworthy CA (i.e. any CA that is not under our - Debian's - control). Even if you have some pinning technique like CP in place,... than a non-Debian rogue CA can simply attack you on your first visit of https://whatever.debian.org/ and your CP is useless. > Ship it as a standard part of iceweasel, pre > configured with a few certs and enabled by default. Well again,... it's not only iceweasel that would needed to be secured but any other browser, git, svn, etc. pp. And even if you'd do that (really hardcoding the actual host certs)... than you have a completely unmaintainable system... you need to patch all programs for any new Debian host cert, for any one that expires or is revoked. This is probably 100 times the efforts of running a own CA. > That nice thing about getting Certificate Patrol working is it helps > everyone - not just Debian. Again... using CP alone won't make things secure - unless you really hard code all the single Debian host certs in all programs that use TLS/SSL (or at least with Debian services). And actually... just hard coding all our host certs wouldn't be enough... code would need to be added, that no other (i.e. non-hard-coded) cert may be used for any debian.org/net service. IMHO far too much effort. It's much easier to run our own Debian CA plus: - for most non-browser programs that allow to specify which CAs are trusted, only add that Debian CA - for browsers: hard code that Debian CA as the only one for debian.org| net Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature