A response about dep and vgo
peter.bourgon.org
A response about dep and vgo
1–10 of 139 posts
Re: A response about dep and vgo
#2The discussion about the original post can be found here: https://news.ycombinator.com/item?id=17623023
This response is a long one, of which the ending deserves special note:
> I hope this story serves as a warning to others: if you’re interested in making substantial contributions to the Go project, no amount of independent due diligence can compensate for a design that doesn’t originate from the core team.
> Maybe some of you are reading this and thinking to yourself, “well, no duh, Peter, that should be obvious.” Maybe so. My mistake.
It personally made me think of this issue / PR in the Go issue tracker, https://github.com/golang/go/issues/20654, about support for constant time arithmetic with bigints. Currently, operations on bigints in Go may leak secret data via timing channels, because calculations with different values take predictably different time. The maintainers have chosen to specially modify only the P256 curve (but not P224, P384, or P521) to work in constant-time.
The author of the issue has written an extensive (somewhat strawman) PR that includes the constant-time code inside the current implementation of the bigint. That's a choice – for seemingly good reasons laid out in the issue, and of which the author admits that it also could be a separate package – but the rest of the conversation is halted in indecision about how the core team should proceed, without referring back to any of the arguments and reasons the original author has put forth.
Re: A response about dep and vgo
#3Go does not exist to raise the profiles of Sam Boyer and Peter Bourgon. Sam wanted to be a Big Man On Campus in the Go community and had to learn the hard way what the D in BDFL means. The state of dep is the same as it was before - an optional tool you might use or might not.
Lots of mentions in Peter's post about things the "dep committee" may or may not have agreed with. Isn't this the same appeal to authority he is throwing at Russ? When did the "dep committee" become the gatekeepers of Go dependency discussions and solutions? Looks like a self-elected shadow government, except it didn't have a "commit bit". Someone should have burst their balloon earlier, that is the only fault here. Russ, you are at fault for leading these people on.
Go is better off with Russ's module work and I personally don't care if Sam and Peter are disgruntled.
Re: A response about dep and vgo
#4Go does not exist to raise the profiles of Sam Boyer and Peter Bourgon. Sam wanted to be a Big Man On Campus in the Go community and had to learn the hard way what the D in BDFL means. The state of dep is the same as it was before - an optional tool you might use or might not. Lots of mentions in Peter's post about things the "dep committee" may or may not have agreed with. Isn't this the same appeal to authority he…
Additionally, dep is, and always was, meant as an experiment to learn from. Russ gave multiple concrete examples of things he learned from dep. That the dep authors don't take this as a win is telling. Pitching dep as the eventual Go dependency management system and having that not be the case is a problem they invented for themselves.
Re: A response about dep and vgo
#5The discussion about the original post can be found here: https://news.ycombinator.com/item?id=17623023 This response is a long one, of which the ending deserves special note: > I hope this story serves as a warning to others: if you’re interested in making substantial contributions to the Go project, no amount of independent due diligence can compensate for a design that doesn’t originate from the core team. > Maybe…
I don't see the comparison you're drawing here. The question proposed in the Go issue is whether the standard bignum library in Go should be constant-time, whether crypto primitives should provide their own constant-time math, or whether a third library for constant-time bignum math should be added that all Go crypto can rely on. That's not an easy question, and meanwhile significant chunks of the bignum crypto code that people actually use in Go is written in assembly anyways.
The Go crypto libraries have a domain-specialist owner: Filippo Valsorda. If you have questions about constant-time math operations in Go, he's a smart and nice guy; you should maybe ping him.
Go's crypto library is imperfect, but it is the best native crypto library provided by any modern language. (Ring is excellent too, but is not as I understand it part of the Rust standard library).
Re: A response about dep and vgo
#6Go does not exist to raise the profiles of Sam Boyer and Peter Bourgon. Sam wanted to be a Big Man On Campus in the Go community and had to learn the hard way what the D in BDFL means. The state of dep is the same as it was before - an optional tool you might use or might not. Lots of mentions in Peter's post about things the "dep committee" may or may not have agreed with. Isn't this the same appeal to authority he…
Ya, I've been following all this drama since the vgo proposal and I also find it somewhat rich. I mean in a way didn't the `dep` folks do exactly the same thing to the `glide` and other existing solutions? At some point you just have to say, hey, you've done good work but I think another approach is better. They did that to glide and Russ did that to them.
Note also that he doesn't dispute that Russ tried to bring them into the fold with his concerns and direction but they rejected his arguments. That's a fight they should have known they were going to lose.
Maintainers / BDFLs get the final say, that's just how it is. Just because there is a large community does not mean they get the final say, just because you put in a lot of work does not mean you get the final say. The reason BDFLs are in the position of making that decision is because they have proven through the accumulation of their previous decisions that they get it right more than they get it wrong. And that's the very reason there is a community around them at all.
If you walk into ANY project, public or private, open sourced or closed, and ignore the lead's objections when you go off in a direction they don't agree with, then yes, you are very likely in for some wasted work. That's just how the world works.
On another note I hope this is the last we hear about all this, please lets move on.
Re: A response about dep and vgo
#7Go does not exist to raise the profiles of Sam Boyer and Peter Bourgon. Sam wanted to be a Big Man On Campus in the Go community and had to learn the hard way what the D in BDFL means. The state of dep is the same as it was before - an optional tool you might use or might not. Lots of mentions in Peter's post about things the "dep committee" may or may not have agreed with. Isn't this the same appeal to authority he…
I've interacted quite a bit with both Sam and Peter. Your characterization rings completely false. I've never gotten the least hint of the impression they were doing this for self-promotion, but rather to serve to fill an obvious vacuum, perhaps even with a degree of reluctance.
I remember being excited when the “dep committee” was formed, because (if I remember correctly) it was set up with the explicit blessing of the Go Team, with a Go Team Member on it to facilitate two-way communication.
Your characterizations are both inaccurate and ugly.
Re: A response about dep and vgo
#8The discussion about the original post can be found here: https://news.ycombinator.com/item?id=17623023 This response is a long one, of which the ending deserves special note: > I hope this story serves as a warning to others: if you’re interested in making substantial contributions to the Go project, no amount of independent due diligence can compensate for a design that doesn’t originate from the core team. > Maybe…
I don't see the comparison you're drawing here. The question proposed in the Go issue is whether the standard bignum library in Go should be constant-time, whether crypto primitives should provide their own constant-time math, or whether a third library for constant-time bignum math should be added that all Go crypto can rely on. That's not an easy question, and meanwhile significant chunks of the bignum crypto code…
> I don't see the comparison you're drawing here.
I think the similarity is as follows:
- there is a desire to fix something that feels like a gap (in this case limited support of constant-time math in standard library)
- there is a change proposal coming from the community
- there are arguments why it should be included and some discussion if it belongs in a separate library or not
- very little or no input from core team
- the whole process is stalled waiting for core team to participate
Now we just need someone on the core team decide they need to research via implementation instead of actively engaging community, end up liking their own solution more and we'll have dep all over again.
Re: A response about dep and vgo
#9The discussion about the original post can be found here: https://news.ycombinator.com/item?id=17623023 This response is a long one, of which the ending deserves special note: > I hope this story serves as a warning to others: if you’re interested in making substantial contributions to the Go project, no amount of independent due diligence can compensate for a design that doesn’t originate from the core team. > Maybe…
I don't see the comparison you're drawing here. The question proposed in the Go issue is whether the standard bignum library in Go should be constant-time, whether crypto primitives should provide their own constant-time math, or whether a third library for constant-time bignum math should be added that all Go crypto can rely on. That's not an easy question, and meanwhile significant chunks of the bignum crypto code…
The comparison is indeed pretty thin; it certainly doesn't come anywhere near the miscommunication and whiffs of NIH that are present in the Dep case.
It still made me think of it, because in that thread there is a domain expert which lays out careful reasoning for the decision to place constant-time arithmetic inside big/int. Among some other discussion, the main hangup is about the placement of the code, and not any core maintainer is signalling go-ahead with any direction. The issuer author could of course continue to work out the existing strawman proposal, but that risks to be abandoned if the core maintainers turn out to change their mind.
Meanwhile, on March 19 2018 a core maintainer asks if "anybody want to fill out this proposal to see what changes would be required in math/big?", despite that the issue itself has an extensive PR with test suite which reveal most of the necessary changes. (either that or it refers to the Aug 17 2017 comment, but that seems to be exactly bford's proposal with a different public API)
Re: A response about dep and vgo
#10Earlier quoted context omitted.
I don't see the comparison you're drawing here. The question proposed in the Go issue is whether the standard bignum library in Go should be constant-time, whether crypto primitives should provide their own constant-time math, or whether a third library for constant-time bignum math should be added that all Go crypto can rely on. That's not an easy question, and meanwhile significant chunks of the bignum crypto code…
> I don't see the comparison you're drawing here. I think the similarity is as follows: - there is a desire to fix something that feels like a gap (in this case limited support of constant-time math in standard library) - there is a change proposal coming from the community - there are arguments why it should be included and some discussion if it belongs in a separate library or not - very little or no input from cor…
> which the author admits that it also could be a separate package
I don't think the similarity is all that apt.
If the core team is the limiting factor in the PR, and if there is a need for this, then why not just make the separate package and be done with it? If it is popular and core wants to merge it in at a different time, then great.