[Haskell-cafe] [haskell-infrastructure] Improvements to package hosting and security

[Michael Snoyman]

On Wed, Apr 15, 2015 at 4:13 PM Gershom B <gershomb at gmail.com> wrote:

> On April 15, 2015 at 8:34:07 AM, Michael Snoyman (michael at snoyman.com)
> wrote:
> > I've given plenty of concrete attack vectors in this thread. I'm not
> going
> > to repeat all of them here. But addressing your "simpler idea": how do we
> > know that the claimed person actually performed that action? If Hackage
> is
> > hacked, there's no way to verify *any* such log. With a crypto-based
> > system, we know specifically which key is tied to which action, and can
> > invalidate those actions in the case of a key becoming compromised.
>
> So amend Carter’s proposal with the requirement that admin/trustee actions
> be signed as well. Now we can audit the verification trail. Done.
>
> But let me pose a more basic question: Assume somebody falsified the log,
> but could _not_ falsify any package contents (because the latter were
> verified at the use site). And further, assume we had a signing trail for
> revisions as well. Now what is the worst that this bad actor could
> accomplish?
>
> This is why it helps to have a “threat model”. I think there is a
> misunderstanding here on what Carter is asking for. A “threat model” is not
> a list of potential vulnerabilities. Rather, it is a statement of what
> types of things are important to mitigate against, and from whom. There is
> no such thing as a completely secure system, except, perhaps an unplugged
> one. So when you say you want something “safe” and then tell us ways the
> current system is “unsafe” then that’s not enough. We need to have a
> criterion by which we _could_ judge a future system at least “reasonably
> safe enough”.
>
> My sense of a threat model prioritizes package signing (and I guess
> revision signing now too) but e.g. doesn’t consider a signed verifiable
> audit trail a big deal, because falsifying those logs doesn’t easily
> translate into an attack vector.
>
> You are proposing large, drastic changes. Such changes are likely to get
> bogged down and fail, especially to the degree they involve designing
> systems in ways that are not in widespread use already. And even if such
> changes were feasible, and even if they were a sound approach, it would
> take a long time to put the pieces together to carry them out smoothly
> across the ecosystem.
>
> Meanwhile, if we can say “in fact this problem decomposes into six nearly
> unrelated problems” and then prioritize those problems, it is likely that
> all can be addressed incrementally, which means less development work,
> greater chance of success, and easier rollout. I remain convinced that you
> raise some genuine issues, but they decompose into nearly unrelated
> problems that can and should be tackled individually.
>
>
>
I think you've missed what I've said, so I'll try to say it more clearly:
we have no insight right now into how Hackage makes decisions about who's
allowed to upload and revise packages. We have no idea how to make a
correspondence between a Hackage username and some externally-verifiable
identity (like a GPG public key). In that world: how can we externally
verify signatures of packages on Hackage?

I'm pretty familiar with Chris's package signing work. It's a huge step
forward. But by necessity of the weaknesses in what Hackage is exposing, we
have no way of fully verifying all signatures.

If you see the world differently, please explain. Both you and Carter seem
to assume I'm talking about some other problem that's not yet been
described. I'm just trying to solve the problem already identified. I think
you've missed a few steps necessary to have a proper package signing system
in place.

You may think that the proposal I've put together is large and a massive
shift. It's honestly the minimal number of changes I can see towards having
a method to fully verify all signatures of packages that Hackage is
publishing. If you see a better way to do it, I'd rather do that, so tell
me what it is.

Michael

* * *

I think the above was clear enough, but in case it's not, here's an
example. Take the yesod-core package, for which MichaelSnoyman and
GregWeber are listed as maintainers. Suppose that we have information from
Hackage saying:

yesod-core-1.4.0 released by MichaelSnoyman
yesod-core-1.4.1 released by FelipeLessa
yesod-core-1.4.2 released by GregWeber
yesod-core-1.4.2 cabal file revision by HerbertValerioRiedel

How do I know:

* Which signatures on yesod-core-1.4.0 to trust? Should I trust
MichaelSnoyman's and GregWeber's only? What if GregWeber wasn't a
maintainer when 1.4.0 was released?
* How can 1.4.1 be trusted? It was released by a non-maintainer. In
reality, we can guess that FelipeLessa used to be a maintainer but was then
removed, but how do we know this?
* Similarly, we can guess that HerbertValerioRiedel is granted as a trustee
the right to revise a cabal file.
* But in any event: how do we get the GPG keys for any of these users?
* And since Hackage isn't enforcing any GPG signatures, what should we do
when the signatures for a package don't exist?

This is just one example of the impediments to adding package signing to
the current Hackage system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150415/329f19a1/attachment-0001.html>