[freenet-support] Re: Last point of failure
Signatures require a) somebody checks THE WHOLE SOURCE for trojans. This will take weeks and therefore will never happen. b) that we can keep the private key secure. This is unlikely. Have you participated (without identifying yourself) in any large projects that currently GPG-sign their sources / binaries? All you have to do is sign them when you package them. What people want from the signature is the knowledge that the package is as the author created it and not repackaged by a third party. As for source errors or hidden trojans, that can always happen, but a signed release lets you announce a patch release, admitting the trojanning and users know that the new release is also from the usual packaging author. Keeping a private key secure is really easy in this context (use a CD/floppy). More importantly you can always create private keys with 3 or 6 month expiries so that you have to create new keys before then and sign them with the old keys so that anyone who actually compromises the key doesn't gain much. Being able to revoke GPG/PGP keys makes this almost unnecessary as well (are you actually familiar with the technology involved in how GPG/PGP work? Go read the fine manual ... www.gnupg.org). with IE or Mozilla for that matter. Please do some research ... Signed JAR files go through verisign. That is not good. Signed JAR files don't go through verisign; that's one company that offers such signatures. You don't actually need to use their signatures; see www.openssl.org or www.openca.org for something more complex. There are open and free ways to create and manage signing authorities for JARs as well (again, I happen to do this stuff for a living). -- Michael T. Babcock CTO, FibreSpeed Ltd. (Hosting, Security, Consultation, Database, etc) This advice brought to you by a lot of cash I didn't charge for the advice ... http://www.fibrespeed.net/~mbabcock/ ___ support mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/support
[freenet-support] Re: Getting rid of the last central point of failure
Date: Mon, 18 Nov 2002 08:51:05 -0800 To: [EMAIL PROTECTED] From: [EMAIL PROTECTED] You can, of course, revoke signatures with GPG without a problem and then sign the distributions with it (at least as a detached signature). The installer could offer to check that signature by calling GPG but this is highly insecure (as anyone who replaced the binary would forge the call). What you really want is for people to check the signature themselves (with GPG/PGP). Yes thats excellent from a corporate perspective since the more areas you leave for the l'users your customers to fuckup the less liability you have. However in an open for the most part volunteer project such liability and profit concerns do not arise so for that reason the developers can afford to design systems to protect the l'user from their own incompetence and are necessary if one cares to attempt to offer security and anonymity rather than create opportunities to destroy it. Your complete lack of grammar and ability to express yourself coherently is somewhat distressing but I'll reply nonetheless. My comment had nothing to do with liability and in fact I do security consulting for individuals and businesses; I am not a lawyer, and do not care about liability issues in this type of arena. The problem that arises with digitally signed binaries is that the signature checking system _must not_ be distributed with the binaries to be checked and the signatures or signator keys _must_ be available out of band. If the binaries are signed and come with a detached signature, any user can double-click the signature file and receive a PGP/GPG message asking if they wish to check the signature. The installer can easily come with the instructions to check the signatures, as well as a short commentary on why this important for the security of their file store and the project as a whole. The binaries, however, must be assumed to be untrusted and untrustable for the sake of such a discussion and as such, only the method I described keeps the user from receiving a message such as 'signature checks out' when in fact the image they received was either tainted or damaged. Feel free to reply with a full discussion / reasoning behind your wanting to do things any differently for this (preferably technical) and I'll listen. There is no reason _not_ to distribute detached signatures for each of the installer and/or JAR images. Signed JAR files are also possible and checkable with IE or Mozilla for that matter. Please do some research ... -- Michael T. Babcock CTO, FibreSpeed Ltd. (Hosting, Security, Consultation, Database, etc) http://www.fibrespeed.net/~mbabcock/ ___ support mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/support
[freenet-support] Re: [freenet-dev] Getting rid of the last central point of failure
Oh yes it's all so simple we sign the webinstaller in fact we don't even need to do that we just insert it under an SSK. /sarcasm. The problem is that we need to be able to revoke and/or update the signing key, otherwise a Bad Guy who got the key could destroy most of the network just by distributing compromized nodes. You can, of course, revoke signatures with GPG without a problem and then sign the distributions with it (at least as a detached signature). The installer could offer to check that signature by calling GPG but this is highly insecure (as anyone who replaced the binary would forge the call). What you really want is for people to check the signature themselves (with GPG/PGP). -- Michael T. Babcock CTO, FibreSpeed Ltd. ___ support mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/support
[freenet-support] Logging to stderr ...
Would it be possible to optionally log to stderr instead of the freenet.log file so I can easily use supervise multilog to maintain my freenet node? Ref: - http://cr.yp.to/daemontools.html (for supervise, multilog, etc.) -- Michael T. Babcock C.T.O., FibreSpeed Ltd. http://www.fibrespeed.net/~mbabcock ___ support mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/support
