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.

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. Prevents shipping an auto-built offline installer. It will have to pull 
binaries from emu anyway, so it doesn't actually solve anything.

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.

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.

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.

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.
- 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: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20081213/516b4b27/attachment.pgp>

Reply via email to