So im using linux desktops for decades now, and bout 2 years ago i finally ditched my for gaming only windows install to go onto linux only setups for gaming also.
I mean, it works alot better than it did before, still i wouldn't recommend it for someone who isn't ready to tinker in order to make stuff work.
The point why i mention this is, while most normal desktop/coding stuff works okay with wayland, as soon i try any gaming its just a sh*show. From stuff that doesn't even start (but works when i run on x) to heavyly increased performance demands from games that work a lot smoother on x.
While i have no personal relation to any of both, and i couldn't technically care less which of them to use - if you are into gaming, at least in my experience, x is rn still the more stable solution.
My post is very contrary to the most here but maybe there is someone else in a similar situation so i think it may be worth writing it.
Background: I've spend the bigger part of the past 20 years of my life continously extending and enhancing my technical knowledge and skills, mostly in IT/Coding but also in some other fields. Meanwhile i kinda let my social life completely degrade and also always care more about solving others problems than my actual own problems.
Therefor the "skills" i want to improve and develop in 2026:
- Learn to take care of myself instead of always putting others first (its not my job to safe the world)
- Don't try to got 150% all of the time and rather slow down
- Care for my health
- Get back into social life
- Actually try to not spend 95% of my free time in front of a screen and go outside (touch grass)
While i accumulated alot of knowledge over the past two decades, if i don't start to care for myself more ill probably won't have much benefit of it other than having accumulated it. Health (biological and mental) are important, neglecting it maybe works shortterm but will kick your ass longterm.
11/10 would read. So much clickbait going around (and lets ignore the articles that "magicly" are upvoted but strangewise have no comments whatsoever.... not sus at all....
Really nice finding for such a young folk - really liked reading into it.Also what i love most about it is what an actually simple vuln it is.
Tho what i find mostly funny bout it is how many people are complaining about the 4k$.
I mean sure the potential "damage" could have been alot higher, tho at the same time there was no contract in place or , at least as far as i understood, a clear bug bounty targeted. This was a, even if well done, random checking of XHR/Requests to see if anything vulnerable can be found - searching for kinda file exposure / xss / RFI/LFI. So everything paid (and especially since this is a mintlify bug not an actual discord bug) is just a nice net gain.
Also ill just drop here : ask yourself, are you searching for such vulns just for money or to make the net a safer place for everyone. Sure getting some bucks for the work is nice, but i personally just hope stuff gets fixed on report.
Funny idea, some days ago i was really annoyed again by the idea that these AI crawlers still ignore all code licenses and train their models against any github repo no matter what so i quickly hammerd down this
basically a github action that extends your README.md with a "polymorphic" prompt injection. I run some "llm"s against it and most cases they just produced garbage.
Thought about also creating a JS variant that you can add to your website that will (not visible for the user) also inject such prompt injections to stop web crwaling like you described
Ok, i kinda get the idea, and with some modification it might be quite handy - but i wonder why its deemed like an "unsolvable" issue right now.
It may sound naive, but packages which include data like said session related or any other that should not persist (until the next Global GC) - why don't you just scramble their value before ending your current action?
And dont get me wrong - yes that implies extra computation yada yada - but until a a solution is practical and builtin - i'd just recommend to scramble such variables with new data so no matter how long it will persist, a dump would just return your "random" scramble and nothing actually relevant.
It is fundamentally not possible to be in complete control of where the data you are working with is stored in go. The compiler is free to put things on the heap or on the stack however it wants. Relatedly it may make whatever copies it likes in between actions defined in the memory model which could leak arbitrary temporaries.
Yeah, .NET tried to provide a specific type related to this concept (SecureString) in the past and AFAIK there were were two main problems that have caused it to fall into disuse;
First one being, it was -very- tricky to use properly for most cases, APIs to the outside world typically would give a byte[] or string or char[] and then you fall into the problem space you mention. That is, if you used a byte[] or char[] array, and GC does a relocation of the data, it may still be present in the old spot.
(Worth noting, the type itself doesn't do that, whatever you pass in gets copied to a non-gc buffer.)
The second issue is that there's not a unified unix memory protection system like in windows; The windows implementation is able to use Crypt32 such that only the current process can read the memory it used for the buffeer.
Hard to understand what you’re asking. This is the solution that will practical and built-in. This is a summary of a new feature coming to Go’s runtime in 1.26.
without language level support, it makes code look like a mess.
Imagine, 3 level nesting calls where each calls another 3 methods, we are talking about 28 functions each with couple of variables, of course you can still clean them up, but imagine how clean code will look if you don't have to.
Just like garbage collection, you can free up memory yourself, but someone forgot something and we have either memory leak or security issues.
There are two main reasons why this approach isn't sufficient at a technical level, which are brought up by comments on the original proposal: https://github.com/golang/go/issues/21865
1) You are almost certainly going to be passing that key material to some other functions, and those functions may allocate and copy your data around; while core crypto operations could probably be identified and given special protection in their own right, this still creates a hole for "helper" functions that sit in the middle
2) The compiler can always keep some data in registers, and most Go code can be interrupted at any time, with the registers of the running goroutine copied to somewhere in memory temporarily; this is beyond your control and cannot be patched up after the fact by you even once control returns to your goroutine
So, even with your approach, (2) is a pretty serious and fundamental issue, and (1) is a pretty serious but mostly ergonomic issue. The two APIs also illustrate a basic difference in posture: secret.Do wipes everything except what you intentionally preserve beyond its scope, while scramble wipes only what you think it is important to wipe.
While in my case i had a program in which i created an instance of such a secret , "used it" and than scrambled the variable it never left so it worked.
Tho i didn't think of (2) which is especially problematic.
Prolly still would scramble on places its viable to implement, trying to reduce the surface even if i cannot fully remove it.
As I understand it, this is too brittle. I think this is trivially defeated if someone adds an append to your code:
func do_another_important_thing(key []byte) []byte {
newKey := append(key, 0x0, 0x1) // this might make a copy!
return newKey
}
key := make([]byte, 32)
defer scramble(&key)
do_another_important_thing(key)
// do all the secret stuff
Because of the copy that append might do, you now have 2 copies of the key in data, but you only scramble one. There are many functions that might make a copy of the data given that you don't manually manage memory in Go. And if you are writing an open source library that might have dozens of authors, it's better for the language to provide a guarantee, rather than hope that a developer that probably isn't born yet will remember not to call an "insecure" function.
This proposal is worse because all the valuable regions of code will be clearly annotated for static analysis, either explicitly via a library/function call, or heuristically using the same boilerplate or fences.
Makes sense basically creating an easy to point out pattern for static analysis to find everything security related.
As another response pointed out, its also possible that said secret data is still in the register, which no matter what we do to the curr value could exist.
> Makes sense basically creating an easy to point out pattern for static analysis to find everything security related.
This is essentially already the case whenever you use encryption, because there are tell-tale signs you can detect (e.g., RSA S-Box). But this will make it even easier and also tip you off to critical sections that are sensitive yet don't involve encryption (e.g., secure strings).
yes, you now have to deal in pointers, but that's not too ugly, and everything is stored in secretStash so can iterate over all the types it supports and thrash them to make them unusable, even without the gc running.
I'm now wondering with a bit of unsafe, reflection and generics magic one could make it work with any struct as well (use reflection to instantiate a generic type and use unsafe to just overwrite the bytes)
This is, in a rather short period of time, the second time that an ovh scheduled database upgrade leaded to hanging instances, this time paired with the information that database backups are not reachable.
While the page claims that the incident is resolved, this is far from true and there are multiple users also experiencing still stuck/non accessible database instances.
Can maybe anyone else confirm they also experience this ?
Cuz of exactly this reason i couldnt find any solution like that for me yet, so i started building my own one. I think the only way something like this is practical is in an on-premise scenario
Since it runs locally on my machine not really much :) im working always on the same machine therefor i don't need any online hosting for my work notes.
I mean, it works alot better than it did before, still i wouldn't recommend it for someone who isn't ready to tinker in order to make stuff work.
The point why i mention this is, while most normal desktop/coding stuff works okay with wayland, as soon i try any gaming its just a sh*show. From stuff that doesn't even start (but works when i run on x) to heavyly increased performance demands from games that work a lot smoother on x.
While i have no personal relation to any of both, and i couldn't technically care less which of them to use - if you are into gaming, at least in my experience, x is rn still the more stable solution.