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

[Carter Schonwald]

A cryptographcially unforgable Hackage log is an interesting idea.   I'll
have to think about what that means though.
On Apr 15, 2015 9:08 AM, "Carter Schonwald" <carter.schonwald at gmail.com>
wrote:

> Ok. Let's get https support into cabal.
>
> How do we best go about doing that?
> On Apr 15, 2015 8:34 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.
>>
>> 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/b8bada38/attachment.html>