On 29/09/15 22:04, [email protected] wrote: > Regarding point 2 best probably simply would be to ping gerard, because he > is working at a new Freenet website and is almost finished according to > this posting of him here, which he posted 5 months ago: > https://emu.freenetproject.org/pipermail/devl/2015-May/038086.html > > > Greetings, > Torben Lechner > > --- Ursprüngliche Nachricht --- > Von: Ian Clarke <[email protected]> > Datum: 29.09.2015 21:50:27 > An: Discussion of development of development issues <[email protected]> > Betreff: [freenet-dev] Behind the times > >> Bringing an off-list conversation onto the list (I failed to cc the list >> in >> the first place). >> >> --- >> >> Unfortunately these aren't the only ways we've fallen behind the times >> (hard to believe we've been doing this for 15 years!). >> >> - 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) The perfect is the enemy of the good. The only third party library we use that has changed in the last 5 years is Bouncycastle, which is signed because it's a cryptographic provider. Whereas if we use Maven, every time we build potentially we are downloading and running hundreds of binaries which are either not signed or which have been built from unsigned binaries.
Just because it's the "industry standard" doesn't mean it's appropriate for our particular use case. Until a few years ago the industry standard was to not encrypt communications other than online banking; now a lot of the internet is HTTPS. Checking a signature or at least a checksum is basic due diligence for security-related software. It's not supported reliably by Maven, apparently for business reasons. Therefore we should build our dependencies from source, and verify at least a checksum to ensure that it hasn't changed specifically for our particular build. It is true that we can't realistically audit the source code of all our dependencies, but that is not a reason to throw our hands in the air and cry "industry standard, we can't do better than the industry standard". However, we have had this argument before. I don't expect to change your mind and you have no hope of changing mine. The last time this came up it led to some deeply unprofessional accusations on both sides. Negotiate with the active developers, this is just my worthless one pence. We should be able to use software which is normally built with Maven by building it from source; it should be possible to automate most of this process, while still checking signatures where possible and downloading from multiple sources to get a known-good-ish checksum where it isn't. >> - 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 See other messages. There is a new website (almost?) ready to deploy. Thankfully we are now past the era where "new" means "flash". I believe the amount of intrusive third party analytics and tracking we have on our current website is unacceptable for much of our main target demographic - people who actually give a damn about privacy. Certainly my use of Google Analytics has never been much beyond what could have been achieved with a good logfile analysis tool - mostly browsers and OSs and overall trends. >> - We could also use an automatic unit testing system like Travis CI >> <https://travis-ci.org/> >> (which is free for O.S projects) We had one for some time, jenkins.freenetproject.org. It's not up at present because nextgens hosted it; a third party provider is a good alternative. We do have an account on a commercial static code analysis site currently. A normal build runs the unit tests (but without the more expensive tests included). Developers can however bypass this via a command line flag. In any case it is useful to run the expensive tests, ideally on a per-commit level with automatic bisection when it fails. I hope that my uni project this year may lead to some higher level unit tests. >> Of course, all of these things will require work. Fortunately, most can >> be >> tackled independently of each-other and so we can bite off one piece at a >> time, if there are any volunteers to take ownership of them. You also proposed moving the bug tracker. That would require *a lot* of work, for little benefit other than a small cash saving.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
