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
