On Monday 15 December 2008 16:29, Zero3 wrote: > > >>> 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.
Exactly. A group of users must have permission to change the binaries. > > 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. It's a blatant security weakness. It is much better to create a separate use for Freenet, and always run the daemon, have the systray icon run per-user (with its binaries only updatable by the freenet user), and have a means to put the node into offline mode via the systray icon. > > >> 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. Yes, that's a point in favour of an offline installer. > > >> 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? > > 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). Nextgens would certainly object to running Microsoft provided binaries on emu, and I can see his point. There is an argument for just providing a gpg signature for the binaries - but otoh since Microsoft provides a signing/verification system we should seriously consider using it. > > > 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. -------------- 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/20081215/3af71f2c/attachment.pgp>
