[Haskell-cafe] Ticking time bomb

[Kevin Quick]

> Git has the ability to solve all of this.
...
> 2. Uploads to hackage either happen through commits to the git  
> repository,
> or an old-style upload to hackage automatically creates a new anonymous
> branch in the git repository.
> 3. The git repository is authorative.  Signing releases, code reviews  
> etc.
> all happens through the git repositories.  This gives us all the
> flexibility of a git-style trust model.
...
> 5. Who owns which package names can be held in a separate meta-tree git
> repository, and can have consensus requirements on commits.
> 6. This special meta-tree can also contain suggested verification keys  
> for
> commits to the other hackage git trees.  It can even contain keys that
> protect Haskell namespaces in general, so that no hackage package can
> overwrite a protected Haskell namespace.
> 7. As backward compatibility, the meta-tree can sign simple hashes of
> already existing packages on hackage.
...
> 1. There could be some git magic script that downloads the signed git tag
> objects only (small data set).  Then another script would generate a
> git-compatible SHA1 of the extracted tarball, given that the tarball was
> fetched from hackage.
> 2. Or cabal-install could fetch directly from git repositories and use
> standard git verification.
> 3. Or a trusted machine creates tarballs from the git repositories, signs
> them and uploads them to hackage.

Without details of git's trust/verification model, it's difficult to see  
how this particular SCM tool provides the trust capabilities being  
discussed any better than a more focused solution.  Additionally, the use  
of git is also difficult for many Windows users (80MB installed footprint,  
last I tried).  git has a much broader solution space than simply ensuring  
the integrity of package downloads, especially when "there could be some  
git magic script" that is still not identified and appears to have the  
same insecurities as the package download/upload itself.

Instead of using the "git" solution and looking for problems to solve with  
it, IMHO we should work from clearly defined problem to solution in  
general terms as our class, and then determine what specific tools  
represent an instance of that  solution class.

-- 
-KQ