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. 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. 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.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
