Re: [go-nuts] Go routine context

['Axel Wagner' via golang-nuts]

Oh, following the link about Structured Concurrency at the end brings you
to https://openjdk.org/jeps/428
That *does* indeed seem to contain discussion about relevant topics.
Perhaps that's the link you intended to post?

On Sat, Oct 1, 2022 at 7:45 AM Axel Wagner 
wrote:

> I've at least skimmed the article and I can't find any of the arguments
> you say are there.
> For thread locals it says, if anything, that they should be avoided with
> virtual threads - at least for some uses (the ones that you'd use a
> sync.Pool for in Go). On coloring it only talks about the advantages of
> virtual threads over async/await, which, well most Gophers will agree with.
>
> Apart from these, I can't find anything that I could reasonably connect to
> context.Context - the article seems almost exclusively an introduction to
> virtual threads and an explanation on how they differ from operating system
> threads. In particular, I don't see anything in this article which could
> address the arguments Ian mentioned.
>
> It teases at more articles, about "Structured Concurrency" and "Extent
> local variables" - the latter sounds as if it *could* be what you talk
> about, but that article doesn't seem to exist yet.
>
> On Sat, Oct 1, 2022 at 6:15 AM Robert Engels 
> wrote:
>
>> Again, please read the paper. The arguments you make are refuted. The
>> lack of routine context is a burden on the Go ecosystem and makes debugging
>> highly concurrent Go systems far more difficult than similar systems in
>> Java.
>>
>> On Sep 30, 2022, at 11:09 PM, Rob Pike  wrote:
>>
>> 
>> One of the critical decisions in Go was not defining names for
>> goroutines. If we give threads/goroutines/coroutines (TGCs) names or other
>> identifiable state, such as contexts, there arises a tendency to push
>> everything into one TGC. We see what this causes with the graphics thread
>> in most modern graphics libraries, especially when using a
>> threading-capable language such as Go. You are restricted in what you can
>> do on that thread, or you need to do some sort of bottlenecking dance to
>> have the full language available and still honoring the requirements of a
>> single graphics thread.
>>
>> One way to see see what this means: Long ago, people talked of a "thread
>> per request"  model, and honestly it was, or would have been, an
>> improvement on standard practice at the time. But if you have cheap TGCs,
>> there is no need to stop there: You can use multiple independently
>> executing TGCs to handle a request, or share a TGC between requests for
>> some part of the work (think database access, for example). You have *the
>> whole language available to you* when programming a request, including
>> the ability to use TGCs.
>>
>> Like Ian, I have not read this paper, but I take it as a tenet that it is
>> better to keep goroutines anonymous and state-free, and not to bind any
>> particular calculation or data set to one thread of control *as part of
>> the programming model*. If you want to do that, sure, go for it, but
>> it's far too restrictive to demand it *a priori* and force it on others
>> *.*
>>
>> -rob
>>
>>
>>
>> On Sat, Oct 1, 2022 at 1:39 PM Ian Lance Taylor  wrote:
>>
>>> On Fri, Sep 30, 2022 at 7:32 AM Robert Engels 
>>> wrote:
>>> >
>>> > Very interesting article came out recently.
>>> https://www.infoq.com/articles/java-virtual-threads/ and it has
>>> implications for the Go context discussion and the author makes a very good
>>> case as to why using the thread local to hold the context - rather than
>>> coloring every method in the chain is a better approach. If the “virtual
>>> thread aka Go routine” is extremely cheap to create you are far better off
>>> creating one per request than pooling - in fact pooling becomes an anti
>>> pattern. If you are creating one per request then the thread/routine
>>> becomes the context that is required. No need for a distinct Context to be
>>> passed to every method.
>>>
>>> I didn't read the article (sorry).
>>>
>>> In a network server a Go context is normally specific to, and shared
>>> by, a group of goroutines acting on behalf of a single request.  It is
>>> also normal for a goroutine group to manage access to some resource,
>>> in which case the context is passed in via a channel when invoking
>>> some action on behalf of some request.  Neither pattern is a natural
>>> fit for a goroutine-local context.
>>>
>>> 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/CAOyqgcWAfdc2Np2KA%2B2-U9Z5Hv7tdHGgJHWDTUg_6pbr%3D8jghg%40mail.gmail.com
>>> .
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop 

Re: [go-nuts] Go routine context

['Axel Wagner' via golang-nuts]

I've at least skimmed the article and I can't find any of the arguments you
say are there.
For thread locals it says, if anything, that they should be avoided with
virtual threads - at least for some uses (the ones that you'd use a
sync.Pool for in Go). On coloring it only talks about the advantages of
virtual threads over async/await, which, well most Gophers will agree with.

Apart from these, I can't find anything that I could reasonably connect to
context.Context - the article seems almost exclusively an introduction to
virtual threads and an explanation on how they differ from operating system
threads. In particular, I don't see anything in this article which could
address the arguments Ian mentioned.

It teases at more articles, about "Structured Concurrency" and "Extent
local variables" - the latter sounds as if it *could* be what you talk
about, but that article doesn't seem to exist yet.

On Sat, Oct 1, 2022 at 6:15 AM Robert Engels  wrote:

> Again, please read the paper. The arguments you make are refuted. The lack
> of routine context is a burden on the Go ecosystem and makes debugging
> highly concurrent Go systems far more difficult than similar systems in
> Java.
>
> On Sep 30, 2022, at 11:09 PM, Rob Pike  wrote:
>
> 
> One of the critical decisions in Go was not defining names for goroutines.
> If we give threads/goroutines/coroutines (TGCs) names or other identifiable
> state, such as contexts, there arises a tendency to push everything into
> one TGC. We see what this causes with the graphics thread in most modern
> graphics libraries, especially when using a threading-capable language such
> as Go. You are restricted in what you can do on that thread, or you need to
> do some sort of bottlenecking dance to have the full language available and
> still honoring the requirements of a single graphics thread.
>
> One way to see see what this means: Long ago, people talked of a "thread
> per request"  model, and honestly it was, or would have been, an
> improvement on standard practice at the time. But if you have cheap TGCs,
> there is no need to stop there: You can use multiple independently
> executing TGCs to handle a request, or share a TGC between requests for
> some part of the work (think database access, for example). You have *the
> whole language available to you* when programming a request, including
> the ability to use TGCs.
>
> Like Ian, I have not read this paper, but I take it as a tenet that it is
> better to keep goroutines anonymous and state-free, and not to bind any
> particular calculation or data set to one thread of control *as part of
> the programming model*. If you want to do that, sure, go for it, but it's
> far too restrictive to demand it *a priori* and force it on others*.*
>
> -rob
>
>
>
> On Sat, Oct 1, 2022 at 1:39 PM Ian Lance Taylor  wrote:
>
>> On Fri, Sep 30, 2022 at 7:32 AM Robert Engels 
>> wrote:
>> >
>> > Very interesting article came out recently.
>> https://www.infoq.com/articles/java-virtual-threads/ and it has
>> implications for the Go context discussion and the author makes a very good
>> case as to why using the thread local to hold the context - rather than
>> coloring every method in the chain is a better approach. If the “virtual
>> thread aka Go routine” is extremely cheap to create you are far better off
>> creating one per request than pooling - in fact pooling becomes an anti
>> pattern. If you are creating one per request then the thread/routine
>> becomes the context that is required. No need for a distinct Context to be
>> passed to every method.
>>
>> I didn't read the article (sorry).
>>
>> In a network server a Go context is normally specific to, and shared
>> by, a group of goroutines acting on behalf of a single request.  It is
>> also normal for a goroutine group to manage access to some resource,
>> in which case the context is passed in via a channel when invoking
>> some action on behalf of some request.  Neither pattern is a natural
>> fit for a goroutine-local context.
>>
>> 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/CAOyqgcWAfdc2Np2KA%2B2-U9Z5Hv7tdHGgJHWDTUg_6pbr%3D8jghg%40mail.gmail.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/CAD38A60-EE4B-4A76-9F7B-66A9939874F5%40ix.netcom.com
> 
> .
>

-- 
You received this 

Re: [go-nuts] Go routine context

[Robert Engels]

To clarify a point that not be obvious - all of the routines involved in 
handling the request are temporary and only live through the life of the 
request - which defacto makes their existence = context, so using a thread 
local is simply a shorthand for passing the context to every method invoked by 
the routine. 

> On Sep 30, 2022, at 11:12 PM, Robert Engels  wrote:
> 
> I disagree. I think if you read the article you’ll understand why. You need 
> to invert the context handling - the pattern you cite is exactly the pattern 
> the author describes but when you create the routines on demand and the 
> subordinate ones - the “thread” is the context and it removes the ugliness of 
> coloring every function in the path with a context variable. 
> 
> I think you’ll find the article interesting. It is certainly written by a CS 
> “god” that knows what he’s talking about. 
> 
>>> On Sep 30, 2022, at 10:39 PM, Ian Lance Taylor  wrote:
>>> 
>>> On Fri, Sep 30, 2022 at 7:32 AM Robert Engels  
>>> wrote:
>>> 
>>> Very interesting article came out recently. 
>>> https://www.infoq.com/articles/java-virtual-threads/ and it has 
>>> implications for the Go context discussion and the author makes a very good 
>>> case as to why using the thread local to hold the context - rather than 
>>> coloring every method in the chain is a better approach. If the “virtual 
>>> thread aka Go routine” is extremely cheap to create you are far better off 
>>> creating one per request than pooling - in fact pooling becomes an anti 
>>> pattern. If you are creating one per request then the thread/routine 
>>> becomes the context that is required. No need for a distinct Context to be 
>>> passed to every method.
>> 
>> I didn't read the article (sorry).
>> 
>> In a network server a Go context is normally specific to, and shared
>> by, a group of goroutines acting on behalf of a single request.  It is
>> also normal for a goroutine group to manage access to some resource,
>> in which case the context is passed in via a channel when invoking
>> some action on behalf of some request.  Neither pattern is a natural
>> fit for a goroutine-local context.
>> 
>> 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/CAOyqgcWAfdc2Np2KA%2B2-U9Z5Hv7tdHGgJHWDTUg_6pbr%3D8jghg%40mail.gmail.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/5FCE08D7-51D6-4104-91C5-6AD9B6EA880A%40ix.netcom.com.

Re: [go-nuts] Go routine context

[Robert Engels]

Again, please read the paper. The arguments you make are refuted. The lack of 
routine context is a burden on the Go ecosystem and makes debugging highly 
concurrent Go systems far more difficult than similar systems in Java. 

> On Sep 30, 2022, at 11:09 PM, Rob Pike  wrote:
> 
> 
> One of the critical decisions in Go was not defining names for goroutines. If 
> we give threads/goroutines/coroutines (TGCs) names or other identifiable 
> state, such as contexts, there arises a tendency to push everything into one 
> TGC. We see what this causes with the graphics thread in most modern graphics 
> libraries, especially when using a threading-capable language such as Go. You 
> are restricted in what you can do on that thread, or you need to do some sort 
> of bottlenecking dance to have the full language available and still honoring 
> the requirements of a single graphics thread.
> 
> One way to see see what this means: Long ago, people talked of a "thread per 
> request"  model, and honestly it was, or would have been, an improvement on 
> standard practice at the time. But if you have cheap TGCs, there is no need 
> to stop there: You can use multiple independently executing TGCs to handle a 
> request, or share a TGC between requests for some part of the work (think 
> database access, for example). You have the whole language available to you 
> when programming a request, including the ability to use TGCs.
> 
> Like Ian, I have not read this paper, but I take it as a tenet that it is 
> better to keep goroutines anonymous and state-free, and not to bind any 
> particular calculation or data set to one thread of control as part of the 
> programming model. If you want to do that, sure, go for it, but it's far too 
> restrictive to demand it a priori and force it on others.
> 
> -rob
> 
> 
> 
>> On Sat, Oct 1, 2022 at 1:39 PM Ian Lance Taylor  wrote:
>> On Fri, Sep 30, 2022 at 7:32 AM Robert Engels  wrote:
>> >
>> > Very interesting article came out recently. 
>> > https://www.infoq.com/articles/java-virtual-threads/ and it has 
>> > implications for the Go context discussion and the author makes a very 
>> > good case as to why using the thread local to hold the context - rather 
>> > than coloring every method in the chain is a better approach. If the 
>> > “virtual thread aka Go routine” is extremely cheap to create you are far 
>> > better off creating one per request than pooling - in fact pooling becomes 
>> > an anti pattern. If you are creating one per request then the 
>> > thread/routine becomes the context that is required. No need for a 
>> > distinct Context to be passed to every method.
>> 
>> I didn't read the article (sorry).
>> 
>> In a network server a Go context is normally specific to, and shared
>> by, a group of goroutines acting on behalf of a single request.  It is
>> also normal for a goroutine group to manage access to some resource,
>> in which case the context is passed in via a channel when invoking
>> some action on behalf of some request.  Neither pattern is a natural
>> fit for a goroutine-local context.
>> 
>> 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/CAOyqgcWAfdc2Np2KA%2B2-U9Z5Hv7tdHGgJHWDTUg_6pbr%3D8jghg%40mail.gmail.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/CAD38A60-EE4B-4A76-9F7B-66A9939874F5%40ix.netcom.com.

Re: [go-nuts] Go routine context

[Robert Engels]

I disagree. I think if you read the article you’ll understand why. You need to 
invert the context handling - the pattern you cite is exactly the pattern the 
author describes but when you create the routines on demand and the subordinate 
ones - the “thread” is the context and it removes the ugliness of coloring 
every function in the path with a context variable. 

I think you’ll find the article interesting. It is certainly written by a CS 
“god” that knows what he’s talking about. 

> On Sep 30, 2022, at 10:39 PM, Ian Lance Taylor  wrote:
> 
> On Fri, Sep 30, 2022 at 7:32 AM Robert Engels  wrote:
>> 
>> Very interesting article came out recently. 
>> https://www.infoq.com/articles/java-virtual-threads/ and it has implications 
>> for the Go context discussion and the author makes a very good case as to 
>> why using the thread local to hold the context - rather than coloring every 
>> method in the chain is a better approach. If the “virtual thread aka Go 
>> routine” is extremely cheap to create you are far better off creating one 
>> per request than pooling - in fact pooling becomes an anti pattern. If you 
>> are creating one per request then the thread/routine becomes the context 
>> that is required. No need for a distinct Context to be passed to every 
>> method.
> 
> I didn't read the article (sorry).
> 
> In a network server a Go context is normally specific to, and shared
> by, a group of goroutines acting on behalf of a single request.  It is
> also normal for a goroutine group to manage access to some resource,
> in which case the context is passed in via a channel when invoking
> some action on behalf of some request.  Neither pattern is a natural
> fit for a goroutine-local context.
> 
> 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/CAOyqgcWAfdc2Np2KA%2B2-U9Z5Hv7tdHGgJHWDTUg_6pbr%3D8jghg%40mail.gmail.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/FB087360-C923-4758-85CC-26410C5CECEE%40ix.netcom.com.

Re: [go-nuts] Go routine context

[Rob Pike]

One of the critical decisions in Go was not defining names for goroutines.
If we give threads/goroutines/coroutines (TGCs) names or other identifiable
state, such as contexts, there arises a tendency to push everything into
one TGC. We see what this causes with the graphics thread in most modern
graphics libraries, especially when using a threading-capable language such
as Go. You are restricted in what you can do on that thread, or you need to
do some sort of bottlenecking dance to have the full language available and
still honoring the requirements of a single graphics thread.

One way to see see what this means: Long ago, people talked of a "thread
per request"  model, and honestly it was, or would have been, an
improvement on standard practice at the time. But if you have cheap TGCs,
there is no need to stop there: You can use multiple independently
executing TGCs to handle a request, or share a TGC between requests for
some part of the work (think database access, for example). You have *the
whole language available to you* when programming a request, including the
ability to use TGCs.

Like Ian, I have not read this paper, but I take it as a tenet that it is
better to keep goroutines anonymous and state-free, and not to bind any
particular calculation or data set to one thread of control *as part of the
programming model*. If you want to do that, sure, go for it, but it's far
too restrictive to demand it *a priori* and force it on others*.*

-rob



On Sat, Oct 1, 2022 at 1:39 PM Ian Lance Taylor  wrote:

> On Fri, Sep 30, 2022 at 7:32 AM Robert Engels 
> wrote:
> >
> > Very interesting article came out recently.
> https://www.infoq.com/articles/java-virtual-threads/ and it has
> implications for the Go context discussion and the author makes a very good
> case as to why using the thread local to hold the context - rather than
> coloring every method in the chain is a better approach. If the “virtual
> thread aka Go routine” is extremely cheap to create you are far better off
> creating one per request than pooling - in fact pooling becomes an anti
> pattern. If you are creating one per request then the thread/routine
> becomes the context that is required. No need for a distinct Context to be
> passed to every method.
>
> I didn't read the article (sorry).
>
> In a network server a Go context is normally specific to, and shared
> by, a group of goroutines acting on behalf of a single request.  It is
> also normal for a goroutine group to manage access to some resource,
> in which case the context is passed in via a channel when invoking
> some action on behalf of some request.  Neither pattern is a natural
> fit for a goroutine-local context.
>
> 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/CAOyqgcWAfdc2Np2KA%2B2-U9Z5Hv7tdHGgJHWDTUg_6pbr%3D8jghg%40mail.gmail.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/CAOXNBZRTgLSos4CXjHRV6zgu-8eLjxn2mYHjo%3DXMmw-Td4gz6g%40mail.gmail.com.

Re: [go-nuts] Go routine context

[Ian Lance Taylor]

On Fri, Sep 30, 2022 at 7:32 AM Robert Engels  wrote:
>
> Very interesting article came out recently. 
> https://www.infoq.com/articles/java-virtual-threads/ and it has implications 
> for the Go context discussion and the author makes a very good case as to why 
> using the thread local to hold the context - rather than coloring every 
> method in the chain is a better approach. If the “virtual thread aka Go 
> routine” is extremely cheap to create you are far better off creating one per 
> request than pooling - in fact pooling becomes an anti pattern. If you are 
> creating one per request then the thread/routine becomes the context that is 
> required. No need for a distinct Context to be passed to every method.

I didn't read the article (sorry).

In a network server a Go context is normally specific to, and shared
by, a group of goroutines acting on behalf of a single request.  It is
also normal for a goroutine group to manage access to some resource,
in which case the context is passed in via a channel when invoking
some action on behalf of some request.  Neither pattern is a natural
fit for a goroutine-local context.

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/CAOyqgcWAfdc2Np2KA%2B2-U9Z5Hv7tdHGgJHWDTUg_6pbr%3D8jghg%40mail.gmail.com.

[go-nuts] Re: Encrypting credentials config file in production and pseudo key rotation

[Brian Candler]

I'm not sure what your threat model is, but I note that if you dump both 
the encrypted data and the key to the filesystem, then the original secret 
data is trivially recoverable.  And with most filesystems, if you delete a 
file, the data is still recoverable.

I would suggest using an external secret manager like Hashicorp Vault.  You 
give your application some credentials (at the simplest an AppRole, which 
is essentially a username and password), which it uses to authenticate to 
the Vault server, obtain a token, and then retrieve the secret data.  It 
then keeps this in RAM only (as presumably it would have done anyway).

Of course, you have to decide whether there is a threat that the attacker 
can break into the application and get hold of the AppRole credentials.  
However an AppRole can be bound to an IP address so that it can't be 
re-used elsewhere, and more importantly you will have an audit log of every 
time the secret was fetched - so if it was fetched when the application 
*wasn't* restarted, this can set off alarm bells.

There are lots of other ways your application can authenticate to Vault 
. For example if it's running in one 
of the big public clouds, then it can use its cloud identity.

Not saying this fits all use cases, but you might want to consider this 
rather than a roll-your-own.

On Friday, 30 September 2022 at 17:34:29 UTC+1 Ivan Buljan wrote:

> Hello World
>
> This relates to that never ending question of securing the credentials in 
> production/staging envs, that is, avoiding storing them as plain text
>
> I am wondering if anyone could share their thoughts about the following 
> approach we are thinking of taking.
>
> Here we go:
>
> During build phase, an encryption key is generated and credentials are 
> encrypted with it.
>
> Once deployed, the instance decrypts credentials with the provided key and 
> does what it needs with them. Just before destroying the original files 
> (creds & key), the instance then generates a new encryption key and 
> re-encrypts a copy of credentials, which it keeps in memory. Newly 
> encrypted credentials along with the key are only dumped onto a filesystem 
> if the application panics and requires to be restarted, at which point the 
> same cycle key rotation decryption/encryption happens again.
>
> Is any security benefit with such approach?
>
>
>

-- 
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/d6eabf99-3da0-42eb-bead-c2eddc471db7n%40googlegroups.com.

[go-nuts] Encrypting credentials config file in production and pseudo key rotation

[Ivan Buljan]

Hello World

This relates to that never ending question of securing the credentials in 
production/staging envs, that is, avoiding storing them as plain text

I am wondering if anyone could share their thoughts about the following 
approach we are thinking of taking.

Here we go:

During build phase, an encryption key is generated and credentials are 
encrypted with it.

Once deployed, the instance decrypts credentials with the provided key and 
does what it needs with them. Just before destroying the original files 
(creds & key), the instance then generates a new encryption key and 
re-encrypts a copy of credentials, which it keeps in memory. Newly 
encrypted credentials along with the key are only dumped onto a filesystem 
if the application panics and requires to be restarted, at which point the 
same cycle key rotation decryption/encryption happens again.

Is any security benefit with such approach?


-- 
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/1340d748-5284-493d-9c94-7b5844ba1a62n%40googlegroups.com.

Re: [go-nuts] How is the relationship between package version and tag, and what is the formation mechanism?

[roger peppe]

Hi,
This is documented in the Go module documentation here:
https://go.dev/ref/mod#vcs-version
  cheers,
rog.


On Thu, 29 Sept 2022 at 18:29, 'Jinchang Hu' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> When we use go list -m dependencyName@Version to get the specific
> information of the version of the dependency package, does the Version and
> the tag of the dependency in github.com correspond, which tags will be
> recognized by the go language, and allow us to pass the go list command Get
> specific information.
>
> --
> 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/b0124d51-8a6d-4ff7-9de4-632545193a17n%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/CAJhgacgArvqaupmJrzDuFibt%3D%3D3RoJPZzaNrk6xydJHckdw_xA%40mail.gmail.com.

Re: [go-nuts] Go routine context

[Robert Engels]

Java has an InheritableThreadLocal for that very reason - that is automatically 
propagated and the child can subsequently override if needed. 

> On Sep 30, 2022, at 9:43 AM, Ian Davis  wrote:
> 
> 
>> On Fri, 30 Sep 2022, at 3:32 PM, Robert Engels wrote:
>> Very interesting article came out recently. 
>> https://www.infoq.com/articles/java-virtual-threads/ and it has implications 
>> for the Go context discussion and the author makes a very good case as to 
>> why using the thread local to hold the context - rather than coloring every 
>> method in the chain is a better approach. If the “virtual thread aka Go 
>> routine” is extremely cheap to create you are far better off creating one 
>> per request than pooling - in fact pooling becomes an anti pattern. If you 
>> are creating one per request then the thread/routine becomes the context 
>> that is required. No need for a distinct Context to be passed to every 
>> method. 
> 
> I don't think it is usual to pool goroutines. Normal usage is to spin one up 
> for each incoming request, which is the pattern used by Go's http server for 
> example.
> 
> I skimmed the article but my knowledge of Java's thread local storage is 
> limited. In Go it's common for requests to spawn subrequests in their own 
> goroutines. With a context you would derive a child context, potentially with 
> a shorter lifetime. What is the equivalent in thread local storage? Is there 
> a way to access parent thread storage from a child (analogous to how a child 
> context has access to all the values assigned to the parent)?
> 
> 
> -- 
> 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/b35520c7-87b2-4b83-be1b-2d2f4257d283%40app.fastmail.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/306D782C-C506-46BD-BBC3-1B336AEE3367%40ix.netcom.com.

Re: [go-nuts] Go routine context

[Ian Davis]

On Fri, 30 Sep 2022, at 3:32 PM, Robert Engels wrote:
> Very interesting article came out recently. 
> https://www.infoq.com/articles/java-virtual-threads/ and it has implications 
> for the Go context discussion and the author makes a very good case as to why 
> using the thread local to hold the context - rather than coloring every 
> method in the chain is a better approach. If the “virtual thread aka Go 
> routine” is extremely cheap to create you are far better off creating one per 
> request than pooling - in fact pooling becomes an anti pattern. If you are 
> creating one per request then the thread/routine becomes the context that is 
> required. No need for a distinct Context to be passed to every method. 

I don't think it is usual to pool goroutines. Normal usage is to spin one up 
for each incoming request, which is the pattern used by Go's http server for 
example.

I skimmed the article but my knowledge of Java's thread local storage is 
limited. In Go it's common for requests to spawn subrequests in their own 
goroutines. With a context you would derive a child context, potentially with a 
shorter lifetime. What is the equivalent in thread local storage? Is there a 
way to access parent thread storage from a child (analogous to how a child 
context has access to all the values assigned to the parent)?

-- 
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/b35520c7-87b2-4b83-be1b-2d2f4257d283%40app.fastmail.com.

[go-nuts] Go routine context

[Robert Engels]

Very interesting article came out recently. 
https://www.infoq.com/articles/java-virtual-threads/ and it has implications 
for the Go context discussion and the author makes a very good case as to why 
using the thread local to hold the context - rather than coloring every method 
in the chain is a better approach. If the “virtual thread aka Go routine” is 
extremely cheap to create you are far better off creating one per request than 
pooling - in fact pooling becomes an anti pattern. If you are creating one per 
request then the thread/routine becomes the context that is required. No need 
for a distinct Context to be passed to every method. 

-- 
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/1353D084-58D1-4586-B0F9-1A1A9669ED24%40ix.netcom.com.

[go-nuts] Re: Creating and Accessing DLL methods in GO

[Brian Candler]

> is go-plugin supported by Windows?

If you mean go's own plugin system, then no: https://pkg.go.dev/plugin 
(sorry, I should have remembered that)

If you mean the go-plugin library from Hashicorp: I believe it should be 
fine.  It's used by Hashicorp Vault, and Vault supports Windows:
https://www.vaultproject.io/downloads

So I'd say it's very likely it does.  Besides, it uses gRPC, and that is 
generic across platforms.

> We want to create go dll and tey to access through go code

You haven't said *why* you want to do this.  There may be a better solution 
to what you're trying to achieve.

-- 
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/d46d6b49-ffe7-4262-8df7-3d4a13c7a448n%40googlegroups.com.

[go-nuts] Re: go program import ?

[alex-coder]

Hi,

I have found data necessary to me there:
go/build.Default.GOROOT in case someone is in interest.

Thank you.

четверг, 29 сентября 2022 г. в 20:59:50 UTC+3, alex-coder: 

> Hi All,
>
> How I could detect programmatically that import in a go code
> belongs to a go distribution ?
>
> thank you very much for the answer.
>

-- 
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/2cef1dbd-a226-43d1-8be3-b6b899e64881n%40googlegroups.com.

[go-nuts] Go implementation of CLP

[ChrisLu]

Seems there are no Go implementation for Compressed Log Processor (CLP) 
yet? 

CLP is a tool capable of losslessly compressing text logs and searching the 
compressed logs without decompression.

https://github.com/y-scope/clp

Chris

-- 
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/a5be674c-0be9-4ee3-88f2-bf8d40549fcdn%40googlegroups.com.