On 05/21/2014 12:43 PM, Seth David Schoen wrote: > Daniel Kahn Gillmor writes: > >> This sounds very much like the idea of certificate transparency (CT), >> but applied to source code or binaries. Have you considered raising >> this with the CT folks? I'm also interested in seeing something like >> this in other contexts (e.g. debian and other OS distributions) and if >> we had a simple, generic way to ensure that everyone was getting the >> same code as everyone else, that would be very nice. >> >> I recognize that debian might have some slightly different challenges in >> terms of logs than just an HTTPS-E ruleset update; but if you're >> interested in exploring where those mechanisms might overlap, i'd be >> happy to have that conversation with you. > > I've made this comparison explicitly in a couple of talks recently, but > I haven't made contact with the CT developers about it. I think it would > be quite productive; another question is whether this deserves (or already > has?) its own mailing list somewhere.
I agree that this ensuring public verifiability of software update metadata should not become part of Zack's GSoC project. :) I brought up a similar idea informally to some WebAppSec folks, and they were not aware of anyone working on something like CT for software updates in the web app world, at least. Perhaps we should form a software-transparency mailing list? -- Yan Zhu <[email protected]>, <[email protected]> Staff Technologist Electronic Frontier Foundation https://www.eff.org 815 Eddy Street, San Francisco, CA 94109 +1 415 436 9333 x134
signature.asc
Description: OpenPGP digital signature
_______________________________________________ HTTPS-Everywhere mailing list [email protected] https://lists.eff.org/mailman/listinfo/https-everywhere
