* 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 :/ > 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. > > 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! > 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. > 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. > 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. > 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. 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. > 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. > - Difficult to maintain, as written in a language other than Java. However, > this language is likely to be straightforward, and as all the config is in > the node we shouldn't need to do much maintenance. > > RESOLUTION: We should do this. We do not have to involve it in the build > process, since it will be an online installer, so it does not present any > significant security risk to emu nor is any significant structural change > needed. > > > I believe the above decisions are practically implementible and should annoy > nextgens and Zero3 to equal degrees. > > QUOTE: > "Consensus is the process by which comrades are alienated by constant > argument > until there is only one person remaining, who can then glory in being right." > > (Okay I just made that up) -------------- 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/b6b3f78f/attachment.pgp>
