[Sorted/trimmed/amended the quotes for readability] On Monday, October 05, 2015 12:52:08 PM Ian Clarke wrote: > On Mon, Oct 5, 2015 at 12:57 AM, xor <[email protected]> wrote: > > > - Maven/Gradle are now de-facto standard build systems for Java apps, > > > and yet we're still using Ant [...] > > > > There are 2 aspects here: > > > > 1) The security issue. > > Right, but it appears that solutions exist for this with Gradle.
"Apache Ant" = 1 320 000 Google hits "Gradle" = 957 000 Google hits :| An advantage of it would be that it seems to have Ant integration. > > 2) What can Maven do which Ant cannot do? Do we need those features? > > Dependency management By that, do you merely mean downloading some JARs from a fixed URI and putting them into the current directory; or is it actually even able to install current versions of stuff on the system's package manager? IIRC, our fred Ant builder used to download a fixed freenet-ext.jar to the current directory on its own, so that's not a Maven seller yet. But if Maven is indeed capable of using the package manager, I would actually get VERY hungry for it :) I prefer installing binaries from the package manager instead of having Maven shove truckloads of them into some backyard directory, as only by using the package manager I get automated security updates. > and more importantly, Maven (and more recently > Gradle) have become pretty-much industry standards, almost no new Java > project uses Ant. If we want to attract new contributors, the fact that we > have an outdated build system will be a turn-off for them. [...] > 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. > > Here is the feature. A developer wants to work on Freenet, so they type: > > $ git clone [email protected]:freenet/fred.git > $ cd fred > $ mvn assembly:assembly > > And now they've built a copy of Freenet. Is that the current experience > for a new developer? Current experience should be something like: $ apt-get install git $ apt-get install ant $ apt-get install default-jre $ git clone ... $ cd fred $ ant (Disclaimer: It is possible that Ant tells you to download some "bcprov" JAR because someone for whatever reason did not bother to update the script to do it. If it worked for freenet-ext.jar previously, I don't know why it wouldn't work for the new bcprov one though. I'd be glad if someone with write-access to our server fixed this.) > By not using a modern dependency management > system we're creating a significant barrier to entry for new contributors > to the code. I speculate you conclude that from at least one of those assumptions: The assumption that someone who first wants to compile a project is incapable or unwilling to install software (such as Ant) to do so. I suspect those assumptions are overkill: @Incapable: Same as someone who is planning to work on a car engine can be assumed to be well beyond being able to drive, someone who wants to compile software can be assumed to be well beyond being able to install software such as Ant. Also, it shouldn't be difficult for a developer to fix out how to run a build system they haven't used yet. In my experience most READMEs contain the command line, so we might expect people to look there? @Unwilling: I don't know how it works for other people, but whenever I compile a new piece of software, I already am 100% expecting to have to install a TRUCKLOAD of stuff. Almost every software needs some kind of library. Ant is just one of them. And there are Ubuntu etc. packages, so people can get it easily. Again, IF Maven is capable of using the package manager, and thus can spare me from having to install any other packages, I am very willing to change my mind to "this is high priority" :) BUT: Overall, I don't think that we have to discuss this to death since Florent provided a very nice idea of a compromise: > Nothing prevents us from having both Ant and Gradle build > scripts while the quirks are ironed out. So I'd say if a volunteer feels like providing Maven scripts, we do accept to merge them as secondary build scripts, but keep recommending Ant as default for now. ACK? > > Also, we've today discussed using the same theme [as at the website > > remake] 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 don't see why either of these would be prerequisites. Sorry, I had left out the explanations for "prerequisites" since they're in the bugtracker. Here is a summary: - If we make the new website design also the Freenet UI theme, then people are likely to mix up the both. This worsens the problem that people are likely to not realize that Freenet and the regular Internet are two different spaces. It's a big problem even now already - our #1 most frequent question is probably "how can I use Freenet to browse regular websites like with Tor?". - To fix the mixup, it would be good to add some indicator to the Freenet web interface which distinguishes Freesites from regular websites. For example a green border. The problem with doing it in HTML is that any site can fake it. So to do this properly, we need browser code: Only browser code can render stuff outside of the HTML canvas to prevent faking. - To get code running in the browser, we need a browser plugin at least -> Thats the first of the above prerequisites. - Tor had a browser plugin, but they don't maintain it anymore. Instead, they ship a whole browser - which probably has some more security benefits as it can disable dangerous parts of the browser codebase. So we might just recycle their whole browser bundle. However, browsers have to be updated very frequently for security reasons, and we cannot keep up with the maintenance. If we give Tor the compiling scripts for a Tor + Freenet bundle, they might realize that it benefits both us and them, and in return deal with deploying binaries + updates for us. They need to compile their Firefox bundle for themselves anyway, adding one more binary installer as output shouldn't be much hassle. -> That's the second of the above prerequisites. You are right, the word "prerequisites" is maybe a bit far fetched with regards to using the new website theme as Freenet UI theme. We probably should do that right away. But I think those ideas are nevertheless interesting: It should be remembered that over the years, it has been agreed dozens of times that we need a custom browser for true security: The current approach of trying to hack the user's regular browser into proper incognito mode is error- prone and hence very dangerous - it might reveal their Freenet usage to Google or whoever. > > [...] bundling Tor+Freenet: [...] > [...] > And now we'd basically have to maintain a custom Tor > installer, in addition to our existing installer. [...] See above: I don't think we maintain it ourselves either. But it's likely that Tor can: Their live CD in fact includes not only Tor, but also I2P. We've already asked them, and they *would* consider to include Freenet in the CD if we provided a Debian package. Providing a standalone installer instead of just a live CD is just a small additional step IMHO: As long as we set it up, and they only have to merge updates of Firefox into it, the maintenance burden shouldn't be that much. > If someone wants to use both Freenet and Tor then they can download them > individually, but I see no good reason to bundle two independent pieces of > software just because they both solve related (but different) problems. Well, the question is if the user's care about the difference: Fact is that Freenet is insanely small compared to the regular Internet. They'll thus likely to continue wanting anonymous access to the regular net - and keep uninstalling Freenet if it can only provide its own small content :( I do plan to soon after the performance work deal with improving the amount of content by getting Freetalk/Sone deployment-ready and implementing filesharing on top of Freetalk :) But that will likely take much longer than the suggested Tor/Freenet bundle. And a volunteer could work on the bundle in parallel, I don't want to do this now since WoT/Sone/FT are more important. Another view on this: We've already done a similar tradeoff with providing opennet in addition to darknet. Opennet is insanely insecure compared to Freenet's goals, and many people hated the idea - but it had to be done to get a decent amount of users. Maybe we could do another pro-usability tradeoff with Freenet + Tor? And finally notice: I do think this is not something which we should be spending money on. We really need to dedicate our resources on getting our existing sub-projects finished. But if a volunteer wants to deal with this, I'd say go for it :) Greetings
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
