When github was uncovered, I was a bit concerned with the idea that it seemed to foment the idea of forking software all over the place, instead of branching, with results that are, in my opinion, quite upsetting in the way some software is handled (see also this David Welton post which is actually quite to the point – I don’t always bash Debian, you know, and at least with the Debian Ruby team I seem to be often on the same page ). I was so concerned that I even wrote an article for LWN about forking and the problems that it comes with.
Thinking about this, I should tell people to read that when they talk about the eglibc mess. And when I can find time I should see to translate my old article about MySQL from Italian to English – and maybe I should see to change the articles page to link the articles directly in HTML form rather than just PDF and DVI.
At any rate, the “fork it” button is not what I’m going to blog about today, but rather what happened yesterday when I decided to update hpricot which is now hosted strictly on github. Indeed there is no download page if not the one in github which points to the tags of the git repository to download.
It starts to get increasingly used the idea that just tagging a release is enough to get it downloaded, no testing, no packaging, nothing else. For Ruby stuff gems are prepared, but that’s it (and I think that github integrates enough logic for not even doing that). It’s cool, isn’t it? No it’s not, not for distributions and not for security.
There is one very important feature for distributions on released code and is the verifiability of the release archives, while it might be a bit too much to ask for all the upstream projects to have a verifiable GnuPG signature and sign all their release, but at least making sure that a release tarball will always be available identical to everybody who download it would be usable. I let you guess that github does not do that which is giving me headaches since it means I have to create the tarballs manually and push them to the Gentoo mirrors for them to be available (git archive makes it not too difficult, but it’s still more difficult that just fetching the release upstream).
I wonder how it might be possible to explain to the Ruby community (because here it’s not just the Rails community I’d say) that distributions are a key to proper management and not something to hinder at every turn.
I think using tagging to release stuff is very easy for developers to do and thus useful.Wouldn’t it be feasibly to add a feature to the next EAPI that allows calculating some kind of directory checksum for the all downloaded data and have that in the manifest?(That might not sound very secure. But the danger that an opensource project might put signed malware on their repositories is always there.)
I think that would be _quite_ an overkill, although yeah I was thinking of something along those lines.There is actually a BSD tool that can do most of what we need: @mtree@; unfortunately I failed at getting any @mtree@ implementation in Linux up to now; fortunately I think “libarchive”:http://code.google.com/p/li… is working toward adding support for read/write of mtree.
Regarding security, the situation is not that bad. Git cryptographically ensures the authenticity of the commit history, so it is enough to sign the commit ID.And thanks to git.eclass, Gentoo ebuilds will also happily check out source code from git trees.
Downloading from git trees is against policy, and it does not check the validity of the commit IDs, and you also have to trust _the server_.Sorry, GIT is not a security panacea.
You don’t have to trust the server, cloning a git repository will give you the entire commit history. Only if you do a shallow copy (which is not the default, although some devs think it is a good idea) then a malicious server could slip in bad things.I agree that the policy of releasing software via git tags is bad. It is just that security is not an argument against it.
The problem is not the release by git tag, the problem goes *much* more deeper:* if github provided _always the same tarball for the same tag_ the problem wouldn’t be there because it would be the same as downloading the same static tarball from any server;* actually, added to the signed git tags it _could_ be considered a bit better (not much, but a bit);* the main problem is that you cannot verify that what github served to me is the same thing that is serving to you without actually comparing the two contents, and that is bad;* downloading software straight from git works for development but should not be allowed for production, and does not work behind proxies, which makes it a _no go_ for policy!* even with the whole history, *git is not a security system of any kind* and does not replace the need for proper peer review and absolute verifiability of the sources; see “this interesting post”:http://kitenet.net/~joey/bl… about the technical details of an attack to git repositories via SHA1 weaknesses; sure it’s not feasible right now, but it cannot be considered so impossible that git is trusted by default.The security point of having proper download archives for source releases still stand strong.
Note that GPG-signing is not enough: GPG uses SHA-1 too as default digest algorithm. Project managers should take care to select SHA-256 for signing in their gpg.conf: see http://www.debian-administr…
Well said.For quite some time I’ve wondered the same thing, namely the effect of DVCS-plethora to the quality of software in the long term.The tools are great and make the life easier when working with well-established projects, but the new associated culture makes me iffy. This thing called ‘github’ is a prime example: it tends to promote the exact opposite of what I consider to be good software engineering practice.If bazaar once was a metaphor, now it is increasingly the reality.
Found this while googling a way to get tarballs up on github. FYI, it appears github allows uploading arbitrary files (aka your own release tarballs) now. So you can build/prepare/sign your own release tarballs and still host them up on github close to your repo.