Re: [go-nuts] Re: Changes to x509 in Go 1.18

The issue is here already: https://github.com/golang/go/issues/51991 - the causes seems to be already known. On Mar 29, 2022 at 12:34:44 AM, 'Jordan Liggitt' via golang-nuts < golang-nuts@googlegroups.com> wrote: > Do you have a standalone reproducer of a certificate go1.17 considered > valid

Re: [go-nuts] Allow a TCP connection, but not a TLS connection based on an ACL

Hey Sean and Robert, Thanks for the suggestions. I can see how the temporary error would work, but as Sean is saying, this is going to add delays that are going to go against what I'm wanting to do. Sean, I'm not sure I understand the part about looping my code. Here is a sample on the

[go-nuts] Re: Changes to x509 in Go 1.18

Do you have a standalone reproducer of a certificate go1.17 considered valid that go1.18 does not? If so, can you file an issue at https://github.com/golang/go/issues for investigation? On Thursday, March 24, 2022 at 2:10:10 AM UTC-4 Jim Idle wrote: > Having just upgraded to 1.18, I find that

Re: [go-nuts] Changes to x509 in Go 1.18

Jim, Looks like we ended up seeing the same problem in a kubernetes test case as well: https://github.com/kubernetes/kubernetes/issues/108956 -- Dims On Thu, Mar 24, 2022 at 2:09 AM Jim Idle wrote: > Having just upgraded to 1.18, I find that quite a few encrypted > connections, for instance

Re: [go-nuts] Changes to x509 in Go 1.18

Thanks for the additional info Jim. thanks! in our case it's a unit test that we could control, but we just got worried about things in the wild like your case for sure when we ship a go1.18 based kubectl. thanks, Dims On Mon, Mar 28, 2022 at 8:41 PM Jim Idle wrote: > Yes - look like it is for

Re: [go-nuts] Changes to x509 in Go 1.18

Yes - look like it is for slightly different reasons. Apple have decided on a new policy for verifying certificates and the certificate must have either two (younger certs) or three (older certs) valid SCTs. I suspect that you could re-issue your cert to comply with this, but I am not sure about

Re: [go-nuts] Allow a TCP connection, but not a TLS connection based on an ACL

abusing temporary delays like that could result in unpredictable performance with up to a second between accepts, not something you want if you are flooded with things you want to deny (which is what an ACL is for). On Mon, Mar 28, 2022, 23:46 robert engels wrote: > You just need to return a

Re: [go-nuts] Allow a TCP connection, but not a TLS connection based on an ACL

Ignore that last part - just use a “temporary” error. > On Mar 28, 2022, at 5:46 PM, robert engels wrote: > > You just need to return a temporary error. It should not be exiting anyway - > unless the “done” channel is valid. > > ctx := context.WithValue(baseCtx, ServerContextKey, srv) > for {

Re: [go-nuts] Allow a TCP connection, but not a TLS connection based on an ACL

You just need to return a temporary error. It should not be exiting anyway - unless the “done” channel is valid. ctx := context.WithValue(baseCtx, ServerContextKey, srv) for { rw, err := l.Accept() if err != nil { select { case <-srv.getDoneChan(): return

Re: [go-nuts] Allow a TCP connection, but not a TLS connection based on an ACL

I would just add a for loop around your code and only return when you have a connection you want to allow, otherwise just log / pass the error elsewhere. On Mon, Mar 28, 2022 at 11:26 PM John wrote: > I'm looking to satisfy this: > >- If you are in an ACL, you can make a TLS connection >

[go-nuts] Allow a TCP connection, but not a TLS connection based on an ACL

I'm looking to satisfy this: - If you are in an ACL, you can make a TLS connection - If you are not in an ACL, you can only a TCP connection, but not a TLS connection* ** It would be better if it didn't honor TCP either, unless it is a health probe* Basically I want to move my

[go-nuts] Re: Constraining a type parameter to implement an interface via pointer receiver

In parallel discussion in the "generics" channel of the "Gophers" Slack workspace, Roger Peppe was kind enough to point me to an example of the structural type constraint

[go-nuts] Re: Constraining a type parameter to implement an interface via pointer receiver

> > Should it be possible to write a type constraint that would allow me to > eliminate this projection function parameter, and instead have the compiler > mandate and ensure that for a given type E, the related type *E > implements Object? > I realized that this desire may be addressed by

[go-nuts] Constraining a type parameter to implement an interface via pointer receiver

I am working with a family of types that integrate with an existing Go project that follow a couple of patterns, and I'd like to manipulate them uniformly by introducing a generic function. My example uses a contrived, whittled-down set of struct fields and interfaces to demonstrate the

Re: [go-nuts] GO routine never exits based on stop condition - unable to find the reason

Great, thanks! On Mon, 28 Mar 2022 at 12:53, Steven Hartland wrote: > No problem, there's a nice little write up on it stackoverflow > > . > > On Mon, 28 Mar 2022 at 17:41, Gowtham Raj

Re: [go-nuts] GO routine never exits based on stop condition - unable to find the reason

No problem, there's a nice little write up on it stackoverflow . On Mon, 28 Mar 2022 at 17:41, Gowtham Raj wrote: > Hello Steven, > > Wow, this solved the problem. Never saw this pattern

Re: [go-nuts] GO routine never exits based on stop condition - unable to find the reason

Hello Steven, Wow, this solved the problem. Never saw this pattern before. Thanks for your help !! If you have any reference material for further reading for patterns like this can you please share them. Regards, Gowtham On Mon, 28 Mar 2022 at 12:21, Steven Hartland wrote: > There is no

Re: [go-nuts] GO routine never exits based on stop condition - unable to find the reason

There is no guarantee that the select chooses the done case, so you need to check in work case as well e.g. https://go.dev/play/p/zAj_qfO4uMA On Mon, 28 Mar 2022 at 16:54, Gowtham Raj wrote: > In this example, we have a *worker*. The idea here is simulate clean > shutdown of all go routines

Re: [go-nuts] GO routine never exits based on stop condition - unable to find the reason

1. your generator never finished 2. your work channel still has things in it, there's no guarantee select will choose done first 3. reading from a closed channel will give you a zero value On Mon, Mar 28, 2022, 16:53 Gowtham Raj wrote: > In this example, we have a *worker*. The idea here is

[go-nuts] GO routine never exits based on stop condition - unable to find the reason

In this example, we have a *worker*. The idea here is simulate clean shutdown of all go routines based on a condition. In this case, go routines get spun - based on workers count. Each go routine reads the channel, does some work and sends output to the outputChannel. The main go routine

Re: [go-nuts] Why is it forbidden to add methods to an existing type?

This works: n, _ := strconv.ParseInt(string(x), 10, 64) Go intentionally does no automatic type conversion, not even this: var a int32 = 1234 var b int64 = a// error: use int64(a) instead It would be inconsistent if passing "mystr" to a function which accepts

Re: [go-nuts] Looked at using Go ... nil/SEGV really bothered me .. Go2 Proposal?

On Mon, Mar 28, 2022 at 12:39 AM Sam Hughes wrote: > @Axel, I really did mean what I said. > So did I. FTR, if OP would have asked for changes to the type-system to be able to represent non-nilable types, my response would have been different. I didn't read their original message as asking for