Notices by hanno (hanno@mastodon.social)

@david_chisnall I mean... they made a staggeringly bad call on EternalBlue, which led to WannaCry, so the third option seems plausible. However, I think reviewing code and missing a bug in an obscure feature and missing that it's enabled by default is also not implausible.

Hot take: DKIM signatures with ed25519 are largely useless🔥🔑

I know what you're thinking. RSA is bad. You read that blogpost with the "f" word. (It's not good.) This isn't about ed25519 vs. RSA, but about how DKIM works

Here's the problem: if you introduce a new crypto algorithm into a protocol, you need to know if the other side" supports it. But in DKIM, you don't. You're sending e-mails to arbitrary receivers. DKIM has no mechanism to tell you if that receiver supports any algorithm.
🧵

@dalias I think in both vulnerability cases it was in ESP (esp{4,6} modules for IPv4/v6). But AH is also "something from IPSEC", so I disabled that as well. I'm not super familiar with IPSEC beyond "it's something I do not use and do not need"...

Hey, we have another linux kernel local root exploit in IPSEC. If you build your own kernels: you probably don't need ipsec, disable INET{6,}_{ESP,AH}.

AI, a few thoughts, observations about AI & security vulns.
My standard line about AI is "there's a lot I'm uncertain about". But let's be clear, there's a lot I don't like & I'm probably biased towards the "here's how spectacularly AI failed once again" news (of which there are plenty) or at least the "it's not as impressive as it may look".
Yet, I don't want to close my eyes if I see things that clearly don't fit my biases. And I know a thing or two about security vulnerabilities.🧵

Something else happened, and that was *very* recently. Those reports grew in numbers.
if I see 1-2 valid reports in a major open source lib from an AI tool, I'm not impressed. If I had enough funding, I could find valid vulns in a variety of ways.
When the Mozilla/Antropic thing came out, that was what I was thinking. "Yeah, these are real bugs, but you know, if I had infinite funding like Antropic, and a team of top security people, you know how many bugs I could find in Firefox?"

The most visible thing how AI impacted security vulnerabilities early on were slop reports. Famously, @bagder shared plenty of experiences with AI written garbage reports.
But there's another more recent development. Real, and valuable security reports show up. I heard those starting early this year. Those were single instances, but they were clearly showing that there are companies out there developing tools that spit out real vulnerabilities, with proof of concepts, and sometimes even patches.

FWIW: I don't have a big conclusion here, I'm just sharing random thoughts and observations. /end thread

But that wasn't an isolated development either. It's clearly showing up everywhere. I'm running out of reasons not to think that AI tools got really good at finding security vulnerabilities.

Obvious caveat: None of that changes that there are plenty of good reasons to be very worried about the whole AI thing.

Ihr sorgt Euch über den hohen Krankenstand? Wir haben da vor ein paar Jahren ein paar Dinge gelernt, wie man Infektionskrankheiten vermeidet. Impfungen, Luftfilter, Homeoffice, Masken, ...
Es ist schon bizarr, wie das komplett nicht Teil der Diskussion dazu ist.

@dalias for what it's worth, I couldn't get this to work. But it seems there's some subtlety, trap command having different usage depending on shell, etc.
For now, it appears putting apache in the back and having "sleep inf" as the main command seems the most pragmatic solution (in case I'm not missing some downside I haven't yet learned about).

@dalias how would I do that practically? can you block a signal in a shell script or does that have to be a c wrapper or something alike?

Today, the issue showed up again, this time with my debugging code showing me the logfiles before shuttiing down the container:
"AH00170: caught SIGWINCH, shutting down gracefully"

What is SIGWINCH? It is a signal for "window change", aka, I resized the terminal window. Ok... that makes some sense that I would observe this occasionally, but not reproducibly, and resizing a terminal is certainly not something I had expected as the cause. But... why?

Mysterious bug from hell: I noticed that a Docker container running an Apache web server was sometimes shutting down for no apparent reason, but rarely enough that it was difficult to reproduce. After adding some debugging (given this shuts down the container there was no way to access the logs afterwards easily) and waiting for the issue to show up again.

🧵

I guess there's some way to workaround this... just have to figure out how.

But... certainly unexpected, and given that "run thing in the foreground in your container" is pretty common stuff these days, maybe Apache should reconsider that decision...

I mean, why does apache, A WEB SERVER THAT SHOULD NOT DISPLAY MUCH ON THE TERMINAL AND CERTAINLY HAS NO GUI TO REDRAW, care when I resize my terminal?
Turns out, as you can read here https://stackoverflow.com/a/787509/3780436 or in their bug tracker (however, they locked down their bugtracker and you cannot even read it without registration) that, apparently, apache decided to reuse the SIGWINCH signal as you usually don't run apache in the foreground...

For what it's worth: this also happens with the official Dockerhub httpd image...
So I guess they haven't found a workaround yet either...

Reported: https://github.com/docker-library/httpd/issues/280

Anyone got a recommendation for a good web search engine? The one I used to use has decided to pivit towards providing a chatbot with a crappy search engine attached that isn't really working properly.

I really don't have any idea what they're doing at google. I had a recent instance where I was searching for a filename that was on an open source mirror in plenty of places, and Google said it knows nothing about it... there's, like, zero possiblity they don't have any of the mirror dirlistings indexed.