First of all let me say that I'm happy to see you participate again :) If you feel like contributing some more, I can highly recommend IRC as the discussion there is nowadays very frequent and vivid. The mailing list is usually used more as a fallback if people don't reply to very important stuff soon enough.
On Tuesday, September 29, 2015 02:50:27 PM Ian Clarke wrote: > Unfortunately these aren't the only ways we've fallen behind the times > (hard to believe we've been doing this for 15 years!). I've recently been citing Freenet as 16 years old, based on the year of the Freenet whitepaper. What's the actual age? :) > - Maven/Gradle are now de-facto standard build systems for Java apps, > and yet we're still using Ant (I was never convinced by the security > argument against these tools, since we don't audit 3rd-party libraries > anyway) There are 2 aspects here: 1) The security issue. I understand that nobody would want to conduct man-in-the-middle via Maven to attack some random Android game developer or whatever. Attacks who are interested in using botnets for spam or whatever also probably even couldn't get access to the Internet backbones to inject their fake binaries. However please look at *our* threat model: Freenet is a highly political project, and thus our biggest threat is governments. Governments control infrastructure, and this includes having access to the core Internet backbones. Conducting MITM is trivial if you have backbone access, and so they're very likely to abuse it if our developers execute arbitrary binary code which is downloaded from the Internet without any verification whatsoever. As you did argue against Ant, one could say that it is also trivial for them to maliciously inject *non*-binary code, i.e. alter the source code of third party projects which we pull without review. So we'd be in the same danger with Ant. However this misses the fact that injecting source code *without getting noticed* is a lot more difficult than injecting binary code: Source code is human-readable, binary code is not. I mean who is going to shove a JAR into a disassembler and read the bytecode? I don't think anyone is going to do that. With using Ant, we at least have the possibly that third-party projects review code on their own before merging it - just as we do. And besides that, I think running arbitrary unsigned code off the Internet is really a core basic security mistake; and hence something which is just not by any means even up for discussion to be done on purpose by a security-focused project as we are. It's Maven's problem if they cannot keep up with industry security standards and thus are ditched in favor of Ant. We shouldn't let ourselves be dragged down to such mistakes just because Maven is popular. 2) What can Maven do which Ant cannot do? Do we need those features? I currently cannot recall anything severe which I'm missing from Ant. It is critically important to notice that it must provide some kind of advantage before we consider changing it. This is because the imbalance between the size of our TODO list and the amount of developer force we have has grown very high - there are far too few developers. So we must avoid work which doesn't yield an immediate big benefit for our users; or potentially even is "only changing stuff around for the sake of changing stuff around". Just have a look at how many subprojects we have: https://wiki.freenetproject.org/Projects Yet we currently only have the money for funding 1-2 persons. And we spent years worth of work upon writing new core fred features, while mostly not dealing with deployment of sub-projects, i.e. client applications. So there is a huge lack of getting existing code out to the users. This makes both developers unhappy because their work is ignored, and Freenet users unhappy because Freenet has few actual features. I'm happy that I've been given the opportunity to work with deployment as client application maintainer, thats a step in the very right direction IMHO. But even if I continue to use all my available time on deployment, we still don't have enough workforce to get *all* apps polished to deploy-ableness any soon. It'll likely take a year for each. So overall I think we should also stick to trying to motivate volunteers to deploy as much as possible - instead of merely dealing with changing things around such as Ant -> Maven. > - Website badly needs an update, it looks very dated and frankly a bit > spammy. Bootstrap <http://getbootstrap.com/> > anyone, or even the Github page generator > <https://github.com/blog/1081-instantly-beautiful-project-pages> > would be a big improvement Steve has been working on deploying the remake, and I'm confident he'll finish it soon: https://testing.freenetproject.org/ (Username / Password = guest) AFAIK this is a direct result of your mail, so thanks for motivating people to do this :) Also, we've today discussed using the same theme for FProxy to make it look more recent as well. This yielded some nice ideas as prerequisites: "Browser extension to indicate whether user is on Freenet or regular Internet" https://bugs.freenetproject.org/view.php?id=6687 "Bundle Tor with Freenet" https://bugs.freenetproject.org/view.php?id=6689 I'm very happy that after all the years I finally got to think as far out of the box as it was necessary to suggest bundling Tor+Freenet: The previous "How to tell users to decide whether to use Tor OR Freenet?" thinking was too conservative. It should rather be "How can we make users benefit from both Tor AND Freenet?". They're quite complementary to each other after all: Freenet provides anonymous access to decentralized sites, Tor does not. Tor provides anonymous access to non-decentralized sites, Freenet does not. Ship both, and users can access the "whole" Internet. If anyone wants to step up to establish collaboration with the Tor developers, please do so - I currently must stay focused on finishing the WoT performance work. Please then before do read the above bugtracker entry, as it mentions aspects which should be considered before contacting Tor. > - We could also use an automatic unit testing system like Travis CI > <https://travis-ci.org/> > (which is free for O.S projects) The Ant scripts of at least the part of our projects I've been working on (fred, Web of Trust, Freetalk) do run the unit tests as part of compiling. The deployment scripts for releasing Freenet binaries also do that IIRC. So it should at least be ensured that tests are run at least once before deployment. You're right though: It would be nice to have the tests run automatically on a server - especially since they can have a long execution time of ~20 minutes on stuff such as WoT where they're more advanced nowadays. Still I'd say this is not something I should be spending paid work upon, as it is not critical to the aforementioned goal of getting many client apps deployed ASAP: I do think I have the discipline to run tests myself when having changed important code - this is because I love unit tests, awesome method of debugging :) I actually would like to get to the point of 100% test coverage in WoT someday. Anyway, I hope we can agree on this: - We can keep Ant unless we discover a feature in Maven which we must have; and if we switch, we first must find a way to fix the security issues. - The website remake should be deployed soon, it's nice. - Travis CI would also be nice, but only if done by a volunteer; not justified to be done as paid work. Greetings & again, thanks for your ideas, they spawned useful work and discussions! -- hopstolive (keyword for Ians spam filter)
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
