[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...
Size: 819 bytes
Desc: This is a digitally signed message part.
More information about the Exherbo-dev