DEV Community: Iain

PHP says to count form parts at the proxy. It can't

Iain — Fri, 23 Oct 2026 15:25:44 +0000

PHP shipped fixes on 21 October for PHP2Shell, two bugs that let a request from anyone run code on the server. Updating is the fix. For anyone who can't yet, the php.net announcement has a list of stopgaps, and one of them is aimed at whatever sits in front of PHP:

Consider enforcing limits at the web server or proxy level for decoded request size, input field
count, multipart part count, header count, and nesting depth. These limits must also cover
requests without a usable Content-Length.

php.net, 21 October

The first bug needs PHP to run out of memory partway through a request, and an upload form with loads of parts, or loads of headers inside one part, is a cheap way to get it there. The GitHub advisory says to keep these limits even after patching, as they "reduce hard OOM and denial of service risk".

I went looking for the nginx setting that counts parts, and there isn't one. So I put nginx, Apache httpd, Caddy, HAProxy and Traefik in front of a little Python backend that just counts what turns up, plus the two open-source WAFs, ModSecurity and Coraza, each with the OWASP Core Rule Set. Then I sent the same harmless forms through all of them: 20,000 one-letter fields, 5,000 empty file inputs, a field name 100 brackets deep, a part with 10,000 made-up headers and so on. Nothing vulnerable behind any of it.

What each layer stopped (the data)

Multipart forms, stock settings plus a size cap, 23 October. Both WAFs run the Core Rule Set. A
tick or a number means it stopped forms past that. Headers are the ones inside one part, depth is
how many brackets deep a field name goes, and ModSecurity's parts leave out real file uploads. PHP
is 8.4.27, and rather than refuse the request it just drops whatever's over.

Size is the bit they can all do (mostly)

Every proxy has a body size limit, and that's where most of the advice I've read stops. nginx, Caddy and Traefik all turned away a 12 MB body with an 8 MB cap, with a Content-Length or chunked.

HAProxy's usual size check is a deny on the Content-Length header, which is what I used, and a chunked request doesn't have one, so the 12 MB walked through. Its own manual says req.body_size only sees what's in the buffer when the body's chunked. That's exactly the "without a usable Content-Length" case php.net asks you to cover.

Apache's size cap skips php-fpm

Apache was the odd one. LimitRequestBody is its size cap, and through ProxyPass the 12 MB went straight past an 8 MB limit. Same with php-fpm behind SetHandler "proxy:fcgi://...". Here's httpd 2.4.69 with LimitRequestBody 8388608, a text file, and a PHP script that prints how much body it got:

$ curl -s -o /dev/null -w "%{http_code}\n" --data-binary @12mb.bin localhost:8096/plain.txt
413
$ curl -s --data-binary @12mb.bin localhost:8096/len.php
cl=12582912 got=12582912

Same server, same limit. The text file gets a 413, and PHP gets all 12 MB.

The docs used to warn you. Up to 2.4.53 they said LimitRequestBody had "limited applicability to proxy requests". 2.4.54, the release that set the default to 1 GB, took that line out, but 2.4's code still switches the limit off for any proxied request. The fix for that went into trunk in 2018 and hasn't come back to 2.4.

With mod_php there's no proxying, so the limit works, and that's the setup php.net rates riskiest. With php-fpm behind Apache, your real size cap is PHP's own post_max_size.

PHP counts most of it already

php.net never mentions it, but PHP has its own setting for everything on that list except the headers, and the counts are on by default. max_input_vars is 1,000, max_input_nesting_level is 64, and max_multipart_body_parts works out as max_input_vars plus max_file_uploads, so 1,020. Here's PHP 8.4.27 getting a 5,000-field form:

Warning: PHP Request Startup: Input variables exceeded 1000. To increase
the limit change max_input_vars in php.ini.
Warning: PHP Request Startup: Multipart body parts limit exceeded 1020.
To increase the limit change max_multipart_body_parts in php.ini.

It keeps the first thousand and carries on. The advisory says the working exploit ran "with default PHP input and memory limits", so the defaults clearly aren't low enough, and it asks you to lower nesting and bound the rest. Turn them down to what your app actually takes. With these, PHP kept 100 fields and dropped the other 4,900:

max_input_vars = 100
max_multipart_body_parts = 100
max_input_nesting_level = 8

Headers in a part is the one PHP has no setting for. The patched releases only keep two from each part, Content-Disposition and Content-Type, so after updating it mostly stops being PHP's problem. Until then, it's down to whatever's in front.

A WAF needs telling

None of the five proxies looks inside a form at all, which makes sense, as none of them parse one. The WAFs do, but not for this.

ModSecurity turned away the 5,000- and 20,000-field forms with "Failed to fully parse request body due to large argument count", a rule in its own recommended config that trips at 1,000 fields. The Core Rule Set has a field-count rule too, but it's off until you set a number. Empty file inputs count as fields, so 5,000 of those got stopped as well. Headers in a part it doesn't count at all, and one part with 10,000 of them went through with every header delivered.

Coraza (inside Caddy) let all 20,000 fields through. The only thing that stopped a pile of headers was Go's own multipart reader, which gives up past 10,000 in one part, and 20 parts of 9,000 each got through fine.

Both will count them if you ask, though. Their rule language has &MULTIPART_PART_HEADERS, the number of part headers in the request:

SecRule &MULTIPART_PART_HEADERS "@gt 500" \
    "id:1001,phase:2,deny,status:413,msg:'too many part headers'"

That stopped 1,000 headers in one part on both WAFs. It counts every part header in the whole request rather than per part, so three parts of 200 trips it too.

That works in your favour, since every part has at least one header, so it caps parts as well. Coraza went from letting 5,000 parts through to a 413. A file input sends two headers (Content-Disposition and Content-Type), so set it a bit over twice the fields in your biggest real form.

SOCFortress published the same idea yesterday in their PHP2Shell rule pack, set at 100 and only for multipart, along with one for nesting. I tried a version of that one on both WAFs too, and it blocked a field name 12 brackets deep and let 11 through:

SecRule ARGS_POST_NAMES|FILES_NAMES "@rx (?:\[[^\]]*\]){12}" \
    "id:1002,phase:2,deny,status:413,msg:'name nested too deep'"

nginx can count, in JavaScript

nginx has no directive for any of it, but njs, nginx's own JavaScript module, got a form parser in 0.9.9, and js_access runs it before the request goes anywhere. This lets everything through except a multipart form it won't parse:

async function form(r) {
  const type = r.headersIn['Content-Type'] || '';
  if (!/^multipart\/form-data/i.test(type)) return;

  try {
    await r.readRequestForm({ maxKeys: 200 });
  } catch (e) {
    r.warn(`form rejected: ${e.message}`);
    r.return(413);
  }
}

export default { form };

load_module modules/ngx_http_js_module.so;

http {
  js_import gate from /etc/nginx/gate.js;

  server {
    client_max_body_size 8m;

    location / {
      js_access gate.form;
      proxy_pass http://backend;
    }
  }
}

On nginx 1.31.8 with njs 1.0.2 it let 200 fields through and turned 201 away, and the form still reached the backend whole after njs had read it. It only looks at multipart, like the WAF rule, so a big urlencoded form is still PHP's max_input_vars to deal with. It does nothing about nesting either, since a[x][x][x] is just a name to it.

The headers took care of themselves. njs won't take more than 32 in a part (Content-Disposition included), so 33 gets a 413 without you asking, and that's baked into the parser rather than a setting. It's a separate module, nginx-module-njs, which the official Docker image already has, apart from the -slim ones.

Pickle-only uploads to Hugging Face doubled since 2024

Iain — Fri, 23 Oct 2026 13:54:59 +0000

Hugging Face is getting more pickle files, not fewer. In the second half of 2024, about one in seventeen people uploading model weights each month put up nothing but pickles. Since March it's been about one in eight.

Pickle-only share of new Hugging Face models (the data)

Each uploader counted once a month. Pickle only means .pt, .pth, .ckpt or .pkl with no
safetensors, GGUF or ONNX alongside, ignoring trainer leftovers. Course and swarm uploads left
out.

That matters because a pickle runs code when you load it, and safetensors doesn't. Safetensors is what transformers writes, and the old pickles on the Hub are meant to be leftovers from before it caught on.

The numbers come from hub-stats, a daily dump of every public repo on the Hub with its file list, as of 21 October. I counted uploaders rather than repos, because one person can push a thousand repos in an afternoon. I also left out the Hugging Face RL course's LunarLander and Huggy models, and Gensyn's BlockAssist, which had over 9,000 people uploading pickled checkpoints from the same app last autumn. Leave those in and October 2025 reads 32%.

It peaked at 15% in May and has slipped every month since, which I'll come back to.

Most of them load with weights_only

Since PyTorch 2.6, torch.load only unpickles tensors and a short list of harmless types unless you tell it otherwise. If these files load that way, the pickle doesn't really matter.

I took one pickle-only repo with a PyTorch checkpoint (.pt, .pth or .ckpt) from each of 114 uploaders, picked at random from everything created between August and 21 October, and read the pickle inside the biggest checkpoint without running it. That's just Python's pickletools over a few ranged requests, so no downloading gigabytes and nothing gets executed. Then I checked everything it asks to import against torch's list.

What's inside 114 new pickle-only models (the data)

One repo per uploader, read on 22 October. Each square is about one percent. Tensors only means it
loads with weights_only=True.

89 of them are a state_dict and maybe an epoch number, and load fine with weights_only on.

The other 25 won't load. Ten of those are over something boring, like a numpy float for the best accuracy or the argparse settings from training. Here's torch 2.14 on the numpy one, trimmed:

Weights only load failed. [...]
  (1) [...] Re-running `torch.load`
  with `weights_only` set to `False`
  will likely succeed, but it can
  result in arbitrary code execution.
  [...]
  (2) Alternatively, to load with
  `weights_only=True` please check
  the recommended steps in the
  following error message.
  WeightsUnpickler error: Unsupported
  global: GLOBAL
  numpy._core.multiarray.scalar was
  not an allowed global by default.
  [...]

The proper fix is option two, torch.serialization.add_safe_globals([...]) with the one numpy type it names. Option one is turning the protection off, it's listed first and it says it'll "likely succeed". I'd guess that's the one most people pick, but I've no way of checking that.

Another seven pickle a class from whatever they were trained with, like a LeRobot policy config, a DeepSpeed object or a model class from the uploader's own code, so they won't load at all without that code installed.

YOLO turns it off for you

The last eight are YOLO models pickled whole, Ultralytics classes and all, usually called best.pt. My favourite spots Xbox controllers. You'd load one with YOLO("best.pt"), and you never see torch's error, because Ultralytics' loader calls torch.load with weights_only=False unless you've asked otherwise. Since June there's been an opt-in safe mode that loads them with weights_only=True and an allowlist of Ultralytics' own classes:

ULTRALYTICS_SAFE_LOAD=1 python detect.py

Without it, a stranger's best.pt runs whatever's in it, on the latest torch and the latest Ultralytics.

None of the 114 files I read asks for anything nasty like os or eval. It's people saving whatever was lying around at the end of training. But you can't tell without looking inside, and most people look inside by loading it.

The newcomers brought them

Between July 2024 and July 2025, about 1,100 people a month uploaded a pickle-only model. From March to September this year it was 3,300 a month, while everyone uploading weights went from about 14,000 to 22,000. Only about one in twelve of this year's pickle uploaders had uploaded any weights in the first seven months of 2025.

Four in five of their repos don't say what library they're for. Looking through them, it's YOLO detectors, crop disease classifiers, robot policies, RVC voice models, research checkpoints and a lot of coursework. torch.save(model, "best.pt") and push.

They don't seem to get many downloads, though that's hard to pin down. The Hub only counts a download for a repo with no library when someone fetches its config file, and most of these haven't got one. Where it can count them, the pickle-only repos made between March and September got about 0.2% of the last 30 days' downloads of everything new from those months. This is the long tail, the stuff you land on from a search, a paper or a tutorial.

It's slipped since May

May was 15.1%, then 14.0, 13.0, 12.5 and 12.3 in September. The first two weeks of October are about 8%, and that's not because the month's half finished, since the same days read the same in a snapshot from five days earlier.

Some of October is a wave of new people. Nearly 2,000 more a week than September's average uploaded weights, most of it safetensors, under names like tiny-transformer and cnn-transformer that look a lot like a new term. But pickle-only uploaders fell too, from about 850 a week in September to about 730, and last October the share went up rather than down. I'm not sure what's going on there.

One domain seller is 6% of the HSTS preload list

Iain — Fri, 23 Oct 2026 13:54:58 +0000

The HSTS preload list is the list of sites your browser will only ever load over HTTPS, before it's even visited them once. It's built into Chrome and Edge, and Firefox makes its own copy from it. You get on by serving HTTPS on every subdomain, sending one header and filling in a form, and the idea is that it's for sites that care about HTTPS enough to promise it for good.

I pulled Chromium's copy on 17 October and looked up all 95,147 entries, mostly out of nosiness about who's on it. The two addresses with the most names on them both belong to someone selling domains.

Who's on the HSTS preload list (the data)

Chromium's entries by the first IPv4 address they resolve to, 17 October 2026. Below the top two, every row is a host with lots of customers or one company's own sites. Cloudflare's behind far more than any of these, but spread over lots of addresses.

That's 5,691 entries between them, about one in every seventeen on the list. Pick one at random and you'll get a white page with the name in capitals, like "HAOMIN.COM MAY BE AVAILABLE!", a button to buy it on GoDaddy and "Proudly Powered by GKJ.com" at the bottom. GKJ's own site says "You came looking for a domain. We probably already own it", and puts the count at 5,000+. Who's registered them is redacted, so I'm going on their word that it's one seller.

I fetched them slowly in random order until the server started telling me to go away. 498 of the 511 that answered were that sale page, 7 more said "UNDER CONSTRUCTION" in the same style, and all 511 sent max-age=63072000; includeSubDomains; preload. There's nothing against the rules in that. When I ran 20 of them through Chromium's own checker this afternoon, all 20 said "Satisfies requirements".

Why a domain seller bothers, I don't know. The few pages the Wayback Machine kept from 2022 to 2024 come from the same kit, with the name in capitals over a slogan like "IN GOD WE TRUST", and the 2022 ones already sent the header. So my guess is it just comes with whatever makes the pages.

It does matter to whoever buys one, though. They get a domain that browsers will only load over HTTPS, and every subdomain under it too, so nas.theirname.com with a self-signed certificate on the home network won't load, because HSTS takes away the button that lets you click through the warning. Getting off the list means asking for removal and then waiting, which hstspreload.org reckons "may take 6-12 weeks to reach most Chrome users, and may take longer for other browsers". You can check any name first with curl "https://hstspreload.org/api/v2/status?domain=haomin.com", which says "status": "preloaded" for this one.

Chromium cut them twice

This seller's names on Chromium's list (the data)

How many of today's 5,691 names were on the list at the end of each month, January 2022 to October 2026.

Nine in ten of them went on in one bulk update in June 2022. In April 2023 Chromium pruned every domain that had "repeatedly failed to meet the continued requirements", which took out 41% of the list and 91% of this seller's names. They went back through the same form as everyone else, and most were back on within six months.

Then a bulk update in August 2025 did it again, cutting the list from 171,166 entries to 95,329 and the seller from over 5,500 to 405. Of 40 other names it removed, every one still fails today, mostly because nothing answers, so it wasn't a bad clear-out. It just took these with it, and 4,659 of the names on the list today have now been cut twice.

They were back within months again, and because that update cleared out so much else, this seller's now pretty much all of the list's growth. Since August 2025 the whole list has shrunk by 182 entries, while this one block grew by 5,286.

Firefox kept losing them

Firefox doesn't take Chromium's list as it is. A script visits every site on it about once a week and drops the ones that don't send the header.

Visiting thousands of sites on one server all at once is exactly what this server doesn't like. When I fetched all 5,691 at 64 at a time, nearly every answer was a 429 Too Many Requests, and not one of those had the header. So in Firefox they came and went depending on how the week's run went:

This seller's names on Firefox's list (the data)

Each update to Firefox's preload list since June 2026. Mozilla's fix went in on 5 October, between the 2 and 6 October updates.

Ryan VanderMeulen at Mozilla spotted it last month. In bug 2075853 he wrote that Chromium's list "holds thousands of domains of one hosting operator in a contiguous block, all served from two addresses", and that checking them in list order meant "the operator answered with 429 for thousands of hosts that otherwise send a valid header, which kept them off the preload list".

The fix landed on 5 October. The script now shuffles the list, tries 429s again at the end, and an error page without the header doesn't knock a site off anymore. Before that, a run where more of them got through, like 26 September's, was gone again the week after. Since then every update has kept what it had and added more, up to 2,275 on 16 October. That's still well short of 5,691, and the bug says why: "the operator still limits the rate over the run as a whole".

Chromium's checker gets waved through

I'd assumed Chromium's culls tripped over the same 429s. Its removal job checks every bulk entry weekly, only looks at the header and not the status code, and queues a domain for removal once it's failed for a month.

But Chromium's checker calls itself hstspreload-bot, so this evening I got the server annoyed with 300 quick requests, then asked ten more names for their page under four different User-Agents:

User-Agent	What came back	HSTS header
Chrome	429	no
Firefox	429	no
Googlebot	429	no
`hstspreload-bot`	200	yes

Same for all ten names. So the rate limit lets Chromium's checker straight through, and it's everyone else who gets the 429, Firefox included. What it did in 2023 and 2025 I can't tell, and the Wayback Machine won't show me enough from just before either cull to find out. They pass Chromium's checks now, and they were cut anyway.

Most sites that block curl only check its name

Iain — Fri, 23 Oct 2026 13:54:27 +0000

Here's chess.com this morning, with the same curl asking five times under different names:

$ for ua in curl/8.18.0 Curl/8.18.0 python-requests/2.32.5 Mozilla/5.0 \
    'myfetcher/1.0 (+https://example.org/bot)'; do
    curl -sL -o /dev/null -w "%{http_code}  $ua\n" -A "$ua" https://chess.com/
  done
403  curl/8.18.0
200  Curl/8.18.0
403  python-requests/2.32.5
200  Mozilla/5.0
200  myfetcher/1.0 (+https://example.org/bot)

A capital C gets you in. That one's chess.com being a bit lazy, and most sites aren't that easy, but the handshake is identical evey time, so the only thing it can be looking at is the name.

That's not what you'll usually hear. Ask why curl gets a 403 and the answer is TLS fingerprinting: big sites look at how your client shakes hands, curl looks nothing like Chrome, so changing the User-Agent won't get you far and you want curl-impersonate or a headless browser. Even Daniel Stenberg, who started curl, calls the User-Agent check "the original and much simpler way" of spotting bots.

That's true for some sites. I wanted to know how many, so I went through the Tranco top 10,000.

Two in three

I sent four clients at every homepage on 18 October, from my server: stock curl 8.18, the same curl with a Chrome 141 User-Agent and Chrome's Accept headers, the same curl calling itself myfetcher/1.0, and curl_cffi pretending to be Chrome right down to the TLS handshake.

The fake Chrome got a proper page from 5,874 of the 10,000. Of the rest, 1,508 blocked even that, which I'd guess is mostly about my server being in a datacentre, and most of the others just didn't answer. So read everything below as "sites that'll talk to a datacentre at all". The strictest ones aren't in it.

Stock curl got blocked at 703 of those 5,874, nearly all with a 403, and about two in five of those a Cloudflare challenge page. Give it Chrome's User-Agent and 451 of the 703 hand over the full page, which is 64%. The made-up myfetcher gets into 421, so 60%. stanford.edu, un.org, cnbc.com, zendesk.com and flightradar24.com are all in there.

It's not a fluke of the day either. Of 453 sites that only blocked the name in runs on 17 October, 441 still did today. A sample of inner pages and page titles from those runs matched what Chrome got, so these aren't stripped-down pages being waved through.

The closest count I could find is a paper on headless Chrome, where swapping HeadlessChrome for Chrome cleared 75% of the blocks that only hit headless Chrome. That's a real browser already, though, and I couldnt find anyone who'd tried it with curl.

So which names get in?

I took the 451 sites that let the Chrome User-Agent through and tried ten User-Agents on each, going by the status code this time:

Sites that let each User-Agent in (the data)

Share of the 451 sites that block curl but let a Chrome User-Agent in, 18 October

python-requests, Wget and Go's default client get turned away almost as often as curl, and so does sending no User-Agent at all. 96 of the sites seem to block "curl" anywhere in the string, as myfetcher/1.0 (curl) gets turned away where the honest one doesn't. Only 55 are like chess.com and miss Curl with a capital. The 2% for plain curl is seven sites that had started letting it in by then.

I didn't expect Mozilla/5.0 on its own to do so badly. It's what alot of advice tells you to use, and it only gets into a third of them. Something that reads like a polite bot gets into 85% of these 451, and Miniflux's feed reader string 88%. Feed readers seem fine generally, for what it's worth: of 153 feeds advertised on the top 2,000 homepages, 7 turned Miniflux away.

So if your script gets a 403, give it a name first. Anything that isn't a tool's default will do, and a URL in it is polite:

curl -A 'myfetcher/1.0 (+https://example.org/bot)' https://example.com/

Does it matter who's in front?

Quite a lot. I read the headers on each block to see whose edge sent it. That tells you who's in front of the site, not who wrote the rule, since a Cloudflare customer can block curl in thier own firewall rules without Cloudflare having any say. Here's the share of curl blocks that the Chrome User-Agent and myfetcher each got past (AWS is CloudFront and friends):

In front	Blocks	Chrome	myfetcher
Cloudflare	392	77%	78%
Akamai	130	23%	28%
AWS	57	82%	32%
Others	124	60%	51%

Behind Cloudflare it's mostly a name check, and any other name will do. Behind Akamai it's mostly the fingerprinting people warn you about, and three in four still won't give curl a page with a Chrome User-Agent on. Behind AWS it wants something that looks like a browser: Mercado Libre's sites, realtor.com and osha.gov let Chrome's string in and turn myfetcher away.

Akamai's also why the middle of the list does worse. Of the sites ranked 2,001 to 5,000 that block curl, only 46% let the Chrome string in, because Akamai's in front of 50 of those 169. Further down, from 5,001 to 10,000, it's in front of 55 of 401, and the Chrome string gets into 71%.

What about from somewhere else?

All of that is from one server in a datacentre. Last night I ran the 157 sites that blocked anything in the top 2,000 again through Cloudflare's WARP VPN, and through Tor. The Chrome User-Agent did a bit better on WARP (81% of curl blocks) and the same on Tor (72%) as from my server. About half the Akamai sites that blocked even the Chrome string from my server only checked the name on WARP, so the address counts as well as the name. I haven't tried it from home broadband, so that's the bit I can't tell you.

Don't fake Chrome by halves

There's a catch with the Chrome string. 79 sites served stock curl fine, then blocked the same curl as soon as it said it was Chrome. adobe.com, slack.com, cisco.com, intel.com, cdc.gov and opensource.org are on that list, and so is w3.org, so the W3C, who write a good chunk of the web's standards, will serve curl all day, just not curl claiming to be Chrome. 32 of the 79 are behind Akamai. My guess is the rule there is "says Chrome, doesn't shake hands like Chrome", which is exactly what curl with a Chrome User-Agent is.

61 of them still let myfetcher in. And it's partly the address again. 12 sites in the top 2,000 did this to my server. Over Tor, all seven I could reach still did, but over WARP only 3 of the 12 did.

So try the honest name first, and save the Chrome string for when that fails, or for anything behind AWS.

Skip the system prompt and the template writes one

Iain — Fri, 23 Oct 2026 13:53:56 +0000

I'd always assumed that if I leave the system prompt out, the model gets my message plus a few role markers round it, and that's it. That's what a chat template is for: the bit of Jinja that ships with a model and turns your list of messages into the one long string it actually reads.

So I sent Llama 3.1 8B Instruct a lone "Who made you?" through transformers, and printed the string:

<|begin_of_text|><|start_header_id|>system<|end_header_id|>

Cutting Knowledge Date: December 2023
Today Date: 26 Jul 2024

<|eot_id|><|start_header_id|>user<|end_header_id|>

Who made you?<|eot_id|><|start_header_id|>assistant<|end_header_id|>

That's a system block that I didn't write, telling the model that it's July 2024. I checkec my watch - todays the 19th of October 2026.

Over a quarter of them add something

I took the 300 most downloaded text generation models on Hugging Face today and rendered a single user message through each one's template, using transformers' own renderer. 189 have a template in the repo (most of the rest are GGUF files, which keep theirs inside, or base models). Then I stripped out the role markers, the special tokens and my message, and looked at what was left.

What 189 popular chat templates add to a lone user message (the data)

The top 300 text generation models on Hugging Face by downloads, 19 October 2026.

114 add nothing, which is what I'd expected from all of them. 23 add something bland, mostly "You are a helpful assistant" or a line setting how hard to think. But the other 52 tell the model who it is, who made it, when its training stopped, what today's date is, or what it's allowed to talk about.

28 of those 52 are one line, Qwen2.5's, repeated across its sizes and everybody's quantised copies of it (Qwen3 dropped it). Lots of the rest are copies too, and if you count each of the 96 different templates once, it's 20 of them that add a name, a date or a scope. So more like a fifth, but those are some of the biggest names on there:

Model	What it adds when you don't
Qwen2.5 7B Instruct	You are Qwen, created by Alibaba Cloud. You are a helpful assistant.
gpt-oss 20B	You are ChatGPT, a large language model trained by OpenAI. Knowledge cutoff: 2024-06 Current date: 2026-10-19
Granite 3.3 2B	Knowledge Cutoff Date: April 2024. Today's Date: October 19, 2026. You are Granite, developed by IBM.
Kimi K2 Instruct	You are Kimi, an AI assistant created by Moonshot AI.
DeepSeek Coder 7B v1.5	You only answer questions related to computer science. For politically sensitive questions, security and privacy issues... you will refuse to answer

So OpenAI's open model calls itself ChatGPT, and a coding model is told not to talk about security. None of it's hidden, it's all in the repo, but you'd only know if you went and read the template.

July 2024 is written into Llama's

Most templates that mention a date ask for today's with strftime_now, a function whatever's running the model is meant to supply. Meta's Llama 3.1 and 3.3 templates do this instead:

{%- if not date_string is defined %}
    {%- set date_string = "26 Jul 2024" %}
{%- endif %}

That's three days after 3.1 came out. If the runner passes a date the model gets that, and if it passes nothing it's 26 July 2024 forever. That's the official Llama 3.1 8B Instruct, downloaded 5.5 million times in the last month, and the quantised copies I checked carry the same file. Llama 3.2 switched to strftime_now, so it gets today.

So does anything pass a date? Same bare message, Meta's 3.1 template, today:

Run with	Told the date is
transformers	26 Jul 2024
vLLM 0.32	26 Jul 2024
llama.cpp's llama-server	19 Oct 2026
Ollama 0.40, `ollama pull llama3.1`	Nothing, no system block at all
Ollama 0.40, a GGUF you imported	19 Oct 2026

(No GPU here, so each runner got a tiny test model wearing the real template, and for vLLM that's its template renderer called directly.) llama.cpp sets date_string to today on every render, and vLLM doesn't set it anywhere. Ollama's own llama3.1 isn't Meta's template at all but a Go one, which only opens a system block when you send a system prompt or tools. Import a GGUF that carries Meta's Jinja, though, and Ollama hands it to its bundled llama-server, which puts today in.

Qwen2.5's line came through transformers and llama-server the same, and Ollama's qwen2.5 ships it as the model's default system prompt.

Your own system prompt only fixes half of it

For Qwen2.5, passing any system message switches the default off, even an empty one:

<|im_start|>system
<|im_end|>

Llama 3.1 is different. Send "Be brief." as the system prompt and the template keeps the stale date and puts yours underneath it:

Cutting Knowledge Date: December 2023
Today Date: 26 Jul 2024

Be brief.

Unless your runner fills it in like llama-server does, you have to pass date_string yourself. In transformers it's another argument to apply_chat_template. vLLM takes it in chat_template_kwargs on the request, which it hands to the template:

{ "chat_template_kwargs": { "date_string": "19 Oct 2026" } }

The model mostly knew already

I wanted to see the DeepSeek Coder refusal for real, so I ran the 1.3B version (same line in its template) with the default and with an empty system message. It happily answered questions on storing passwords in Flask, SQL injection and setting up ufw either way, in nearly the same words. It turned down "What is the capital of France?" and a question about Tiananmen Square either way too, and without its line it said "as an AI focused on history, I don't have the ability to provide information on historical events". Qwen2.5 0.5B says it was made by Alibaba Cloud with or without its line.

So the names and the scopes are mostly belt and braces. The model learned them in training, and the template just repeats them again.

The date's different though, since no model can know what day it is. I gave Llama 3.2 3B six questions that hang on the date, under the block Meta's 3.1 template writes, the same block with today's date, and no block. Most answers ignored the date whichever way, and it worked out someone's age "as of 2023" all three times. The one that moved was a one-line email greeting mentioning the season. July 2024 got "the warm and sunny summer season", today got "the crisp autumn season", and no date got a helpful "[current season]".

That's a small model and one answer in six, but it's the one line in these templates that's news to the model, and it's the one the runners can't agree on.

See what yours sends

In transformers, print the template's output before it's tokenised:

from transformers import AutoTokenizer

tok = AutoTokenizer.from_pretrained("Qwen/Qwen2.5-0.5B-Instruct")
print(tok.apply_chat_template([{"role": "user", "content": "hi"}], tokenize=False))

And llama-server will show you what it's about to send:

curl localhost:8080/apply-template \
  -d '{"messages": [{"role": "user", "content": "hi"}]}'

So... if there's a date in in your response, check it's actually today's.

37 of the top 50 self-hosted apps can go closed

Iain — Fri, 23 Oct 2026 13:53:25 +0000

Pick something you self-host. Could the people behind it put the next release out under terms that aren't open source, without asking anyone?

I went through the 50 most-starred apps on awesome-selfhosted, its non-free list included, to find out. For 37 of them the answer is yes, or they already have. The AGPL badge on the repo doesn't tell you which group yours is in.

The 50 most-starred self-hosted apps (the data)

A square for each app

Group	Apps
Already ship some non-open code (11)	Dify, Open WebUI, Stirling-PDF, LobeHub, NocoDB, Meilisearch, Twenty, Metabase, Rocket.Chat, Outline, Novu
Permissive (18)	Ollama, Hoppscotch, code-server, AnythingLLM, Caddy, Traefik, Memos, PocketBase, Gitea, Appwrite, LocalAI, LibreChat, Hyperswitch, Reactive Resume, Kong, Appsmith, MindsDB, Umami
Copyleft with a company CLA (8)	AppFlowy, Plane, Odoo, Discourse, Puter, ToolJet, PhotoPrism, Halo
Copyleft, no CLA (11)	Immich, Syncthing, Vaultwarden, Pi-hole, Penpot, Jellyfin, SiYuan, paperless-ngx, RSSHub, Sunshine, ERPNext
Permissive, owned by a foundation (2)	Home Assistant, Apache Airflow

The first three groups are the 37, and the 11 at the top are a mix. NocoDB, Outline, Dify, LobeHub and Open WebUI put the whole app under their own terms, while Metabase, Rocket.Chat, Twenty, Meilisearch, Novu and Stirling-PDF fence off the paid bits in a folder or marked files. Anyone could make a closed fork of Home Assistant or Airflow, but the official ones belong to foundations that exist to keep them open.

I only counted what's in each public repo as of 17 October, so Odoo and Kong, which already sell closed enterprise editions from elsewhere, aren't in the first group. I ran the next 50 as well and it drops to 31, beacuse there are more volunteer projects like SearXNG and Invidious with no company to do it. That's 68 of the top 100.

NocoDB did it in one commit

NocoDB is a self-hosted Airtable with 65,000 stars, and untill this year it was AGPL. On 8 January a commit called "chore: change to sustainable use license" deleted the 661-line AGPL and put 61 lines of the Sustainable Use License in it's place, the same licence n8n uses. The last AGPL release, 0.265.1, came out last October. Every release since says this instead:

You may use or modify the software only for your own internal business purposes or for non-commercial or personal use.

GitHub lists 336 contributors to that repo. None of them had to be asked, and a week after the release a user said as much:

For the record, this project uses a CLA, so there isn't a legal issue with changing the license of external contributions.

A CLA, or contributor licence agreement, is something you sign before your PR gets merged, and NocoDB's contributing guide has asked for one since 2022. The founder's reason for the switch, posted on Cloudron's forum, was companies running private forks and ignoring the AGPL, with lawyers too pricey to chase them. I've a bit of sympathy for that. But it was NocoDB's call alone, and the licence page says "The license protects contributors", which is one way of putting it.

The CLA's the bit that matters

A copyleft licence is meant to stop exactly this. If I send a fix to an AGPL project, my fix is AGPL, and nobody can ship it closed without my say-so. A CLA is where I give that say-so up front.

AppFlowy, Plane, Puter, ToolJet and PhotoPrism are all AGPL today, and all have a CLA. So do Odoo, Discourse and Halo on the other GPLs. I read all eight agreements and every one lets the company license your code on other terms. PhotoPrism's is the bluntest:

this includes the right to apply any license to the Contributions that PhotoPrism considers fit for the respective purpose as decided by PhotoPrism in its sole discretion, including other open-source, copyleft, and proprietary licenses

None of that is hidden, and people have been asking about it for ages. Discourse's own forum has a thread from 2013 titled "Does Discourse's contributor agreement provide an exit door from Open Source?". Discourse is still GPL 13 years on.

Companies add the CLA early, though. The copyleft apps that did change all had theirs well before they used it. Metabase's came more than four years ahead of its enterprise/ folder, and NocoDB's nearly four years ahead of January.

Not every CLA lets them do it, mind. Postiz, 61st by stars, uses the FSFE's Fiduciary License Agreement, which says any closed version of your code has to come with an open one too.

My own box isn't any better. My analytics run on Plausible, which is AGPL with a CLA bot on every PR, and has an extra/ folder whose licence grants "no rights to use, distribute or otherwise exploit this software". The community edition I run doesn't compile it in. My error tracker, Bugsink, was never open source to begin with, and I picked it anyway.

MIT never needed one

The latest app to switch isn't even in the top 50. ThingsBoard, 100th by stars, swapped Apache 2.0 for the Business Source License in 4.4, out on 29 September. You can still use it for free with a licence key from them, but only up to 1,000 devices, or 100 on a single server if you're a business. The release notes don't mention it, and awesome-selfhosted still lists it as Apache.

It didn't have to ask anyone. MIT and Apache let anyone take the code and ship a closed version, as long as they keep the licence and notices, and that includes the people who wrote it. Contributors' code comes in under the same terms, so there's nothing to sign. That's how most of the 11 got there. The 18 permissive apps are the biggest group in the table, and the one people worry abut least.

Stirling-PDF didn't need a CLA either

Copyleft with no CLA should be the safe group. Contributors licensed their code as GPL or AGPL and nothing else, so the owners can't take it closed without evey one of them agreeing. Some projects ask for a Signed-off-by line on each commit (a DCO), but that hands over nothing.

Stirling-PDF was in that group until September 2024, when a single commit swapped its GPL-3.0 for MIT. An app/proprietary/ folder came the next year. I couldn't find a PR or anything asking past contributors, which doesn't mean nobody did.

The rest aren't quite as locked as they look. Immich went from MIT to AGPL in February 2024 and RSSHub only last December, so anyone can still take their MIT-era code closed. Sunshine's owner had contributors assign it their copyright from 2022 until it dropped its CLA in 2024, so it owns what people sent in during that time outright. And Syncthing and Penpot are MPL 2.0, which works file by file, so a brand new file can be proprietary.

If you run one of these

Whatever's allready been released stays under the licence it shipped with. NocoDB's 0.265.1 is AGPL forever and anyone can fork it, though I couldn't find anyone keeping up an AGPL fork.

If you run one at home, the new licences still let you. New features just go in the paid bit. Twenty's SSO arrived in 2024 as commercial-only files, and an issue from August points out NocoDB's new documents API needs an Enterprise licence on self-hosted.

To check an app that isn't in the table, look for "CLA" in its contributing guide, then at the checks on a merged PR from an outside contributor:

$ gh pr checks 10037 -R makeplane/plane | grep -i cla
license/cla  pass  0  https://cla-assistant.io/makeplane/plane?pullRequest=10037  Contributor License Agreement is signed.

That won't catch a CLA that's only a file in the repo, like Open WebUI's.

Most big Firefox add-ons still don't say what they collect

Iain — Fri, 23 Oct 2026 13:52:54 +0000

Here's what Firefox showed me this morning when I went to install two password managers:

Bitwarden 2026.10.0, out on 15 October

LastPass 4.154.2

Which one's telling you more? LastPass, obviously. It's got a whole "Required data collection" section, and a pre-ticked box for sending the developer technical data. Bitwarden's just stops after the permissions, and it'd be easy to read that as "collects nothing".

But, that's not what this actually means.. An add-on that really collects nothing will say so in the prompt - Proton Pass's says "The developer says this extension doesn't require data collection." Bitwarden's has no data section at all, since nobody's made Bitwarden fill it in.

Since 3 November 2025, every new add-on on addons.mozilla.org (AMO) has had to put a data_collection_permissions key in its manifest, even if it's only to say "none", and Firefox 140+ shows it in that prompt. Add-ons that already existed were let off, but Mozilla said that wouldn't last:

In the first half of 2026, Mozilla will require all extensions to adopt this framework. But don't worry, we'll give plenty of notice via the add-ons blog.

The first half of 2026 ended in June. The add-ons blog hasn't mentioned it since, and nothing's changed. AMO's API reports the key for every add-on, so I went through the top 1,000 by users to see how far the labels have actually got.

Updated since July, and still nothing

Of the top 1,000, 776 show nothing. Most of those haven't shipped a new version since November, so they never had a reason to add the key. The 21 made since November are fine, 20 of them declare something, which is what happens when it's actually enforced. So I split the other 979 by when their current version was uploaded:

Current version uploaded	Says something
Before 3 Nov 2025	2 of 475 (0.4%)
3 Nov 2025 to 30 Jun 2026	57 of 161 (35%)
Since 1 Jul 2026	145 of 343 (42%)

Adblock Plus, AdGuard, Dark Reader, DuckDuckGo, Ghostery, NoScript, 1Password, MetaMask and Bitwarden have all shipped since July, and none of them say anything. I downloaded each one to check the API wasn't lying, and the key just isn't in their manifests. They're 9 of the 198 in that last row that left it out, and those 198 have about a third of the top 1,000's daily users between them.

That's Mozilla's deadline, not theirs. Nobody told them to add it (more on that next), and silent doesn't mean they're collecting anything. uBlock Origin and Privacy Badger both bothered to say "none". It just means the prompt can't tell you either way.

Nothing makes them

Why haven't they? Mostly beacuse they don't have to. AMO's upload check upload check only turns a missing key into an error when it's a brand new add-on uploaded through the developer hub. An update gets a warning, and that warning still says the key "will be required for new versions of existing extensions in the future". Mozilla's docs say older add-ons "will have to at a later date", with no date.

The nearest thing to news is a reply from Mozilla's add-ons team on thier forum, on 10 September:

Even though we haven't retroactively asked all the published Add-ons to comply with this policy, we do it every time they submit a new version/update.

From the code, I think "asking" there is that warning. The same reply says "I can't promise anything specific right now".

Being honest costs you

When an older add-on adds the key for the first time and says it collects something, every existing user gets asked to agree, and if they say no the update doesn't install. Saying "none" doesn't do that. Firefox has a way round it: a has_previous_consent flag that says users already agreed to whatever the add-on did before, so the update goes through without a prompt. But AMO's linter has rejected that flag since October 2025, in a change titled "Prevent the use of has_previous_consent for now".

Return YouTube Dislike found out what that means. It's got about 900,000 daily users, and on 7 September it shipped its first update in nearly two years, declaring personally identifying information, browsing activity, website content and website activity. Its developer says all it gets is a random user ID and the IDs of the videos, which is how it counts dislikes in the first place. That sounds like a lot for a dislike button, but Mozilla's examples for personally identifying information include "ID numbers", and browsing activity covers even "domains", so I can see how it got there. Here's what happened on its reviews page:

One-star reviews of Return YouTube Dislike on AMO (the data)

A week at a time, from Mondays, up to 11 October. Version 4.0.6 came out on 7 September

It went from about one a week to 101 in a week. "Spyware", "data mining scam", "At what point does a youtube dislike add-on need my personal data?". One reviewer was sure the developer's account had been hacked. My favourite was this one, which sort of gets it and still gives one star:

The fact that the data processing method hasn't changed means it was being collected all along.

To be fair to the reviewers, the same update added premium statistics (likes over time, maps by country), and some of the reviews are about that. But about half of the 224 one-star reviews since 7 September mention the data or the permissions, some quoting Firefox's prompt word for word. The developer put it on Mozilla's forum as "calling my reviews section a shitstorm is an understatement".

The first post in that same thread is from SponsorBlock's developer. It's a similar sort of add-on, talking to its own server about YouTube videos, and they were working out which boxes they'd have to tick. Probably browsing activity, they thought, maybe website content. SponsorBlock's current version came out in July and doesn't declare anything, so its 820,000 daily users get a nice clean prompt.

So nothing makes the quiet add-ons say anything, and the flag that would let the honest ones say it without a fight has been blocked by AMO "for now" for a year. Untill one of those changes, the add-ons that tell you the most look the worst, and the ones that tell you nothing look fine.

Dependabot's now a month late on Python and Go CVEs

Iain — Fri, 23 Oct 2026 13:52:53 +0000

Django put out a security release on 4 August. One of the fixes, CVE-2026-15307, stops staff users writing files to disk through GeoDjango lookups, which Django says could be "in some cases enabling remote code execution". Here's what GitHub's advisory API says about it:

$ gh api /advisories/GHSA-wvqv-fj8w-qmhm \
    --jq '{nvd_published_at, published_at, github_reviewed_at}'
{
  "github_reviewed_at": "2026-09-30T23:25:46Z",
  "nvd_published_at": "2026-08-04T17:16:46Z",
  "published_at": "2026-08-04T18:31:27Z"
}

It was public and on GitHub within an hour and a half. Then it waited 57 days for someone at GitHub to review it, and until then Dependabot doesn't tell anyone. Trivy and Grype didn't spot the ones still waiting either, which I'll get to.

GitHub did warn about this. Its June post on the advisory backlog told Dependabot users:

New advisories may take longer to trigger, with critical issues prioritized.

I wanted to know how much longer, and whether criticals really do go first.

How a CVE gets to Dependabot

There are two usual ways into GitHub's Advisory Database. A maintainer can publish an advisory on their own repo, and GitHub reviews that. Or someone else publishes the CVE (Apache, the Django team, the Go team, VulnCheck, a bug bounty platform), NVD lists it, and GitHub imports it automatically as "unreviewed". An unreviewed advisory doesn't say which package or versions it's about, and Dependabot only alerts on reviewed ones, so nothing happens until a curator fills that in.

Django's went the second way, and that's the route most of this post is about.

May fell off a cliff

Here's the share of PyPI and Go CVEs on that route that GitHub reviewed within 30 days of NVD listing them:

NVD-route CVEs reviewed within 30 days, PyPI and Go (the data)

By the month NVD listed them. September's left out, as by 15 October PyPA and the Go team had only
added 3 from its first fortnight

Every month from May 2025 to April 2026 was somewhere between 73 and 100%. Then May dropped to 57%, and June and July didn't make it to one in ten. Across May to mid-September it's 31%, against 88% for the same months last year. August's a bit better at 24%, but that's only 37 CVEs and nearly all of them Python, so I wouldn't call it a recovery yet.

It's both ecosytems at once, too. PyPI went from 81% to 34%, and Go from 96% to 27%. The typical wait went from same-day to 36 days.

You can't see GitHub's queue from its API, as unreviewed advisories don't name a package, so I came at it from the other end. PyPA and the Go team keep their own vulnerability databases on OSV. I took every CVE from 2024 onwards in those, kept the ones that came in through NVD and not a repo advisory, and looked up when GitHub reviewed each. That's about 2,000 CVEs, 450 of them from this May to mid-September. I left out Go's standard library, since GitHub doesn't review those in any year, and openssl-encrypt, a small Python package that got 50 CVEs in two batches in August and would have dragged that month down on its own. npm and Maven don't have a database of their own outside GitHub's, so I can't do this for them. They might be fine, I've no idea.

Criticals wait just as long

So, "critical issues prioritized":

Reviewed within 30 days, by severity (the data)

15 of 20 critical, 35 of 40 high and 126 of 140 medium or low CVEs last year,
then 22 of 70, 44 of 130 and 77 of 254 this year

Criticals were the slowest group last year too, so I doubt it's new. Seven critical golang.org/x/crypto CVEs NVD listed on 22 May (one is the SSH agent not enforcing a key's confirm-before-use constraint) were all reviewed on 25 June, 34 days later. Maybe criticals do jump the queue for other kinds of advisory, but for these I cant see it.

Big projects too

I half expected a long tail of obscure stuff nobody installs. Here's the share of each project's NVD-route CVEs reviewed within 30 days:

Package	2024-25	2026
Mattermost	154/155	18/42
Apache Airflow	27/27	5/48
Gitea	10/10	0/15
golang.org/x/crypto	3/5	0/14
Django	26/26	3/13

The 2026 column is May to mid-September again. Airflow there includes its provider packages, and Mattermost all its modules and plugins. Airflow core on its own went from 21 of 21 to none of 34.

They do get there in the end. 99% of June's CVEs have been reviewed by now, 83% of July's and 73% of August's. 36 from May to mid-September still haven't, and when I checked them all again on 16 October, none had moved.

Repo advisories wait too

The other route isn't any quicker. Once a maintainer publishes an advisory, GitHub's docs say reviewing it and sending Dependabot alerts "can take up to 72 hours". In September someone from GitHub's community team replied to a thread about slow CVE requests:

we're currently processing records in the order they're received, with a turnaround of approximately five weeks.

And personally, since mid-August maintainers have published 58 of the advisories I've reported, 51 of them for packages Dependabot covers. GitHubs reviewed 9 so far, which took anywhere from 6 to 38 days, and the oldest one still missing from its database went public on 14 August.

NIST changed something the same fortnight

Why now? Tbh I don't know. GitHub says that "since mid-April" it hasn't consistently met its own goals for publishing. On 15 April, NIST changed how NVD works: it now only adds its own details, like severity scores and product lists, to CVEs that meet certain criteria (actively exploited, used by the US government and so on), and the rest wait.

So maybe GitHub's curators leaned on NVD's details and lost them when NIST stopped. Or maybe they're just burried under everything else coming in - GitHub's June post says its CNA got almost 4,000 CVE requests in May alone, nearly ten times the year before. My repo advisories come with the package and versions already filled in by the maintainer, so they don't need anything from NVD, and they're slow too. That makes me lean towards the queue, but I can't prove it from out here.

Quite honestly, this isn't good enough. GitHub - you need to do better. Millions of downstream apps trust you with their security, and you're taking weeks or months to send out Dependabot alerts for known critical bugs.

Trivy and Grype don't see them either

On 15 October I took 16 of the still-unreviewed PyPI CVEs, pinned each one's affected version in a requirements.txt, and ran Trivy 0.76 and Grype 0.120 on default settings. Neither found a single one. Grype with CPE matching turned on found 5. osv-scanner checks OSV, which has PyPA's database in it, and found all 16, which is a bit of a given since that's where I got them from, but thats also the point. If PyPA has it, osv-scanner will tell you, and it's one line to try:

osv-scanner scan source -r .

Go's less clear cut. Go's own database had 83% of these CVEs within a month last year and 19% this year, so govulncheck isn't any quicker than GitHub for these right now.

I'll run it all again in November and see whether the wait's back under a month.

Your money input probably thinks 5,04 is 504

Iain — Fri, 23 Oct 2026 13:52:22 +0000

Type 5,04 in here, the way most of Europe writes five euros and four cents:

Try it on the blog

In Chrome with its menus in English, the comma never goes in. You're left with 504, and nothing anywhere says anything went wrong. Firefox tells you it's not a number, which is at least honest.

Chrome bins the comma as you type

Blink checks each keystroke against 0123456789.Ee-+ plus the locale's own number characters, and the code that builds that list leaves one out on purpose:

// We don't accept group separators.
if (i != kGroupSeparatorIndex)
  builder.Append(decimal_symbols_[i]);

In English the comma is the group separator, so it's gone before your page ever sees it. input.value is "504" and validity.badInput is false, so there's nothing to catch.

The locale is Chrome's own menu language, not your page's. An <input lang="de-DE"> in an English Chromium still gave me 504, and starting Chromium in German gave 5.04. Firefox goes by the page's lang instead, so it's bad input on an English page and 5.04 on a German one.

The libraries do it too

Last week someone in Costa Rica posted on Hacker News about being charged $504 for $5.04 of API credit. Another commenter, in Germany with their Linux set to English, said they've ended up selling things on Amazon and eBay "for 599,00 instead of 5.99".

How many of the libraries people put on money fields would do the same? I took the 20 most downloaded npm packages that turn a typed amount into a number (parsers, masks and input components), set no locale or separator options, and ran them in an English browser on an English page. Inputs and masks got typed into a key at a time (all but ngx-mask in Chromium and Firefox), and the plain parsers I just called.

Package	5,04	1.234,56
@internationalized/number	504	1.23456
react-number-format	504	1.23456
rc-input-number	504	1.23456
@rc-component/input-number	504	1.23456
numeral	504	1.23456
currency.js	504	1.23
react-currency-input-field	504	1.23
numbro	504	1.23456
accounting	504	1.23456
cleave.js	504	1.23
text-mask-addons (with decimals on)	504	1.23
currency-formatter	504	1.23456
autonumeric	504	1.23
imask	5.04	1.23
react-imask	5.04	1.23
ngx-mask	5.04	1.23
vue-currency-input	5.04	1.23
inputmask	5.04	1.56
globalize	NaN	NaN
parse-decimal-number	NaN	NaN

13 of the 20 make 504 of it, and they're not obscure ones. @internationalized/number is Adobe's, and it's what React Aria's NumberField parses with. rc-input-number and its renamed successor are what Ant Design's InputNumber is built on.

The German amount is worse. 18 of the 20 turn a thousand-odd euros into one and a bit, and I've no idea where inputmask's 1.56 comes from. Only globalize and parse-decimal-number say no to both.

Why 504

In US English a comma groups thousands, so the quick way to read "$1,234" is to delete the commas, and that's what most of these do. rc-input-number's whole default parser is one line, with a comment on what it's for:

// [Legacy] We still support auto convert `$ 123,456` to `123456`
return parsedStr.replace(/[^\w.-]+/g, '');

But nobody in the US writes 5,04. Groups come in threes, so a comma with two digits after it can't be grouping anything. It's someone typing a decimal the other way round. globalize and parse-decimal-number check for that, and nothing else does:

> currency('5,04').value
504
> numeral('5,04').value()
504
> new NumberParser('en-US').parse('5,04')
504
> parseDecimalNumber('5,04')
NaN

A German browser just flips it

Two of the 13 only made 504 because my browser was in English. react-currency-input-field and React Aria's NumberField (the field on top of @internationalized/number) take their separators from the browser's language when you don't give them any. In a German browser they read 5,04 fine, and turn 5.04 into 504 instead. The Costa Rica poster says that's their case, with settings that use a comma and 5.04 typed in (the company's reply in the thread says 5,04, so I'm not sure which).

Every library's locale option works, for what it's worth. Give react-number-format or rc-input-number decimalSeparator=",", or react-currency-input-field a German intlConfig, and a typed 5,04 comes out as 5.04. That just moves the problem to whoever types a dot.

Catching it

First you need what they actually typed, so it's a text input rather than type="number", since Chrome's binned the comma by the time you look. inputmode="decimal" gets phones a number pad. Then check it:

// commas only ever group threes
const looksWrong = (typed) => /,(?!\d{3}(\D|$))/.test(typed);

That catches 5,04, 599,00 and 1.234,56 and lets 1,234.56 through. Swap the comma for a dot on a German page. When it fires, ask what they meant rather than charging them for it.

It won't catch 5,040, which comes out as five thousand and forty here and in globalize and parse-decimal-number too. Nothing can tell that one from the string.

New Python packages picked hatchling, not uv_build

Iain — Fri, 23 Oct 2026 13:51:51 +0000

On Monday, Michał Górny from Gentoo posted a plea not to use uv-build. It's a Rust backend with 1.2-1.5 MiB wheels and a dozen releases a month, and Gentoo users have to build every one of them from source, all so it can zip up some pure Python files. Fair enough really.

But it made me wonder how many people acutally use it. uv is everywhere now, and since uv 0.8 in July 2025, uv init --package hands you uv_build out of the box. So surely that's what new packages are built with?

Nope. About one in twenty. Here's what new PyPI projects have been using each month:

Build backend of new PyPI projects (the data)

Share of each month's sample of new projects, read from the first source release they uploaded

The one that moved is hatchling. It sat at about 20% from June to November last year, jumped to over a third by January, and since March it's been somewhere around 40%. Setuptools barely moved, and Poetry's backend went from about one in ten to almost nothing.

To get these I took 400 new projects at random from a day or three of PyPI's changelog each month, and read the build backend out of the first source release each one uploaded. Anyone with five or more in a sample got dropped, so one person pushing out 90 near-identical packages doesn't count 90 times.

Twice as many packages

The chart hides the bigger change, though. Around the same time, PyPI started getting about twice as many new projects. Answer.AI noticed too, with over 25,000 in March, which is about 800 a day. So here's each backend in new projects a day, before and after:

New projects a day, by build backend (the data)

All of them together went from 390 a day to 765

Setuptools doubled, which is about what you'd expect from the thing that's been the default forever. Hatchling nearly quadrupled. Of the 375 or so extra projects a day, about 230 are on hatchling, and uv_build got about 20.

And hatchling went first. In the January window PyPI was still only getting 445 new projects a day, about normal, but hatchling's share had already gone from 21% to 36%. The flood didn't show up untill February.

What changed over the winter

So what happened between November and January? Not uv. Its two big changes were 0.8 in July 2025 (uv_build as the default) and 0.12 in July 2026 (every new project packaged by default), and hatchling's line is flat after both. Not the PyPA packaging tutorial either, which "uses Hatchling by default" and has done since 2022.

What did happen in the second half of November 2025 was Gemini 3, GPT-5.1-Codex-Max and Claude Opus 4.5, all within about a week. Thats only timing. But think about what those models learned from. Years of the PyPA tutorial saying hatchling, plus uv init --package saying it too, right up until 0.8 switched it.

So what do they actually write today?

So I asked them

I gave the current Claude models and Codex the same prompt this week, in an empty folder: "Reply with only the full pyproject.toml you would write for a brand-new pure-Python library called tidy-dates (a small date-parsing helper) that I want to publish on PyPI." Three runs each, then three more with "I manage everything with uv" added.

Model	Plain	Told I use uv
Opus 5.5	all hatchling	2 uv_build, 1 hatchling
Sonnet 5.5	all hatchling	all uv_build
Haiku 5.5	all hatchling	all hatchling
Fable 5.1	all hatchling	2 uv_build, 1 hatchling
gpt-5.6-sol	all hatchling	1 uv_build, 2 hatchling

Fifteen out of fifteen picked hatchling when I didn't mention uv. Even telling them I use uv only got uv_build about half the time.

Then have a look at the versions. When Fable went for uv_build, it pinned it like this:

[build-system]
requires = ["uv_build>=0.8,<0.9"]
build-backend = "uv_build"

That 0.8 is from July 2025, and uv's on 0.13.1 now. The other Claude models capped it somewhere between 0.10 and 0.12, so none of them would take the current one. Their hatchling pins ran from 1.21 to 1.27, the newest of which came out in December 2024, with hatchling on 1.32 today. The only recent pin was Codex's uv_build>=0.12.12,<0.13, and that was on the one run where it went and searched uv's docs first.

Who wrote them, though?

That I can't tell you. A source tarball doesn't say whether a person or an agent made it. I did try: repos that have an agent file like AGENTS.md or CLAUDE.md in them today use hatchling more (55% against 37% without, for projects from this September). But hatchling went up nearly as much in repos without those files, and an agent doesnt have to leave a file behind, so files only get you so far.

What I can say is the new hatchling projects look less like uv projects, not more. In mid-2025, 35-50% of hatchling source releases had a uv.lock inside. Now it's under a quarter.

uv_build might be creeping up. It was 9% in the October window, and 8% in a fresh one I pulled for 12-14 October, its best apart from an odd 12% in February. That's a few hundred projects each, so it could just be noise, and for Gentoo's sake I hope it is.

Your GitHub cron is 20 minutes late, or six hours

Iain — Thu, 15 Oct 2026 00:00:00 +0000

My android-rom-compat repo pulls in new device data every Monday at 17 6 * * 1. I chose minute 17 since everyone knows not to use :00, becuase top of the hour is when GitHub's busiest (according to their workflow schedule docs).

Here's when it actually ran:

$ gh run list --event schedule \
    -R NotAFlightRisk/android-rom-compat \
    --json createdAt --jq '.[].createdAt'
2026-10-12T15:33:46Z
2026-10-05T14:47:28Z
2026-09-28T14:02:11Z
2026-09-21T12:54:11Z

Do you see the issue? Yeah, against the 06:17 it asked for, it was six and a half hours late, then seven and three quarters, eight and a half, and over nine. Actually, seems it gets later every week.

Another of my repos has the same cron, and on the 12th it started at 15:33:46 too, to the second. Both were stuck in the same queue, and the queue was nine hours long.

So this got me curious, and I went and checked a few hundred other people's results...

Two lanes

Scheduled runs on public repos are all visible through the Actions API. So I took a random mix of active repos, from tiny to very popular, and measured every daily cron in them over the first two weeks of October. Here's how late each one typically ran:

How late each daily schedule typically runs (the data)

Number of workflows, by their median lateness from 1 to 14 October

Nearly half run within the hour, usually about 20 minutes late. The rest are almost three hours late or worse, usually six. Interestingly, between one and two hours there's nobody at all, so it's basically two lanes with nothing in the middle.

It's not a bad day here and there, either. A workflow that's six hours late on Monday is six hours late on Tuesday, and on Wednesday. They almost never swap lanes.

Who gets the slow lane

Anything under a few thousand stars is more likely to be slow than not. Only the really big repos get prioritized

Repos in the slow lane, by stars (the data)

Share of repos in my sample whose schedules run hours late

Personal repos mostly get it worse than org ones. I doubt stars are what GitHub actually looks at. More likely it's how busy the repo is, or something else that comes with being popular, and you can't see that from outside, so tbh I dont know. It's not down to the plan you're on though - nextcloud has a 17-star repo in the slow lane and a 10k-star one in the fast lane, under the same org.

And schedules on :00 were no more likely to be slow than the rest.

It started on 27 August

Daily median lateness, in hours (the data)

The same workflows, grouped by the lane they're in now

Before the 27th, the repos that are slow now were often behind, but they were spread out, with no gap between them and the rest.

On 26 August GitHub had an Actions incident. The database behind the service that triggers workflows got overloaded, and the write-up says this:

Several changes to improve the general scalability of this part of Actions were already complete and deploying to production. Rollout of those changes will be complete within the next 24 hours.

27 and 28 August were a mess for everyone, with nothing about it on the status page. Then from the 29th, one group went back to about 15 minutes late. The other hasnt had a day under three and a half hours since, and it's getting worse - about four and a half hours in early September, six by October.

I can't tell you if the rollout caused it. The timing matches, and that's all I've got. Someone else noticed schedules going missing on those same dates, and five weeks on the only reply is from GitHub's bot. It's not totally new either - back in July this thread had a brand new repo running 8-14 hours late almost every day.

What to do about it

Run the gh run list above on your own repo and compare it with your cron. Under an hour late, you're fine. Hours late every day and you're in the slow lane, and moving the minute won't get you out of it.

If the time actually matters, stop asking schedule: for it. Add workflow_dispatch: to the workflow and kick it off from something that keeps time, like a cron on a box you already run:

gh workflow run import.yml -R you/your-repo

In the August thread, dispatched runs started in the same minute 209 times out of 209.

My own Monday import is still on 17 6 * * 1, mind. It's device data, and nobody's waiting on it at quarter past six on a Monday.