[Haskell-cafe] Ticking time bomb

[Alexander Kjeldaas]

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

> On 01/31/2013 08:54 AM, Alexander Kjeldaas wrote:
>
>> On Thu, Jan 31, 2013 at 9:26 AM, Vincent Hanquez <tab at snarc.org> wrote:
>>
>>  On 01/31/2013 06:27 AM, Ertugrul Söylemez wrote:
>>>
>>>  In any case there is no valid excuse for the lack of crypto.  It's too
>>>> easy to attack Hackage, so we need some crypto regardless of what we
>>>> interpret it as.
>>>>
>>>> My proposal is:
>>>>
>>>>     1. Build the necessary machinery into Cabal to allow signing keys
>>>> and
>>>>        packages and verifying the signatures, ideally through GnuPG.
>>>>        Cabal would benefit from that even without cabal-install and
>>>>        Hackage.
>>>>
>>>>  Seems there's lots of suggestion of using gnupg, which is a perfectly
>>> valid answer if cabal was unix only, but i'm not sure it's a valid option
>>> considering windows. Sure you can install gnupg somehow, but sounds to me
>>> it's going the same problem as gtk2hs on windows.
>>>
>>> One better way, would be to tap in the 2, work in progress, gnupg haskell
>>> replacement:
>>>
>>> http://hackage.haskell.org/****package/openpgp<http://hackage.haskell.org/**package/openpgp>
>>> <http://**hackage.haskell.org/package/**openpgp<http://hackage.haskell.org/package/openpgp>
>>> >
>>> http://hackage.haskell.org/****package/hOpenPGP<http://hackage.haskell.org/**package/hOpenPGP>
>>> <http://**hackage.haskell.org/package/**hOpenPGP<http://hackage.haskell.org/package/hOpenPGP>
>>> >
>>>
>>>
>>> AFAIK, both packages are not yet handling anything related to WoT, but
>>> just do the signing/verification (which is same status as my ad-hoc
>>> experiment)
>>>
>>>
>>>  In this case I think this is the wrong approach.  There must be at least
>> one way to work within a trust model that is not fragile.  Whether this is
>> fully supported on all platforms is actually not very important.
>>
>> I have pointed out why simply signing packages is fragile and how git is
>> better suited for this task.  We are not going to reimplement all the good
>> infrastructure that already exists (gpg, git), so making that a
>> requirement
>> is not a good idea IMO.
>>
>> Basic verification of signatures should work on Windows, I agree.  But the
>> underlying WoT should be a little bit more sophisticated.  This means it
>> has to be based on standard tools, or it will never happen.
>>
>>  I think you misunderstood me.
>
> Having a fully working pgp package, means you have full control of the pgp
> stack, you don't rely on hard-to-get out tools, and it can be integrated
> with cabal directly for a full WoT experience.
>
> Also git doesn't solve the hackage problem, there's not necessarily a
> one-to-one mapping between packages and their repositories.
>
>
Regarding git, I don't see anyone even suggesting that hackage should
support multiple 'signed-off-by's, signing diffs between packages, and
signing releases.  I don't see anyone supporting 3rd-parties signing
packages at will.

All of this is significant engineering effort that just won't happen.

And even if it does, it still doesn't solve the problem, because all of the
above is required to protect our base ghc, cabal-install tools anyways.  If
cabal-install is hacked, hackage is hacked.

And even when all of this is done, a design where there is a set of trusted
developers is flawed.  The set of trusted developers will increase over
time, and there will be the need to restrict which developers can release
which package.

How do you protect that information, which keys can sign which packages?
 That information must itself be signed off by someone.  If not, ouch some
obscure developer in the trusted set hijacked an important package because
he was owned.

That signing in itself *requires* either consensus or a trusted third
party.  Consensus is a superior method and IMO required.

Actually, all modifications to important packages requires consensus by at
least two developers to avoid the threat posed by "owned" developers.

So although it is not a waste of time to "secure" hackage, it is always
going to be slightly fragile as long as ghc is fragile for example, and it
just isn't ever going to *really* solve the problem.

Git has the ability to solve all of this.

So a better use of resources IMO is to skip securing hackage by own means,
but to standardize on using git as the infrastructure for securing hackage.
 Then the same infrastructure that should secure ghc should secure hackage.

To explain this in concrete terms, to do this, all that is needed is
*something like* the following:

1. Each package on hackage gets its own repository (say on github or
similar).
    (I've actually put all of hackage in a single git repository - it works
fine, so there are no relevant size problems)
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.
4. If a package already has a git repository, that repository can be used
instead of the 'hackage' one.
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.

I'll just note that none of the above requires any changes to Hackage at
all.

That is the modification story.  On the verification side there are
multiple options:

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.
    At the same time, a set of distrustful machines do the same thing by
running cron-jobs that check the trusted machine.
    This is slightly fragile, but would "mostly work".

Alexander


> --
> Vincent
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130131/5f34614f/attachment.htm>