Hi Nicohood, On Thu, Dec 01, 2016 at 04:23:27PM +0100, NicoHood wrote: > you do not need to move the packages as fast as possible into > community. I became TU month ago and arduino is still not in community > because some issues needed to be solved first. So quality and security > is more important here.
Agreed. > About all this https discussion: > I think we should all confirm with the gpg and https standards we made > recently (and the string hashes that i suggested) and we should also try > to increase the quality of AUR in general and especially as TU to advise > other people to do so too. > Packaging a secure chat program and being so lazy about https makes me > wonder. > > I think it'd be good for you to rethink the https (and gpg, hash) topic, > because (especially) as secure chat messenger packager it'd be extremely > important to me that you try to achieve the best security as possible. You almost sound like I'm opposing all forms of "security" (whatever you mean by that). Of course we should promote the use of TLS and HTTPS on the Internet, even though the trust model is flawed and implementations are bloated/bugged. My point is that in the context of packaging, we have different requirements than for web browsing. HTTPS does not provide authenticity and integrity of the sources themselves, which is what we are interested in. PGP (preferably) and strong hash algorithms (as a substitute) should be used for that. To avoid repeating the same arguments, I agree with what seblu said on arch-dev-public: On Tue, Nov 01, 2016 at 04:03:04PM +0100, Sébastien Luttringer wrote: > TLS is about security of the transportation of sources, not the security > of sources themselves, that's why I asked, to know what you had in mind. > > My definition of securing the sources, is a way to trust the sources at > the build time, no matter the way they were fetched. I want to be sure > that my sources are "correct" even if I get them by usb key, ftp, rsync > or even if they were not corrupted locally by a btrfs bug. And when > possible, I want to be sure that the server (mirror or not) was not > compromised (even at the first fetch). > > Keeping that in mind, enforcing tls, doesn't improve much the source > security. In fact, it improves only security during the transportation > of the sources at the cost of the caching. Besides this issue, I already mentioned another drawback of using HTTPS: untrusted certificates (either expired, self-signed, or just signed by an untrusted CA) will cause build failure. This was a real issue for OpenWRT, so they switched to using --no-check-certificate in 2010  to avoid build failures. Sources are already validated with a checksum. Anyway, some of my packages do not use HTTPS, and this is indeed mostly because of laziness. I consider this is a low priority task. It does not mean that I am fundamentally opposed to the use of HTTPS, especially for "big" providers like github which are not very likely to have expired certs. I had a look at the sources for my AUR packages, and here is the result: - 5 fetched over HTTPS - 7 fetched over git+https:// - 5 fetched over HTTP, with no HTTPS available - 1 fetched over FTP, with no HTTPS available - 5 fetched over HTTP while HTTPS is available (including 1 with a PGP signature) - 6 fetched over git:// while git+https:// is available So, less than half of them needed to be "fixed". I just switched to HTTPS for 10 out of the 11 fixable packages. The only remaining one is linux-mptcp, because I plan to move it away from git soon anyway. Baptiste  https://git.lede-project.org/?p=openwrt/source.git;a=blobdiff;f=scripts/download.pl;h=633a4f6f7d;hp=fe27df5e8f;hb=65fad8645d;hpb=5884b43b51
Description: PGP signature