On Thu, Jan 31, 2013 at 2:31 PM, Michael Grube <[email protected]>wrote:
> > > On Thu, Jan 31, 2013 at 1: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: >> > >> > > I was thinking about the fact that we still build Freenet using the >> tools >> > > that were available to us a decade ago, while the Java world has >> moved on >> > > to more sophisticated dependency management tools like Maven. >> > > >> > > I recall that the reason for not using Maven is that it doesn't >> operate >> > > over a secure connection, and it leaves us open to the compromise of >> any of >> > > Freenet's dependencies Maven repositories. >> > > >> > > 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? >> > > >> > > However, one approach that might alleviate this concern is that we >> run our >> > > own Maven repository which will host any dependencies we need, and >> then >> > > configure Maven not to pull from the central Maven repos. >> > > >> > > There is the other issue that Maven can be a PITA to use, however >> there >> > > are similar alternatives: >> http://www.streamhead.com/maven-alternatives/ >> > > >> > > Thoughts? >> > > >> > Maven's really not that bad. If people are absolutely terrified about >> > depedencies being compromised, maybe make a quick script to do a >> checksum >> > on the dependencies once they're donwloaded. >> >> Maven does not do any sort of signature checking. Maven's own repository >> doesn't even do SSL IIRC. > > > http://maven.apache.org/guides/mini/guide-repository-ssl.html > > > >> It is therefore not suitable for building binaries that will be >> distributed. In my view this is true of any binaries that will be >> distributed to anyone, but it certainly isn't true of building binaries for >> an auto-updater capable of deploying 5,000 nodes within an hour - a >> significant target for conventional malware even if it wasn't for the fact >> that some of these people really do need their privacy. >> >> If we run our own repository: >> - We need to maintain it. This is more unnecessary work. >> - We need to host it. This is more CPU usage on the small, cheap, rather >> limited VM that runs the website etc. >> >> 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. >> > > Some kind of Infocalypse bridge? > > >> >> 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. >> >> If you really want security advice ask nextgens. But it looks to me like >> Maven is hopeless for our purposes. For a non-security-related project, for >> a single developer who doesn't distribute the resulting binaries, fine. For >> a corporate setup where both the developers and the server are inside the >> firewall, fine. But for us, it does not make sense. >> >> Regarding not auditing dependencies, we do try to obtain "clean" copies >> of our dependencies. Also most of them aren't security critical, and so >> aren't updated regularly. Ordinarily this would be a bad thing - but it >> does reduce the number of opportunities for malware to slip in. The biggest >> dependency is db4o, and IMHO we should get rid of it soon, it's been >> nothing but a nightmare. Whenever we have looked into updating it we have >> found new and wonderful bugs, and so haven't bothered... >> >> In any case, the fact that we haven't audited every line of some of our >> dependencies is not an excuse for failing to perform basic due dilligence >> on our build process. Freenet is security sensitive, it has an >> auto-updater, it's not safe for us to just grab jars from wherever and hope >> for the best, which seems to be what most of the Java community do. And >> it's what Maven does too, without any form of authentication. >> >> The best person to ask for security advice on this sort of issue is >> Nextgens anyway. He's been around lately. >> > >
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
