On Saturday 13 December 2008 16:11, Florent Daigni?re wrote: > * Matthew Toseland <toad at amphibian.dyndns.org> [2008-12-13 12:21:01]: > > > Issues for the installer. Both Zero3 and nextgens seem to have decided to > > sulk, so I'll arbitrarily decide these issues where there is deadlock and if > > anyone objects he can reply to this thread with a reasoned argument. > > > > 1. Whether we should remove all the questions from the current installer, > > always auto-start, and ask the user about plugins and auto-update from the > > first-time wizard. > > > > RESOLUTION: Passed without much discussion. > > That's the good way forward. Previously you were objecting to me making > the node auto-start, hence we couldn't get rid of the panel anyway :/
Ok so you support that. Good. > > > 2. Whether it should run from the startup group, by the logged-in user, rather > > than as a system service running in its own user. > > > > RESOLUTION: We should continue to run Freenet as a system service. > > > > WHY: Freenet keeps all its config files in one place. Running it as one user > > and then another user would result in it breaking due to permissions > > problems. The only ways to avoid this are 1) running it as a separate user, > > or 2) having per-user configuration, including the node, the Friends list and > > so on. IMHO 2) is utterly unacceptable, because we end up with one node per > > user, and updating would be tricky if not impossible. And that. > > > > 3. Whether to compile and sign the current installer on emu. > > > > Nextgens has suggested that we should sign the installer elsewhere. The > > bytecode could still be verified provided that the dev who builds it builds > > it with appropriate options and declares which JVM they are using. > > > > PRO: Not putting all our eggs in one basket. Non-java installers can be signed > > by their authors, distributed from emu, and download stuff from emu and check > > emu's signatures. > > > > CON: Most devs' boxes, with the exception of nextgens', are less secure than > > emu. > > Not much I can do againt that... you have got the project's keys > (including emu's r00t): your box should be secure. > > > Prevents shipping an auto-built offline installer. > > Why? > We can trigger something somewhere from emu when a new release is done! Fair point. We can do that on emu, in a limited user or a dedicated VM, just as well. It's a question of what leaves us with least vulnerability. > > > It will have to pull binaries from emu anyway, so it doesn't actually solve anything. > > That statement is just plain wrong. > As explained several times already, including on > http://archives.freenetproject.org/message/20080601.124311.f9b57658.en.html > the current scheme guaranties: > 1) the integrity of the mirrored content > 2) the authenticity of it (forward only) > > It lacks the "bootstrapping" of the trust path and that was supposed to > be done by signing the installer using someone's personal key which > would be trusted by a 3rd party. > > To sum up: > 1) You get a signed installer from $(wherever) > 2) It sets up a trust path (we bundle a CA into it) > 3) You get subsequent code updates from a trusted channel (using > the CA you got during bootstrapping or the keyring hard coded into the > node) > > In order for that scheme to be useful, we DO NOT WANT THE PRIVATE KEY > USED TO SIGN THE INSTALLER TO BE ON EMU. Moreover, we probably don't > want the bytecode to be produced by emu for that matter; but that's an > other question. > > 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). > > > 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. > > > 4. Whether we should ship the "offline" installer by default. > > > > PRO: Less chance of a user in a hostile regime either being denied service or > > giving themselves away. Less impact if emu is DoS'ed. Simpler installer. > > > > CON: Less statistics, problems with outdated versions, installer must be built > > and signed on emu, must sign the installer automatically on emu, Microsoft > > and many other ship "online" installers, actual download is larger and > > therefore more likely to be cancelled. > > > > RESOLUTION: Lets stick with the online installer. There are good reasons to > > use an offline installer, but implementing it means nextgens leaving and me > > having to admin emu, which I am frankly not competent to do. Apart from that, > > nextgens says there would be security issues with building it every time, > > about which he is probably right. > > I don't care whether we go for an offline or an online installer. I just > know that the "sparing bandwidth" argument doesn't stand. > > What I object to is: in order: > 1) setting up wine on emu (because of several reasons; can > develop if need be) > 2) building installers on emu > 3) signing installers on emu > > One thing is certain: if you do "apt-get install wine" on emu, I will leave > you with administrating emu. We already build installers on emu. And you have not yet convinced me that it would be beneficial to build the installer elsewhere and the code on emu. 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). > > > 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. > > 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. > > > 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? That real code signing certs that the JVM will take seriously cost mucho $ ? -------------- 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/ef26296d/attachment.pgp>
