I'd like to ignore features of Hackage like "browsing code" for purposes of this discussion. That's clearly something that can be a feature layered on top of a real package store by a web interface. I'm focused on just that lower level of actually creating a coherent set of packages. In that realm, I think you've understated what trust we're putting in Hackage today. We have to trust it to: * Properly authenticate users * Keep authorization lists of who can make uploads/revisions (and who can grant those rights) * Allow safe uploads of packages and metadata * Distribute packages and metadata to users safely I think we agree, but I'll say it outright: Hackage currently *cannot* succeed at the last two points, since all interactions with it from cabal-install are occurring over non-secure HTTP connections, making it vulnerable to MITM attacks on both upload and download. The package signing work- if completely adopted by the community- would address that. What I'm raising here is the first two points. And even those points have an impact on the other two points. To draw this out a bit more clearly: * Currently, authorized uploaders are identified by a user name and a password on Hackage. How do we correlate that to a GPG key? Ideally, the central upload authority would be collecting GPG public keys for all uploaders so that signature verification can happen correctly. * There's no way for an outside authority to vet the 00-index.tar.gz file downloaded from Hackage; it's a completely opaque, black box. Having the set of authorization rules be publicly viewable, auditable, and verifiable overcomes that. I'd really like to make sure that we're separating two questions here: (1) Is there a problem with the way we're trusting Hackage today? (2) Is the strawman proposal I sent anywhere close to a real solution? I feel strongly about (1), and very weakly about (2). On Wed, Apr 15, 2015 at 7:07 AM Gershom B wrote:

So I want to focus just on the idea of a “trust model” to hackage packages.

I don’t think we even have a clear spec of the problem we’re trying to solve here in terms of security. In particular, the basic thing hackage is a central authority for is “packages listed on hackage” — it provides a namespace, and on top of that provides the ability to explore the code under each segment of the namespace, including docs and code listings. Along with that it provides the ability to search through that namespace for things like package descriptions and names.

Now, how does security fit into this? Well, at the moment we can prevent packages from being uploaded by people who are not authorized. And whoever is authorized is the first person who uploaded the package, or people they delegate to, or people otherwise added by hackage admins via e.g. the orphaned package takeover process. A problem is this is less a guarantee than we would like since e.g. accounts may be compromised, we could be MITMed (or the upload could be) etc.

Hence comes the motivation for some form of signing. Now, I think the proposal suggested is the wrong one — it says “this is a trustworthy package” for some notion of a web of trust of something. Webs of trust are hard and work poorly except in the small. It would be better, I think, to have something _orthogonal_ to hackage or any other package distribution system that attempts a _much simpler_ guarantee — that e.g. the person who signed a package as being “theirs” is either the same person that signed the prior version of the package, or was delegated by them (or hackage admins). Now, on top of that, we could also have a system that allowed for individual users, if they had some notion of “a person’s signature” such that they believed it corresponded to a person, to verify that _actual_ signature was used. But there is no web of trust, no idea given of who a user does or doesn’t believe is who they say they are or anything like that. We don’t attempt to guarantee anything more than a “chain of custody,” which is all we now have (weaker) mechanisms to enforce.

In my mind, the key elements of such a system are that it is orthogonal to how code is distributed and that it is opt-in/out.

One model to look at might be Apple’s — distribute signing keys widely, but allow centralized revocation of a malicious actor is found. Another notion, somewhat similar, is ssl certificates. Anybody, including a malicious actor, can get such a certificate. But at least we have the guarantee that once we start talking to some party, malicious or otherwise, no other party will “swap in” for them midstream.

In general, what I’m urging is to limit the scope of what we aim for. We need to give users the tools to enforce the level of trust that they want to enforce, and to verify certain specific claims. But if we shoot for more, we will either have difficult to use system, or will fail in some fashion. And furthermore I think we should have this discussion _independent_ of hackage, which serves a whole number of functions, and until recently hasn’t even _purported_ to even weakly enforce any guarantees about who uploaded the code it hosts.

Cheers, Gershom

...

any use of cryptographic primitives of any form NEEDS to articulate what the trust model is, and what the threat model is

likewise, i'm trying to understand who the proposed feature set is meant to serve.

Several groups are in the late stages of building prototypes at varying points in the design space for improving package hosting right now for haskell, and I'm personally inclined to let those various parties release the tools, and then experiment with them all, before trying to push heavily for any particular design that hasn't had larger community experimentation.

I actually care most about being able to have the full package set be git cloneable, both for low pain on premise hackage hosting for corporate intranets, and also for when i'm on a plane or boat and have no wifi. At my current job, ANY "host packages via s3" approach is totally untenable, and i'm sure among haskell using teams/organizations, this isn't a unique problem!

The Author authentication/signing model question in an important one, but I"m uncomfortable with just saying "SHA512 and GPG address that". Theres A LOT of subtlety to designing a signing protocol thats properly audit-able and secure! Indeed, GPG isn't even a darn asymmetric crypto algorithm, its a program that happens to IMPLEMENT many of these algorithms. If we are serious about having robust auditing/signing, handwaving about the cryptographic parts while saying its important is ... kinda irresponsible. And frustrating because it makes it hard to evaluate the hardest parts of the whole engineering problem! The rest of the design is crucially dependent on details of these choices, and yet its that part which isn't specified.

to repeat myself: there is a pretty rich design space for how we can evolve future hackage, and i worry that speccing things out and design by committee is going to be less effective than encouraging various parties to build prototypes for their own visions of future hackage, and THEN come together to combine the best parts of everyones ideas/designs. Theres so much diversity in how different people use hackage, i worry that any other way will run into failing to serve the full range of haskell users!

cheers

On Tuesday, April 14, 2015 at 1:01:17 AM UTC-4, Michael Snoyman wrote:

...

That could work in theory. My concern with such an approach is that- AFAIK- the tooling around that kind of stuff is not very well

developed, as

...

opposed to an approach using Git, SHA512, and GPG, which should be easy to combine. But I could be completely mistaken on this point; if existing, well vetted technology exists for this, I'm not opposed to using it.

On Mon, Apr 13, 2015 at 6:04 PM Arnaud Bailly | Capital Match < arn...@capital-match.com > wrote:

...

Just thinking aloud but wouldn't it be possible to take advantage of cryptographic ledgers a la Bitcoin for authenticating packages and

...

...

...

the history of change ? This would provide redundancy as the

...

...

...

log is distributed and "naturally" create a web of trust or at least authenticate transactions. People uploading or modifying a package would have to sign a transactions with someone having enough karma to allow

...

...

...

Then packages themselves could be completely and rather safely distributed through standard p2p file sharing.

I am not a specialist of crypto money, though.

My 50 cts Arnaud

Le lundi 13 avril 2015, Dennis J. McWherter, Jr. > >> > a écrit :

...

This proposal looks great. The one thing I am failing to understand

(and

...

...

I recognize the proposal is in early stages) is how to ensure redundancy in the system. As far as I can tell, much of this proposal discusses the centralized authority of the system (i.e. ensuring secure distribution) and only references (with little detail) the distributed store. For instance, say I host a package on a personal server and one day I decide to shut that server down; is this package now lost forever? I do see this line: "backup download links to S3" but this implies that the someone is willing to pay for S3 storage for all of the packages.

Are there plans to adopt a P2P-like model or something similar to support any sort of replication? Public resources like this seem to come and go, so it would be nice to avoid some of the problems associated with high churn in the network. That said, there is an obvious cost to replication. Likewise, the central authority would have to be updated with new, relevant locations to find the file (as it is currently

...

...

...

...

In any case, as I said before, the proposal looks great! I am looking forward to this.

On Monday, April 13, 2015 at 5:02:46 AM UTC-5, Michael Snoyman wrote:

...

Many of you saw the blog post Mathieu wrote[1] about having more composable community infrastructure, which in particular focused on improvements to Hackage. I've been discussing some of these ideas

with both

...

...

Mathieu and others in the community working on some similar

...

...

...

...

...

also separately spent some time speaking with Chris about package signing[2]. Through those discussions, it's become apparent to me

...

...

...

...

...

there are in fact two core pieces of functionality we're relying on Hackage for today:

* A centralized location for accessing package metadata (i.e., the cabal files) and the package contents themselves (i.e., the sdist tarballs) * A central authority for deciding who is allowed to make releases of packages, and make revisions to cabal files

In my opinion, fixing the first problem is in fact very straightforward to do today using existing tools. FP Complete already hosts a full Hackage mirror[3] backed by S3, for instance, and having the metadata mirrored to a Git repository as well is not a difficult technical challenge. This is the core of what Mathieu was proposing as far as composable infrastructure, corresponding to next actions 1 and 3 at the end of his blog post (step 2, modifying Hackage, is not a prerequesite). In my opinion, such a system would far surpass in usability, reliability, and extensibility our current infrastructure, and could be rolled out in a few days at most.

However, that second point- the central authority- is the more interesting one. As it stands, our entire package ecosystem is

...

...

...

...

...

huge level of trust in Hackage, without any serious way to vet what's going on there. Attack vectors abound, e.g.:

* Man in the middle attacks: as we are all painfully aware, cabal-install does not support HTTPS, so a MITM attack on downloads from Hackage is trivial * A breach of the Hackage Server codebase would allow anyone to upload nefarious code[4] * Any kind of system level vulnerability could allow an attacker to compromise the server in the same way

Chris's package signing work addresses most of these vulnerabilities, by adding a layer of cryptographic signatures on top of Hackage as

...

...

...

...

...

central authority. I'd like to propose taking this a step further: removing Hackage as the central authority, and instead relying entirely on cryptographic signatures to release new packages.

I wrote up a strawman proposal last week[5] which clearly needs work to be a realistic option. My question is: are people interested in moving forward on this? If there's no interest, and everyone is satisfied with continuing with the current Hackage-central-authority, then we can

...

...

...

...

...

with having reliable and secure services built around Hackage. But if others- like me- would like to see a more secure system built from

...

...

...

...

...

ground up, please say so and let's continue that conversation.

[1] https://www.fpcomplete.com/blog/2015/03/composable- community-infrastructure [2] https://github.com/commercialhaskell/commercialhaskell/wiki/ Package-signing-detailed-propsal [3] https://www.fpcomplete.com/blog/2015/03/hackage-mirror [4] I don't think this is just a theoretical possibility for some

...

...

...

...

...

in the future. I have reported an easily trigerrable DoS attack on

On April 14, 2015 at 10:57:00 PM, Carter Schonwald ( carter.schonwald@gmail.com) wrote: tracking transactions this. proposed). thoughts. I've that placing a the proceed the point the

...

...

...

...

...

current Hackage Server codebase, which has been unresolved for 1.5 months now [5] https://gist.github.com/snoyberg/732aa47a5dd3864051b9

--

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 commercialhaskell+unsubscribe@googlegroups.com. To post to this group, send email to commercialhaskell@googlegroups.com.

To view this discussion on the web visit

...

https://groups.google.com/d/msgid/commercialhaskell/4487776e-b862-429c-adae-...

...

.

...

For more options, visit https://groups.google.com/d/optout.

-- *Arnaud Bailly*

CTO | Capital Match

CapitalMatch

71 Ayer Rajah Crescent | #06-16 | Singapore 139951

(FR) +33 617 121 978 / (SG) +65 8408 7973 | arn...@capital-match.com | www.capital-match.com

Disclaimer:

*Capital Match Platform Pte. Ltd. (the "Company") registered in Singapore (Co. Reg. No. 201501788H), a subsidiary of Capital Match Holdings Pte. Ltd. (Co. Reg. No. 201418682W), provides services that involve arranging for multiple parties to enter into loan and invoice discounting agreements. The Company does not provide any form of investment advice or recommendations regarding any listings on its platform. In providing its services, the Company's role is limited to an administrative function and the Company does not and will not assume any advisory, fiduciary or other duties to clients of its services.*

_______________________________________________ haskell-infrastructure mailing list haskell-infrastructure@community.galois.com http://community.galois.com/mailman/listinfo/haskell-infrastructure

-- 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 commercialhaskell+unsubscribe@googlegroups.com. To post to this group, send email to commercialhaskell@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/commercialhaskell/etPan.552de40d.3d1b58ba.... . For more options, visit https://groups.google.com/d/optout.

On Wed, Apr 15, 2015 at 8:19 AM Gershom B wrote:

Ok, to narrow it down, you are concerned about the ability to

...

* Properly authenticate users * Keep authorization lists of who can make uploads/revisions (and who can grant those rights)

and more specifically:

...

* Currently, authorized uploaders are identified by a user name and a password on Hackage. How do we correlate that to a GPG key? Ideally, the central upload authority would be collecting GPG public keys for all uploaders so that signature verification can happen correctly. * There's no way for an outside authority to vet the 00-index.tar.gz file downloaded from Hackage; it's a completely opaque, black box. Having the set of authorization rules be publicly viewable, auditable, and verifiable overcomes that.

On 1) now you have the problem “what if the central upload authority’s store of GPG keys is violated”. You’ve just kicked the can. “Web of Trust” is not a tractable answer. My answer is simpler: I can verify that the signer of version 1 of a package is the same as the signer of version 0.1. This is no small trick. And I can do so orthogonal to hackage. Now, if I really want to verify that the signer of version 1 is the person who is “Michael Snoyman” and is in fact the exact Michael Snoyman I intend, then I need to get your key by some entirely other mechanism. And that is my problem, and, definitionally, no centralized store can help me in that regard unless I trust it absolutely — which is precisely what I don’t want to do.

You've ruled out all known solutions to the problem, therefore no solution exists ;) To elaborate slightly: the issue of obtaining people's keys is a problem that exists in general, and has two main resolutions: a central authority, and a web of trust. You've somehow written off completely the web of trust (I'm not sure *why* you think that's a good idea, you haven't explained it), and then stated that- since the only remaining option is a central authority- it's no better than Hackage. I disagree: 1. Maintaining security of a single GPG key is much simpler than maintaining the security of an entire web application, as is currently needed by Hackage. 2. There's no reason we need an either/or setup: we can have a central authority sign keys. If user's wish to trust that authority, they may do so, and thereby get access to other keys. If that central authority is compromised, we revoke that authority and move on to another one. Importantly: we haven't put all our eggs in one basket, as is done today.

On 2) I would like to understand more of what your concern with regards to “auditing” is. What specific information would you like to know that you do not? Improved audit logs seem again orthogonal to any of these other security concerns, unless you are simply worried about a “metadata only” attack vector. In any case, we can incorporate the same signing practices for metadata as for packages — orthogonal to hackage or any other particular storage mechanism. It is simply an unrelated question. And, honestly, compared to all the other issues we face I feel it is relatively minor (the signing component, not a better audit trail).

There's a lot of stuff going on inside of Hackage which we have no insight into or control over. The simplest is that we can't review a log of revisions. Improving that is a good thing, and I hope Hackage does so. Nonetheless, I'd still prefer a fully open, auditable system, which isn't possible with "just tack it on to Hackage."

In any case, your account of the first two points reveals some of the confusion I think that remains:

...

* Allow safe uploads of packages and metadata * Distribute packages and metadata to users safely

What is the definition of “safe” here? My understanding is that in the field of security one doesn’t talk about “safe” in general, but with regards to a particular profile of a sort of attacker, and always only as a difference of degree, not kind.

I didn't think this needed diving into, because the problems seem so fundamental they weren't worth explaining. Examples of safety issues are: * An attacker sitting between an uploader and Hackage can replace the package contents with something nefarious, corrupting the package for all downloaders * An attacker sitting between a downloader and Hackage can replace the package contents with something nefarious, corrupting the package for that downloader * This doesn't even have to be a conscious attack; I saw someone on Reddit report that they tried to download a package at an airport WiFi, and instead ended up downloading the HTML "please log in" page * Eavesdropping attacks on uploaders: it's possible to capture packets indicating upload headers to Hackage, such as when using open WiFi (think the airport example again). Those headers include authorization headers. Thanks to Hackage now using digest authentication, this doesn't lead to an immediate attack, but digest authentication is based on MD5, which is not the most robust hash function * Normal issues with password based authentication: insecure passwords, keyloggers, etc. * Vulnerabilities in the Hackage codebase or its hosting that expose passwords and/or allow arbitrary uploads

So who do we want to prevent from doing what? How “safe” is “safe”? Safe from what? From a malicious script-kid, from a malicious collective “in it for the lulz,” from a targeted attack against a particular end-client, from just poorly/incompetently written code? What are we “trusting”? What concrete guarantees would we like to make about user interactions with packages and package repositories?

While I’m interrogating language, let me pick out one other thing I don’t understand: "creating a coherent set of packages” — what do you mean by “coherent”? Is this something we can specify? Hackage isn’t supposed to be coherent — it is supposed to be everything. Within that “everything” we are now attempting to manage metadata to provide accurate dependency information, at a local level. But we have no claims about any global coherence conditions on the resultant graphs. Certainly we intend to be coherent in the sense that the combination of a name/version/revision should indicate one and only one thing (and that all revisions of a version should differ at most in dependency constraints in their cabal file) — but this is a fairly minimal criteria. And in fact, it is one that is nearly orthogonal to security concerns altogether.

All I meant is a set of packages uploaded by an approved set of uploaders, as opposed to allowing in arbitrary modifications used by others.

What I’m driving at is — it sounds like we _mainly_ want new decentralized security mechanisms, at the cabal level, but we also want, potentially, a few centralized mechanisms. However, centralization is weakness from a security standpoint. So, ideally, we want as few centralized mechanisms as possible, and we want the consequences of those mechanisms being broken to be “recoverable” at the point of local verification.

Yes, that's exactly the kind of goal I'm aiming towards.

Let me spell out a threat model where that makes sense. An adversary takes control of the entire hackage server through some zero day linux exploit we have no control over — or perhaps they are an employee at the datacenter where we host hackage and secure control via more direct means, etc. They have total and complete control over the box. They can accept anything they want, and they can serve anything they want. And they are sophisticated enough to be undetected for say a week.

Now, we want it to be the case that _whatever_ this adversary does, they cannot “trick” someone who types “cabal install warp” into instead cabal installing something malicious. How do we do so? _Now_ we have a security problem that is concrete enough to discuss. And furthermore, I would claim that if we don’t have at least some story for this threat model, then we haven’t established anything much “safer” at all.

This points towards a large design space, and a lot of potential ideas, all of which feel entirely different than the “strawman” proposal, since the emphasis there is towards the changes to a centralized mechanism (even if in turn, the product of that mechanism itself is then distributed and git cloneable or whatever).

If we have agreement that the problem exists, I'm quite happy to flesh out other kinds of attack vectors and then discuss solutions. Again, my proposal is purely meant to be a starting point for discussion, not an answer to the problems. Michael

On Wed, Apr 15, 2015 at 8:50 AM Gershom B wrote:

On April 15, 2015 at 1:43:42 AM, Michael Snoyman (michael@snoyman.com) wrote:

...

...

There's a lot of stuff going on inside of Hackage which we have no insight into or control over. The simplest is that we can't review a log of revisions. Improving that is a good thing, and I hope Hackage does so. Nonetheless, I'd still prefer a fully open, auditable system, which isn't possible with "just tack it on to Hackage.”

Ok, I’m going to ignore everything else and just focus on this, because it seems to be the only thing related to hackage, and therefore should be thought of separately from everything else.

What _else_ goes on that “we have no insight or control over”? Can we document the full list. Can we specify what we mean by insight? I take that to mean auditability. Can we specify what we mean by “control? (There I have no idea).

(With regards to revision logs, revisions are still a relatively new feature and there’s lots of bits and bobs missing, and I agree this is low hanging fruit to improve).

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. However, *all* of that is predicated on trusting Hackage to properly authenticate users and be immune to attacks. For example, even if I can ask Hackage who uploaded a certain package/version, there's no way I can audit that that's actually the case, besides going and asking that person. And I can't even do *that* reliably, since the only identification for an uploader is the Hackage username, and I can't verify that someone actually owns that username without asking for his/her password also. One feature Hackage could add that would make the latter a bit better would be to verify identity claims from people (ala OpenID), though that still leaves us in the position of needing to fully trust Hackage. Michael

On Wed, Apr 15, 2015 at 9:14 AM Gershom B wrote:

On April 15, 2015 at 1:57:07 AM, Michael Snoyman (michael@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

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 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" wrote:

...

On Wed, Apr 15, 2015 at 9:14 AM Gershom B wrote:

...

On April 15, 2015 at 1:57:07 AM, Michael Snoyman (michael@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

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 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" 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@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" wrote:

...

On Wed, Apr 15, 2015 at 9:14 AM Gershom B wrote:

...

On April 15, 2015 at 1:57:07 AM, Michael Snoyman (michael@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

-- 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 commercialhaskell+unsubscribe@googlegroups.com. To post to this group, send email to commercialhaskell@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/commercialhaskell/CAHYVw0xbNQPZ%2Bockbn1Zv... 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.

On April 15, 2015 at 8:34:07 AM, Michael Snoyman (michael@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.

So amend Carter’s proposal with the requirement that admin/trustee actions be signed as well. Now we can audit the verification trail. Done. But let me pose a more basic question: Assume somebody falsified the log, but could _not_ falsify any package contents (because the latter were verified at the use site). And further, assume we had a signing trail for revisions as well. Now what is the worst that this bad actor could accomplish?  This is why it helps to have a “threat model”. I think there is a misunderstanding here on what Carter is asking for. A “threat model” is not a list of potential vulnerabilities. Rather, it is a statement of what types of things are important to mitigate against, and from whom. There is no such thing as a completely secure system, except, perhaps an unplugged one. So when you say you want something “safe” and then tell us ways the current system is “unsafe” then that’s not enough. We need to have a criterion by which we _could_ judge a future system at least “reasonably safe enough”. My sense of a threat model prioritizes package signing (and I guess revision signing now too) but e.g. doesn’t consider a signed verifiable audit trail a big deal, because falsifying those logs doesn’t easily translate into an attack vector. You are proposing large, drastic changes. Such changes are likely to get bogged down and fail, especially to the degree they involve designing systems in ways that are not in widespread use already. And even if such changes were feasible, and even if they were a sound approach, it would take a long time to put the pieces together to carry them out smoothly across the ecosystem. Meanwhile, if we can say “in fact this problem decomposes into six nearly unrelated problems” and then prioritize those problems, it is likely that all can be addressed incrementally, which means less development work, greater chance of success, and easier rollout. I remain convinced that you raise some genuine issues, but they decompose into nearly unrelated problems that can and should be tackled individually. Cheers, Gershom

On Wed, Apr 15, 2015 at 4:13 PM Gershom B wrote:

On April 15, 2015 at 8:34:07 AM, Michael Snoyman (michael@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.

So amend Carter’s proposal with the requirement that admin/trustee actions be signed as well. Now we can audit the verification trail. Done.

But let me pose a more basic question: Assume somebody falsified the log, but could _not_ falsify any package contents (because the latter were verified at the use site). And further, assume we had a signing trail for revisions as well. Now what is the worst that this bad actor could accomplish?

This is why it helps to have a “threat model”. I think there is a misunderstanding here on what Carter is asking for. A “threat model” is not a list of potential vulnerabilities. Rather, it is a statement of what types of things are important to mitigate against, and from whom. There is no such thing as a completely secure system, except, perhaps an unplugged one. So when you say you want something “safe” and then tell us ways the current system is “unsafe” then that’s not enough. We need to have a criterion by which we _could_ judge a future system at least “reasonably safe enough”.

My sense of a threat model prioritizes package signing (and I guess revision signing now too) but e.g. doesn’t consider a signed verifiable audit trail a big deal, because falsifying those logs doesn’t easily translate into an attack vector.

You are proposing large, drastic changes. Such changes are likely to get bogged down and fail, especially to the degree they involve designing systems in ways that are not in widespread use already. And even if such changes were feasible, and even if they were a sound approach, it would take a long time to put the pieces together to carry them out smoothly across the ecosystem.

Meanwhile, if we can say “in fact this problem decomposes into six nearly unrelated problems” and then prioritize those problems, it is likely that all can be addressed incrementally, which means less development work, greater chance of success, and easier rollout. I remain convinced that you raise some genuine issues, but they decompose into nearly unrelated problems that can and should be tackled individually.

I think you've missed what I've said, so I'll try to say it more clearly: we have no insight right now into how Hackage makes decisions about who's allowed to upload and revise packages. We have no idea how to make a correspondence between a Hackage username and some externally-verifiable identity (like a GPG public key). In that world: how can we externally verify signatures of packages on Hackage? I'm pretty familiar with Chris's package signing work. It's a huge step forward. But by necessity of the weaknesses in what Hackage is exposing, we have no way of fully verifying all signatures. If you see the world differently, please explain. Both you and Carter seem to assume I'm talking about some other problem that's not yet been described. I'm just trying to solve the problem already identified. I think you've missed a few steps necessary to have a proper package signing system in place. You may think that the proposal I've put together is large and a massive shift. It's honestly the minimal number of changes I can see towards having a method to fully verify all signatures of packages that Hackage is publishing. If you see a better way to do it, I'd rather do that, so tell me what it is. Michael * * * I think the above was clear enough, but in case it's not, here's an example. Take the yesod-core package, for which MichaelSnoyman and GregWeber are listed as maintainers. Suppose that we have information from Hackage saying: yesod-core-1.4.0 released by MichaelSnoyman yesod-core-1.4.1 released by FelipeLessa yesod-core-1.4.2 released by GregWeber yesod-core-1.4.2 cabal file revision by HerbertValerioRiedel How do I know: * Which signatures on yesod-core-1.4.0 to trust? Should I trust MichaelSnoyman's and GregWeber's only? What if GregWeber wasn't a maintainer when 1.4.0 was released? * How can 1.4.1 be trusted? It was released by a non-maintainer. In reality, we can guess that FelipeLessa used to be a maintainer but was then removed, but how do we know this? * Similarly, we can guess that HerbertValerioRiedel is granted as a trustee the right to revise a cabal file. * But in any event: how do we get the GPG keys for any of these users? * And since Hackage isn't enforcing any GPG signatures, what should we do when the signatures for a package don't exist? This is just one example of the impediments to adding package signing to the current Hackage system.

In the future, we can at first optionally, and then later on a stricter basis encourage and then enforce signing. I think this is a good idea.

But, and here we apparently disagree completely, it seems to me that everything else is not and should not be the job of a centralized server.

Actually, I think you and Michael are in violent *agreement* on this particular point. At the core of the gist that was pointed to earlier in this thread [1], is the idea that we should have some kind of central notepad, where anyone is allowed to scribble anything they like, even add pointers to packages that are completely broken, don't build, or are malicious trojan horses. Then, it's up to end users to filter out the wheat from the chaff. In particular, it's up to the user to pretend those scribbles that were added by untrusted sources were just never there, *according to the users own trust model*. The central notepad does not enforce any particular trust model. It just provides sufficient mechanism so that the information necessary to support common trust models, such as WoT of GPG keys, can be uploaded and/or pointed to and found. In this way, any trust model can be supported. We could refactor Hackage on top of this notepad, and have Hackage upload metadata about those scribbles that *it* thinks are legit, say because Hackage performed the scribble itself on behalf of some user, but only did so after authenticating said user, according to its own notion of authentication. Users are free to say "I trust any scribble to the notepad about any package that was added by an authenticated Hackage user". Or "I only trust scribbles from my Haskell friends whom I have met at ICFP and on that occasion exchanged keys". Or a union of both. Or anything else really. [1] https://gist.github.com/snoyberg/732aa47a5dd3864051b9

Now, if I get it right, you want to allow anyone to upload foo-1.0.1 to hackage and let user sort it out if he trusts this update. It will never work: for all we know about security, when asked "do you trust this package's signature?" user will either get annoyed, shrug and click "Yes", or if paranoid, get annoyed and go away. He is just does not know enough to make decisions you are asking him to make. And adding vector implementation with something malicious in it's build script just became a matter of "cabal upload". If you build such a system, you have to provide it with reasonable set of defaults, and it is where "we are in business of key distribution" thing raises its head again.

The above all sounds reasonable to me. Note however that, not that I'm convinced that this is a good default, but the default here could well be: "trust whatever was added to the notepad by Hackage on behalf of some authenticated user". That gets us back to today's status quo. We can do better of course, but just to say that this "notepad" can be completely transparent to end users, depending only on tooling. One way to know what is added by Hackage is to have Hackage sign whatever it writes in the notepad, using some key or certificate that the tooling trusts by default. That's really the baseline. As I said, we can do much better. At least with the central notepad approach, we're pushing policy about what packages to trust down to end user tooling, which can be swapped in and out at will, without having some central entity dictate a weaker and redundant policy. I agree with Gershom's sentiment that the policy for what to trust should be left open. It should be left up to the user. One family of policies, already discussed in this thread, is a GPG WoT. That family of policies may or may not fly for all users, I don't know, but at least the tooling for that already exists, and it's easy to put in place. Another family is implementations of The Update Framework suggested by Duncan here: https://groups.google.com/d/msg/commercialhaskell/qEEJT2LDTMU/_uj0v5PbIA8J I'm told others are working along similar lines. It'd be great if those people came out of the woodwork to talk about what they're doing in the open. And since clearly there's interest in safer package distribution, formulate proposals with a comment about how it fares to address a specific threat model, such as the 9 attacks listed in this paper (same authors as links posted previously in this thread twice): ftp://ftp.cs.arizona.edu/reports/2008/TR08-02.pdf That list of attacks is a superset of the attacks listed by Michael previously. Not all policies will address all attacks in a way that's entirely satisfactory, but at least with the central notepad we can easily evolve them over time.

On Wed, Apr 15, 2015 at 5:56 AM Carter Schonwald wrote:

any use of cryptographic primitives of any form NEEDS to articulate what the trust model is, and what the threat model is

likewise, i'm trying to understand who the proposed feature set is meant to serve.

Several groups are in the late stages of building prototypes at varying points in the design space for improving package hosting right now for haskell, and I'm personally inclined to let those various parties release the tools, and then experiment with them all, before trying to push heavily for any particular design that hasn't had larger community experimentation.

I'd be fine with that, if there was public discussion of what those projects are trying to solve. Of the ones that I have asked questions about, I haven't heard any of them trying to address the trust/security issues I've raised here, which is why I'm asking the mailing list if there's interest. I'm not OK with simply stalling any community process for improving our situation because "someone's working on something related, and it'll be done Real Soon Now(tm)." That's a recipe for stagnation.

I actually care most about being able to have the full package set be git cloneable, both for low pain on premise hackage hosting for corporate intranets, and also for when i'm on a plane or boat and have no wifi. At my current job, ANY "host packages via s3" approach is totally untenable, and i'm sure among haskell using teams/organizations, this isn't a unique problem!

I agree completely. And similarly, hosting all packages in a Git repository is *also* unusable in other situations, such as normal users wanting to get a minimal set of downloads to get started on a project. That's why I left the download information in this proposal at URL; you can add different URLs to support Git repository contents as well. It would also be pretty easy to modify the all-cabal-files repo I pointed to and create a repository containing the tarballs themselves. I don't know if Github would like hosting that much content, but I have no problem helping roll that out.

The Author authentication/signing model question in an important one, but I"m uncomfortable with just saying "SHA512 and GPG address that". Theres A LOT of subtlety to designing a signing protocol thats properly audit-able and secure! Indeed, GPG isn't even a darn asymmetric crypto algorithm, its a program that happens to IMPLEMENT many of these algorithms. If we are serious about having robust auditing/signing, handwaving about the cryptographic parts while saying its important is ... kinda irresponsible. And frustrating because it makes it hard to evaluate the hardest parts of the whole engineering problem! The rest of the design is crucially dependent on details of these choices, and yet its that part which isn't specified.

I think you're assuming that my "proposal" was more than a point of discussion. It's not. When starting this thread, I tried to make it clear that this is to gauge interest in creating a real solution. If there's interest, we should figure out these points. If there's no interest, then I'm glad I didn't invest weeks in coming up with a more robust proposal.

to repeat myself: there is a pretty rich design space for how we can evolve future hackage, and i worry that speccing things out and design by committee is going to be less effective than encouraging various parties to build prototypes for their own visions of future hackage, and THEN come together to combine the best parts of everyones ideas/designs. Theres so much diversity in how different people use hackage, i worry that any other way will run into failing to serve the full range of haskell users!

I disagree here pretty strongly. Something with a strong social element requires discussion upfront, not someone creating a complete solution and then trying to impose it on everyone else. There are certainly things that *can* be done without discussion. Hosting cabal and tar.gz files in a Git repo, or mirroring to S3, are orthogonal actions that require no coordination, for instance. But tweaking the way we view the trust model of Hackage is pretty central, and needs discussion. Michael

cheers

On Tuesday, April 14, 2015 at 1:01:17 AM UTC-4, Michael Snoyman wrote:

...

That could work in theory. My concern with such an approach is that- AFAIK- the tooling around that kind of stuff is not very well developed, as opposed to an approach using Git, SHA512, and GPG, which should be easy to combine. But I could be completely mistaken on this point; if existing, well vetted technology exists for this, I'm not opposed to using it.

On Mon, Apr 13, 2015 at 6:04 PM Arnaud Bailly | Capital Match < arn...@capital-match.com> wrote:

Just thinking aloud but wouldn't it be possible to take advantage of

...

...

cryptographic ledgers a la Bitcoin for authenticating packages and tracking the history of change ? This would provide redundancy as the transactions log is distributed and "naturally" create a web of trust or at least authenticate transactions. People uploading or modifying a package would have to sign a transactions with someone having enough karma to allow this.

Then packages themselves could be completely and rather safely distributed through standard p2p file sharing.

I am not a specialist of crypto money, though.

My 50 cts Arnaud

Le lundi 13 avril 2015, Dennis J. McWherter, Jr. a écrit :

...

This proposal looks great. The one thing I am failing to understand (and I recognize the proposal is in early stages) is how to ensure redundancy in the system. As far as I can tell, much of this proposal discusses the centralized authority of the system (i.e. ensuring secure distribution) and only references (with little detail) the distributed store. For instance, say I host a package on a personal server and one day I decide to shut that server down; is this package now lost forever? I do see this line: "backup download links to S3" but this implies that the someone is willing to pay for S3 storage for all of the packages.

Are there plans to adopt a P2P-like model or something similar to support any sort of replication? Public resources like this seem to come and go, so it would be nice to avoid some of the problems associated with high churn in the network. That said, there is an obvious cost to replication. Likewise, the central authority would have to be updated with new, relevant locations to find the file (as it is currently proposed).

In any case, as I said before, the proposal looks great! I am looking forward to this.

On Monday, April 13, 2015 at 5:02:46 AM UTC-5, Michael Snoyman wrote:

...

Many of you saw the blog post Mathieu wrote[1] about having more composable community infrastructure, which in particular focused on improvements to Hackage. I've been discussing some of these ideas with both Mathieu and others in the community working on some similar thoughts. I've also separately spent some time speaking with Chris about package signing[2]. Through those discussions, it's become apparent to me that there are in fact two core pieces of functionality we're relying on Hackage for today:

* A centralized location for accessing package metadata (i.e., the cabal files) and the package contents themselves (i.e., the sdist tarballs) * A central authority for deciding who is allowed to make releases of packages, and make revisions to cabal files

In my opinion, fixing the first problem is in fact very straightforward to do today using existing tools. FP Complete already hosts a full Hackage mirror[3] backed by S3, for instance, and having the metadata mirrored to a Git repository as well is not a difficult technical challenge. This is the core of what Mathieu was proposing as far as composable infrastructure, corresponding to next actions 1 and 3 at the end of his blog post (step 2, modifying Hackage, is not a prerequesite). In my opinion, such a system would far surpass in usability, reliability, and extensibility our current infrastructure, and could be rolled out in a few days at most.

However, that second point- the central authority- is the more interesting one. As it stands, our entire package ecosystem is placing a huge level of trust in Hackage, without any serious way to vet what's going on there. Attack vectors abound, e.g.:

* Man in the middle attacks: as we are all painfully aware, cabal-install does not support HTTPS, so a MITM attack on downloads from Hackage is trivial * A breach of the Hackage Server codebase would allow anyone to upload nefarious code[4] * Any kind of system level vulnerability could allow an attacker to compromise the server in the same way

Chris's package signing work addresses most of these vulnerabilities, by adding a layer of cryptographic signatures on top of Hackage as the central authority. I'd like to propose taking this a step further: removing Hackage as the central authority, and instead relying entirely on cryptographic signatures to release new packages.

I wrote up a strawman proposal last week[5] which clearly needs work to be a realistic option. My question is: are people interested in moving forward on this? If there's no interest, and everyone is satisfied with continuing with the current Hackage-central-authority, then we can proceed with having reliable and secure services built around Hackage. But if others- like me- would like to see a more secure system built from the ground up, please say so and let's continue that conversation.

[1] https://www.fpcomplete.com/blog/2015/03/composable- community-infrastructure [2] https://github.com/commercialhaskell/commercialhaskell/wiki/ Package-signing-detailed-propsal [3] https://www.fpcomplete.com/blog/2015/03/hackage-mirror [4] I don't think this is just a theoretical possibility for some point in the future. I have reported an easily trigerrable DoS attack on the current Hackage Server codebase, which has been unresolved for 1.5 months now [5] https://gist.github.com/snoyberg/732aa47a5dd3864051b9

--

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 commercialhaskell+unsubscribe@googlegroups.com. To post to this group, send email to commercialhaskell@googlegroups.com .

To view this discussion on the web visit

...

https://groups.google.com/d/msgid/commercialhaskell/4487776e-b862-429c-adae-... https://groups.google.com/d/msgid/commercialhaskell/4487776e-b862-429c-adae-477813e560f3%40googlegroups.com?utm_medium=email&utm_source=footer .

...

For more options, visit https://groups.google.com/d/optout.

--

*Arnaud Bailly*

...

CTO | Capital Match

CapitalMatch

71 Ayer Rajah Crescent | #06-16 | Singapore 139951

...

(FR) +33 617 121 978 / (SG) +65 8408 7973 | arn...@capital-match.com |

...

www.capital-match.com

Disclaimer:

...

*Capital Match Platform Pte. Ltd. (the "Company") registered in Singapore (Co. Reg. No. 201501788H), a subsidiary of Capital Match Holdings Pte. Ltd. (Co. Reg. No. 201418682W), provides services that involve arranging for multiple parties to enter into loan and invoice discounting agreements. The Company does not provide any form of investment advice or recommendations regarding any listings on its platform. In providing its services, the Company's role is limited to an administrative function and the Company does not and will not assume any advisory, fiduciary or other duties to clients of its services.*

-- 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 commercialhaskell+unsubscribe@googlegroups.com. To post to this group, send email to commercialhaskell@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/commercialhaskell/33c89d4a-12b9-495b-a151-... https://groups.google.com/d/msgid/commercialhaskell/33c89d4a-12b9-495b-a151-7e317177b061%40googlegroups.com?utm_medium=email&utm_source=footer . For more options, visit https://groups.google.com/d/optout.