On Thursday 31 Jan 2013 22:22:06 Ian Clarke wrote: > On Thu, Jan 31, 2013 at 3:34 PM, Matthew Toseland <t...@amphibian.dyndns.org > > wrote: > > > > > But most importantly, we need it to be reasonably easy to *develop > > Freenet > > > > anonymously*. This is not a theoretical aspiration. There are anonymous > > > > developers today, and some of them are extremely productive at times. > > > > > > They can use a Tor proxy. > > > > IMHO we should not force that on them. Tor has a different threat model, > > and is much easier to block. Whereas developing over Freenet, without using > > Tor at all, is quite possible right now, or would be if we maintained an > > official on-freenet git/hg repo (using tools that already exist). To be > > fair, existing anonymous devs do pull from the main repo via Tor, but IMHO > > we should not require them to do so. > > Now that I think about it, it may be possible to host a Maven repository in > Freenet… AFAIK it's just straight-up HTTP GETs.
No server side scripting? Interesting in principle. I wonder how it would deal with failures and updates. In general HTTP-based services over Freenet (like apt-get) won't work well unless they are rewritten to be more robust, to use Freenet's updating mechanisms, and to use parallel connections (and possibly avoiding some freenet antipatterns such as giant directories). Certainly the uploading side would need to be written. > > > > I'm trying to bring us into 2013, Maven is virtually a standard Java > > tool > > > these days. freenet-ext.jar has to be built, has to be kept up-to-date. > > > It's basically an ugly home-grown dependency management solution. > > > Originally there were no alternatives, but now there are, and there are > > > easy solutions to the problems that you've outlined with it. > > > > No, Maven does not help with freenet-ext.jar at all. The end-user does not > > use Maven. > > Using Maven's assembly plugin - it's trivially easy to compile your code, > together with all dependencies, into a single .jar. This is not a Maven feature, it's an ant feature. But it does not work if one of the jars is a JCA crypto provider. These jars have to be signed, and therefore have to be separate. At an absolute minimum we need to ship TWO jars, and we need to be able to update both of them. However there are good reasons for splitting freenet-ext.jar up in a more fine grained way, and the auto-updater infrastructure is quite capable of dealing with this. For example, reducing the size of the download when updating; using the system jars on packages on certain operating systems; etc etc. There are workarounds, but they involve significant cost in cash, maintenance or performance: We could buy a Java code signing certificate and rebuild and re-sign it ourselves. Which doesn't fit cleanly with Maven, though I'm sure it's possible. Or we could give up on using the standard Java encryption API (JCA) and use the Bouncycastle lightweight API for everything, and have to ship our own native JNI libraries for optimised ECC (native gives a 4x speedup IIRC even on x86, granted it's only used for connection setup and SSKs). We can't rely on Oracle's built in crypto either, as some versions of Java 1.6 don't support modern (ECC) crypto at all. Maven does not help us with deployment. The major problems with deployment have already been solved, apart from updating the wrapper (which again requires a separate jar so that we can update both the jar and the native binaries at the same time). Just because something is new does not mean it is appropriate for us. I have been trying to use modern components where possible, e.g. JCA. Now can we please shut up about Maven? It will not save us any time in the short term, or in the long term, and we have a huge amount of stuff to deal with already! On Thursday 31 Jan 2013 21:34:49 Matthew Toseland wrote: > Including the dependency jars in the main freenet jar shipped is possible > with or without Maven - except that it isn't for at least one jar, the > Bouncycastle crypto provider, which needs to be bundled separately as it is > signed. I'm not sure whether we could combine it if we signed the whole file, > but even then we'd need a code signing cert for Java. We do need one for > Windows, but IIRC you mostly have to pay separately for Java vs for Windows. > For linux installs it's good for packages to be able to use the system > version of bouncycastle (and other libraries), which is what originally > motivated infinity0's work on splitting up freenet-ext.jar. > > What does make a difference is the changes made to the auto-updater I made > last year. These allow us to ship the bouncycastle jar, to update it, and to > ship whatever other jars we need, updating them when we need to. We can split > up freenet-ext.jar however we want (including using infinity0's branch). > > But given that freenet-ext.jar changes *very* slowly, I don't see an urgent > issue. > > The most urgent issue related to this area is updating the wrapper, which can > cause problems on Windows, but which is tricky to update because wrapper.jar > is included in freenet-ext.jar, and needs to be compatible with the native > binaries. Maven does not help here either.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
