Many things have been decided, a few remain. Nextgens' main concerns turn out to relate to where things are built and who signs them.
Windows installer: The Windows installer should not be built on emu. An online installer could either be built on Windows or on *nix. An offline installer could be built on *nix, and doing so would not require any Microsoft tools, even if the EXE was signed, as there is an open source EXE signing implementation. Security and offline installers: There are security advantages to having an online installer. Namely that it doesn't have to be built by either emu or the dev who releases the stable builds. It can be built only when needed. So if the key used for signing the installers is compromised, this only compromises new installs. If the updater's key is compromised, this only compromises nodes which auto-update. And if emu is compromised, this only compromises nodes which are updated manually, assuming that we build the stable build jars on emu. If we do in fact use an online installer, it would have to be built when a new stable build is released, and signed (locally) by the dev doing the releasing (most probably me). Hence a release would involve the installer's key, the updater's key, and probably some limited access to emu as well. However there are a limited number of people we trust to the point that we'd let them build an installer which we then distribute IMHO. Even if we use an online installer, it would probably have to be built by me. Meaning that I would have the installer key on my computer, and an informed attacker would attack me instead of emu, and get all the keys plus root access to emu. In which case it probably makes sense to use an offline installer, and build and sign everything on a dev's computer when releasing a new stable build. A peripheral issue is sorting out the build process for freenet-ext.jar. Signing: Until a while ago, the installer was built by nextgens using his code signing certificate. It therefore would be recognised by java, and show a different warning (just a different color iirc?). The signer was "Florent Daigniere", not FPI. Right now installers are built by and signed by me. The certificate I use is an official FPI cert including my name and FPI's, but is not a proper code signing cert and I don't think it's even related to our StartCom cert, although in any case the JVM doesn't know about StartCom. Ideally we would have an official FPI code signing cert, probably one per developer allowed to do a release. These are expensive - in the region of $500. I don't know if the issues are the same for signing EXEs as for signing jars; hopefully one cert could be used for both? System service on Windows: It is increasingly clear that our only options on Windows are to run as a service under LocalSystem, or to run as a service under a dedicated Freenet user, mostly because of permissions problems. Config in the first-time wizard / always auto-start: Putting all the config in the first-time wizard, always auto-starting and warning the user about this has been agreed. Whether or not we should provide a remove-the-service script is an open question - Zero3 thinks we shouldn't, I think we should. Offline installer by default: There are clear advantages to an offline installer, not least being that it reduces the likelihood of catastrophic errors in hostile regimes. But there are also disadvantages and there is no clear consensus. Nextgens is not obstructing this, as long as it is built and signed on a developer's computer rather than emu. -------------- 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/20081216/fe65bcba/attachment.pgp>
