Proposal: Changes to the PVP

[MightyByte]

On Thu, Apr 10, 2014 at 12:33 AM, Michael Snoyman <michael at snoyman.com> wrote:
>
>
>
> On Thu, Apr 10, 2014 at 2:51 AM, Gershom Bazerman <gershomb at gmail.com>
> 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 <michael at snoyman.com> wrote:
>
>
>
> On Thu, Apr 10, 2014 at 2:51 AM, Gershom Bazerman <gershomb at gmail.com>
> 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>