On Tue, Dec 16, 2008 at 4:07 AM, Matthew Toseland <toad at amphibian.dyndns.org> wrote: > 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.
Just for your infomation. All ISP in China is filtering DNS request containing "freenet" Including freenet.co.uk, freenet.com, freenet-antennas.com, etc.... Some are deploying HTTP proxy too. It would be a little easier if some of our mirrors doesn't contain "freenet" in the url. >> >> 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. > > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl >
