<div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div><span style="font-size:13.1999998092651px;line-height:19.7999992370605px">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.</span><br style="font-size:13.1999998092651px;line-height:19.7999992370605px"></div></div><br><div class="gmail_quote">On Wed, Apr 15, 2015 at 3:20 PM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com">carter.schonwald@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">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</p>
<p dir="ltr">And additonally: there Is a globally visible feed / log of all Hackage edits.  </p>
<p dir="ltr">I believe some folks are working to add those features to hackage this spring.  </p>
<p dir="ltr">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.  </p>
<p dir="ltr">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.  </p>
<div class="gmail_quote">On Apr 15, 2015 2:47 AM, "Michael Snoyman" <<a href="mailto:michael@snoyman.com" target="_blank">michael@snoyman.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote">On Wed, Apr 15, 2015 at 9:14 AM Gershom B <<a href="mailto:gershomb@gmail.com" target="_blank">gershomb@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On April 15, 2015 at 1:57:07 AM, Michael Snoyman (<a href="mailto:michael@snoyman.com" target="_blank">michael@snoyman.com</a>) wrote:<br>
> I'm not intimately familiar with the Hackage API, so I can't give a<br>
> point-by-point description of what information is and is not auditable.<br>
<br>
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.”?<br>
<br>
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.<br>
<br>
Cheers,<br>
Gershom<br></blockquote><div><br></div><div>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:</div><div><br></div><div>* 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?</div><div>* I know of no way to see the history of authorization rules.</div><div>    * Was JohnDoe always a maintainer of foobar, or was that added at some point?</div><div>    * Who added this person as a maintainer?</div><div>    * Who gave this other person trustee power? Who took it away?</div><div><br></div><div>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.</div><div><br></div><div>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."</div><div><br></div><div>Michael</div></div></div>
</blockquote></div>
</blockquote></div>