Yes I did. Sorry all. > On Jun 26, 2020, at 7:42 PM, Sebastien Rosset <[email protected]> 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 <[email protected]> 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 <[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/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 [email protected]. > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/4000E6BA-2727-404A-886E-A3B15A8BB2BB%40ix.netcom.com.
