This has been an issue in the past, where NGINX disagreed with a CVE being assigned, but a CVE is the easiest way to get a vulnerability fixed across the ecosystem and in the distributions that distribute NGINX.
Each time something is silently fixed it takes much longer and is much harder to actually get the fix approved/backported/whatever is necessary to get it fixed.
Long answer: Most DBs key on lastname, so MegaZone is my last name, officially, and I have no first name. Then I leave the first name blank if it'll let me, but more often I need to put something in there - so these days I use 'MZ' as that's what I have people call me. I used to use 'Mr', and I still need to use that on some government forms so everything will match up.
License and passport have no first name and MegaZone for a last name.
My SSN Card has 'Mr MegaZone' - when I changed it, back in 2000, the SSA said their computers just could not handle a blank first name. They wanted to put in something like NFN MegaZone, FNU MegaZone, etc. (No First Name, First Name Unknown) I suggested 'Mr' because it tickled me to make the government call me Mister MegaZone. ;-)
Airline tickets are something where I use Mr MegaZone. I have Global Entry/PreCheck, and even though my IDs have no first name, the ticketing systems do NOT like that. So my PreCheck stuff is under Mr MegaZone. I made the mistake if booking once under MZ MegaZone, and even though all my PreCheck info was on there, it didn't work and I got stuck in the normal security line. Lesson learned.
My passport does break other systems sometimes - I go on cruises with my wife and they, of course, base things on your passport. So I usually end up as FNU MegaZone, which leads to hilarity as crew members try to pronounce 'FNU' as a name. Usually once I'm onboard I can get into the system and edit things, but such is life.
This seems like mostly a non-issue, since this module isn't compiled by default. I guess it's good to fix it regardless, but it seems unnecessary to issue a security advisory/CVE for this. HTTP/3 is an experimental feature in nginx that isn't built by default and isn't included in most distribution builds.
I'm a novice at nginx and using modules. how do I figure out if the nginx docker images that I use are effected by this? it looks like the default image uses `debian:bookworm-slim`. is it safe to assume that the compiled version in that upstream image isn't using any additional modules?
> The issues affect nginx compiled with the ngx_http_v3_module (not
compiled by default) if the "quic" option of the "listen" directive
is used in a configuration file.
The official nginx docker images ship with HTTP3 module enabled - and we have released the updated ones earlier today - so please update to stay secure.
You can also launch something like:
$ docker run -ti --rm nginx:latest nginx -V
to check which modules are compiled in to the binary you're running.
https://news.ycombinator.com/item?id=39373327