I'm 100% in favor of that. Last time it was brought up, we ended up in a debate about the the Haskell Platform and the PVP, which left the relevant package authors not wanting to get involved. If someone starts the conversation up, I will fully support it.
That will fix the largest problem we have. It still means we're placing all of our trust in Hackage, which sets up a single point of failure. We can, and should, do better than that. On Wed, Apr 15, 2015 at 4:09 PM Carter Schonwald <[email protected]> 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" <[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 >>>> >>> -- > You received this message because you are subscribed to the Google Groups > "Commercial Haskell" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/commercialhaskell/CAHYVw0xbNQPZ%2Bockbn1Zve69eQoZ4OOeUKt-bqa72vn-N_FQPg%40mail.gmail.com > <https://groups.google.com/d/msgid/commercialhaskell/CAHYVw0xbNQPZ%2Bockbn1Zve69eQoZ4OOeUKt-bqa72vn-N_FQPg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. >
_______________________________________________ haskell-infrastructure mailing list [email protected] http://community.galois.com/mailman/listinfo/haskell-infrastructure
