Hi all!
I’d like to pose a problem, propose a possible solution and then
finally ask some questions at the end.
A remaining problem with the distribution of Haskell packages is that
the process from end to end is generally unsecured and lacks any
notion of quality control. This is a problem for a few types of people
who fit into our primary goals:
A lot of of good will currently goes into trusting Hackage (1) as a
way of uploading, (2) as an archive, (3) as quality control (none) and
(4) as a download process. None of these are secured to any standard.
This is up for discussion. Previous discussion about this issue has
let to such ideas as:
In fact, the above approaches are in a process of development, but a
couple years has gone past with no discernible progress. I argue that
this is good; these solutions (as is) are not a good idea because:
It seems much more safe and practical to go with package
signing. Michael and I have discussed the following solution of
“reviewing”. Hopefully it will be entirely unsurprising and
obvious. It goes roughly like this:
The nature of a signature depends on the review and the reviewer; this
is why I use the term “review” and not simply signing:
Within this process the following points hold:
Note: we’re not talking about source control here, signing Git commits
or tags is a misleading notion. We are specifically referring to
signing the .tar.gz archive itself.
To implement this solution, the software already exists:
What, I believe, we would need to implement this, would be:
What Github and Git teach us is that if you make the steps as simple
as git init; git remote add …; git push; then any developer will
happily follow this process. Make it hard and nobody will do it.
Some example work in this area from 2013:
https://github.com/chrisdone/cabal-sign This serves as a
demonstration, but it couples the signature with the package. I don’t
recommend this software or propose it, but the README is rather
illustrative of how simple the process can be. To be clear, use of
standard key servers with education on how to maintain a web of trust
would be the preferred approach here.
Debian’s package manager:
http://manpages.ubuntu.com/manpages/gutsy/man1/dpkg-sig.1.html
The questions I’d like to ask are:
Cheers!
--
You received this message because you are subscribed to the Google Groups "Commercial Haskell" group.
To unsubscribe from this group and stop receiving emails from it, send an email to commercialhask...@googlegroups.com.
To post to this group, send email to commerci...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/commercialhaskell/CAAJHNPBP6u3AZTGOPNdUkFG7k7WtuAuQPREKhR6quNc72%3DGjxA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
CTO | Capital Match
CapitalMatch
www.capital-match.com - 71 Ayer Rajah Crescent | #06-16 | Singapore 139951
(FR) +33 617 121 978 / (SG) +65 84 08 79 73 | arn...@capital-match.com
Disclaimer:
Capital Match Holdings Pte. Ltd. (the "Company") registered in Singapore (Co. Reg. No. 201418682W) engages in factoring and lending activity only to corporations and limited liability partnerships. The Company does not offer services to other persons or entities, nor engages in deposit taking. The Company operates as an "excluded moneylender" and does not fall under the purview of the Moneylenders Act.
Hi all!
I’d like to pose a problem, propose a possible solution and then
finally ask some questions at the end.
I should also point out that server-based index signing isn't quite as bad all that when it comes to the threat of server compromise. See the description of the update framework for details. The key points though are that things can be arranged so that multiple machines must be compromised to be able to forge signatures, including non-public facing machines. The root key is stored offline so the system can be restored in the event of a key compromise. Secretly subverting existing packages can be partially mitigated against by distributed checking of the package checksums. Corruption of newly uploaded packages can also be partially mitigated against by a more complicated form of distributed checksum checking. So the point is, sever compromise is a real issue, but things can be arranged to make it hard to achieve and so that any compromise is detected promptly.
## Usage or lack thereofWhat if package authors don't want to bother signing their package? They don't want to install PGP, but they most certainly use a SCM. Assuming we can auto-detect the SCM, The sdist step is now just:cabal sdist v0.4.3The command will verify that the tag exists in the local repo and in the project URI specified in the SCM information.If we can get the author to securely log in to Hackage and enter the project URI, things become more difficult to hack because we can verify information against what is in the SCM. If the SCM or package directory information is changed, the SCM fetch is not going to work. Changing the SCM commit and the cabal version allows an attacker only the easy ability to attempt to convince us to use an older version of the package, not one that they create (because we can verify that against what is in the SCM).So we need a secure client to to tell Hackage about a URI. We all have one: a browser. Creating a new package means logging in, writing down a package name, a SCM, and a URI. Releasing a package is a later event that requires giving Hackage a cabal version and a SCM commit revision. Even if this meta-data release is insecure we can check the data against the SCM.# Security weaknessesA big weakness of the SCM approach is that we must trust the URI. If Github is hacked, we are hacked. SCM mirrors, a sha of package contents, and the difficulty of faking a git sha can prevent tampering with *previous* versions. Publishing *new* versions from a compromised SCM repo can be protected against by* authenticating the sending of giving a cabal version and a commit revision* specifying multiple SCM urls that must all be pushed to (this will require every url to be compromised with write access).## CentralizationAnother weakness is the centralized distribution of package information: Hackage could be compromised. We can solve this by having multiple Hackages. But I don't really mean Hackage, I just mean a simple meta-data repository with API access. These servers can be running in multiple locations. When you release a package, you push your information to multiple servers (potentially insecurely, although securely giving the URI for a package would be required). When you download your package, you check package information from multiple servers and verify that they are all the same.# DistributionThe signing proposals assumes centralized package distribution (with mirroring). The SCM provides a secure direct transport mechanism. However, we are relying on Github being up.
## Local SCM verificationA company can operate a local Hackage by downloading the package meta-data and cloning all the SCM repos (that it uses). This local Hackage could be a server that polls for updated meta-data and gathers the latest SCM updates. A persistent update process helps avoid SCM downtime issues. In addition, this process would automatically verify that the SCM contents match the meta-data.# SCM benefits unrelated to securityCabal already has a command to fetch the source. If it also knew how to checkout a specific release, that helps to hack on an open source library you are depending on.There is a problem with having a local copy of an open source library though. You should bump versions in your local copy, but that will just confuse cabal because it also finds version info on Hackage. I think there is an opportunity here to integrate SCM commit hash information to avoid confusion.# ConclusionAdding package signing is the clearest way to secure the basic package installation workflow, if we can get everyone to do it. SCM integration can complement package signing security.SCM integration has the potential to add real end-to-end security by itself. However, the security has weaknesses unless a user can securely transmit some release metadata or change their workflow to push code to multiple locations.SCM integration also offers* local forks that are practical to deal with in a secure way and easier to install* a direct package transport mechanism that is secure
Michael
On Sat Feb 07 2015 at 9:20:45 PM Greg Weber <gr...@gregweber.info> wrote:# Signing proposal weaknesses## Security - compromised private keyDone properly signing leaves one major attack point: the private key of the key pair. Adding the SCM attributes to the package data makes attacks much harder. We can verify the package contents against what is in the SCM. The attacker must also compromise something at the package SCM url. In the case of Github, Github is unlikely to be completely compromised. A more likely scenario is for an attacker to gain privilege to commit to a repo. In that case, the attacking commit will be very visibile.I think if someone has their GPG private key compromised, it's pretty likely that they could have their SSH private key compromised as well. I don't see this as a serious win for the SCM proposal.
I think we're relying on a lot of other things, like everyone agreeing on a few core SCMs that support signing, and hosting their code on trusted servers. It seems like we're drastically increasing the attack vectors with this approach.