Re: Proposal: Changes to the PVP

On Thu, Apr 10, 2014 at 12:33 AM, Michael Snoyman wrote:

On Thu, Apr 10, 2014 at 2:51 AM, Gershom Bazerman wrote:

...

On 4/9/14, 5:13 PM, Michael Snoyman wrote:

...

And this is where I think the PVP is doing a disservice with its current wording. Users have this expectation, but it doesn't actually hold up in reality. Reasons why it may fail include:

* Typeclass instance leaking from transitive dependencies. * Module reexports leaking from transitive dependencies. * Someone made a mistake in an upload to Hackage (yes, that really does happy, and it's not that uncommon). * The package you depend on doesn't itself follow the PVP, or so on down the stack.

So my point is: even though the *goal* of the PVP is to provide this guarantee, it *doesn't* provide this guarantee. Since we have a clear alternative that does provide this guarantee (version freezing), I think we should make it clear that the PVP does not solve all problems, and version freezing should be used.

Along the same lines I am concerned about the expectation of security provided by SSL. As the recent Heartbleed bug shows, we have an expectation that we have security, but this may fail in practice. As such, even though the *goal* of SSL is to provide this guarantee, it *doesn't* provide this guarantee, and furthermore it is a pain to comply with, certificates are expensive, etc. Since we have a clear alternative that does provide this guarantee (one-time-pads coupled with dead drops and a system of code phrases), I think we should make it clear that public key encryption does not solve all problems, and other techniques should be used.

That's a flawed analogy, since:

It's a perfect analogy because it uses your EXACT same wording. You just don't seem to want to see it.

1. I never suggested not using the PVP.

Neither did he. Your words could be interpreted as suggesting not using the PVP just as easily as you interpreted his words as suggesting not using SSL.

2. The *additional* tool I recommended (version freezing) is going to be cheap to use, since it's included in the tool everyone's already using (cabal).

The additional tool you recommended actually is completely orthogonal to the original issue just as one-time-pads and dead drops are completely orthogonal to the goal of SSL. Multiple people have mentioned this over and over again in this thread but you don't seem to be listening.

3. Freezing has additional benefits not covered by the PVP, which we should be encouraging users to take advantage of anyway.

One-time-pads have additional benefits not covered by SSL, which (if the cost-benefit is acceptable) we should be encouraging users to take advantage of anyway. On Thu, Apr 10, 2014 at 12:33 AM, Michael Snoyman wrote:

On Thu, Apr 10, 2014 at 2:51 AM, Gershom Bazerman wrote:

...

On 4/9/14, 5:13 PM, Michael Snoyman wrote:

...

And this is where I think the PVP is doing a disservice with its current wording. Users have this expectation, but it doesn't actually hold up in reality. Reasons why it may fail include:

* Typeclass instance leaking from transitive dependencies. * Module reexports leaking from transitive dependencies. * Someone made a mistake in an upload to Hackage (yes, that really does happy, and it's not that uncommon). * The package you depend on doesn't itself follow the PVP, or so on down the stack.

So my point is: even though the *goal* of the PVP is to provide this guarantee, it *doesn't* provide this guarantee. Since we have a clear alternative that does provide this guarantee (version freezing), I think we should make it clear that the PVP does not solve all problems, and version freezing should be used.

Along the same lines I am concerned about the expectation of security provided by SSL. As the recent Heartbleed bug shows, we have an expectation that we have security, but this may fail in practice. As such, even though the *goal* of SSL is to provide this guarantee, it *doesn't* provide this guarantee, and furthermore it is a pain to comply with, certificates are expensive, etc. Since we have a clear alternative that does provide this guarantee (one-time-pads coupled with dead drops and a system of code phrases), I think we should make it clear that public key encryption does not solve all problems, and other techniques should be used.

That's a flawed analogy, since:

1. I never suggested not using the PVP. 2. The *additional* tool I recommended (version freezing) is going to be cheap to use, since it's included in the tool everyone's already using (cabal). 3. Freezing has additional benefits not covered by the PVP, which we should be encouraging users to take advantage of anyway.

A better analogy would be: Given that SSL has some flaws:

* Possible buggy implementation * Possible MITM attack * Possible untrustworthy server

It's best not to send passwords over SSL in plaintext. Therefore, we recommend that when sending passwords, you use a client-side hashing scheme to avoid sending sensitive data to the server. This transport should still occur over SSL.

Michael

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries