[Confiks]

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

[tptacek]

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

[c2h5oh]

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

[mbreese]

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

[c2h5oh]

I'm not aware of a way to plug your own crypto to a lot of things that are part of standard library and I'm not aware of a way to plug your own math library to existing crypto.

[jessaustin]

Would they take PRs for adding that bit of plugability?

[tptacek]

Probably not.

[agnivade]

I think your expectations from huge open source projects are a bit too much. There are over 3500 issues open currently as of this moment, and new issues get opened every 15-20 minutes. The Go core team is like 10 people. That being said -

> - very little or no input from core team

I simply don't see this being true. Apart from OP (who is expected to comment a lot, because it is his proposal), the thread has comments from Robert Griesemer, Russ Cox, Austin Clements, Adam Langley and many others.

> - the whole process is stalled waiting for core team to participate

Again, not true. See Ian's and Russ' last comment. It is actually waiting on further information.

All that being said, instead of complaining how there is no response on a thread by the core team, maybe you can contribute by answering the questions Russ and Ian has raised, and ping others as needed.

[Confiks]

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)