On Tue, Dec 16, 2008 at 12:29 AM, Zero3 <zero3 at zerosplayground.dk> wrote: > Matthew Toseland skrev: >> 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. >> > > I'm sorry if that's the impression I've given. That is not how I feel > about this. I'm willing to compromise when the project as a whole > believes another way than mine is the right, and the situations have > been discussed through. I'm feeling that we are moving towards that, but > when a single person comes up and asks me to change a fundamental part > of my plan with the installer - with arguments i can't agree with - I'd > like to make sure that it's the right thing to do. > >>>> 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? >> > > Yes, a single node per machine, shared between concurrent users on the > same machine. I cannot see why any files should be prevented from being > updated in a Windows multi-user environment. File ownership is very > rarely used in Windows, and mixed file ownership of the Freenet files > wouldn't really matter. What matters is that all users (we want to have > access to Freenet) have inheritable read-write access to the Freenet folder. > > The executables wouldn't have be completely world-writable. I wouldn't > recommened giving the guest group/user access (for example). But if we > want user X to be able to update Freenet bins, we must obviously give > him write-access to do so. Hypothetically speaking, that could be a > security issue if user X replaces Freenet executables with bogus stuff > and waits for user Y to execute it. If that is a big problem, I'd say > either don't give unprivileged users write-access to the Freenet folder > (which with the current structure of Freenet would prevent them for > using Freenet alltogether) or run Freenet as a service. Both ways have > advantages and disadvantages in my opinion. > >> >>> 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 ... >> > > If you are unable to connect, an online installer won't work at all, > mind you. > >>> 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? >>
There is a opensource clone of Authenticode tools. http://osslsigncode.sourceforge.net/ > > I'm not sure. I'll have to dig into the license and read first. If we > actually need to sign the .exe using the Windows signing stuff? (Often > projects seem to simply distribute signed hashes?) > >>> 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. >> >> > > I'll have to check it out. About trusting Windows, I was thinking in the > lines of: As we distribute a Windows version of Freenet, we obviously > have to trust the Windows operating system, and thereby Microsoft. > Therefore, I don't think it would be a security compromise to use > Microsoft's own signing tools for the Windows installer (again: if we > actually want to sign the .exe in this way). > >> 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? >> > > A bit out of my league. I'm not that much into all this signing stuff. > >>>> 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. >> >> > > Great way of making decisions then :-/ > > - Zero3 > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl >
