> > 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 " 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". > > > 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 :) > 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. > 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 :/ > 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, whereas new ones signed by your non-trusted key are showing a scary yellow one. > > > 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. > > > > > 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. -------------- 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/8784c789/attachment.pgp>
