On 12/12/2017 06:59, Poul-Henning Kamp wrote: > -------- > In message <86d13kgnfh....@desk.des.no>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= > w > rites: >> "Poul-Henning Kamp" <p...@phk.freebsd.dk> writes: >>> The only realistic way for the FreeBSD project to implement end-to-end >>> trust, is HTTPS with a self-signed cert, distributed and verified >>> using the projects PGP-trust-mesh and strong social network. >> Your suggestion does not remove implicit and possibly misplaced trust, >> it just moves it from one place to another. Instead of trusting a >> certificate authority and DNS, you trust the source of the public key, >> and probably also DNS. As always, it boils down to a) key distribution >> is hard and b) what's your threat model? > I don't think I agree with any of that ? > > With respect to authenticity of the FreeBSD SVN repo I cannot > imagine anybody else being even one percent as qualified and > trustworth as the FreeBSD projects own core-team. > > In particular I would never trust any "In the CA-racket for the > money" organization to do so. > > If you are worried that the FreeBSD project "staff" cannot > handle a root-cert competently, then the exposure is no > smaller or larger than if it was a CA-signed cert they fumbled. > > Trusting DNS doesn't apply it if the project root-cert was > stored on my local machine after I used my best judgement of PGP > signatures to conclude that it was authentic. > > And I don't really see distribution of this particular key being > difficult at all: We already PGP sign release checksums for > authenticity and it the FreeBSD root-cert is just another file to > get same treatment. > > Poul-Henning Agreed.
Now the question becomes this -- is the proper means to handle this via TLS (using that root cert) OR should the *transport* be fixed so that https doesn't need to be used? I argue the second, because the goal when it comes to source distributions is ensuring that the code you transfer is bit-wise identical to the code on the FreeBSD project repositories *which can be mirrored.* Attempting to "overload" TLS with this responsibility now requires that the project take operational and security responsibility for the integrity of any *mirror* of said code, which is IMHO flatly unreasonable and thus is simply not going to happen. Otherwise you can have all the assurance you want that the bits you get are the bits that were on the disk at the other end, but no assurance at all that the bits on the disk *are the same as the bits on the FreeBSD project's machines!* Solve the problem at the correct location -- either fix svn to sign and verify updates or dump it for something that can and use that existing mechanism (e.g. git) -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/
smime.p7s
Description: S/MIME Cryptographic Signature
