On Thursday 31 Jan 2013 20:37:43 Ian Clarke wrote: > On Thu, Jan 31, 2013 at 12:59 PM, Matthew Toseland < > [email protected]> wrote: > > > On Thursday 31 Jan 2013 17:50:32 Michael Grube wrote: > > > On Thu, Jan 31, 2013 at 11:36 AM, Ian Clarke <[email protected]> > > wrote: > > > > This is despite the fact that no such compromise as ever occurred on > > any > > > > project that I'm aware of, and since we don't do code audits of > > Freenet's > > > > current dependencies, our current approach doesn't immunize us against > > it > > > > anyway. > > > > Have you actually tried to find out? > > If by "try" you mean a quick > Google<https://www.google.com/webhp?sourceid=chrome-instant&ion=1&ie=UTF-8#hl=en&tbo=d&sclient=psy-ab&q=maven%20repository%20compromise&oq=&gs_l=&pbx=1&fp=eba5ecb19bdd79c3&ion=1&bav=on.2,or.r_gc.r_pw.r_cp.r_qf.&bvm=bv.41642243,d.b2I&biw=1371&bih=983>search, > then yes.
They don't have to compromise the repository. All they have to do is spoof it, if we're using HTTP. Although as Michael pointed out it is possible to use HTTPS. > > If we run our own repository: > > - We need to maintain it. This is more unnecessary work. > > Not a lot, probably less than dealing with the freenet-ext.jar mess. See below. > > > - We need to host it. This is more CPU usage on the small, cheap, rather > > limited VM that runs the website etc. > > It won't use significant CPU or bandwidth, only developers will access it, > and Maven caches dependencies locally. Ok. > > > 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. > > > Exactly what problem are you trying to solve here? It's really not that > > hard to build Freenet. Granted it should be easier; the immediate problem > > is you need not only freenet-ext.jar (which the build scripts will fetch > > for you if you set one line in a config file; the first time you run ant it > > will tell you this), but also the bouncycastle jar, which isn't > > auto-fetched. > > 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. 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 [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
