* 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. > > " 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. > 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? > 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. > > > > > 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. > > 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. -------------- 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/20081213/7335f039/attachment.pgp>
