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" <[email protected]> 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 < > [email protected]> 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" <[email protected]> wrote: >> >>> >>> >>> On Wed, Apr 15, 2015 at 9:14 AM Gershom B <[email protected]> wrote: >>> >>>> On April 15, 2015 at 1:57:07 AM, Michael Snoyman ([email protected]) >>>> 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 >>> >>
_______________________________________________ haskell-infrastructure mailing list [email protected] http://community.galois.com/mailman/listinfo/haskell-infrastructure
