* Matthew Toseland <toad at amphibian.dyndns.org> [2008-12-16 00:14:58]:
> On Monday 15 December 2008 23:58, Florent Daigni?re wrote: > > * Matthew Toseland <toad at amphibian.dyndns.org> [2008-12-13 19:20:21]: > > > > > On Saturday 13 December 2008 18:57, Florent Daigni?re wrote: > > > > * Matthew Toseland <toad at amphibian.dyndns.org> [2008-12-13 18:01:03]: > > > > > > > > > On Saturday 13 December 2008 17:22, Florent Daigni?re wrote: > > > > > > > > In any case we are NOT protected from the compromise of emu nor > by > > > the > > > > > > > > compromise of the key used to sign the installer. > > > > > > > > > > > > > > Exactly. Right now we build both the installers and the jars on > emu. > > > If > > > > > emu is > > > > > > > compromised, it can supply bogus installers and bogus jars. If we > move > > > the > > > > > > > building of the installers off emu (which requires having some > idea > > > how to > > > > > > > build it from cleanroom, it's a rather involved process iirc), > > > > > > > emu > can > > > > > still > > > > > > > supply bogus jars, so we are vulnerable to both machines being > > > > > compromised. > > > > > > > However, if we don't update the installer very often, our > > > > > > > exposure > on > > > that > > > > > > > side is minimal. But isn't it still safer to generate both on > > > > > > > emu? > Or > > > to > > > > > > > generate and sign both on some other machine, which would have to > be > > > > > reliable > > > > > > > and secure? (amphibian.dyndns.org is powerful but not reliable). > > > > > > > > > > > > Which part of " > > > > > > > > > > > > - in case the installer's key is compromised, only *new* nodes are > at > > > risk > > > > > > - in case the updater's key is compromised, only *automatically > updated* > > > > > > nodes are at risk > > > > > > - in case emu is compromised, only *manually updated* nodes are at > risk > > > > > > > > > > AND new nodes. But okay. > > > > > > > > No, installers shouldn't ship emu's bytecode either. > > > > > > They should bundle locally-built bytecode then? > > > > Yes. It's the signer's responsibility to ensure that the produced > > bytecode he is signing is "good". > > > > > And we'd just use emu for update.sh testing? > > > > Yes... and catastrophic manual updates, shall the auto-updater be > > broken. > > Should we build the snapshots for update.sh testing on emu? Should we? No! May we? Yes because it's convenient Usually build-bots are using completely separated platforms. > > > > > Or do we need yet another key, this one automated, to > > > auto-build the jars off emu and then upload them to emu? > > > > No; that wouldn't be a good idea imo. > > Anyway we have SSL already. > > > > > > > > > > > > " don't you understand? > > > > > > > > > > > > In case you store the keys on emu OR make the installer publish > emu's > > > > > binaries, > > > > > > you do jeopardize the overall security of the system. > > > > > > > > > > > > It's all about mitigating risks by using different "domains". > > > > > > > > > > In which case: > > > > > 1. You would have no objection to me building a windows installer, > > > > > and > us > > > > > hosting it on emu? > > > > > > > > If you mean "using emu to distribute it on the mirror network" that's > > > > fine by me; If you really mean distributing a xxMB file from emu it's > > > > not. > > > > > > Obviously using the mirror network. > > > > Fine then :) > > > > > > > > > > > 2. We should move the process of building and signing the installer > off > > > emu to > > > > > my computer (and yours if you still want to build them). Each person > able > > > to > > > > > build an installer should have a separate certificate derived from > > > > > the > > > master > > > > > key, listing both their name and the Freenet Project Inc. > > > > > > > > Yes. > > > > > > > > > Agreed? Implementing the latter in a cleanroom fashion will require > that I > > > > > have some idea how to build the installer, it's a somewhat convoluted > > > process > > > > > to get it set up > > > > > > > > Checkout, do "ant"; what's convoluted exactly? > > > > > > You need izPack and the launcher binaries in various places iirc ... > > > > Yes, you need your copy of izPack. Building the online installer is > > straightforward... building the offline one is a bit trickier as you've > > to "tell" the installer where the required packs are. > > > > [snip.] > > > > > > > > > > I'm not arguing we should invest $ into getting a signed certificate. I > > > > am sure we have professional developers here who do have a valid, > > > > trusted certificate. > > > > > > Whom we can trust? Such as? > > > > I don't think it's a matter of trust here; well, I don't know; I do have > > one for instance and I'm sure we could find others if we asked. > > > > Would anyone reading this mailing list volunteer to build and sign one > > of our installers? > > IMHO it is a matter of trust as much as anything. It shouldn't be up to us trusting someone: it's the user's responsibility to trust or not the guy who packaged the installer he is going to use. That's why we introduce a 3rd party here! In case of debian you trust the packager for being honest; he doesn't even have to be endorsed by upstream. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20081216/fbf5907f/attachment.pgp>
