黑客下载的身份验证？
有什么办法可以保证hackage下载的真实性吗？据我所知，什么也没有。没有用于 hackage 的 https，也没有用于 tarball 的（强）校验和，也没有签名。
那么：如何验证 hackage 下载的真实性呢？
Is there any way to ensure authenticity of downloads from hackage? As far as I can see, there's nothing. No https for hackage, and neither (strong) checksums for tarballs, and neither are they signed.
So: how can I verify the authenticity of downloads from hackage?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
新的 Hackage 服务器很快就会取得重大进展。马特在夏天的代码中致力于此。看看他的博客：http://cogracenotes.wordpress.com/
人们对管理贡献者进行了思考以新的、更好的方式登录，但尚未验证下载的真实性。
另一方面，据我记得，https 支持将成为 hackage 2 的一部分。
签名的 tarball 听起来可能有用，但还没有完成考虑实施它们的工作。 Hackage 是开源的，获得贡献或者只是仔细考虑功能提案都会有所帮助。
There's been significant work on a new Hackage server Real Soon Now. Matt worked on it for summer of code. Take a look at his blog: http://cogracenotes.wordpress.com/
There's been thought put into managing contributor logins in new and better ways, but not yet into verifying the authenticity of downloads.
Https support, on the other hand, is slated to be part of hackage 2, as I recall.
Signed tarballs sound potentially useful, but there just hasn't been work done to think about implementing them. Hackage is open source, and it would be helpful to either get contributions, or even just carefully thought through feature proposals.
目前的答案是不能。唯一的身份验证是上传（通过基本 HTTP 身份验证完成）。
人们要求不同级别的安全性：
新服务器将处理第二期。
将签名清单添加到黑客索引中可以解决第一个问题。这将是一个相对轻量级的解决方案。它不能确保上传的包是由特定的任何人或服务器没有被黑客攻击。
第三个将是更重量级的，我们不能明智地希望这只是可选的。一方面，这意味着维护人员必须签署他们的包。这也意味着用户必须以某种方式管理钥匙串或类似的信任网络。这将需要大量的基础设施，例如让 gnupg 在 Windows 上工作将是一个皮塔饼。
Currently the answer is that you cannot. The only authentication is for uploads (done by basic HTTP auth).
There are various levels of security that people ask for:
The new server will handle the second issue.
Adding a signed manifest to the hackage index would solve the first one. That would be a relativley lightweight solution. It does not ensure that the uploaded package is by anyone in particular or that the server has not been hacked.
The third would be much more heavyweight and we cannot sensibly hope for this ever to be more than optional. For one thing it means maintainers have to sign their packages. It also means users somehow have to manage a keychain or similar web of trust. This would be a lot of infrastructure, e.g. making gnupg work on windows would be a pita.