Improvements to package hosting and security

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
88 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Improvements to package hosting and security

Michael Snoyman
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.

[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  

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Improvements to package hosting and security

Michael Snoyman
Also, since it's relevant, here's a Github repo with all of the cabal files from Hackage which (thanks to a cron job and Travis CI) automatically updates every 30 minutes:


On Mon, Apr 13, 2015 at 1:02 PM Michael Snoyman <[hidden email]> 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.

[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  

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Improvements to package hosting and security

Arian van Putten
Without adding much to the discussion myself, I just want to drop this link here: http://www.cs.arizona.edu/stork/packagemanagersecurity/ . It addresses some interesting issues concerning package repositories.

Anyhow I personally think the current state of hackage (not even https) is unacceptable and I'm really excited that people seem to be working on this.




On Mon, Apr 13, 2015 at 12:28 PM, Michael Snoyman <[hidden email]> wrote:
Also, since it's relevant, here's a Github repo with all of the cabal files from Hackage which (thanks to a cron job and Travis CI) automatically updates every 30 minutes:


On Mon, Apr 13, 2015 at 1:02 PM Michael Snoyman <[hidden email]> 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.

[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  

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe




--
Groetjes,

Arian

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Improvements to package hosting and security

Francesco Ariis
In reply to this post by Michael Snoyman
On Mon, Apr 13, 2015 at 10:02:45AM +0000, Michael Snoyman wrote:
> 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.

I finished reading the proposal, the only minor remark I have is on this
sentence:

    " Each signature may be revoked using standard GPG revokation.

It is the /key/ being revoked really, not the single signature (in our case
it would mean revoking every-package-version-or-revision-signed-by-that-key).
This in turn highlights the need for a well defined process on how to
handle "key transitions" (task left to the single implementators).


A distributed and secure hackage sounds like a dream, I really hope this
comes to life!
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Improvements to package hosting and security

Michael Snoyman


On Mon, Apr 13, 2015 at 3:21 PM Francesco Ariis <[hidden email]> wrote:
On Mon, Apr 13, 2015 at 10:02:45AM +0000, Michael Snoyman wrote:
> 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.

I finished reading the proposal, the only minor remark I have is on this
sentence:

    " Each signature may be revoked using standard GPG revokation.

It is the /key/ being revoked really, not the single signature (in our case
it would mean revoking every-package-version-or-revision-signed-by-that-key).
This in turn highlights the need for a well defined process on how to
handle "key transitions" (task left to the single implementators).



I think I was just wrong at that part of the proposal; it wouldn't be "standard GPG revokation" since, as you point out, that's for revoking a key. We'd need a custom revokation mechanism to make this work.

But as to your more general point: there was an added layer of indirection that I considered but didn't write up, but I happen to like. The idea would be that all of the authorization lists would work based off of an identifier (e.g., an email address). We would then have a separate mapping between email addresses and GPG public keys, which would follow the same signature scheme that all of the other files in the repo follow.

The downside to this is that it redoes the basic GPG keysigning mechanism to some extent, but it does address key transitions more easily.

Another possibility would be to encode the release date of a package/version and package/version/revision and use that date for checking validity of keys. That way, old signatures remain valid for perpetuity.

I'll admit to my relative lack of experience with GPG, so there's probably some built-in mechanism for addressing this kind of situation which would be better to follow.
 
A distributed and secure hackage sounds like a dream, I really hope this
comes to life!

--

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Improvements to package hosting and security

Dennis J. McWherter, Jr.
In reply to this post by Michael Snoyman
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] <a href="https://www.fpcomplete.com/blog/2015/03/composable-community-infrastructure" target="_blank" rel="nofollow" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fwww.fpcomplete.com%2Fblog%2F2015%2F03%2Fcomposable-community-infrastructure\46sa\75D\46sntz\0751\46usg\75AFQjCNG_fJPrZAIhS8eWgJjFfDQ7s9dJ0w';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fwww.fpcomplete.com%2Fblog%2F2015%2F03%2Fcomposable-community-infrastructure\46sa\75D\46sntz\0751\46usg\75AFQjCNG_fJPrZAIhS8eWgJjFfDQ7s9dJ0w';return true;">https://www.fpcomplete.com/blog/2015/03/composable-community-infrastructure  
[2] <a href="https://github.com/commercialhaskell/commercialhaskell/wiki/Package-signing-detailed-propsal" target="_blank" rel="nofollow" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fcommercialhaskell%2Fcommercialhaskell%2Fwiki%2FPackage-signing-detailed-propsal\46sa\75D\46sntz\0751\46usg\75AFQjCNHX0bAakI4la9aRqeMMuw7aoQRjwQ';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fcommercialhaskell%2Fcommercialhaskell%2Fwiki%2FPackage-signing-detailed-propsal\46sa\75D\46sntz\0751\46usg\75AFQjCNHX0bAakI4la9aRqeMMuw7aoQRjwQ';return true;">https://github.com/commercialhaskell/commercialhaskell/wiki/Package-signing-detailed-propsal  
[3] <a href="https://www.fpcomplete.com/blog/2015/03/hackage-mirror" target="_blank" rel="nofollow" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fwww.fpcomplete.com%2Fblog%2F2015%2F03%2Fhackage-mirror\46sa\75D\46sntz\0751\46usg\75AFQjCNGJFD5j7As-_qZYrFvGtZT2HJCqrQ';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fwww.fpcomplete.com%2Fblog%2F2015%2F03%2Fhackage-mirror\46sa\75D\46sntz\0751\46usg\75AFQjCNGJFD5j7As-_qZYrFvGtZT2HJCqrQ';return true;">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] <a href="https://gist.github.com/snoyberg/732aa47a5dd3864051b9" target="_blank" rel="nofollow" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgist.github.com%2Fsnoyberg%2F732aa47a5dd3864051b9\46sa\75D\46sntz\0751\46usg\75AFQjCNHMMUQ2gK7wS5vEMm7FQ9E0B6TzYg';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgist.github.com%2Fsnoyberg%2F732aa47a5dd3864051b9\46sa\75D\46sntz\0751\46usg\75AFQjCNHMMUQ2gK7wS5vEMm7FQ9E0B6TzYg';return true;">https://gist.github.com/snoyberg/732aa47a5dd3864051b9  

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Improvements to package hosting and security

Michael Snoyman
I purposely didn't get into those details in this document, as it can be layered on top of the setup I described here. The way I'd say this should be answered is twofold:

* FP Complete already hosts all packages on S3, and we intend to continue hosting all packages there in the future
* People in the community are welcome (and encouraged) to make redundant copies of packages, and then add hash-to-URL mappings to the main repo giving those redundant copies as additional download locations.

In that sense, the FP Complete S3 copy would simply be one of potentially many redundant copies that could exist.

On Mon, Apr 13, 2015 at 5:57 PM Dennis J. McWherter, Jr. <[hidden email]> wrote:
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.

[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  

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Improvements to package hosting and security

Michael Snoyman
In reply to this post by Dennis J. McWherter, Jr.
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 <[hidden email]> 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. <[hidden email]> 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.

[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  

--


--
Arnaud Bailly

CTO | Capital Match

CapitalMatch

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

(FR)  +33 617 121 978 / (SG) +65 8408 7973 | [hidden email] | 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-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Improvements to package hosting and security

David Turner-2
The cryptocurrency model is interesting, certainly, but it's solving a
quite different problem: by giving authority to the majority of
computational power, it allows users to trust the network without
needing to break anonymity. Anonymity is really hard, and not needed
here. Without it, the cryptocurrency model is basically just Git: a
sequence of transactions that can be cryptographically verified.

Stick with the Git + GPG plan IMO.

On 14 April 2015 at 06:01, Michael Snoyman <[hidden email]> 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
> <[hidden email]> 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. <[hidden email]>
>> 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.
>>>
>>> email to [hidden email].
>>>
>>>
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/commercialhaskell/4487776e-b862-429c-adae-477813e560f3%40googlegroups.com.
>>>
>>>
>>>
>>
>>
>>
>> --
>> Arnaud Bailly
>>
>> CTO | Capital Match
>>
>> CapitalMatch
>>
>> 71 Ayer Rajah Crescent | #06-16 | Singapore 139951
>>
>> (FR)  +33 617 121 978 / (SG) +65 8408 7973 | [hidden email] |
>> 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-Cafe mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Improvements to package hosting and security

Carter Schonwald
In reply to this post by Michael Snoyman
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 <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="P_a5CowgSKIJ" rel="nofollow" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">arn...@...> 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 href="javascript:" target="_blank" gdf-obfuscated-mailto="P_a5CowgSKIJ" rel="nofollow" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">den...@...> 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] <a href="https://www.fpcomplete.com/blog/2015/03/composable-community-infrastructure" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fwww.fpcomplete.com%2Fblog%2F2015%2F03%2Fcomposable-community-infrastructure\46sa\75D\46sntz\0751\46usg\75AFQjCNG_fJPrZAIhS8eWgJjFfDQ7s9dJ0w';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fwww.fpcomplete.com%2Fblog%2F2015%2F03%2Fcomposable-community-infrastructure\46sa\75D\46sntz\0751\46usg\75AFQjCNG_fJPrZAIhS8eWgJjFfDQ7s9dJ0w';return true;">https://www.fpcomplete.com/blog/2015/03/composable-community-infrastructure  
[2] <a href="https://github.com/commercialhaskell/commercialhaskell/wiki/Package-signing-detailed-propsal" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fcommercialhaskell%2Fcommercialhaskell%2Fwiki%2FPackage-signing-detailed-propsal\46sa\75D\46sntz\0751\46usg\75AFQjCNHX0bAakI4la9aRqeMMuw7aoQRjwQ';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fcommercialhaskell%2Fcommercialhaskell%2Fwiki%2FPackage-signing-detailed-propsal\46sa\75D\46sntz\0751\46usg\75AFQjCNHX0bAakI4la9aRqeMMuw7aoQRjwQ';return true;">https://github.com/commercialhaskell/commercialhaskell/wiki/Package-signing-detailed-propsal  
[3] <a href="https://www.fpcomplete.com/blog/2015/03/hackage-mirror" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fwww.fpcomplete.com%2Fblog%2F2015%2F03%2Fhackage-mirror\46sa\75D\46sntz\0751\46usg\75AFQjCNGJFD5j7As-_qZYrFvGtZT2HJCqrQ';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fwww.fpcomplete.com%2Fblog%2F2015%2F03%2Fhackage-mirror\46sa\75D\46sntz\0751\46usg\75AFQjCNGJFD5j7As-_qZYrFvGtZT2HJCqrQ';return true;">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] <a href="https://gist.github.com/snoyberg/732aa47a5dd3864051b9" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgist.github.com%2Fsnoyberg%2F732aa47a5dd3864051b9\46sa\75D\46sntz\0751\46usg\75AFQjCNHMMUQ2gK7wS5vEMm7FQ9E0B6TzYg';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgist.github.com%2Fsnoyberg%2F732aa47a5dd3864051b9\46sa\75D\46sntz\0751\46usg\75AFQjCNHMMUQ2gK7wS5vEMm7FQ9E0B6TzYg';return true;">https://gist.github.com/snoyberg/732aa47a5dd3864051b9  

--


--
Arnaud Bailly

CTO | Capital Match

CapitalMatch

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

(FR)  +33 617 121 978 / (SG) +65 8408 7973 | <a href="javascript:" style="color:rgb(17,85,204)" target="_blank" gdf-obfuscated-mailto="P_a5CowgSKIJ" rel="nofollow" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">arn...@... | <a href="http://www.capital-match.com/" style="font-size:12.8000001907349px;color:rgb(17,85,204)" target="_blank" rel="nofollow" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Fwww.capital-match.com%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNFDYLYF7XfSo-XoN0MYJg8VE2rtAg';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Fwww.capital-match.com%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNFDYLYF7XfSo-XoN0MYJg8VE2rtAg';return true;">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-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: [haskell-infrastructure] Improvements to package hosting and security

Gershom Bazerman
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


On April 14, 2015 at 10:57:00 PM, Carter Schonwald ([hidden email]) 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 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 <
> > [hidden email] > 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.
> >>>
> >>> an email to [hidden email].
> >>>
> >>>
> >> To view this discussion on the web visit
> >>> https://groups.google.com/d/msgid/commercialhaskell/4487776e-b862-429c-adae-477813e560f3%40googlegroups.com 
> >>>  
> >>> .
> >>
> >>
> >>>
> >>>
> >>
> >>
> >> --
> >> *Arnaud Bailly*
> >>
> >> CTO | Capital Match
> >>
> >> CapitalMatch
> >>
> >> 71 Ayer Rajah Crescent | #06-16 | Singapore 139951
> >>
> >> (FR) +33 617 121 978 / (SG) +65 8408 7973 | [hidden email]
> >> | 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
> [hidden email]
> http://community.galois.com/mailman/listinfo/haskell-infrastructure
>  

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Improvements to package hosting and security

Greg Weber
In reply to this post by Michael Snoyman
What security guarantees do we get from this proposal that are not present from Chris's package signing work?
Part of the goal of the package signing is that we no longer need to trust Hackage. If it is compromised and packages are compromised, then anyone using signing tools should automatically reject the compromised packages.

Right now I think the answer is: that this provides a security model for revisions: it limits what can be done and formalizes the trust of this process in a cryptographic way. Whereas with Chris's work there is no concept of a (trusted) revision and a new package must be released?

On Mon, Apr 13, 2015 at 3:02 AM, Michael Snoyman <[hidden email]> 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.

[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  

--


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Improvements to package hosting and security

Michael Snoyman
In reply to this post by Carter Schonwald


On Wed, Apr 15, 2015 at 5:56 AM Carter Schonwald <[hidden email]> 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 <[hidden email]> 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. <[hidden email]> 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.

[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  

--


--
Arnaud Bailly

CTO | Capital Match

CapitalMatch

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

(FR)  +33 617 121 978 / (SG) +65 8408 7973 | [hidden email] | 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-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: [haskell-infrastructure] Improvements to package hosting and security

Michael Snoyman
In reply to this post by Gershom Bazerman
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 <[hidden email]> 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


On April 14, 2015 at 10:57:00 PM, Carter Schonwald ([hidden email]) 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 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 <
> > [hidden email] > 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
> >>>>
> >>> --
> >>>
> >> > >>> "Commercial Haskell" group.
> >>> > >>> an email to [hidden email].
> >>> > >>>
> >> > >>> https://groups.google.com/d/msgid/commercialhaskell/4487776e-b862-429c-adae-477813e560f3%40googlegroups.com
> >>>
> >>> .
> >>
> >>
> >>> > >>>
> >>
> >>
> >> --
> >> *Arnaud Bailly*
> >>
> >> CTO | Capital Match
> >>
> >> CapitalMatch
> >>
> >> 71 Ayer Rajah Crescent | #06-16 | Singapore 139951
> >>
> >> (FR) +33 617 121 978 / (SG) +65 8408 7973 | [hidden email]
> >> | 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
> [hidden email]
> http://community.galois.com/mailman/listinfo/haskell-infrastructure
>

--

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Improvements to package hosting and security

Michael Snoyman
In reply to this post by Greg Weber
Yes, I think you've summarized the security aspects of this nicely. There's also the reliability and availability guarantees we get from a distributed system, but that's outside the realm of security (unless you're talking about denial of service).

On Wed, Apr 15, 2015 at 7:12 AM Greg Weber <[hidden email]> wrote:
What security guarantees do we get from this proposal that are not present from Chris's package signing work?
Part of the goal of the package signing is that we no longer need to trust Hackage. If it is compromised and packages are compromised, then anyone using signing tools should automatically reject the compromised packages.

Right now I think the answer is: that this provides a security model for revisions: it limits what can be done and formalizes the trust of this process in a cryptographic way. Whereas with Chris's work there is no concept of a (trusted) revision and a new package must be released?

On Mon, Apr 13, 2015 at 3:02 AM, Michael Snoyman <[hidden email]> 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.

[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  

--

--

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Improvements to package hosting and security

Greg Weber


On Tue, Apr 14, 2015 at 9:50 PM, Michael Snoyman <[hidden email]> wrote:
Yes, I think you've summarized the security aspects of this nicely. There's also the reliability and availability guarantees we get from a distributed system, but that's outside the realm of security (unless you're talking about denial of service).

Is it possible to separate out the concept of trusted revisions from a distributed hackage (into 2 separate proposals) then?
If Hackage wanted to it could implement trusted revisions. Or some other (distributed or non-distributed) package service could implement it (as long as the installer tool knows to check for revisions there, perhaps this would be added to Chris's signing tooling).
 

On Wed, Apr 15, 2015 at 7:12 AM Greg Weber <[hidden email]> wrote:
What security guarantees do we get from this proposal that are not present from Chris's package signing work?
Part of the goal of the package signing is that we no longer need to trust Hackage. If it is compromised and packages are compromised, then anyone using signing tools should automatically reject the compromised packages.

Right now I think the answer is: that this provides a security model for revisions: it limits what can be done and formalizes the trust of this process in a cryptographic way. Whereas with Chris's work there is no concept of a (trusted) revision and a new package must be released?

On Mon, Apr 13, 2015 at 3:02 AM, Michael Snoyman <[hidden email]> 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.

[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  

--

--


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Improvements to package hosting and security

Michael Snoyman


On Wed, Apr 15, 2015 at 8:02 AM Greg Weber <[hidden email]> wrote:
On Tue, Apr 14, 2015 at 9:50 PM, Michael Snoyman <[hidden email]> wrote:
Yes, I think you've summarized the security aspects of this nicely. There's also the reliability and availability guarantees we get from a distributed system, but that's outside the realm of security (unless you're talking about denial of service).

Is it possible to separate out the concept of trusted revisions from a distributed hackage (into 2 separate proposals) then?
If Hackage wanted to it could implement trusted revisions. Or some other (distributed or non-distributed) package service could implement it (as long as the installer tool knows to check for revisions there, perhaps this would be added to Chris's signing tooling).
 

It would be a fundamental shift away from how Hackage does things today. I think the necessary steps would be:

1. Hackage ships all revisions to cabal files somehow (personally, I think it should be doing this anyway).
2. We have a list of trustees who are allowed to edit metadata. The signing work already has to recapture that information for allowed uploaders since Hackage doesn't collect GPG keys
3. Every time a revision is made, the person making the revision would need to sign the new revision

I'm open to other ideas, this is just what came to mind first.

Michael 

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: [haskell-infrastructure] Improvements to package hosting and security

Gershom Bazerman
In reply to this post by Michael Snoyman
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.

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).

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.

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.

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.

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).

Cheers,
Gershom


On April 15, 2015 at 12:47:58 AM, Michael Snoyman ([hidden email]) wrote:

> 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).


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Improvements to package hosting and security

Greg Weber
In reply to this post by Michael Snoyman


On Tue, Apr 14, 2015 at 10:08 PM, Michael Snoyman <[hidden email]> wrote:


On Wed, Apr 15, 2015 at 8:02 AM Greg Weber <[hidden email]> wrote:
On Tue, Apr 14, 2015 at 9:50 PM, Michael Snoyman <[hidden email]> wrote:
Yes, I think you've summarized the security aspects of this nicely. There's also the reliability and availability guarantees we get from a distributed system, but that's outside the realm of security (unless you're talking about denial of service).

Is it possible to separate out the concept of trusted revisions from a distributed hackage (into 2 separate proposals) then?
If Hackage wanted to it could implement trusted revisions. Or some other (distributed or non-distributed) package service could implement it (as long as the installer tool knows to check for revisions there, perhaps this would be added to Chris's signing tooling).
 

It would be a fundamental shift away from how Hackage does things today. I think the necessary steps would be:

1. Hackage ships all revisions to cabal files somehow (personally, I think it should be doing this anyway).
2. We have a list of trustees who are allowed to edit metadata. The signing work already has to recapture that information for allowed uploaders since Hackage doesn't collect GPG keys
3. Every time a revision is made, the person making the revision would need to sign the new revision

I'm open to other ideas, this is just what came to mind first.

Perhaps this is not really doable, but I was thinking there should be a proposal for a specification for trusted revisions. These are integration details for Hackage just as the current proposal has some implementation about a distributed package service.

I actually think the easiest way to make revisions secure with Hackage is to precisely limit what can be revised. If one can only change an upper bound of an existing dependency that greatly limits the attack vectors.


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: [haskell-infrastructure] Improvements to package hosting and security

Michael Snoyman
In reply to this post by Gershom Bazerman


On Wed, Apr 15, 2015 at 8:19 AM Gershom B <[hidden email]> 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

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
12345