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

[Carter Schonwald]

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/daf0fc5d/attachment.html>