On Fri, Jun 26, 2020 at 12:54 PM Sebastien Rosset <[email protected]> wrote: > > As an aside, the most common use of the encoding/asn1 package is most likely > crypto/x509. x509. Certificate exposes public fields that use the > asn1.ObjectIdentifier, so asn1 ends up being exposed in a lot of > applications, such as for TLS connection management.
True, but will those packages be affected by a change in the encoding/asn1 API? When I said that the package was not widely used I should have said that not many other packages import it, and thus not many other packages are affected by any changes. I shouldn't have implied that only a few Go programs import it at all. Ian > On Friday, June 26, 2020 at 12:04:09 PM UTC-7, Sebastien Rosset wrote: >> >> sure, thank you. I will go through the PR review process for asn1 and x509, >> maybe some good ideas will come up. >> Sebastien >> >> On Friday, June 26, 2020 at 11:51:05 AM UTC-7, Ian Lance Taylor wrote: >>> >>> On Fri, Jun 26, 2020 at 11:03 AM Sebastien Rosset <[email protected]> wrote: >>> > >>> > @ianlancetaylor , thank you for the quick reply. The reason I was asking >>> > is because potentially this could have been used to fix `type >>> > ObjectIdentifier []int` in the `encoding/asn1` package and the >>> > `crypto/x509` package. Currently these package are not fully compliant >>> > with the ASN.1 specification, which means in practice some certificates >>> > cannot be parsed. >>> > >>> > >>> > I am trying to fix the encoding/asn1 and crypto/x509 package by adding >>> > support for OID values that are greater than 2^31. There are multiple >>> > ways to fix the issues, and unfortunately it won't be possible to simply >>> > change the ObjectIdentifier type because that would break too many >>> > applications. If it's not possible to change the type, then most >>> > alternatives seem to be somewhat cumbersome. For reference the PR is >>> > https://github.com/golang/go/pull/39795. >>> >>> Thanks, understood. >>> >>> Generics don't solve all problems. I agree that there seems to be a >>> way that we could modify generics to solve this particular problem. >>> But it means introducing an idea that the rest of the language has >>> decided to reject: default values for arguments. I don't think it >>> would be consistent with the language to permit default values for >>> type arguments when we do not permit default values for non-type >>> arguments. While we don't have to be strictly consistent here, I >>> think we need a good reason to break consistency. And in the larger >>> scheme of things I don't think that making it easier to make a >>> backward compatible change to one specific package, a package that is >>> not all that widely used, is a good enough reason. >>> >>> I'm not claiming to have the final word, but that is my opinion. >>> >>> Ian > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/a34c936f-b68e-4f63-aad2-47c0869f71e0o%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUzN4S%3Dm2Hr8kmStcLNe7HsDA62mJkcdg8-%2B-Xk7dHG8w%40mail.gmail.com.
