RE: [freenet-support] DeBarsacCharleshenri?
I'm in as MikaMikado too... /N -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Stephen Mollett Sent: den 22 november 2002 10:04 To: [EMAIL PROTECTED] Subject: RE: [freenet-support] DeBarsacCharleshenri? I just tried it and got logged in as MikaMikado... Definitely something seriously wrong with security on the webserver. :-/ Stephen --- Pete Soden [EMAIL PROTECTED] wrote: Way hey I've just logged in as him as well! Not a good situation for the project really. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Doug Bostrom Sent: 22 November 2002 01:13 To: [EMAIL PROTECTED] Subject: [freenet-support] DeBarsacCharleshenri? Anybody else seeing a weird symptom with the freenetproject.org site, namely that visiting the page automatically logs you in as DeBarsacCharleshenri with all rights and privileges pertaining? ... = == Buy a Pentium 4 (tm) for more accurate errors, faster crashes, brighter blue screens and quicker reboots! __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com ___ support mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/support ___ 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
Re: [freenet-support] Re: Getting rid of the last central point of failure
On Fri, Nov 22, 2002 at 08:42:29AM -0500, Michael T. Babcock wrote: 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. 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. 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 ... Signed JAR files go through verisign. That is not good. -- Michael T. Babcock CTO, FibreSpeed Ltd. (Hosting, Security, Consultation, Database, etc) http://www.fibrespeed.net/~mbabcock/ -- Matthew Toseland [EMAIL PROTECTED] [EMAIL PROTECTED] Freenet/Coldstore open source hacker. Employed full time by Freenet Project Inc. from 11/9/02 to 11/1/03 http://freenetproject.org/ msg02220/pgp0.pgp Description: PGP signature
[freenet-support] Now logged in as MikaMikado on freenetproject.org
But I'm not that person, FYI. -- Americans generally do the right thing, after first exhausting all the available alternatives. - Winston Churchill ___ support mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/support
[freenet-support] Re: [Tech] Re: JARs
Compress a 60k JAR of HTML to 6k and insert it. Then, retrieving any of the HTML pages gets you all of them. Insert the small images that appear on more than one page as a group again, which may be 150k or so, and insert it so that retrieving any of those common images gets you all of them for the site. All this is good. We just have to implement ZIP key//file in ZIP, and all of this becomes possible. well, we had the top of this mail now 100 times.. maybe everybody now realizes that bundling files which belong together might lead to a good idea ---~~--- but matthew, why your approach with ZIP@ ? why not use oskar's approach with metadata information which makes *far* more sense to me. ZIP@ is stupid, because the data contained within the archive does not need a special key - it's a file just like any other file, so no special key is needed OK. Proposal: Currently manifest sites use Redirect.Target=some key or DateRedirect (which has .Increment, .Target and .Offset). Add ZIPRedirect: ZIPRedirect.Target=some key, which is a ZIP ZIPRedirect.Filename=filename within zip to extract redirections may work but i think it's the wrong approach, too. it's simply not transparent enough. so every file which resides within the archive must be indexed with a ZIPRedirect.Filename param, which will simply be a too big workaround for embedding archives my idea would be based on metadata information, too, but would look like this: Version Revision=1 EndPart [...] Document Redirect.Target=freenet:SSK@some/some//mycommon.zip/next.gif Name=next.gif Info.Format=image/gif EndPart [...] Document Redirect.Target=freenet:CHK@blablaarchivefiledata Name=mycommon.zip Info.Format=application/x-freenet-site-archive (or application/x-zip or whatever archive format fproxy/etc should be able to understand) Info.UseAsABundle=true EndPart [...] End notice here the additional field Info.UseAsABundle, set to true (default false). this enables the client to see that the file the Name fields describes is an archive (and not a directory) which can be opened to retrieve files like mycommon.zip/next.gif from within the archive. everything else on the metadata remains untouched, no new key types are needed. [[[ i'm not very good at metadata discussions, but maybe this is a way you can gather some clues from? ]]] ---~~--- It could be worth discussing whether fproxy should be caching the data contents itself, or reextract the bundle every time (counting on the DataStore to cache it). we have a temp directory, use it for extracting the archive (maybe if n files are going to be retrieved from the archive, otherwise do not expand the archive into temp) this will leave some files lying around, i know. so maybe it's wise to extract the files into the datastore (using their own CHK, not the archive's) so the first look can go into the DS, if the requested file is not present, look into the archive, and possibly extract the file found into the DS, where it is cached when the file is requested the next time. ---~~--- comments? The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ___ support mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/support
[freenet-support] Non-support related discussions on this list
I have noticed a few discussions which aren't really directly related to helping people to use Freenet, and are therefore Off-Topic for this mailing list. Such discussions should be on the chat mailing list, not here on support. You can subscribe here: http://hawk.freenetproject.org/mailman/listinfo/chat/ Ian. -- Ian Clarkeian@[freenetproject.org|locut.us|cematics.com] Latest Project http://cematics.com/kanzi Personal Homepage http://locut.us/ ___ support mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/support
Re: [freenet-support] splitfiles. Again
On Fri, Nov 22, 2002 at 08:03:14PM -, Vitenka - Zen wrote: Download failed. Couldn't download enough blocks to reconstruct segment: 0. required: 128 downloaded: 128 Using 537. It'd be enormously helpful if you found that this was repeatable on demand... try checking the skip local datastore flag to make it redownload everything, does it happen again? If so I can give you a some patched files, or a patched JAR, to try to catch more info about it. -- Matthew Toseland [EMAIL PROTECTED] [EMAIL PROTECTED] Freenet/Coldstore open source hacker. Employed full time by Freenet Project Inc. from 11/9/02 to 11/1/03 http://freenetproject.org/ msg02225/pgp0.pgp Description: PGP signature
Re: [freenet-support] Re: Getting rid of the last central point of failure
-BEGIN PGP SIGNED MESSAGE- On Fri, 22 Nov 2002 06:41:59 -0800 Matthew Toseland [EMAIL PROTECTED] wrote: On Fri, Nov 22, 2002 at 08:42:29AM -0500, Michael T. Babcock wrote: 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 dear dear, I bullshit for a living but have arrived at a point i do what ever i find fun and entertaining, but specialze in teen-parent psych so i only spell check when im paid to. is somewhat distressing but I'll reply nonetheless. yes its also effective bait for the anal rententive 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. Its not the point, rats running corporate mazes or any maze soon foget the walls form their behavior, but from a usablilty perspective freenet right now hase enough ways in configurable options to really screw yourself up and perhaps the nodes around you. The most common really dumb thing I've seen and MS walks then right into it, is people putting everything they ever see or touch on their desktop. Condsider how bad the computer literate user really is offering a another realy great way to screw themselves isnt a good idea. The level freenet requires now is, if you can rebuild a carburator without a manual you can run freenet, the ideal is more like press play than crash courses in encrption technology and techniques. Fine if its to remain a protocol for motivated unix geeks, chinese dissidents terrorists theives and pornographers with technical experinece thats laudible alone, but with the recent p/r it was found people couldnt determine their own ip. So the objection was the general direction, let the experts hammer out the hows and why. However if ure having problems with ure teens i'll be glad to take to take 60 to 100 grand off ya. My favorite trick to gain confidence is tell'em they're fine they're parents are fucked and here's the papers to involunatily commit them to the nearest county facility. Never failed yet to make them feel comfotable and empowered. 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. 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. 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 ... Signed JAR files go through verisign. That is not good. -- Michael T. Babcock CTO, FibreSpeed Ltd. (Hosting, Security, Consultation, Database, etc) http://www.fibrespeed.net/~mbabcock/ -- Matthew Toseland [EMAIL PROTECTED] [EMAIL PROTECTED] Freenet/Coldstore open source hacker. Employed full time by Freenet Project Inc. from 11/9/02 to 11/1/03 http://freenetproject.org/
[freenet-support] Aussie enquiry
Hello, I came accross this on the net.Is a mirror available for Australia?Regards, Ken.Add photos to your e-mail with MSN 8. Get 2 months FREE*. ___ support mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/support
