Yes I did. Sorry all. 

> On Jun 26, 2020, at 7:42 PM, Sebastien Rosset <sros...@gmail.com> wrote:
> 
> 
> Did you reply to the wrong thread?
> 
>> On Friday, June 26, 2020 at 3:09:42 PM UTC-7, Robert Engels wrote:
>> What about an option to disable the signal on the thread as it crosses the 
>> CGo boundary? This seems better than disabling the async preemption entirely?
>> 
>>>> On Jun 26, 2020, at 4:45 PM, Sebastien Rosset <sro...@gmail.com> wrote:
>>>> 
>>> 
>>> 
>>> Below are the publicly exposed asn1.ObjectIdentifier fields in the 
>>> golang/go repo. It has fairly limited exposure,
>>> but I'm sure some people will argue it's too much (maybe ok in go 2.x but 
>>> not 1.x?).
>>> encoding/asn1:
>>> My guess is this would be primarily used by SNMP applications such as 
>>> https://github.com/soniah/gosnmp/search?q=asn1&unscoped_q=asn1
>>> crypto/x509/pkix package has 4 exported fields using asn1.ObjectIdentifier
>>> crypto/x509 package:
>>>  ECDSA keys
>>>  Used in the x509.Certificate struct:
>>> // A Certificate represents an X.509 certificate.
>>> type Certificate struct {
>>>   ...
>>>   UnhandledCriticalExtensions []asn1.ObjectIdentifier
>>>   UnknownExtKeyUsage []asn1.ObjectIdentifier
>>>   PolicyIdentifiers []asn1.ObjectIdentifier
>>> }
>>> 
>>> I doubt there are many applications that actually inspect these 3 fields.
>>> 
>>> 
>>> 
>>>> On Friday, June 26, 2020 at 12:53:43 PM UTC-7, Sebastien Rosset 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.
>>>> 
>>>>> 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 golan...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/39bf626a-ed31-4c89-bc0f-a685927e7046o%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/8a0157a1-aea2-489e-99ce-42e5c135a61do%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/4000E6BA-2727-404A-886E-A3B15A8BB2BB%40ix.netcom.com.

Reply via email to