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. > > " 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? 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. 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 and we really shouldn't just rsync the binaries from emu. But on the other hand, a directory listing and maybe a copy of the current build script is probably enough to reconstruct 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. > 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? > > > > > 5. Whether to ship Zero3's native windows installer, and whether to build > > it > > > > on emu. > > > > > > > > Zero3 building it on his machine and us not verifying it but then > > distributing > > > > it from emu is unacceptable; IMHO we should build it on emu if we ship it > > at > > > > all. This is possible, since AHK is GPL and has a command line compiler, > > and > > > > Wine will happily run it without the X libraries. > > > > > > The debian package doesn't. I am not going to recompile wine nor let you > > > keep an old, never updated, copy of their code with setuid bits lying > > > around on a box I am supposed to administrate. > > > > Wine does not need setuid bits or X libraries. > > > > I don't see what is wrong with using the same version of wine - in my > > experience apps that work with one version frequently don't work with the > > next - and we will be applying this to 1) a GPL'ed piece of software, which > > we should be able to obtain a clean copy of (as much as any of the large > > pieces of unreviewed open source code we rely on) and 2) the source code for > > the installer. I am willing to run it in a small VM if you think that is > > wise. > > Running it on emu is not wise for the reasons explained above. > > Thinking that virtualization helps security is just misunderstanding of > how it works. > > http://kerneltrap.org/OpenBSD/Virtualization_Security > > > > > > > We don't cross-compile native libraries; I don't see why we should > > > bother compiling native installers on emu... There is no gain out of > > > doing it. As explained previously automation can be achieved > > > through different means... and in the case of the installer I'm still > > > to be convinced it's something we want at all. > > > > The only real gain, if we use an online installer, is that it means our > > security depends only on emu not being compromised, rather than offering two > > equally interesting targets. > > Putting all your eggs into the same basket assuming I am able to secure > emu properly is silly. Ok. However we do have all our eggs in several baskets, and I don't see any real solution ... I would welcome some advice in private on securing my systems... > > > > > PRO: > > > > - Auto-install of the JVM if necessary, thus easier for windows users. > > > > - Much simpler than the current installer in the sense of far fewer > > stages. > > > > CON: > > > > - Can't be signed on emu unless somebody comes up with an open source exe > > > > signing tool ... does Wine provide one? In any case a real code signing > > cert > > > > is expensive, gpg-signing the exe is probably the easiest way to establish > > a > > > > real trust path. > > > > > > I have valid certificates; I used them for signing the java installer > > > but I am obviously not going to sign those windows binaries. > > > > I thought they were only valid for websites? > > Not my personal certificate. > > > That real code signing certs that the JVM will take seriously cost mucho $ ? > > They do cost $ ; but I happen to have one. > > Anyway, because of liability concerns, and our fast diverging views of what the > installer should be and should provide, I am not willing to sign the installer > anymore. 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??? 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. 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. -------------- 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/3eae7717/attachment.pgp>
