[Haskell-cafe] Ticking time bomb

Alexander Kjeldaas alexander.kjeldaas at gmail.com
Thu Jan 31 12:42:53 CET 2013


On Thu, Jan 31, 2013 at 11:40 AM, Vincent Hanquez <tab at snarc.org> wrote:

> On 01/31/2013 10:06 AM, Ertugrul Söylemez wrote:
>
>> Joachim Breitner <mail at 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.
>
>
It is still useful to protect "most users" and detect malicious code
"really quickly".  Someone will always have the package installed and will
notice, so the intruder will only be able to do very targeted attacks.

Basically this creates at chain of trust for each package.  What I think
you want is a chain of trust between packages.

Alexander


>
> --
> Vincent
>
> ______________________________**_________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/**mailman/listinfo/haskell-cafe<http://www.haskell.org/mailman/listinfo/haskell-cafe>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130131/c4a54d2e/attachment.htm>


More information about the Haskell-Cafe mailing list