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

[Michael Snoyman]

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.

There are no nebulous claims going on here. Hackage is interacting with
users in a way that is completely susceptible to MITM attacks. That's a
fact, and an easily exploitable attack vector for someone in the right
position in the network. I'm also precisely *not* recommending we tack
security things on top: I'm proposing we design a secure system from the
ground up.

Also, if we're going to talk about nebulous, let's start with the word
"enterprise sounding." That's an empty criticism, and I should hope we're
above that kind of thing.

On Wed, Apr 15, 2015 at 3:20 PM Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> Ok, let me counter that with a simpler idea: every Hackage edit action has
> an explanation field that the trustee can choose to optionally write some
> text in
>
> And additonally: there Is a globally visible feed / log of all Hackage
> edits.
>
> I believe some folks are working to add those features to hackage this
> spring.
>
> I am emphatically against stronger security things being tacked on top
> without a threat model that precisely jusrifies why. Recent experience has
> shown me that organizations which mandate processes in the  the name of a
> nebulous security model counter intuitively become less secure and less
> effective.
>
> Let me repeat myself, enterprise sounding security processes should only
> be adopted in the context of a concrete threat model that actually
> specifically motivates the applicable security model.  Anything else is
> kiss of death.  Please be concrete. Additonally, specificity allows us to
> think of approaches that can be both secure and easy to use.
> On Apr 15, 2015 2:47 AM, "Michael Snoyman" <michael at snoyman.com> wrote:
>
>>
>>
>> On Wed, Apr 15, 2015 at 9:14 AM Gershom B <gershomb at gmail.com> wrote:
>>
>>> On April 15, 2015 at 1:57:07 AM, Michael Snoyman (michael at snoyman.com)
>>> wrote:
>>> > I'm not intimately familiar with the Hackage API, so I can't give a
>>> > point-by-point description of what information is and is not auditable.
>>>
>>> Okay, then why did you write "There's a lot of stuff going on inside of
>>> Hackage which we have no insight into or control over.”?
>>>
>>> I would very much like to have a clarifying discussion, as you are
>>> gesturing towards some issue we should think about. But it is difficult
>>> when you make broad claims, and are not able to explain what they mean.
>>>
>>> Cheers,
>>> Gershom
>>>
>>
>> I think you're reading too much into my claims, and specifically on the
>> unimportant aspects of them. I can clarify these points, but I think
>> drilling down deeper is a waste of time. To answer this specific question:
>>
>> * There's no clarity on *why* change was approved. I see that person X
>> uploaded a revision, but why was person X allowed to do so?
>> * I know of no way to see the history of authorization rules.
>>     * Was JohnDoe always a maintainer of foobar, or was that added at
>> some point?
>>     * Who added this person as a maintainer?
>>     * Who gave this other person trustee power? Who took it away?
>>
>> All of these things would come for free with an open system where
>> authorization rules are required to be encoded in a freely viewable file,
>> and signature are used to verify the data.
>>
>> And to be clear, to make sure no one thinks I'm saying otherwise: I don't
>> think Hackage has done anything wrong by approaching things the way it has
>> until now. I probably would have come up with a very similar system. I'm
>> talking about new functionality and requirements that weren't stated for
>> the original system. Don't take this as "Hackage is bad," but rather, "time
>> to batten down the hatches."
>>
>> Michael
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150415/d2bb6e7c/attachment.html>