runtime/secret (Go 1.26): erasing secrets from core dumps + reproducible proof

[Cheikh Seck]

Go 1.26's runtime/secret (GOEXPERIMENT=runtimesecret) tags allocations inside secret.Do(f) for erasure — the right layer to stop secrets leaking into crash core dumps. Key takeaway: it marks, doesn't wipe — you must call runtime.GC() right after or you still leak, and it's a no-op off linux/amd64+arm64.

I built a reproducible harness (canary → SIGSEGV → scan the core): control leaks, secret doesn't. Repo + Dockerfile: https://github.com/cheikh2shift/go-snippets/tree/main/secret-demo

Writeup: https://towardsdev.com/runtime-secret-go-1-26s-answer-to-secrets-leaking-in-core-dumps-d884615e971f

[Duncan Harris]

I think you probably need to stop posting these articles to this group. It is not scalable. People will get annoyed.

[Cheikh Seck]

Ok

[Jason E. Aten]

Nah. To me, these are fine. They are both topical to Go and discuss novel aspects of Go programming, and are written fairly infrequently. I for one appreciate them and have learned about important topics like eBPF from them. They seems like appropriate use of go-nuts to me.

I could wish the articles didn't use AI without fact checking... but meh, humans make plenty of mistakes too.

[Cheikh Seck]

I usually try to fact check the best I can. At the same time, I believe this group is for new package releases and langauge features so it makes sense not to share on here.

[Cheikh Seck]

Also, disclaimer, writing these articles recently started as an experiment where I had an agent I built train itself on my most previously successful posts (2022)  and write in that style, voice and tone. The first few went unnoticed lol A friend recommended mentionning it was written by said agent as a selling point and case study for it.

[Jason E. Aten]

I don't think there is any consensus for Go users, but after RSC's analysis (link? my github search foo is failing me) I think the Go development team adopted his recommendation to not mention AI use in any git commit messages, no matter if an LLM was used or not. 

His analysis was long but in short that was, if I recall correctly, to a) not give the LLM manufacturers free advertising; and b) convey the expectation that the human whose name is on it is ultimately responsible for all of it, no matter what percentage of the commit was AI generated.

Moreover, I would add, c) these days most people will assume most things have some AI support -- even if there is none. And the accusations and refutations (seen constantly in some forums like Hacker News) is tiresome and not particularly interesting. So the same guideline makes sense to me -- for articles like yours. I expect you will use AI if you like, but mentioning your own AI in your articles was the only thing that struck me as a bit crassly commercial. As I said, I'd like to actively encourage writing on topics of interest to Go users -- I wish other folks were writing articles such as yours. But you don't need to advertise your AI model too. I don't want to speak for Duncan, but I have a hard time imaging the actual content was what he was objecting too.

Perhaps tangentially, it stikes me that one difficulty is that we most often use AI when we don't know the actual answer ourselves. That seems to be the best place (only place?) where it is extremely reasonable to point out that AI was used. "The AI said X but I have conflicting evidence Y, what is the right answer?" is something human experts will be doing alot of. It seems both un avoidable and natural to ask such questions.

But otherwise I have been favoring just leaving off attribution to any degree to the LLMs, for the reasons a, b, and c above. I don't want to advertise, and I need to take full accountability for the content anyway; and the discussion of whether or not something was LLM supported is boring and contributes little. To my way of thinking, mentioning AI use as a disclaimer comes out to the same thing as advertising--so I would avoid it. That said, if you AI model overlaps with Go in some way (was created with Go, uses Go, is tuned for Go specifically), then talking about it directly in one post seems perfectly reasonable. 

[Cheikh Seck]

I'll keep sharing the articles on the slack channel though. I'm learning a lot by working on 'em too.