Hi, (after I've started to play with dgit today — and very much like it so far! — a friend pointed me to this bug)
Ian Jackson: > The ftpmaster api service is currently provided over HTTP over TLS, > based on with a standard X.509 web PKI cert from Let's Encrypt. > We want, instead, those API queries to be secured by a public key > shipped in a Debian packge. Getting rid of any third-party root of trust would be awesome. But given this bug is 4 years old, perhaps a mitigation would be a reasonable first step until a complete solution is found? I'd like to propose this mitigation: Use only outgoing HTTPS connections if the remote peer can be correctly authenticated using a certificate signed by Let's Encrypt Assuming an adversary who can do active MitM attacks between the dgit client and the host that exposes the ftpmaster API, this would effectively downgrade the current problem, that is: dgit is subvertable by X.509 CA cabal to: dgit is subvertable by an adversary who can get a certificate signed by the Let's Encrypt CA for the hostname that exposes the ftpmaster API I did not implement such CA pinning with LWP recently (the current code I have that does exactly this uses WWW::Curl instead) but IIRC this is doable with LWP too. Cheers, -- intrigeri
