| 19 Nov 2025 |
 vcunat | OK, so you need an exception to bypass Anubis for this use case. | 17:06:33 |
| vcunat | adamcstephens: can you retry now? | 17:10:24 |
| vcunat | (just trying a quick prototype) | 17:10:43 |
 adamcstephens | still got the anubis page | 17:11:14 |
| vcunat | I suppose someone more capable than me in this would have a look 😅 | 17:17:20 |
| adamcstephens | In theory a bot policy as below should work, but it isn't scoped at all if that is desired. I don't see managed policies already in nixos/infra though, and not sure how the defaults are handled by adding one...
- name: distrobuilder
user_agent_regex: distrobuilder
action: ALLOW
| 17:21:57 |
| vcunat | I thought we have these here
https://github.com/NixOS/infra/blob/main/build/hydra-proxy.nix#L96 | 17:23:15 |
| vcunat | But maybe I'm wrong. | 17:23:24 |
| vcunat | i.e. the approach is to allow some URLs, not some agents. | 17:24:06 |
| adamcstephens | ahh | 17:24:59 |
 hexa (signing key rotation when) | I assume an anubis update was backported and that caused this change in behavior | 17:31:19 |
| adamcstephens | that rule should handle the intermediate and final redirects, but not the initial request /job/nixos/trunk-combined/nixos.incusContainerImage.x86_64-linux/latest/download-by-type/file/squashfs-image | 17:31:27 |
| adamcstephens | yeah, i kinda guessed it was an anubis update given the infra git history | 17:31:43 |
| adamcstephens | how about /job/[^/]+/[^/]+/[^/]+/latest/download-by-type/[^/]+ ? | 17:39:47 |
| adamcstephens | maybe a bit more explicit than the others, so could drop the last match | 17:42:04 |
| vcunat | 🤷 deployed
locations."~ ^/job/[^/]+/[^/]+/[^/]+/latest/download-by-type/[^/]+" = {
proxyPass = "http://hydra-server";
};
(temporarily)
| 17:42:55 |
| adamcstephens | hmm, still no luck | 17:44:24 |
| adamcstephens | strangely it works for curl with a distrobuilder user-agent, but not with the go program itself. | 17:48:50 |
| adamcstephens | I'm assuming that's anubis trusting curl, but detecting the go application and blocking it | 17:50:48 |
| adamcstephens | not sure why that regex isn't matching though. :/ | 17:58:33 |
| vcunat | 🤔 appended another /[^/]+ to cover the whole URL, I think. But I don't know. | 18:05:54 |
| adamcstephens | i think the ~ is a partial match. but i'm also pretty rusty with nginx rules | 18:10:55 |
| adamcstephens | still fails | 18:11:16 |
| vcunat | I also thought, but it was easy to try when we lack ideas. | 18:24:45 |
 ghpzin | If anubis update is suspected, there was a mention about blocking "Docker / OCI registry clients" by default accidentally in 1.23.0+
https://github.com/TecharoHQ/anubis/pull/1253
(there is a way to opt-in fix it in 1.23.1) | 18:45:52 |
| ghpzin | * If anubis update is suspected, there was a mention about blocking "Docker / OCI registry clients" by default accidentally in 1.23.0+
https://github.com/TecharoHQ/anubis/pull/1253
https://github.com/TecharoHQ/anubis/releases/tag/v1.23.1
(there is a way to opt-in fix it in 1.23.1) | 18:47:54 |
| adamcstephens | That seems an unlikely issue as this isn't a docker/oci client | 19:07:45 |
 teutat3s | Maybe related, we noticed more breakage than just docker / OCI clients with the update from anubis 1.22 to 1.23, specifically codeberg pages (pages-server) was no longer able to reach our forgejo. I don't have a specific commit to point the finger at, but my impression is that anubis 1.23 somehow applies stricter rules. | 19:17:27 |
| teutat3s | * Maybe related, we noticed more breakage than just docker / OCI clients with the update from anubis 1.22 to 1.23, specifically codeberg pages (pages-server) was no longer able to reach our forgejo. I don't have a specific commit to point the finger at, but my impression is that anubis 1.23 somehow applies stricter rules.
EDIT: Downgrading to anubis 1.22 fixed our specific issue. | 19:18:55 |
| 20 Nov 2025 |
|  John joined the room. | 05:31:05 |
