<div dir="ltr">On Thu, Jan 31, 2013 at 11:48 AM, Vincent Hanquez <span dir="ltr"><<a href="mailto:tab@snarc.org" target="_blank">tab@snarc.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 01/31/2013 08:54 AM, Alexander Kjeldaas wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Thu, Jan 31, 2013 at 9:26 AM, Vincent Hanquez <<a href="mailto:tab@snarc.org" target="_blank">tab@snarc.org</a>> wrote:<br>
<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On 01/31/2013 06:27 AM, Ertugrul Söylemez wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In any case there is no valid excuse for the lack of crypto. It's too<br>
easy to attack Hackage, so we need some crypto regardless of what we<br>
interpret it as.<br>
<br>
My proposal is:<br>
<br>
1. Build the necessary machinery into Cabal to allow signing keys and<br>
packages and verifying the signatures, ideally through GnuPG.<br>
Cabal would benefit from that even without cabal-install and<br>
Hackage.<br>
<br>
</blockquote>
Seems there's lots of suggestion of using gnupg, which is a perfectly<br>
valid answer if cabal was unix only, but i'm not sure it's a valid option<br>
considering windows. Sure you can install gnupg somehow, but sounds to me<br>
it's going the same problem as gtk2hs on windows.<br>
<br>
One better way, would be to tap in the 2, work in progress, gnupg haskell<br>
replacement:<br>
<br>
</div><a href="http://hackage.haskell.org/**package/openpgp" target="_blank">http://hackage.haskell.org/**<u></u>package/openpgp</a><<a href="http://hackage.haskell.org/package/openpgp" target="_blank">http://<u></u>hackage.haskell.org/package/<u></u>openpgp</a>><br>
<a href="http://hackage.haskell.org/**package/hOpenPGP" target="_blank">http://hackage.haskell.org/**<u></u>package/hOpenPGP</a><<a href="http://hackage.haskell.org/package/hOpenPGP" target="_blank">http://<u></u>hackage.haskell.org/package/<u></u>hOpenPGP</a>><div class="im">
<br>
<br>
AFAIK, both packages are not yet handling anything related to WoT, but<br>
just do the signing/verification (which is same status as my ad-hoc<br>
experiment)<br>
<br>
<br>
</div></blockquote><div class="im">
In this case I think this is the wrong approach. There must be at least<br>
one way to work within a trust model that is not fragile. Whether this is<br>
fully supported on all platforms is actually not very important.<br>
<br>
I have pointed out why simply signing packages is fragile and how git is<br>
better suited for this task. We are not going to reimplement all the good<br>
infrastructure that already exists (gpg, git), so making that a requirement<br>
is not a good idea IMO.<br>
<br>
Basic verification of signatures should work on Windows, I agree. But the<br>
underlying WoT should be a little bit more sophisticated. This means it<br>
has to be based on standard tools, or it will never happen.<br>
<br>
</div></blockquote>
I think you misunderstood me.<br>
<br>
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.<br>
<br>
Also git doesn't solve the hackage problem, there's not necessarily a one-to-one mapping between packages and their repositories.<span class="HOEnZb"><font color="#888888"><br>
<br></font></span></blockquote><div><br></div><div style>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.</div>
<div style><br></div><div style>All of this is significant engineering effort that just won't happen.</div><div style><br></div><div style>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.</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>That signing in itself *requires* either consensus or a trusted third party. Consensus is a superior method and IMO required.</div><div style><br></div><div style>Actually, all modifications to important packages requires consensus by at least two developers to avoid the threat posed by "owned" developers.</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>Git has the ability to solve all of this.</div><div style><br></div><div style>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.</div>
<div style><br></div><div style>To explain this in concrete terms, to do this, all that is needed is *something like* the following:</div><div style><br></div><div style>1. Each package on hackage gets its own repository (say on github or similar).</div>
<div style> (I've actually put all of hackage in a single git repository - it works fine, so there are no relevant size problems)</div><div style>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.</div>
<div style>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.</div><div style>4. If a package already has a git repository, that repository can be used instead of the 'hackage' one.</div>
<div style>5. Who owns which package names can be held in a separate meta-tree git repository, and can have consensus requirements on commits.</div><div style>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.</div>
<div style>7. As backward compatibility, the meta-tree can sign simple hashes of already existing packages on hackage.</div><div style><br></div><div style>I'll just note that none of the above requires any changes to Hackage at all.</div>
<div style><br></div><div style>That is the modification story. On the verification side there are multiple options:</div><div style><br></div><div style>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.</div>
<div style>2. Or cabal-install could fetch directly from git repositories and use standard git verification.</div><div style>3. Or a trusted machine creates tarballs from the git repositories, signs them and uploads them to hackage.</div>
<div style> At the same time, a set of distrustful machines do the same thing by running cron-jobs that check the trusted machine.</div><div style> This is slightly fragile, but would "mostly work".</div>
<div style>
<br></div><div style>Alexander</div><div style> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
-- <br>
Vincent<br>
</font></span></blockquote></div><br></div></div>