Proposal: Changes to the PVP

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
50 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Changes to the PVP

MightyByte
In addition to the well-state objections elsewhere in this thread, I
think this proposal is too vague and subjective.  So it gets a -1 from
me.

Point #1 needs to specify actual text.  I'm -1 on the text Michael
gives later because I disagree with that definition of reproducible
builds.

Point numbers 3 and 4 are too vague, subjective, and would cause
contention in the community.  Package authors are already free to to
associate extra meaning with A and B.  If you're willing to put in
version bounds after this PVP change, I don't see why you shouldn't be
willing to put them in before it.

On Wed, Apr 9, 2014 at 4:47 AM, Michael Snoyman <[hidden email]> wrote:

> I would like to propose the following changes to the PVP. These are the same
> changes that I recently published on the Yesod blog[1]. For more information
> on the motivations behind these changes, please see that blog post.
>
> 1. The goal of the PVP needs to be clarified. Its purpose is not to ensure
> reproducible builds of non-published software, but rather to provide for
> more reliable builds of libraries on Hackage. Reproducible builds should be
> handled exclusively through version freezing, the only known technique to
> actually give the necessary guarantees.
>
> 2. Upper bounds should not be included on non-upgradeable packages, such as
> base and template-haskell (are there others?). Alternatively, we should
> establish some accepted upper bound on these packages, e.g. many people
> place base < 5 on their code.
>
> 3. We should be distinguishing between mostly-stable packages and unstable
> packages. For a package like text, if you simply import Data.Text (Text,
> pack, reverse), or some other sane subset, there's no need for upper bounds.
> (Note that this doesn't provide a hard-and-fast rule like the current PVP,
> but is rather a matter of discretion. Communication between library authors
> and users (via documentation or other means) would be vital to making this
> work well.)
>
> 4. For a package version A.B.C, a bump in A or B indicates some level of
> breaking change. As an opt-in approach, package authors are free to
> associated meaning to A and B beyond what the PVP requires. Libraries which
> use these packages are free to rely on the guarantees provided by package
> authors when placing upper bounds. (Note that this is very related to point
> (3).)
>
> Discussion period: 3 weeks.
>
> [1] http://www.yesodweb.com/blog/2014/04/proposal-changes-pvp
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Changes to the PVP

Johan Tibell-2
In reply to this post by Greg Weber
On Wed, Apr 9, 2014 at 6:28 PM, Greg Weber <[hidden email]> wrote:
Sure, but the commenter did define their exact meaning of reproducible and stated they think that is what the PVP is for. This appears to be the definition of being confused about what the PVP is meant for.

Here's what the commenter said:

You're probably right; Simply stated, I considered "reproducible build" to mean that if there was a package on Hackage that I could cabal install foobar with a given GHC version at some point in time, I would be able to do that for each later point in time (e.g. 1 year later) using the very same GHC version (at least). Isn't that was the PVP was created to accomplish in the first place?

This definition of reproducible builds is exactly what the PVP guarantees. If you define your dependency bounds as implied by the PVP and the packages you depend on follow the PVP your package will continue to build in the future, if it built today*. That doesn't mean that it will always use the exact same versions that were used today, but the commenter didn't suggest that.
 
There isn't any situation in which the train of thought expressed here is useful in practice, particularly since we know that the PVP does not actually guarantee a package will install.

I wasn't aware. When doesn't PVP guarantee that a package will install?
 
The useful train of though is to distinguish between applications and libraries and state how dependency freezing is necessary for applications.

This hasn't nothing to do with what's being discussed.

* The caveat about instance/module re-export leaks that was mentioned before still applies.

-- Johan


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Changes to the PVP

Carter Schonwald
i'm currently -1 on this myself too for now.  


On Wed, Apr 9, 2014 at 2:01 PM, Johan Tibell <[hidden email]> wrote:
On Wed, Apr 9, 2014 at 6:28 PM, Greg Weber <[hidden email]> wrote:
Sure, but the commenter did define their exact meaning of reproducible and stated they think that is what the PVP is for. This appears to be the definition of being confused about what the PVP is meant for.

Here's what the commenter said:

You're probably right; Simply stated, I considered "reproducible build" to mean that if there was a package on Hackage that I could cabal install foobar with a given GHC version at some point in time, I would be able to do that for each later point in time (e.g. 1 year later) using the very same GHC version (at least). Isn't that was the PVP was created to accomplish in the first place?

This definition of reproducible builds is exactly what the PVP guarantees. If you define your dependency bounds as implied by the PVP and the packages you depend on follow the PVP your package will continue to build in the future, if it built today*. That doesn't mean that it will always use the exact same versions that were used today, but the commenter didn't suggest that.
 
There isn't any situation in which the train of thought expressed here is useful in practice, particularly since we know that the PVP does not actually guarantee a package will install.

I wasn't aware. When doesn't PVP guarantee that a package will install?
 
The useful train of though is to distinguish between applications and libraries and state how dependency freezing is necessary for applications.

This hasn't nothing to do with what's being discussed.

* The caveat about instance/module re-export leaks that was mentioned before still applies.

-- Johan



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Changes to the PVP

Herbert Valerio Riedel
In reply to this post by Michael Snoyman
Hello Michael,

While I can see merit in some parts[1] of this proposal, I don't agree
with this proposal as a whole.

Therefore I'm -1 on the proposal in its current form.

 [1]: E.g. having different upper-bound policies for the special class of
      the few non-upgradable packages -- however even that has
      consequences that need to be examined carefully

PS: I'd suggest breaking this proposal up into smaller incremental
    sub-proposals and discuss them one at a time.


On 2014-04-09 at 10:47:14 +0200, Michael Snoyman wrote:

> I would like to propose the following changes to the PVP. These are the
> same changes that I recently published on the Yesod blog[1]. For more
> information on the motivations behind these changes, please see that blog
> post.
>
> 1. The goal of the PVP needs to be clarified. Its purpose is not to ensure
> reproducible builds of non-published software, but rather to provide for
> more reliable builds of libraries on Hackage. Reproducible builds should be
> handled exclusively through version freezing, the only known technique to
> actually give the necessary guarantees.
>
> 2. Upper bounds should not be included on non-upgradeable packages, such as
> base and template-haskell (are there others?). Alternatively, we should
> establish some accepted upper bound on these packages, e.g. many people
> place base < 5 on their code.
>
> 3. We should be distinguishing between mostly-stable packages and unstable
> packages. For a package like text, if you simply import Data.Text (Text,
> pack, reverse), or some other sane subset, there's no need for upper
> bounds. (Note that this doesn't provide a hard-and-fast rule like the
> current PVP, but is rather a matter of discretion. Communication between
> library authors and users (via documentation or other means) would be vital
> to making this work well.)
>
> 4. For a package version A.B.C, a bump in A or B indicates some level of
> breaking change. As an opt-in approach, package authors are free to
> associated meaning to A and B beyond what the PVP requires. Libraries which
> use these packages are free to rely on the guarantees provided by package
> authors when placing upper bounds. (Note that this is very related to point
> (3).)
>
> Discussion period: 3 weeks.
>
> [1] http://www.yesodweb.com/blog/2014/04/proposal-changes-pvp
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries

--
"Elegance is not optional" -- Richard O'Keefe
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Changes to the PVP

Michael Snoyman
In reply to this post by Michael Snoyman
I have to say, the responses on this thread are truly confusing. Let's ignore point (3) of my proposal (since it can essentially be subsumed under (4)). Point (2) is clearly a change in the PVP, and boils down to "users get cabal error messages" or "users get GHC error messages." I understand (though strongly disagree with) those opposed to the change I'm proposing there. So let's ignore it.

For (1) and (4), the responses vary from support, to opposition, to "that's what the PVP already says." So there's clearly a problem here, and I don't think the problem is in my proposal: people have very different ideas of what the PVP actually expects of us.

So forget my proposal for the moment, I want to engage in a thought experiment. What does the current PVP say about the following scenarios:

1. A user is writing an application based on a number of Hackage libraries. He places version bounds following the PVP, e.g. `text >= 1.0 && < 1.1, aeson >= 0.7 && < 0.8`.
    a. Has he done a good enough job of writing his application?
    b. Should he have an expectation that, no matter what happens, his software will always build when running `cabal clean && cabal install` (assuming same GHC version and OS)?
    c. Should he have an expectation that the code will always run in the same way it did when first built?
2. I author a package called foo and release version 1.2 with the statement: "I guarantee that the Foo module will exist and continue to export the foo1 and foo2 functions, with the same type signature, until version 2.0."
    a. If a user of the foo package only uses the foo1 and foo2 functions, is he "in violation" of the PVP by using a bound on the foo package of `foo >= 1.2 && < 2`?



On Wed, Apr 9, 2014 at 11:47 AM, Michael Snoyman <[hidden email]> wrote:
I would like to propose the following changes to the PVP. These are the same changes that I recently published on the Yesod blog[1]. For more information on the motivations behind these changes, please see that blog post.

1. The goal of the PVP needs to be clarified. Its purpose is not to ensure reproducible builds of non-published software, but rather to provide for more reliable builds of libraries on Hackage. Reproducible builds should be handled exclusively through version freezing, the only known technique to actually give the necessary guarantees.

2. Upper bounds should not be included on non-upgradeable packages, such as base and template-haskell (are there others?). Alternatively, we should establish some accepted upper bound on these packages, e.g. many people place base < 5 on their code.

3. We should be distinguishing between mostly-stable packages and unstable packages. For a package like text, if you simply import Data.Text (Text, pack, reverse), or some other sane subset, there's no need for upper bounds. (Note that this doesn't provide a hard-and-fast rule like the current PVP, but is rather a matter of discretion. Communication between library authors and users (via documentation or other means) would be vital to making this work well.)

4. For a package version A.B.C, a bump in A or B indicates some level of breaking change. As an opt-in approach, package authors are free to associated meaning to A and B beyond what the PVP requires. Libraries which use these packages are free to rely on the guarantees provided by package authors when placing upper bounds. (Note that this is very related to point (3).)



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Changes to the PVP

Johan Tibell-2
On Wed, Apr 9, 2014 at 9:22 PM, Michael Snoyman <[hidden email]> wrote:
So forget my proposal for the moment, I want to engage in a thought experiment. What does the current PVP say about the following scenarios:

1. A user is writing an application based on a number of Hackage libraries. He places version bounds following the PVP, e.g. `text >= 1.0 && < 1.1, aeson >= 0.7 && < 0.8`.
    a. Has he done a good enough job of writing his application?

That's a kinda vague question. :) Has he made sure that his package will continue to build if there are backwards incompatible changes in text or aeson? Yes.
 
    b. Should he have an expectation that, no matter what happens, his software will always build when running `cabal clean && cabal install` (assuming same GHC version and OS)?

"No matter what happens" is also kinda vague. Assuming no bugs in GHC, Cabal, etc and assuming he's using a hermetic build environment (such as sandboxes), yes. The reason a hermetic build environment is needed is that otherwise unrelated packages might constrain the build environment (i.e. the infamous "building X will break Y" problems of the past.)
 
    c. Should he have an expectation that the code will always run in the same way it did when first built?

No. text or aeson might introduce bugs in minor/patch releases. The code might run differently on different platforms (e.g. due to different word sizes).
 
2. I author a package called foo and release version 1.2 with the statement: "I guarantee that the Foo module will exist and continue to export the foo1 and foo2 functions, with the same type signature, until version 2.0."
    a. If a user of the foo package only uses the foo1 and foo2 functions, is he "in violation" of the PVP by using a bound on the foo package of `foo >= 1.2 && < 2`?

No.

-- Johan
 

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Changes to the PVP

MightyByte
In reply to this post by Michael Snoyman
Here's my view.

1a. I don't know how to answer this question because I have no idea
what "good enough job" means.
1b. Unequivocally yes, we should do our best to support this
expectation to the best of our ability.  However we can't state it as
strongly as "no matter what happens".  I think we can say "as long as
all of his dependencies are well-behaved, the package should be pretty
likely to build..."
1c. If "always run in the same way" means that it will always be built
with the same set of transitive dependencies, then no.
2a is a bit stickier.  I want to say yes, but right now I'll leave
myself open to convincing.  My biggest concern in this whole debate is
that users of the foo package should specify some upper bound, because
as Greg has said, if you don't, the probability that the package
builds goes to ZERO (not epsilon) as t goes to infinity.  Personally I
like the safe and conservative upper bound of <1.3 because I think
practically it's difficult to make more granular contracts work in
practice and it follows the PVP's clear meaning.  If you're committing
to support the same API up to 2.0, why can't you just commit to
supporting that API up to 1.3?  The author of foo still has the
flexibility to jump to 2.0 to signal something to the users, and when
that happens, the users can change their bounds appropriately.

On Wed, Apr 9, 2014 at 3:22 PM, Michael Snoyman <[hidden email]> wrote:

> I have to say, the responses on this thread are truly confusing. Let's
> ignore point (3) of my proposal (since it can essentially be subsumed under
> (4)). Point (2) is clearly a change in the PVP, and boils down to "users get
> cabal error messages" or "users get GHC error messages." I understand
> (though strongly disagree with) those opposed to the change I'm proposing
> there. So let's ignore it.
>
> For (1) and (4), the responses vary from support, to opposition, to "that's
> what the PVP already says." So there's clearly a problem here, and I don't
> think the problem is in my proposal: people have very different ideas of
> what the PVP actually expects of us.
>
> So forget my proposal for the moment, I want to engage in a thought
> experiment. What does the current PVP say about the following scenarios:
>
> 1. A user is writing an application based on a number of Hackage libraries.
> He places version bounds following the PVP, e.g. `text >= 1.0 && < 1.1,
> aeson >= 0.7 && < 0.8`.
>     a. Has he done a good enough job of writing his application?
>     b. Should he have an expectation that, no matter what happens, his
> software will always build when running `cabal clean && cabal install`
> (assuming same GHC version and OS)?
>     c. Should he have an expectation that the code will always run in the
> same way it did when first built?
> 2. I author a package called foo and release version 1.2 with the statement:
> "I guarantee that the Foo module will exist and continue to export the foo1
> and foo2 functions, with the same type signature, until version 2.0."
>     a. If a user of the foo package only uses the foo1 and foo2 functions,
> is he "in violation" of the PVP by using a bound on the foo package of `foo
>>= 1.2 && < 2`?
>
>
>
> On Wed, Apr 9, 2014 at 11:47 AM, Michael Snoyman <[hidden email]>
> wrote:
>>
>> I would like to propose the following changes to the PVP. These are the
>> same changes that I recently published on the Yesod blog[1]. For more
>> information on the motivations behind these changes, please see that blog
>> post.
>>
>> 1. The goal of the PVP needs to be clarified. Its purpose is not to ensure
>> reproducible builds of non-published software, but rather to provide for
>> more reliable builds of libraries on Hackage. Reproducible builds should be
>> handled exclusively through version freezing, the only known technique to
>> actually give the necessary guarantees.
>>
>> 2. Upper bounds should not be included on non-upgradeable packages, such
>> as base and template-haskell (are there others?). Alternatively, we should
>> establish some accepted upper bound on these packages, e.g. many people
>> place base < 5 on their code.
>>
>> 3. We should be distinguishing between mostly-stable packages and unstable
>> packages. For a package like text, if you simply import Data.Text (Text,
>> pack, reverse), or some other sane subset, there's no need for upper bounds.
>> (Note that this doesn't provide a hard-and-fast rule like the current PVP,
>> but is rather a matter of discretion. Communication between library authors
>> and users (via documentation or other means) would be vital to making this
>> work well.)
>>
>> 4. For a package version A.B.C, a bump in A or B indicates some level of
>> breaking change. As an opt-in approach, package authors are free to
>> associated meaning to A and B beyond what the PVP requires. Libraries which
>> use these packages are free to rely on the guarantees provided by package
>> authors when placing upper bounds. (Note that this is very related to point
>> (3).)
>>
>> Discussion period: 3 weeks.
>>
>> [1] http://www.yesodweb.com/blog/2014/04/proposal-changes-pvp
>
>
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Changes to the PVP

Michael Snoyman


On Wed, Apr 9, 2014 at 10:57 PM, MightyByte <[hidden email]> wrote:
Here's my view.

1a. I don't know how to answer this question because I have no idea
what "good enough job" means.
1b. Unequivocally yes, we should do our best to support this
expectation to the best of our ability.  However we can't state it as
strongly as "no matter what happens".  I think we can say "as long as
all of his dependencies are well-behaved, the package should be pretty
likely to build..."

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.
 
1c. If "always run in the same way" means that it will always be built
with the same set of transitive dependencies, then no.
2a is a bit stickier.  I want to say yes, but right now I'll leave
myself open to convincing.  My biggest concern in this whole debate is
that users of the foo package should specify some upper bound, because
as Greg has said, if you don't, the probability that the package
builds goes to ZERO (not epsilon) as t goes to infinity.  Personally I
like the safe and conservative upper bound of <1.3 because I think
practically it's difficult to make more granular contracts work in
practice and it follows the PVP's clear meaning.  If you're committing
to support the same API up to 2.0, why can't you just commit to
supporting that API up to 1.3?  The author of foo still has the
flexibility to jump to 2.0 to signal something to the users, and when
that happens, the users can change their bounds appropriately.


This sounds more like a personal opinion response rather than interpretation of the current PVP. I find it troubling that we're holding up the PVP as the standard that all packages should adhere to, and yet it's hard to get an answer on something like this.

The point of giving a guarantee to 2.0 is that it involves less package churn, which is a maintenance burden for developers, and removes extra delays waiting for maintainers to bump version bounds, which can lead to Hackage bifurcation.

But again, my real question is: what does the PVP say right now? We can't even have a real discussion of my initial proposal if no one can agree on what the PVP says about that situation right now!

Michael

 
On Wed, Apr 9, 2014 at 3:22 PM, Michael Snoyman <[hidden email]> wrote:
> I have to say, the responses on this thread are truly confusing. Let's
> ignore point (3) of my proposal (since it can essentially be subsumed under
> (4)). Point (2) is clearly a change in the PVP, and boils down to "users get
> cabal error messages" or "users get GHC error messages." I understand
> (though strongly disagree with) those opposed to the change I'm proposing
> there. So let's ignore it.
>
> For (1) and (4), the responses vary from support, to opposition, to "that's
> what the PVP already says." So there's clearly a problem here, and I don't
> think the problem is in my proposal: people have very different ideas of
> what the PVP actually expects of us.
>
> So forget my proposal for the moment, I want to engage in a thought
> experiment. What does the current PVP say about the following scenarios:
>
> 1. A user is writing an application based on a number of Hackage libraries.
> He places version bounds following the PVP, e.g. `text >= 1.0 && < 1.1,
> aeson >= 0.7 && < 0.8`.
>     a. Has he done a good enough job of writing his application?
>     b. Should he have an expectation that, no matter what happens, his
> software will always build when running `cabal clean && cabal install`
> (assuming same GHC version and OS)?
>     c. Should he have an expectation that the code will always run in the
> same way it did when first built?
> 2. I author a package called foo and release version 1.2 with the statement:
> "I guarantee that the Foo module will exist and continue to export the foo1
> and foo2 functions, with the same type signature, until version 2.0."
>     a. If a user of the foo package only uses the foo1 and foo2 functions,
> is he "in violation" of the PVP by using a bound on the foo package of `foo
>>= 1.2 && < 2`?
>
>
>
> On Wed, Apr 9, 2014 at 11:47 AM, Michael Snoyman <[hidden email]>
> wrote:
>>
>> I would like to propose the following changes to the PVP. These are the
>> same changes that I recently published on the Yesod blog[1]. For more
>> information on the motivations behind these changes, please see that blog
>> post.
>>
>> 1. The goal of the PVP needs to be clarified. Its purpose is not to ensure
>> reproducible builds of non-published software, but rather to provide for
>> more reliable builds of libraries on Hackage. Reproducible builds should be
>> handled exclusively through version freezing, the only known technique to
>> actually give the necessary guarantees.
>>
>> 2. Upper bounds should not be included on non-upgradeable packages, such
>> as base and template-haskell (are there others?). Alternatively, we should
>> establish some accepted upper bound on these packages, e.g. many people
>> place base < 5 on their code.
>>
>> 3. We should be distinguishing between mostly-stable packages and unstable
>> packages. For a package like text, if you simply import Data.Text (Text,
>> pack, reverse), or some other sane subset, there's no need for upper bounds.
>> (Note that this doesn't provide a hard-and-fast rule like the current PVP,
>> but is rather a matter of discretion. Communication between library authors
>> and users (via documentation or other means) would be vital to making this
>> work well.)
>>
>> 4. For a package version A.B.C, a bump in A or B indicates some level of
>> breaking change. As an opt-in approach, package authors are free to
>> associated meaning to A and B beyond what the PVP requires. Libraries which
>> use these packages are free to rely on the guarantees provided by package
>> authors when placing upper bounds. (Note that this is very related to point
>> (3).)
>>
>> Discussion period: 3 weeks.
>>
>> [1] http://www.yesodweb.com/blog/2014/04/proposal-changes-pvp
>
>
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Changes to the PVP

Johan Tibell-2
On Wed, Apr 9, 2014 at 11:13 PM, Michael Snoyman <[hidden email]> 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.

We're aware of these two issues and the PVP page mentions one of them. It should also mention the other together with a workaround. These issues seem rare however. I've never run into them.
 
* Someone made a mistake in an upload to Hackage (yes, that really does happy, and it's not that uncommon).

Nothing will help you in this case as a library author, as you cannot freeze your deps in your .cabal file, which would be the only option if you're worried about this.
 
* The package you depend on doesn't itself follow the PVP, or so on down the stack.

Sure. You don't get benefits from the PVP if people don't follow the PVP.

You second sentence suggests that there are other failure modes, I'd love to know about them so we can discuss them.

As I see it now there are two real failure modes (the first two you listed), one we can fix with tooling (make sure people follow the PVP), and one I don't think it's worth caring about (accidental uploads of broken stuff.)
 
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.

It provides the guarantee with the exceptions of you two first points, which don't worry me much as I've never seen them happen outside the Yesod ecosystem (i.e. they seem rare.) Version freezing is orthogonal to the stuff the PVP talks about so I think we will just confuse users by talking about it in the PVP. Perhaps you could put together a little "how to build" stuff guide and raise awareness of the issue that way?

-- Johan


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Changes to the PVP

Ganesh Sittampalam
In reply to this post by Michael Snoyman
On 09/04/2014 09:47, Michael Snoyman wrote:

> I would like to propose the following changes to the PVP. These are the
> same changes that I recently published on the Yesod blog[1]. For more
> information on the motivations behind these changes, please see that
> blog post.
>
> 1. The goal of the PVP needs to be clarified. Its purpose is not to
> ensure reproducible builds of non-published software, but rather to
> provide for more reliable builds of libraries on Hackage. Reproducible
> builds should be handled exclusively through version freezing, the only
> known technique to actually give the necessary guarantees.

-1: as discussed in this thread, this seems to be based on a strawman.

I am also against any mention of version-freezing in the PVP as I think
it is an orthogonal concept.


> 3. We should be distinguishing between mostly-stable packages and
> unstable packages. For a package like text, if you simply import
> Data.Text (Text, pack, reverse), or some other sane subset, there's no
> need for upper bounds. (Note that this doesn't provide a hard-and-fast
> rule like the current PVP, but is rather a matter of discretion.
> Communication between library authors and users (via documentation or
> other means) would be vital to making this work well.)

-1: I don't want to have to read 20 sets of documentation to set the 20
dependencies in my package.

> 4. For a package version A.B.C, a bump in A or B indicates some level of
> breaking change. As an opt-in approach, package authors are free to
> associated meaning to A and B beyond what the PVP requires. Libraries
> which use these packages are free to rely on the guarantees provided by
> package authors when placing upper bounds. (Note that this is very
> related to point (3).)

-1: this doesn't add anything to the PVP

Ganesh

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Changes to the PVP

Gershom Bazerman
In reply to this post by Michael Snoyman
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.

Cheers,
Gershom
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Changes to the PVP

Michael Snoyman
In reply to this post by Johan Tibell-2



On Thu, Apr 10, 2014 at 12:30 AM, Johan Tibell <[hidden email]> wrote:
On Wed, Apr 9, 2014 at 11:13 PM, Michael Snoyman <[hidden email]> 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.

We're aware of these two issues and the PVP page mentions one of them. It should also mention the other together with a workaround. These issues seem rare however. I've never run into them.
 
* Someone made a mistake in an upload to Hackage (yes, that really does happy, and it's not that uncommon).

Nothing will help you in this case as a library author, as you cannot freeze your deps in your .cabal file, which would be the only option if you're worried about this.
 
* The package you depend on doesn't itself follow the PVP, or so on down the stack.

Sure. You don't get benefits from the PVP if people don't follow the PVP.

You second sentence suggests that there are other failure modes, I'd love to know about them so we can discuss them.


The point is that we don't know. The typeclass/reexport business went undocumented until a few weeks ago, which took at least a few people by surprise big time. Maybe those are the only issues that remain in the PVP.
 
As I see it now there are two real failure modes (the first two you listed), one we can fix with tooling (make sure people follow the PVP), and one I don't think it's worth caring about (accidental uploads of broken stuff.)
 

But as has been mentioned elsewhere, the accidental uploads is far worse than it seems at first, since cabal can backtrack and continue using the bad version! If I upload foo-1.0.0.1 that mistakenly says it works with bar 1.1, and then issue a point release foo-1.0.0.2 that puts the upper bound back on bar, cabal will no longer get any PVP upper bound benefits, since it will simply try to use foo-1.0.0.1.

And if we're OK saying we'll retroactively change foo-1.0.0.1, we can just as easily retroactively change packages to add in upper bounds.
 
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.

It provides the guarantee with the exceptions of you two first points, which don't worry me much as I've never seen them happen outside the Yesod ecosystem (i.e. they seem rare.) Version freezing is orthogonal to the stuff the PVP talks about so I think we will just confuse users by talking about it in the PVP. Perhaps you could put together a little "how to build" stuff guide and raise awareness of the issue that way?



I think it's obvious that no amendment to the text of the PVP will be accepted by this list, so educating users that they're using their tools incorrectly clearly won't be happening on that page.

Michael

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Changes to the PVP

Michael Snoyman
In reply to this post by Gershom Bazerman



On Thu, Apr 10, 2014 at 2:51 AM, Gershom Bazerman <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Changes to the PVP

Carter Schonwald
that analogue has a flaw,  CAs :), the MITM to rule them all, one time pads are still needed to resolve that. 

-2


On Thu, Apr 10, 2014 at 12:33 AM, Michael Snoyman <[hidden email]> wrote:



On Thu, Apr 10, 2014 at 2:51 AM, Gershom Bazerman <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Changes to the PVP

Ganesh Sittampalam
In reply to this post by Michael Snoyman
On 10/04/2014 05:30, Michael Snoyman wrote:

> * Module reexports leaking from transitive dependencies.

Shouldn't we just be saying "don't reexport entire modules from other
packages"? Is there a scenario where this is useful? One scenario I can
see is perhaps inside groups of packages maintained by the same author
or in the same source tree, but then the author can bump all the
packages in sync if necessary.

> I think it's obvious that no amendment to the text of the PVP will be
> accepted by this list, so educating users that they're using their tools
> incorrectly clearly won't be happening on that page.

Didn't Johan get an amendment agreed a few weeks ago? I think your
current amendments will have difficulty because they are based on
premises that many people disagree with, but that doesn't mean that no
amendments at all are possible.

Cheers,

Ganesh



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Changes to the PVP

MightyByte
In reply to this post by Michael Snoyman
On Wed, Apr 9, 2014 at 5:13 PM, Michael Snoyman <[hidden email]> wrote:

>
>
> On Wed, Apr 9, 2014 at 10:57 PM, MightyByte <[hidden email]> wrote:
>>
>> Here's my view.
>>
>> 1a. I don't know how to answer this question because I have no idea
>> what "good enough job" means.
>> 1b. Unequivocally yes, we should do our best to support this
>> expectation to the best of our ability.  However we can't state it as
>> strongly as "no matter what happens".  I think we can say "as long as
>> all of his dependencies are well-behaved, the package should be pretty
>> likely to build..."
>
>
> 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:

The PVP states: "What is missing from this picture is a policy that
tells the library developer how to set their version numbers, and
tells a client how to write a dependency that means their package will
not try to compile against an incompatible dependency."  That's pretty
clear to me.  The disservice is insisting that a complex gray issue is
black and white by using phrases like "no matter what happens".  It's
also clear that this is Haskell we're talking about.  We value purity,
referential transparency, and controlling side effects.  When I
translate those ideas to the package world I tend to think that if
I've gone to the trouble to get code working today, I want to maximize
the probability that it will work at any point in the future.

> * 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.

Nowhere does the PVP state a goal of guaranteeing anything, so this is
a straw man and a completely invalid point in this discussion.  In
fact, the wording makes it pretty clear that there are no guarantees.
In a perfect world the PVP would ensure that code that builds today
will build for all time while allowing for some variation in build
plans to allow small patches and bug fixes to be included in your
already working code.  Alas, we don't live in that world.  But that
doesn't mean that we shouldn't try to get as close to that state of
affairs as we can.

As others have mentioned, version freezing is a completely orthogonal
issue, otherwise we wouldn't even have the notion of bounds to begin
with.  We would simply have cabal files that specify a single version
and be done.  The whole point of the PVP is to NOT lock down to a
single version.  You want to have simple backwards compatible
dependency bug fixes automatically work with your code.

>>
>> 1c. If "always run in the same way" means that it will always be built
>> with the same set of transitive dependencies, then no.
>> 2a is a bit stickier.  I want to say yes, but right now I'll leave
>> myself open to convincing.  My biggest concern in this whole debate is
>> that users of the foo package should specify some upper bound, because
>> as Greg has said, if you don't, the probability that the package
>> builds goes to ZERO (not epsilon) as t goes to infinity.  Personally I
>> like the safe and conservative upper bound of <1.3 because I think
>> practically it's difficult to make more granular contracts work in
>> practice and it follows the PVP's clear meaning.  If you're committing
>> to support the same API up to 2.0, why can't you just commit to
>> supporting that API up to 1.3?  The author of foo still has the
>> flexibility to jump to 2.0 to signal something to the users, and when
>> that happens, the users can change their bounds appropriately.
>>
>
> This sounds more like a personal opinion response rather than interpretation
> of the current PVP. I find it troubling that we're holding up the PVP as the
> standard that all packages should adhere to, and yet it's hard to get an
> answer on something like this.

Here's what the PVP says:

"When publishing a Cabal package, you should ensure that your
dependencies in the build-depends field are accurate. This means
specifying not only lower bounds, but also upper bounds on every
dependency.
At some point in the future, Hackage may refuse to accept packages
that do not follow this convention."

I'm pretty sure this is why Johan answered "no" to your question of
whether it violates the PVP.  So ok, by the letter of the PVP I guess
this isn't a violation.  But it depends on what point in time we're
talking about.  If 1.2 is the most recent version, then the PVP points
out that having an upper bound of < 1.3 carries a little risk with it.
 Using an upper bound of 2.0 at that point in time carries a lot more
risk because the PVP (the closest thing we have to a standard) allows
for breakages within that bound, and the fact is that there's no
guarantee the package will ever get to 2.0.  If however the currently
released version is 2.0 and you have discovered that it breaks your
package, then that version bound is fine.

So at one point in time `foo >= 1.2 && < 2` is quite risky, but at
another it's the right thing.  For awhile now I've been advocating a
new feature that allows us to specify a bound of <! 2 when you know
your package breaks at that version and <1.3 when it's simply untested
and might actually work.  This kind of a solution adds information to
the whole system unlike your approach of throwing out upper bounds
which throws information away, making an already hard problem
hopeless.

Alternatively, if you foo is your package and you have set up some
scheme where you agree that breaking changes in some subset of your
API will come with a bump to 2.0 and breaking changes to the rest will
have a bump to 1.3, then I don't have a problem with you setting your
bound to 2.0 if you only use those more stable functions.  But I don't
think that as a general rule other people should use the < 2.0 bound
because it's subjective, difficult to negotiate, and cannot be
automatically checked.  I think clear and simple wins the day here.

> The point of giving a guarantee to 2.0 is that it involves less package
> churn, which is a maintenance burden for developers, and removes extra
> delays waiting for maintainers to bump version bounds, which can lead to
> Hackage bifurcation.

Less package churn?  Package churn is solely related to the number of
backwards-incompatible changes per unit time and nothing else.  I
don't care what version numbers you're using or whether you're
following the PVP or not.  If you're breaking backwards compatibility,
then you're churning, pure and simple.  The PVP already gives a
guarantee that those functions should stay the same up to 1.3.  So a
contract with your users that those functions won't change until 2.0
is effectively no different from having a contract that they won't
change until 1.3.  It's just an arbitrary number.  If you haven't
changed the API, then don't bump to 1.3.  The only difference comes if
you want to change some functions, but not others.  And there's simply
no good way to draw that distinction barring MUCH better static
analysis tools that do the full API check for you.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Changes to the PVP

Michael Snoyman
In reply to this post by Ganesh Sittampalam



On Thu, Apr 10, 2014 at 9:19 AM, Ganesh Sittampalam <[hidden email]> wrote:
On 10/04/2014 05:30, Michael Snoyman wrote:

> * Module reexports leaking from transitive dependencies.

Shouldn't we just be saying "don't reexport entire modules from other
packages"? Is there a scenario where this is useful? One scenario I can
see is perhaps inside groups of packages maintained by the same author
or in the same source tree, but then the author can bump all the
packages in sync if necessary.

> I think it's obvious that no amendment to the text of the PVP will be
> accepted by this list, so educating users that they're using their tools
> incorrectly clearly won't be happening on that page.

Didn't Johan get an amendment agreed a few weeks ago? I think your
current amendments will have difficulty because they are based on
premises that many people disagree with, but that doesn't mean that no
amendments at all are possible.


I should have clarified: no amendment that points out flaws in the PVP. My premise is simple: the PVP is a useful tool, but does not address all cases. Since people seem to mistakenly believe that it will protect them from all build problems, the text should be amended to make that clear. Every attempt I've made to come up with text that is acceptable to this list has been met with resistance. If someone else can come up with a modification that is acceptable, great. But I'm not going to continue trying, and will instead try to inform people through other channels that they need to use something more than the PVP if they want reproducible builds.

Michael 

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Changes to the PVP

Ivan Lazar Miljenovic
In reply to this post by Ganesh Sittampalam
On 10 April 2014 16:19, Ganesh Sittampalam <[hidden email]> wrote:
> On 10/04/2014 05:30, Michael Snoyman wrote:
>
>> * Module reexports leaking from transitive dependencies.
>
> Shouldn't we just be saying "don't reexport entire modules from other
> packages"? Is there a scenario where this is useful? One scenario I can
> see is perhaps inside groups of packages maintained by the same author
> or in the same source tree, but then the author can bump all the
> packages in sync if necessary.

Re-exporting modules like Control.Applicative for parsing libraries?

Admittedly, this is for a module in base rather than a third-party library.

>
>> I think it's obvious that no amendment to the text of the PVP will be
>> accepted by this list, so educating users that they're using their tools
>> incorrectly clearly won't be happening on that page.
>
> Didn't Johan get an amendment agreed a few weeks ago? I think your
> current amendments will have difficulty because they are based on
> premises that many people disagree with, but that doesn't mean that no
> amendments at all are possible.
>
> Cheers,
>
> Ganesh
>
>
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries



--
Ivan Lazar Miljenovic
[hidden email]
http://IvanMiljenovic.wordpress.com
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Changes to the PVP

Ganesh Sittampalam
In reply to this post by Michael Snoyman
On 10/04/2014 07:24, Michael Snoyman wrote:

>
>
>
>     Didn't Johan get an amendment agreed a few weeks ago? I think your
>     current amendments will have difficulty because they are based on
>     premises that many people disagree with, but that doesn't mean that no
>     amendments at all are possible.
>
>
> I should have clarified: no amendment that points out flaws in the PVP.
> My premise is simple: the PVP is a useful tool, but does not address all
> cases. Since people seem to mistakenly believe that it will protect them
> from all build problems, the text should be amended to make that clear.
> Every attempt I've made to come up with text that is acceptable to this
> list has been met with resistance. If someone else can come up with a
> modification that is acceptable, great. But I'm not going to continue
> trying, and will instead try to inform people through other channels
> that they need to use something more than the PVP if they want
> reproducible builds.

The problem with instance removal is already documented in section 2.3.

The "Rationale" section is perhaps slightly inaccurate in that it says
"and tells a client how to write a dependency that means their package
will not try to compile against an incompatible dependency". Perhaps we
could just change "means" to "in most cases means"?

I think the more general communication that the PVP isn't X where it
doesn't explicitly claim to be X are indeed best kept to other channels
in order to keep the whole thing brief.

Ganesh

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Changes to the PVP

MightyByte
In reply to this post by Michael Snoyman
On Thu, Apr 10, 2014 at 12:33 AM, Michael Snoyman <[hidden email]> wrote:

>
>
>
> On Thu, Apr 10, 2014 at 2:51 AM, Gershom Bazerman <[hidden email]>
> 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 <[hidden email]> wrote:

>
>
>
> On Thu, Apr 10, 2014 at 2:51 AM, Gershom Bazerman <[hidden email]>
> 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
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
123