261–270 of 347 posts
Earlier quoted context omitted.
Looks like Focal (20.04) isn't on an affected version. Jammy (22.04) looks like it is.
What about, uh, 18.04? Edit: 18.04 Bionic is unaffected, the ssh version is 7.6 which is too old.
Earlier quoted context omitted.
What's the advantage of this relatively obscure tool compared to something standard like wireguard or stunnel?
* The tool is not obscure, it's packaged in most distributions.[1][2][3] It was written and maintained by Colin Percival, aka "the tarnsnap guy" or "the guy who invented scrypt". He is the security officer for FreeBSD. * spiped can be used transparently by just putting a "ProxyCommand" in your ssh_config. This means you can connect to a server just by using "ssh", normally. (as opposed to wireguard where you need to…
Why are we all still running an ssh server written in an unsafe language in 2024?
What is the better working alternative?
Earlier quoted context omitted.
This isn't the case for OpenSSH but because a lot of environments (essentially all managed runtimes) actually do this transparently for you when you register a signal "handler" it might be that less people are aware that actual signal handlers require a ton of care. On the other hand "you can't even call strcmp in a signal handler or you'll randomly corrupt program state" used to be a favorite among practicing C lawy…
Why can't you call strcmp? I think a general practice of "only call functions that are explicitly blessed as async-signal-safe" is a good idea, which means not calling strcmp as it hasn't been blessed, but surely it doesn't touch any global (or per-thread) state so how can it corrupt program state? Update: according to https://man7.org/linux/man-pages/man7/signal-safety.7.html strcmp() actually is async-signal-safe a…
Earlier quoted context omitted.
Not always, 36C3 - A systematic evaluation of OpenBSD's mitigations https://www.youtube.com/watch?v=3E9ga-CylWQ
Wouldn't a good systematic evaluation need (or at least benefit from) a few actual working exploits/PoCs? I keep asking this as a long-time OpenBSD user who is genuinely interested in seeing it done, but so far everyone who has said "it's flawed" also reserved themselves the convenience of not having to prove their point in a practical sense.
Earlier quoted context omitted.
> Oh, SEL4 is without any doubt useful, it wouldn't be as popular and coveted if it wasn't, but I think you are trying to say widespread. There is a laptop running OpenIndiana illumos on my desk. I mean useful, though through the lens of my usecases (read: if it can't run a web browser or server, I don't generally find it useful). I've only really heard of seL4 being popular in embedded contexts (mostly cars?), not g…
> I mean useful, though through the lens of my usecases Better to stick to standard definitions in the future so you won't have to explain your personal definitions later on. > No, I think your examples were excellent for illustrating the differences in systems; you can get a more secure system by severely limiting how much it can do So you not only missed the point but decided to take away an entirely different mess…
Earlier quoted context omitted.
> Okay, let's say if you know something useful with a better record. Oh, SEL4 is without any doubt useful , it wouldn't be as popular and coveted if it wasn't, but I think you are trying to say widespread . However, you seem to have taken my examples literally and missed my point, which is trying to judge the security of an OS by its vulnerabilities is a terrible, terrible approach. > but it does include everything o…
> Oh, SEL4 is without any doubt useful, it wouldn't be as popular and coveted if it wasn't, but I think you are trying to say widespread. There is a laptop running OpenIndiana illumos on my desk. I mean useful, though through the lens of my usecases (read: if it can't run a web browser or server, I don't generally find it useful). I've only really heard of seL4 being popular in embedded contexts (mostly cars?), not g…
I mean, OpenBSD does security mitigation sealioning, so nobody really wants to engage with their stupider ideas
Earlier quoted context omitted.
> I mean useful, though through the lens of my usecases Better to stick to standard definitions in the future so you won't have to explain your personal definitions later on. > No, I think your examples were excellent for illustrating the differences in systems; you can get a more secure system by severely limiting how much it can do So you not only missed the point but decided to take away an entirely different mess…
You're not being serious if you are suggesting Plan 9 as a more secure OS than OpenBSD.
Earlier quoted context omitted.
That sounds... familiar. Are you perchance the maintainer of SnakeYAML? Yes, it is correct to file a CVE of the highest priority against your project, because "only intended for processing data from trusted sources" is a frankly ridiculous policy for a serialization/deserialization library. If it's your toy project that you never expected anyone to use anyway, you don't care about CVEs. If you want to be taken seriou…
> "only intended for processing data from trusted sources" is a frankly ridiculous policy for a serialization/deserialization library. Truly, it's a design decision so ridiculous nobody else has made it. Except Python's pickle, Java's serialization, Ruby's Marshal and PHP's unserialize of course. But other than that, nobody!