On Saturday 13 December 2008 17:40, Zero3 wrote: > Matthew Toseland skrev: > > 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. > > I'm not sulking as in "to express ill humor or offense by remaining > sullenly silent or withdrawn.", if that's what you mean. But I don't > reply to mails 24/7, so I'm sorry if that is misunderstood as sulking. > Not my intention.
No I meant it in the sense of having an entrenched position which you are unwilling to compromise on, threatening to leave if you don't get your way and blaming it on the other guy. Which was true of both of you at the time. However the debate seems to have moved on somewhat now. > > > 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. > > > > Huh? Did you read my last couple of replies to nextgens? There is no > permission breaking of any kind going on here, as I tried to explain in > the other thread. I don't see how that can possibly be true. We are not just sharing the binaries, we are updating the binaries, and we are sharing the config files: - We want a single node, for all the users on the system, even if some are connecting remotely and/or several users have open sessions on the same physical screen. - We must be able to update the freenet.ini, wrapper.conf, and the jars. In exceptional circumstances we also need to update the update.cmd and related files. - If we run Freenet from the start menu, it can be started by multiple users. Some of them may have admin rights and some will not. Who is supposed to own the files in that case? Should we have executable files be world writable? Is that a remotely good idea? > I have yet to see any kind of proof to that claim of > nextgen's, or a least a proper explanation of these "permission > problems" I haven't been able to reproduce at all. The argument doesn't > even make sense, as you are giving permissions to the installed node > files to the Freenet user atm. If there was permission problem, as > claimed, then users wouldn't be able to access the node files from their > regular user... With Freenet running under its own user, it can happily update its own files, there is no problem. If it breaks, the user runs update.cmd, which replaces files or makes new ones, and we have to fix the permissions so that the Freenet user can still use them. This is usually possible, but there is no fundamental reason why it should be, especially if the user running update.cmd is not the user who installed it. One conceivable solution would be to create a Freenet group rather than user, and deny all access to Freenet for anyone not in that group ... we could ask the user at install time which users he wants to be in the group... > > > 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. > > Huh x2? > > 1) "Less statistics": As I mentioned several times already, if you want > statistics (even though I disagree about doing it in this way), I can > simply make the installer fetch ..../counter.php (or something like > that) on the website. If the website is down for any reason, the only > cost would be the statistics, as the installer can just continue anyway > (as it already has the files it needs to do the actual install). Which would be blatant spyware. Whereas the way we do it right now is defensible. > > 2) "Problems with outdated versions": That's a fair argument. But even > very old nodes are able to UOM. For a reasonable period. We do not support old connection types indefinitely. > I have also offered solutions to help > that problem, the most appealing probably being to warn and offer to > download a new installer if installer is very old at execution time. This will help, but right now it's handled transparently. Except if you are unable to connect, which is a legitimate problem ... > > 2) "Installer must be built and signed on emu": Unless I'm > misunderstanding you, you just argued earlier that it wouldn't make any > real difference as we are signing .jars there already. I don't know if > Java signs .exe files, but Microsoft has official tools to do so as > well: http://msdn.microsoft.com/en-us/library/aa380259(VS.85).aspx Which are included with Windows and while they may run on Wine, doing so would require a Windows license, correct? > > 3) "Microsoft and many other ship "online" installers": How is that a > "consequence" to us? It's a justification: online installers are not exceptional. There's a simple tradeoff between starting the installer quickly, and thus not losing the user's attention, versus having it take longer by having to download everything, and having to deal with proxy issues and so on (which don't affect us). > > 4) "Actual download is larger and therefore more likely to be > cancelled": It's an ~8 MB download! Less than a minute on a standard > 2Mbit connection. Roughly the same size as FireFox (7.1 MB). If users > cancels the download because of having to wait a single minute, I'm > quite sure the user won't be pleased with the loading times within > Freenet *at all*! Agreed. It's pretty big even now, because the java installer isn't very size-efficient. > > > - 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. > > See my link above. Surely SDK binaries from Microsoft can be trusted, > since we trust Windows itself in the first place? If we really *needs* > to do the "built-in" .exe signing. Are they redistributable? I.e. can we run them on a unix machine without having to buy a copy of Windows and install it first? If so that expands our options considerably. And no, I don't trust Windows in the first place. Also, would we need to buy a separate code signing certificate for signing windows EXEs? Or could we use one derived from the StartCom cert or derived from a code signing cert bought for signing jars? However, in the light of nextgens' recent comments, we *could* build an online installer on a Windows box, and then distribute it from emu. Provided that we had a reasonable assurance that that box could be trusted. I would strongly prefer it if we could build them on a unix box however. That might not be emu at all, as nextgens has explained, it could be my box. It would make it much easier to automate the process, and thereby enable us to provide a bundle-installer which is updated on new stable builds. Theoretically this could be done on Windows ... > > > I believe the above decisions are practically implementible and should annoy > > nextgens and Zero3 to equal degrees. > > > > I hope that's just meant as a joke... :-/ It was not intended as a joke at the time. -------------- 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/a8dcbfc0/attachment.pgp>
