On Thu, Jan 31, 2013 at 11:48 AM, Vincent Hanquez <t...@snarc.org> wrote:
> On 01/31/2013 08:54 AM, Alexander Kjeldaas wrote: > >> On Thu, Jan 31, 2013 at 9:26 AM, Vincent Hanquez <t...@snarc.org> wrote: >> >> On 01/31/2013 06:27 AM, Ertugrul Söylemez wrote: >>> >>> In any case there is no valid excuse for the lack of crypto. It's too >>>> easy to attack Hackage, so we need some crypto regardless of what we >>>> interpret it as. >>>> >>>> My proposal is: >>>> >>>> 1. Build the necessary machinery into Cabal to allow signing keys >>>> and >>>> packages and verifying the signatures, ideally through GnuPG. >>>> Cabal would benefit from that even without cabal-install and >>>> Hackage. >>>> >>>> Seems there's lots of suggestion of using gnupg, which is a perfectly >>> valid answer if cabal was unix only, but i'm not sure it's a valid option >>> considering windows. Sure you can install gnupg somehow, but sounds to me >>> it's going the same problem as gtk2hs on windows. >>> >>> One better way, would be to tap in the 2, work in progress, gnupg haskell >>> replacement: >>> >>> http://hackage.haskell.org/****package/openpgp<http://hackage.haskell.org/**package/openpgp> >>> <http://**hackage.haskell.org/package/**openpgp<http://hackage.haskell.org/package/openpgp> >>> > >>> http://hackage.haskell.org/****package/hOpenPGP<http://hackage.haskell.org/**package/hOpenPGP> >>> <http://**hackage.haskell.org/package/**hOpenPGP<http://hackage.haskell.org/package/hOpenPGP> >>> > >>> >>> >>> AFAIK, both packages are not yet handling anything related to WoT, but >>> just do the signing/verification (which is same status as my ad-hoc >>> experiment) >>> >>> >>> In this case I think this is the wrong approach. There must be at least >> one way to work within a trust model that is not fragile. Whether this is >> fully supported on all platforms is actually not very important. >> >> I have pointed out why simply signing packages is fragile and how git is >> better suited for this task. We are not going to reimplement all the good >> infrastructure that already exists (gpg, git), so making that a >> requirement >> is not a good idea IMO. >> >> Basic verification of signatures should work on Windows, I agree. But the >> underlying WoT should be a little bit more sophisticated. This means it >> has to be based on standard tools, or it will never happen. >> >> I think you misunderstood me. > > Having a fully working pgp package, means you have full control of the pgp > stack, you don't rely on hard-to-get out tools, and it can be integrated > with cabal directly for a full WoT experience. > > Also git doesn't solve the hackage problem, there's not necessarily a > one-to-one mapping between packages and their repositories. > > Regarding git, I don't see anyone even suggesting that hackage should support multiple 'signed-off-by's, signing diffs between packages, and signing releases. I don't see anyone supporting 3rd-parties signing packages at will. All of this is significant engineering effort that just won't happen. And even if it does, it still doesn't solve the problem, because all of the above is required to protect our base ghc, cabal-install tools anyways. If cabal-install is hacked, hackage is hacked. And even when all of this is done, a design where there is a set of trusted developers is flawed. The set of trusted developers will increase over time, and there will be the need to restrict which developers can release which package. How do you protect that information, which keys can sign which packages? That information must itself be signed off by someone. If not, ouch some obscure developer in the trusted set hijacked an important package because he was owned. That signing in itself *requires* either consensus or a trusted third party. Consensus is a superior method and IMO required. Actually, all modifications to important packages requires consensus by at least two developers to avoid the threat posed by "owned" developers. So although it is not a waste of time to "secure" hackage, it is always going to be slightly fragile as long as ghc is fragile for example, and it just isn't ever going to *really* solve the problem. Git has the ability to solve all of this. So a better use of resources IMO is to skip securing hackage by own means, but to standardize on using git as the infrastructure for securing hackage. Then the same infrastructure that should secure ghc should secure hackage. To explain this in concrete terms, to do this, all that is needed is *something like* the following: 1. Each package on hackage gets its own repository (say on github or similar). (I've actually put all of hackage in a single git repository - it works fine, so there are no relevant size problems) 2. Uploads to hackage either happen through commits to the git repository, or an old-style upload to hackage automatically creates a new anonymous branch in the git repository. 3. The git repository is authorative. Signing releases, code reviews etc. all happens through the git repositories. This gives us all the flexibility of a git-style trust model. 4. If a package already has a git repository, that repository can be used instead of the 'hackage' one. 5. Who owns which package names can be held in a separate meta-tree git repository, and can have consensus requirements on commits. 6. This special meta-tree can also contain suggested verification keys for commits to the other hackage git trees. It can even contain keys that protect Haskell namespaces in general, so that no hackage package can overwrite a protected Haskell namespace. 7. As backward compatibility, the meta-tree can sign simple hashes of already existing packages on hackage. I'll just note that none of the above requires any changes to Hackage at all. That is the modification story. On the verification side there are multiple options: 1. There could be some git magic script that downloads the signed git tag objects only (small data set). Then another script would generate a git-compatible SHA1 of the extracted tarball, given that the tarball was fetched from hackage. 2. Or cabal-install could fetch directly from git repositories and use standard git verification. 3. Or a trusted machine creates tarballs from the git repositories, signs them and uploads them to hackage. At the same time, a set of distrustful machines do the same thing by running cron-jobs that check the trusted machine. This is slightly fragile, but would "mostly work". Alexander > -- > Vincent >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe