spyc

Both libexpat ("Expat") and uriparser are following the curl security vacation and will not accept new vulnerability reports before 2026-08-01, starting today.

[1] https://github.com/libexpat/libexpat/issues/1277

[2] https://github.com/uriparser/uriparser/issues/323

The current implementation breaks semantics of functions with tail recursion from within loops: https://github.com/raaidrt/tacopy/issues/1

Potentially the movie itself is also or more of interest. The related thread is: https://news.ycombinator.com/item?id=45056377

Both implementations of doas for Linux have (the same) unfixed security issue:

- https://github.com/Duncaen/OpenDoas/issues/106

- https://github.com/slicer69/doas/issues/110

I have a hard time recommending doas over sudo on Linux when the issue has been fixed in sudo but not in doas.

Lost trust for sure. Who knows if Redis would be AGPL now if Valkey did not exist.

If anyone wonders what atop looks like at runtime or what it would be useful for, there's a video dedicated to the tool at https://www.youtube.com/watch?v=27AtCR5ftyM .

I see, thanks!

Update: I found https://www.bismuth.sh/ at https://news.ycombinator.com/user?id=ianbutler .

I'm reading "I can go into why another time." like "I don't have time" personally, not like "I am not allowed to say".

Hi! Three things:

- There is no commit with a SHA1 like that in atop Git history and what you shared is too long for a SHA1, it looks more like a SHA256. Did you share the right checksum? The only other way I can read this is that it's a SHA256 checksum of one of the past atop release tarballs or artifacts. I have not yet checked those.

- I have tried finding your tool Bismuth but all I find is things KDE and crypto currencies. Please share a link to the Bismuth that you are working on.

- You technically said that you are working on Bismuth /and/ found something, not that you found the bug /through/ Bismuth. Please clarify if and how that was the case.

Thank you!

There are parsers that only implement a tiny subset of XML. And Expat has compile time flags to disable some of that machinery where not needed. It's arguably no longer XML then though.

Thank you!

Thanks for sharing that research!

"Quickly kill the process" is still a denial of service security problem.

Correct.

Did you see the article references [1][2] from 2006 and 2017 that already argue that recursion is a security problem? It's not new just not well-known.

[1] https://www.researchgate.net/publication/220477862_The_Power...

[2] https://www.qualys.com/2017/06/19/stack-clash/stack-clash.tx...

That idea works in general but causes false positives: No artificial limit you pick is "right" and the false positives can be avoided by getting rid of the recursion altogether.

PS: It's not one single function, not direct but indirect recursion.

The point of termination is beyond stack overflow here, that's the problem. And unlike heap, stack does not tell you gently that it's running out.

Not if you need to report the same thing to multiple parties. And why make it hard to someone who does whitehat work for you.

That's not a good reason to not host the file.

People who spent hours finding the right security contacts for companies without luck would likely disagree. The key failure is not the single missing file, but that security contacts are too hard to find and the effect that has.

The way I read https://lore.kernel.org/stable/20231205122122.dfhhoaswsfscuh... 6.5+ should be okay. PS: Please correct me if not!

Could you share your source on how/when/if O_DIRECT is required? Have a link?

The backing Git repository is at https://github.com/MegaManSec/Squid-Security-Audit

One way would be not using "cmake --build" but invoking make directly yourself after calling CMake.

The list is about Video Game Randomizers, so maybe not.

Exactly.

Where is the "chance" part in that picture? Are you saying you envy a chance of burnout?

If that's truthful news, it is truly disgusting. Maybe helps some fanboys of Elon to finally wake up.

Glad you like it.