Matthew Toseland skrev: > 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. >
Can anyone (nextgens?) quickly sum up the reasons for running as LocalSystem vs. our own user? > 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. > Main reason for me not wanting to provide a removal script is that I think we should take a clear position, meaning either: A) Give the user the choice about installing the daemon and ask about it *before* we install it B) Deny the user the choice (e.g. the daemon will be a requirement for running Freenet), and do not provide any means of removing the daemon (besides uninstalling Freenet altogether), but *do* inform the user before we actually install it. Installing the daemon but providing a removal script seems (to me) to only serve to nag those who actually wants to get rid of it. People who wants the daemon (or don't care about it) won't use the shortcut, and wouldn't have disabled it in the installer (if we ask). People who actually *do* care and doesn't want to daemon will remove it after installation anyway (script provided or not), so not asking before installing it will simply serve to annoy them. (and these people will probably know how to find the service control panel anyway, so we just clutter their start menu even more :-/) > 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. > In any way, it all sounds fair to me! (I'll leave the crypto stuff to you guys though, don't know enough about that to seriously comment on it) - Zero3
