[Exherbo-dev] Integrity checking

Niels Ole Salscheider niels_ole at salscheider-online.de
Thu Feb 19 20:24:05 UTC 2015


this topic has been discussed several times but Exherbo still lacks integrity 
checking for distfiles. The main reason why it has never been implemented is 
that it is said to break the development workflow.

We had some proposals to use git-annex for distfiles but there has not been 
any work on it. Also, one problem with git-annex is that it is written in 
Haskell which we do not want in the system set.
Yet, I think that integrity checking is important: it might not completely 
protect against e. g. the NSA but without it you become an easy target - for 
example, if you have to install something when only some untrusted and shared 
wireless connection is available. Integrity checking also helps to detect 
corrupt downloads or when upstream silently modifies a released tarball which 
can be annoying.

I would therefore like to discuss how a simple checksum based approach could 
look like and in which way it might break someone's workflow.

Such an approach could for example add a [[ checksum = SHA256 ]] annotation to 
each file in DOWNLOADS. We could have a tool that automatically fetches the 
files in the exheres and that adds / updates the checksum annotations. It 
would also present the computed checksums to the user so that he can compare 
them with published checksums from other sources. Maybe we could even run this 
tool as a git commit hook so that the process becomes mostly transparent...

We do not only have to check the downloaded files but also our repositories. 
Git helps here a bit since the SHA1 hashes change when history is rewritten.
Rewriting history is however something that occurs often during development. 
Therefore I suggest that we use forced pulls only from some configurable and 
trusted suffixes (so that "cave sync arbor --suffix local" continues to work 
when rewriting history during development). But we should make git complain if 
we pull from the official repositories and history is rewritten.
Of course, it is still possible to add malicious commits to the top but these 
are hopefully a bit easier to spot. Also, we can prevent most MITM attacks by 
using https for our repositories.

What do you think?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.exherbo.org/pipermail/exherbo-dev/attachments/20150219/994bf384/attachment.asc>

More information about the Exherbo-dev mailing list