On 01/31/2013 10:06 AM, Ertugrul Söylemez wrote:

Joachim Breitner <mail@joachim-breitner.de> wrote:

And that may even be more harmful, because an insecure system with a
false sense of security is worse than an insecure system alone.

Let's do it properly.

but don’t overengineer it either. Simply adding to hackage the
possibility to store a .asc file next to the tar.gz file that contains
the cryptographic signature would be a great start, and allow us to
develop a WoT model later on.

(I try to resist from wondering whether this could go into hackage1 or
only hackage2, and in the latter case, whether that means that we
actually have the time to overengineer the system.)

In fact, a lot would already be gained by a simple „warn if foo-2.0 is
signed with a different key than the version of foo already installed“
on cabal-install and people having a closer look at uploads from
different people. Not much infrastructure needed there.

That was exactly my suggestion actually.  It requires the ability to
make and check signatures.  The making can be done with external tools
like GnuPG, but the checking has to be done by cabal-install.  To detect
changed keys there also needs to be a trust database, which can be a
simple directory in ~/.cabal/ where files are named after the
fingerprint of the key it contains.

The most important part is a sensible user interface.  The whole process
should be invisible to the user, until there is a signature error.  The
first installation of a package will actually generate a handful of
signature errors, because the keys are not known yet.

This shouldn't be too hard to implement and requires only a small change
to Hackage and cabal-install's upload command to begin.

That's not a proper solution, and definitively in the warm fuzzy feeling department.

What if you install a package for the first time and this package has just been re-uploaded maliciously with a different key and a payload ?
What if you're relying on hackage mirrors, what stop this mirror to regenerate all signatures with a new key ?

It also make maintainers change difficult, and doing genuine non-maintainer upload.

--
Vincent

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe