First I'll confess I have not gone over the code with a fine tooth code, not plumbed the devl list, nor read the specs. That's just too much for me to take on a hobby - I'm trying to look at what I am finding and feeling as a neophyte approaching Freenet with a desire to lend a hand. And luckily I'm dumb enough to ask a lot of questions and thick skinned enough to be completely fine with criticism (if you're OK with the questions :)
>From my peculiar perspective, trying to get Freenet to work on a platform I've >come to really like in the last six months after trying Freenet over quite a >few years, I feel that there's now a way I can meaningfully add to the >project, both in work and equipment (i.e. a dedicated node with 24x7 up-time). >I think it can be made into a Freenet appliance - it does hardware AES 256/256 >_I think_, but I will be confirming that soon. But I'll be getting back to the >code and I'll dig into the tests a little, and perhaps I'll look into what >Fred would look like using Maven organization, which is a increasingly widely >used standard a large and growing number of people are used to. I might try >and knock out a test Maven pom to build Fred. Addressing security, Maven is a >build system, it will not put anything in your distribution that is not >specified by you (even if it does need to download a whole bunch of files into >its repo to do so), so security should not an issue. What it does add is the >ability to address quality issues more easily, say, by creating consistent >builds and test runs, and by providing interfaces for tools such as Sonar >(http://www.sonarsource.org/) to give you feedback on what you are doing, >making management easier. First though, the biggest issue I have using the ARM detection in Fred 1358, using my *special* freenet-ext.jar with the ARM .so's in it, is that there's not enough entropy :( Maybe it's something to do with the 'plug having no hardware clock! So I'll look at that, and also bringing the platform detection code in Fred out from a number of duplicates into, for example, a single enum. Using JCE is an interesting discussion point, as if you do look at JCE providers there are few to choose from that really utilize the available hardware, or even OS. Look at MSCAPI as a stunted JCE provider for example. I think you'd be good extracting the crypto out of Fred into a JCE provider... into a Freenet JCE provider sub-project. That would throw out options to use OS and hardware if coded and as needed. But all said and done, Freenet is *waaayyyy waayyyy* faster today than it has been, ever, especially the last few builds. But looking forward from the great leap in response times, it leads me to think about the challenges in installing and deploying it (e.g. on embedded headless systems), of QOS for the small (text) files vs, the large (graphics) files, and now in the challenge of developing it and keeping Freenet a viable project. ---------------------------------------------------------------- There are lots of unit tests in the test/ folder, including for crypto. However there aren't many unit tests for crypto. The more serious concern is that crypto is somewhat nonstandard (256/256 Rijndael, whereas AES is 256/128 Rijndael, with PCFB/CFB, which is a somewhat uncommon mode and looking slightly weak). Fixing this would require significant work. It will happen eventually but is not IMHO a critical issue at present. Non-standard crypto means hardware acceleration may not work. Native C code might still work on the other hand. I suggest you do some profiling - what is actually using the CPU? Is it symmetric crypto or asymmetric crypto, or is it garbage collection due to not having enough memory, or is it something else? There is already some native code acceleration for modPow(), which is the biggest part of asymmetric crypto (in NativeBigInteger). However, recent JVMs are much faster than older ones. And of course you'd have to recompile for ARM. There *are* interfaces, for instance Rijndael is a BlockCipher. Try to get a bit more specific. What classes do you need interfaces for? Or more likely factory methods? IIRC we call new Rijndael(...) in various places - but we usually store it as a BlockCipher. Ideally we would use the Java official crypto API. We would then have to ship Bouncycastle because some JVMs don't have full strength encryption (I'm not sure if this is still true in 1.6?). And we could take advantage of native acceleration libraries on some platforms. I'd prefer not to shift to maven at this point. It would be a lot of work and from using it I suspect it is grossly insecure. That is, whenever I've run it it's downloaded vast numbers of tarballs with no sign of signature verification. I'm sorry if I appear critical; that's not my intention, IMHO a Freenet appliance is a great idea.
-----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.14 (MingW32) mQGNBE0DMWABDADD2sd9JDgi+lvPRux+4qNqitTgeAId3B3pcW3L1vajxHWRB/60 YOamva8EVI1Kv+48gNAAlPazSL07y7CAGp6bYCCTc7UIgGGDgzarxT716YxWP7Bu BJ121TIwZvP0479LaIBc2EEX0atwsgUWFUDXwidSZ/0wr14UwIwnSgbSnDpYt6Tu qZg6a/bruho5mwKgUlnjwVq0w/jKbjOkMErjDYGIdtOVkmqvg7Yae49NRUW0eONj okFO7LmNR4zv6csS07P55b0I7zcuJOc0WbOQhfNZ1/B5xrYAlxKY793IOROvhxcz RD2wnevhIQic3W5E3Iv50G/OjvzFBAmposbPxOjR4lxryARam9PA0t3y5bQk1iJ6 AH2+y18QoYzzWvJKA1NhUh8J9JHm37ZueneuRA2BT7WhkVHuXwbH7TOesuZEXcsY 5yFLCqSCYoQfb4XTEviJLfpkkZBnZL0kEN825cb2hDO4ozKzSWl8a+K8d2zBPEeF MvWgp6WE+hX6TL0AEQEAAbQ5U2ViYXN0aWFuIFdlZXRhYml4IDxmcmVlbmV0LjEw LnRlY2hub21hdGlvbkByZWN1cnNvci5uZXQ+iQG+BBMBAgAoAhsPBgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTYRChAUJBD044AAKCRA+t5ZtZXrl1iebC/9L8vKS MjEyHWlzYFnIctXJeGA7BjIzCyPukUPKABeWQyaL3Du5ndLQJHIzTDFUz6DFxf+S tUUsmIqleZUShwDIBcOMZXZDJ9kt/fHW0OdL2MWETidS31k3aF4PucV57i+eQuIV 5MlMa9ruwQ0ALEqqBEI6Do7MfFWjcKtT6vHm9JLuk+prhILXlGvOu6/6hQVaQz9+ FIVUtyYax26qAPNugKdINdciobyccqjedpOaoGmKC8wqVE68riHZLQNgn9FuIy+/ RRrXCf2Gz+rN3FaWxKRnb5OYg8mC1hyZcMkyB9mWUZsV+0/YU79jEYuEVRcaXEt7 va4S1AX8/or3KKPELbXAq2ltYAK2h8KEyVwOyT2aaHijPWL0FNzIThihYFUKC7DK /aSqaNo9RF3PzeTtJV7Ap5pln8z9LfS4Z7NgALpNisPtR6U5cbMhBcIWFswDpY6e sUARv0YpWDGX4moehsbbyj5oygyNJgvHlMGWifS/ARN2eMeRWGkdm2AOlCWJAbgE EwECACIFAk0DMWACGw8GCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJED63lm1l euXWOX0MAJcBCvl+wOX8dlJttghTNh6qKFzFEv1oWx/NxSJ0QohYg/j/PgMrmGQm CASVjxzf1S5DVAUXlGQoqrslWdAu1drNWoG9ykqnCAQTaoXXf9hdKsJswnb43voB fcqJjYA89fNkFtk3GwyDjH31jvRI3VGJRLyj6Is6u8/S0oXpdNzdV3Po/C95Th8A vmnOTQXw+cDSkCRmhYxfuiAMkNgQ/nOYkelRzdMIZtTbVzZ3XRnw9VmMOx7NZm73 B+2EF26nttkPVikid7XIzy+lVPCDxAQRIPqxqDV0dHN/z+hMR5XUSTNRwcq26iM8 Bq1TvMg3156rnxpTb+3N2XzUNtzmhSzh+MDJNFkZR2taK9hVwhoq8C+TUHjXeu+v aGzs2Iz695kD0QRSzCkt3CxDeWDNgqma4fKuE5gMXXN78nHQLBFQrl0T83WgCwVH xzDly6GQ+b7UqlgpNEWX2+T25nlsfj4TAxKRmHzau7bR5Xedh1MEt7bxCt1gSzG4 piBsxRRuFw== =9pt0 -----END PGP PUBLIC KEY BLOCK-----
_______________________________________________ Devl mailing list [email protected] http://freenetproject.org/cgi-bin/mailman/listinfo/devl
