[freenet-support] Freenet 0.7 build 1210
Freenet 0.7 build 1210 is out. Sorry for the delay in announcing it. It will be mandatory at midnight. There was also a minor git mess relating to tagging - it was released from a local branch because I forgot to push before tagging, although it has been merged back into master now. If you are building from source you need to either clone the tag or do git fetch -t origin to fetch orphan tags. Changes: - Startup fix: you can now move the persistent temp directory, as long as you update freenet.ini accordingly. This is also an issue when moving the node. - Startup fix: Deleting the persistent temp dir and moving the node failed to startup - Let the node start up even if the database is unrecoverably corrupted. Tell the user what the situation is, and refuse to do any persistent requests or inserts. - Don't commit every database job immediately, unless we need to for memory reasons (some job types), for UI reasons (e.g. starting a request), every 30 seconds, or after every job if the new alwaysCommit config option is enabled. This should reduce disk I/O and improve performance significantly on some systems with big queues. - Fix various client layer bugs, in freesite inserts and other things. - SSK insert collision handling fix - store the data as well as forwarding it. - Minor crypto optimisation in handling SSKs. - First time wizard: remove the memory limit selection page, add a page to ask the user whether to auto-update Freenet and whether to load JSTUN and UPnP (this may reduce performance on a new node *slightly*, but we don't want to have to ask in the installer), warn the user about monthly bandwidth usage, always show the bandwidth and store size pages, minor fixes. - Enable javascript support by default in fproxy, minor fixes, get rid of the MIME type column on the queue page in simple mode, more tolerant parsing of noderefs and bulk download lists. - Fix various connection level bugs, which hopefully once everyone has 1210 will fix the forced disconnected because not acknowledging packets bug. In simulation this fixes Unmatchable packet from blah, which really shouldn't happen! - Minor plugin code improvements (new APIs, require XMLLibrarian version 22). - Internal bugfix which hopefully only was breaking IPv6 address detection from peers. - Internal bugfix relating to moving files, might have caused bugs in several places. - Don't let default changes override the local option for whether to preallocate the store. - Lots of internal cleanup and some work on the many-nodes-one-VM simulators / automated network tests, including a new long-term data retrievability test. Also, the XMLLibrarian plugin now shows a search's progress without using javascript, and immediately from typing a search on the homepage (thanks mikeb). KeyExplorer 0.4 beta is out, and there has been more work on the WoT web of trust plugin (thanks saces). A bugfix in the UPnP plugin, and as previously mentioned we deployed the new windows installer (thanks Zero3). Thanks to: sdiz 3BUIb3S50i platy nextgens saces juiceman signature.asc Description: This is a digitally signed message part. ___ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
Re: [freenet-support] Could not load plugin KeyExplorer!
On Monday 18 May 2009 23:51:33 Eric Chadbourne wrote: When I try to load the plugin manually it fails. Google revealed no solution. Tips? Thanks, Eric C Should be fixed now. Is it? signature.asc Description: This is a digitally signed message part. ___ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
Re: [freenet-support] Is it my system, or had builds 1208 -1209 have severe performance issues?
On Sunday 17 May 2009 22:24:57 Juiceman wrote: On Fri, May 15, 2009 at 2:37 PM, Matthew Toseland t...@amphibian.dyndns.org wrote: On Wednesday 13 May 2009 18:29:47 Evan Daniel wrote: On Wed, May 13, 2009 at 7:33 AM, Matthew Toseland t...@amphibian.dyndns.org wrote: On Friday 08 May 2009 17:40:58 Juiceman wrote: Weird. node.db4o was an insane 375 MB. I deleted it and and added a bunch of downloads. Now it is less than 10 MB. That definitely helped some with the disk thrashing. I think I found the main problem, and I'm embarrassed to say apparantly I had xmlspider plugin running and writing GB+ files to the same disk the node resides on. I turned this off and the disk usage became manageable. I also upgraded my HDD from an older 2 MB cache model to one with 16 MB and now Freenet is zipping along nicely. I did see some errors in the log so I am sending it to Toad for review. P.S. I would recommend not installing the xmlspider by default on installs. Victor - might this be your issue as well? ROFL. So that just leaves victor... Is it normal that node.db4o never shrinks? I have completed all the downloads I had running and removed them from the page, yet node.db4o doesn't get smaller. I have rebooted the node also. This IMHO is bad because it will eventually kill performance with disk access... Yes, the only way to ensure it shrinks is to defrag it. This is on the todo list, but it does not seem urgent to me. Is it really a huge, monstrous, evil, all-consuming problem more urgent than the 500 other things we have to deal with? I see two issues. First, my node.db4o has broken 100MiB. That's not a problem, but eventually it would be. I can deal with this by emptying my download / upload queues, deleting it, and re-adding any keys, but that's annoying. It's not urgent, but an option to defrag at startup would be nice if it doesn't take too much of your time. Second issue is a minor security thing. I'm probably less paranoid than most Freenet users, but I would like to know that after I download a file, the traces left behind by doing so are well defined. That would include the file itself and the fact that its blocks are in my cache. I'd rather not also have that info in the node.db4o file (is it encrypted?). Again, not urgent, but worth dealing with eventually. The truly paranoid will have motion detectors that unmount their encrypted filesystems and start scrubbing RAM before the Bad Guys (TM) can sit down at the keyboard, right? Evan Daniel On Thursday 14 May 2009 01:54:02 Dennis Nezic wrote: Or have the node automatically delete it when the queues are empty? Automatically deleting node.db4o when there is nothing queued might work. The main problem is that we would then not be able to put things other than queued requests into it. Meaning if we want to persist e.g. stats, passive requests etc, we will need a separate database. Is that much work? Have a filequeue.db4o and a nodeinfo.db4o Then we can safely delete the filequeue when there are no pending persistent requests? True, it might be worth it. We don't encrypt node.db4o at present. We should have the option of encrypting it for those who don't want to encrypt the whole drive, but then we would need a way to ask the user for the password on startup, or put it in some easily shreddable file (shredding files doesn't work with modern filesystems). But for the really paranoid, db4o is a bit of a PITA. There is no way we can guarantee that no traces of old requests are present, because db4o doesn't have garbage collection. All we can say is we've tested it and debugged the leaks found by the tests. But it is certainly possible for bugs introduced since then, or not found, to cause leakage of objects. If we encrypt the persistent client layer, and only start it up with a password, then we will still want the rest of the node to work when we don't have the password. So probably we should have two databases... signature.asc Description: This is a digitally signed message part. ___ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
Re: [freenet-support] Bug report: 1 peers forcibly disconnected due to not acknowledging packets
On Sunday 17 May 2009 21:30:28 Juiceman wrote: On Fri, May 15, 2009 at 2:38 PM, Matthew Toseland t...@amphibian.dyndns.org wrote: On Saturday 02 May 2009 11:09:37 theymos wrote: Freenet asked me to report this bug to you. I'm on Freenet 0.7 Build #1209 rbuild01209-real, Freenet-ext Build #26 r23771. I just updated to 1209 a few hours ago. I updated using update.cmd because the built-in update wasn't working. Probably a bug: please report: 1 peers forcibly disconnected due to not acknowledging packets. 1 of your peers are having severe problems (not acknowledging packets even after 10 minutes). This is probably due to a bug in the code. Please report it to us at the bug tracker at https://bugs.freenetproject.org/ or to the support mailing list supp...@freenetproject.org. Please include this message and what version of the node you are running. The affected peers (you may not want to include this in your bug report if they are darknet peers) are: I might just have fixed this in git... Nope, still there. Running #1210 build01210 (this is after -pre4 I guess?) I only get them once a day or so. Wait until 1210 is mandatory. signature.asc Description: This is a digitally signed message part. ___ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
[freenet-support] Idea/algorithm : Fair use media file transformer
Idea/algorithm : Fair use media file transformer A potential way to transform media files for legal sharing via fair use. Consider a desired media file (for example a song), as an array A[1..N] of numbers. Consider a New work B [1..k*N] of numbers. Initialize B to a completely new (or random) set of numbers. Next, For x = 1to N set B[k*x] = A[x]. (if you prefer, you can transform it by a reversible function - such as adding or multiplying by constants). This creates a NEW WORK B[1..kN]. This work will sound completely different from work A, it is a new work, any contents that WERE of A have been transformed markedly, and would not be recognized by a reasonable person as being the same. New Work B could be separately copyrighted, or given to the public domain. New work B could - it would seem - be distributed freely by its creator (or others - if authorized or if in public domain). Now granted, someone who receives New Work B - MIGHT - in the privacy of their home - offline - RETRANSFORM New Work B for personal use. That transformation MIGHT include extracting every Nth number from B[] and saving it into an array C[] (or A'[], or it could involve any of a WIDE variety of transformations that satisfy the user in the privacy of her own home. For example : For x=1..N set A'[x]=B[x*k] (or any other transformation the recipient likes). It *IS* possible that some transformations might result in a file which might potentially infringe on a pre-existing copyright, and if this is illegal it should NOT be done. Of course one might argue that this is personal transformation of a work and fair for private use, and potentially protected by privacy but I don't know the legal nature of this. (Naturally, if it is illegal in a given jurisdiction it should NOT be done). It seems to me that this NEW WORK creation and transmission approach should be protected by copyright law itself. If you create a new work and copyright it, and/or if you give it to the public domain, you presumably have the RIGHT to allow others to copy and share it as you wish. Now it may be true that any work of a given length N can be transformed into any OTHER work of a given length N, but clearly it would be absurd to say that there is only ONE possible legally protected work of length N and noone can create another such work. (Similarly, a work A[1..N] could be transformed into j works of length N/j (or longer). Each of these new works could be unique -containing many different numbers -although containing N/j of the work A (possibly transformed) interspersed infrequently among it). Nevertheless each work would be CLEARLY new, and would NOT sound at all similar to any reasonable person when played. I hope that you found this theoretical idea / hypothetical algorithm to be of interest. Thank you for your time. - Gerhard ___ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
[freenet-support] 0.8
This is a Type III anonymous message sent you through the Mixminion server 'pboxlevel3'. If you do not want to receive anonymous messages through this server, please contact pbox-ad...@winstonsmith.info and your email address will promptly be added to the list of disallowed recipients. Please note that the Mixminion anonymity network is designed in a way such that there is no viable means of tracking the sender of a message, so blacklisting your address is really the best _anyone_ can do. Do not reply to this email as it is since its sender is fictitious and obviously not related to the person who actually sent the message. To learn more about the experimental Mixminion network and internet anonymity in general, please start at http://mixminion.net -BEGIN TYPE III ANONYMOUS MESSAGE- Message-type: plaintext I noticed on the website that you're working towared 0.8 being released later this year. will you be including premix (onion) routing in this release? If not, when do you expect it to be implemented? -END TYPE III ANONYMOUS MESSAGE- ___ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
Re: [freenet-support] 0.8
On Monday 18 May 2009 03:12:06 [Anonymous] Anon User wrote: I noticed on the website that you're working towared 0.8 being released later this year. will you be including premix (onion) routing in this release? Maybe. It will probably include Bloom filter sharing. This may or may not require encrypted rendezvous tunnels. This is the latest incarnation of the premix routing proposal; classic premix onion routing is poor in that it costs a lot of hops and gives a very small anonymity set. Encrypted rendezvous tunnels are a variation on a proposal in a paper; basically we send out a series of anchor requests, which are random routed for some distance and then approach a particular location, each has a part of a secret, and when enough of them come together on a single node, we put them together to create an onion-like encrypted tunnel through the shortest route. We may however be able to safely implement Bloom filter sharing with only some changes to caching - specifically, we would not cache until the HTL reduces below some threshold. This solves datastore seizure attacks, although it is (still) possible to try to find the circle of nodes several hops away from the originator where data was cached when the HTL did fall below the threshold. We would probably need to tweak the HTL parameters. At the moment, HTL is at the maximum (10) for an average of 10 hops (10% chance of decrementing to 9); this is too much if we are not caching the returned data, we would probably change the average path length to say 2 (50% chance of decrementing), and increase the max HTL to 18 so there is the same number of hops overall. The current thinking is that requests would be cached at HTL 16 or lower and inserts at HTL 14 or lower. We will try to ensure that 0.8 is no less secure than 0.7. Bloom filter sharing should improve performance considerably, but clearly has the potential for security issues; we are essentially letting our peers know what is in our datastore! But IMHO this is a risk that can be managed - and there are some security benefits, e.g. if you can fetch all of a file from your trusted darknet peers then an attacker who isn't one of them doesn't get a look in. The bulk flag may be implemented on the 0.8 timescale, it would improve performance noticeably and might make requests slightly more distinguishable (in that you have a flag indicating whether the requestor wants low latency or high throughput); this isn't significant IMHO when considering serious attacks. MHKs (top-block redundancy) will definitely be in 0.8, and have no security impact afaik. Hopefully we will also include auto-update of plugins over Freenet, which should improve security for most people, and make Freenet work better in hostile environments. If not, when do you expect it to be implemented? If it's not in 0.8 it should be in 0.9. Encrypted tunnels are not inherently a really difficult feature, but they will likely require a great deal of tuning and similar work related to security/performance tradeoffs. And tunnels will likely cost a significant amount of performance. They may only be enabled at MAXIMUM security level; there would be little point at NORMAL as Sybil is just way too easy on opennet. Of course, by that logic, since almost nobody uses darknet, tunnels may never happen ... But we have 6-8 months' funding from Google, hopefully we will be able to improve security over this period as well as performance and usability. signature.asc Description: This is a digitally signed message part. ___ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
