[FFmpeg-devel] [RFC] statictrac, trac and caching

[Kacper Michajlow]

On Sun, 15 Jun 2025 at 16:53, James Almer
<jamrial-at-gmail.com at ffmpeg.org> wrote:
>
> On 6/15/2025 10:35 AM, Michael Niedermayer wrote:
> > Hi all
> >
> > As it seems someone figured out how to make AI solve anubis, which made trac
> > rather slow due to the DDOS from 100 different IPs, which eventually
> > we had to block.
> > (maybe timo has time to write an incident report?)
> >
> > Some questions
> > * does someone know how to make trac use/set cache-control headers
> >      (this would simply and plainly reduce load on trac for pages that dont change
> >       but has to play along correctly with user sessions and all that)
> >
> > * should we make a static copy of the whole trac so the
> >      AI users, vibe coders, AI data analyists, and AI bot trainers can actually
> >      use trac while everyone else also can use it ?
> >      that static copy would then get updated ... i dont know, maybe once a week?
> >      side effect, even humans would have a "instant responce but older trac" too
>
> How would this work? We then just expect LLMs to crawl it while leaving
> the live one alone?
>
> Maybe requiring to be logged in to actually access the bug list would
> workaround this, leaving only the wiki open. Or requiring to be logged
> in to access attachments (Which afaik was what most bots tried to fetch
> yesterday).

Allowing public access to the bug lists is important for visibility
and for search engines to index the bugs/discussions. Ideally we want
users to find the first party trac first, instead of some dodgy forum
when searching for bugs/solutions.

Maybe it's time to retire the trac? It is quite slow by design and not
really actively maintained anymore. Holding onto legacy software
always increases the burden of maintainability.

But as mentioned on IRC, it seems to be classic DDoS, so likely not
something that would be easily circumvented by any access restriction.

> These look like residential IPs from a botnet (all same ISP, so possibly compromised
> IoT device).
>
> Publishing these seems in poor taste.

This.

- Kacper