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? And we'd just use emu for update.sh testing? Or do we need yet another key, this one automated, to auto-build the jars off emu and then upload them to emu? > > > > " 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. > > > 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 ... > > > and we really shouldn't just rsync the binaries from emu. > > Why? They are signed; that's how I did it. > > > But on the other hand, a directory listing and maybe a copy of the current > > build script is probably enough to reconstruct it. > > Hmmm, I guess we have different definitions of clean-rooms. You > shouldn't take anything but source code out of emu to build it. I meant about the IzPack and other supporting binaries. > > > > > > > RESOLUTION: IMHO the current system works fine. Nextgens has stated > > his > > > > > > intention not to participate in any further discussions about the > > > > installer, > > > > > > so we'll ignore him. > > > > > > > > > > "works fine until we get rooted". As you have strongly emphasised on how > > > > > insecure your boxes are and described in details how things work, my > > > > > guess is that it will happen soon. > > > > > > > > Perhaps. Emu has been rooted at least twice. A professional could probably > > > > root either machine without us ever knowing, modern rootkits are scary. > > > > > > I'm not convinced you need to be a professional to do it; nor that > > > targeting emu is the way I would go if I wanted to do it :) > > > > Granted. > > > > > > > We already build installers on emu. > > > > > > BECAUSE YOU FORCED ME TO. It's not because we use to do something silly > > > that we should extend that behaviour instead of fixing it. > > > > Okay so lets fix it. > > > > > > > And you have not yet convinced me that it > > > > would be beneficial to build the installer elsewhere and the code on emu. > > > > > > I was assuming you did understand the security argument. Obviously you > > > didn't :/ > > > > You have explained it now, it makes a reasonable amount of sense. Although in > > practice we are probably in deep trouble whatever we do. > > > > > > > We > > > > could build both on the same third party box, this might marginally reduce > > > > our vulnerability to e.g. bytemark, but it means maintaining and securing > > two > > > > systems instead of one (since most users won't verify the cert, it does > > > > matter that emu isn't compromised, even if it's pure web server). > > > > > > > > > > > Huh? Fix the users then. If users aren't paying attention to "security > > > details", they shouldn't even expect freenet to provide them any level > > > of protection whatsoever. > > > > > > The JVM verifies the cert for you! > > > Previous installers signed by my key were showing a "blue" confirmation > > > prompt, > > > > Because you have a real code signing cert. However it is in your name and this > > brings up both legal and usability problems. > > > > "Usability problems" => educate the user. We already had an argument > about this one. Documentation is an admission of failure. Not all the time but most of it. > > > > whereas new ones signed by your non-trusted key are showing a > > > scary yellow one. > > > > Because mine is derived from the StartCom cert? Or is mine an unsigned key? > > Yours is probably unsigned > > > Okay, so as far as keys go: > > > > Some versions of the installer were signed by your private code-signing key. > > These would have worked most transparently, with least warnings, however they > > have the problem that the signing party is not the freenet project - who is > > this Florent Daigniere person??? > > Once again, educating the user is the only way to go: > > Either by telling him who is the guy in charge of building the installer > OR by telling him to ignore the warning. > > I do think that the first option is the best. > > > We have a master key from StartCom, which is not recognised by Java or by most > > browsers, but has the big advantage of costing $0. > > > > The SSL key is derived from the master key. > > No, we don't have what you call a "master key"; They didn't sign our CA > as a sub CA. > > > If I build a copy of the installer on emu, it is signed using my key which is > > kept on emu and I believe is derived from the master key. > > > > A real code signing key in the name of the Freenet Project Inc would cost on > > the order of $500 a year. > > 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? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20081213/5b785156/attachment.pgp>
