On Fri, Jun 26, 2020 at 12:54 PM Sebastien Rosset <sros...@gmail.com> 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 <sro...@gmail.com> 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 golang-nuts+unsubscr...@googlegroups.com.
> 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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUzN4S%3Dm2Hr8kmStcLNe7HsDA62mJkcdg8-%2B-Xk7dHG8w%40mail.gmail.com.

Reply via email to