Re: [go-nuts] Security implications of exposed Go runtime anon pipes

On Linux, you can interfere with any process via the process filesystem typically mounted at /proc in several creative ways, given you have access rights to a particular process. CAP_SYS_PTRACE isn't just for the ptrace syscall, but also for access inside /proc. The open file descriptors of Lin

Re: [go-nuts] Golang ORM Performances

Hello, I am actually scared by the fact to implement a bigger DB application on plain code level and tend rather to use a ORM. Reason for that is that doing all DB access methods in the application language (Go or Java) tends to a codebase where you have SQL code snippets scattered over in your

Re: [go-nuts] Security implications of exposed Go runtime anon pipes

On Thu, Jan 9, 2025 at 10:22 AM Moritz Sanft wrote: > > Thanks for your swift response. Let me clarify some things that I didn't seem > to convey well in my initial question. > > Probably the most important; I'm not looking to disclose a vulnerability in > Go here. If I was to disclose that, I w

Re: [go-nuts] Security implications of exposed Go runtime anon pipes

Hey Ian! Thanks for your swift response. Let me clarify some things that I didn't seem to convey well in my initial question. Probably the most important; I'm not looking to disclose a vulnerability in Go here. If I was to disclose that, I would use the points of contact you've mentioned. I'm

Re: [go-nuts] Security implications of exposed Go runtime anon pipes

On Thu, Jan 9, 2025 at 9:16 AM Moritz Sanft wrote: > > I've recently came across a Go application with an arbitrary file write > vulnerability restricted to `/proc/self`. After researching for a little, > I've found the following article which exploits such a vulnerability in a > NodeJS applica

Re: [go-nuts] Golang ORM Performances

My statement will be unpopular fact. My workplace using gorm for application with avg 3k qps. Even at some point its exponentially increase to around 50k (campaign event). Its a big project. Never had issue caused by gorm specifically. On Thu, Jan 9, 2025, 9:41 PM Mike Schinkel wrote: > On Jan

[go-nuts] Security implications of exposed Go runtime anon pipes

Hey there! I've recently came across a Go application with an arbitrary file write vulnerability restricted to `/proc/self`. After researching for a little, I've found the following article which exploits such a vulnerability in a NodeJS application, escalating it into remote code execution by

Re: [go-nuts] Golang ORM Performances

> On Jan 8, 2025, at 11:56 PM, Henry wrote: > > I am not aware of any SQL wrapper in Go, but then I didn't look hard enough. > At work, we implemented our own SQL wrapper for a few databases we commonly > work with. In .Net, you have LINQ, but LINQ is a query-only language. But the > idea is t

Re: [go-nuts] "go-import" is great, we need "go-delete"

How about a flag for 'go list' making the transaction log on sum.golang.org optional? Or, how about just let users run their own: sum.wit.com # my own immutable transaction log. I don't see how this helps with your initial request to delete modules

[go-nuts] Re: Performance: Restrictions on arguments in registers in SSA implementation

+1 that spills (and moving structures from registers to stack is essentially spills) should be decided by a specialized pass (register allocator), not during SSA build. Relying on a heuristic to do "pre-spilling" is, IMHO, a design flaw. @Arseny Samoylov, I wonder if you tried to disable this r