On Wed, Dec 17, 2008 at 3:46 AM, Zero3 <zero3 at zerosplayground.dk> wrote:
> 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?
Multi-user system.
One instance per Computer
- File permission is a nightmare.
--> Everyone Full permission
security problem
--> NTFS permission inheritance
tried, doesn't work that well.
either we end up with too many permissions,
or things break too easily.
One instance per User
- Low uptime
Running as a delicate user and provide a tray icon (Bunny)
is preferred by toad (?) and me.
>> 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)
>
