I'm taking the liberty of forwarding this discussion to the development list, because I have a strong suspicion that none of the Freenet developers read the support list.
"thomas" has discovered that fproxy is leaving unencrypted data files in /tmp, which if discovered by a malicious party, would eliminate any deniability of content retrieved via fproxy. ----- Forwarded message from Ed Onken <edonken at midwest.net> ----- At 12:34 AM 08/21/2002 +0100, Roger Hayter wrote: >In message <20020820222422.GL32462 at pegasus.wooledge.org>, Greg Wooledge ><greg at wooledge.org> writes >>thomas (thomas at tomys.de) wrote: >> >>>- Start fproxy >>>- connect from a remote PC to the fproxy >>>- try to browse some freenet sites >>>- In the /tmp directory on the fproxy box i found many t****** files >>>- a "file /tmp/t???????" shows me that these files includes >>>html/jpg/gif.... >> >>Wow -- you're right. There are definitely files being created by the >>user ID that runs the freenet node (*not* the web browser, as I thought) >>in /tmp. I have no idea what these files are used for. >> >>For whatever it's worth, on my node, all of the files in /tmp are less >>than 10 minutes old. >> >>Thanks for bringing this to my attention (even though I'm not a Java >>programmer and therefore can't do much about it). >If they don't last very long, that's probably why no-one has noticed it >before. I suppose it is pretty inevitable that the plain text of a >Freenet request is going to exist on the machine Freenet is running on in >some form or other, but actually leaving it in /tmp seems worrying. I hope >no-one thought contacting fproxy on someone else's server was in any way >anonymous, but this confirms it is trivially easy to read such traffic. >-- >Roger Hayter You might want to take a look at freenet.support.FileBucket. I think the culprit you are looking for is the no-arg constructor. It creates a file bucket in a "temporary" directory. There are a few System properties and a couple (Linux and Windows) OS-specific hardcodings in there governing where to put the files that are created by the no-arg constructor. There is a finalizer which will delete any new files created by the FileBucket, but finalizers are not guaranteed to run, so it's not exactly 100%. The finalizer is probably why the files don't live very long--at least until you shut down your node abruptly (cuz there ain't no other way to do it :/) You might want to set one of the system properties for the JVM running your node that are mentioned in the code to force these files to a specific location so they can be easily cleaned up manually in case the finalizer didn't get a chance to do that.
