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

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

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 987 bytes --]

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

thx

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Some Animals are More Equal Than Others. - George Orwell's book Animal Farm

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 3135 bytes --]

Hi

On Sun, Jun 15, 2025 at 03:35:15PM +0200, 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.

for the record, heres btw the 100 IP addresses from where the attack yesterday
happened: (i think timo said there where more addresses later but thats the list
when i looked)

    405 149.40.74.100
    471 149.40.74.145
    437 149.40.74.169
    493 149.40.74.185
    268 149.40.74.195
    394 149.40.74.23
    490 149.40.74.32
    384 149.40.74.87
    339 149.40.75.14
    389 149.40.75.142
    436 149.40.75.148
    353 149.40.75.200
    437 149.40.75.223
    471 149.40.75.246
    454 149.40.75.247
    497 149.40.75.81
    411 149.52.62.123
    405 149.52.62.124
    336 149.52.62.125
    474 149.52.62.126
    405 149.52.62.127
    423 149.52.62.130
    395 149.52.62.131
    266 149.52.62.133
    427 149.52.62.134
    392 149.52.62.135
    333 149.52.62.138
    403 149.52.62.139
    509 149.52.62.140
    189 149.52.62.142
    471 149.52.62.143
    257 149.52.62.144
    403 149.52.62.145
    270 149.52.62.146
    492 149.52.62.148
    318 149.52.62.151
    369 149.52.62.152
    404 149.52.62.153
    452 149.52.62.154
    406 149.52.62.155
    421 149.52.62.157
    253 149.52.62.158
    403 149.52.62.162
    384 149.52.62.163
    467 149.52.62.164
    473 149.52.62.165
    302 149.52.62.168
    435 149.52.62.169
    262 149.52.62.171
    439 149.52.62.172
    433 149.52.62.176
    504 149.52.62.177
    313 149.52.62.178
    402 149.52.62.181
    392 149.52.62.182
    433 149.52.62.184
    442 149.52.62.187
    579 149.52.62.189
    381 149.52.62.190
    338 149.52.62.191
    459 149.52.62.192
    456 149.52.62.194
    467 149.52.62.195
    412 149.52.62.196
    426 149.52.62.197
    457 149.52.62.200
    464 192.200.193.112
    445 192.200.193.113
    488 192.200.193.117
    333 192.200.193.119
    464 192.200.193.121
    359 192.200.193.126
    354 192.200.193.129
    468 192.200.193.131
    437 192.200.193.133
    424 192.200.193.137
    474 192.200.193.142
    502 192.200.193.146
    416 192.200.193.152
    448 192.200.193.153
    427 192.200.193.155
    350 192.200.193.160
    340 192.200.220.116
    261 192.200.220.117
    376 192.200.220.120
    370 192.200.220.141
    392 192.200.220.169
    504 192.200.220.180
    459 192.200.220.2
    468 192.200.220.237
    432 192.200.220.45
    442 192.200.220.57
    419 192.200.220.66
    470 192.200.220.81
    408 192.200.220.82
    305 192.200.220.85
    378 192.200.220.87
    477 192.200.220.9
    260 192.200.220.93
    363 192.200.220.96


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 1
"Used only once"    - "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[Derek Buitenhuis]

On 6/15/2025 2:42 PM, Michael Niedermayer wrote:
> for the record, heres btw the 100 IP addresses from where the attack yesterday
> happened: (i think timo said there where more addresses later but thats the list
> when i looked)

These look like residential IPs from a botnet (all same ISP, so possibly compromised
IoT device).

Publishing these seems in poor taste.

- Derek
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] Forensics Was: [RFC] statictrac, trac and caching

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1201 bytes --]

Hi Derek

On Sun, Jun 15, 2025 at 02:53:57PM +0100, Derek Buitenhuis wrote:
> On 6/15/2025 2:42 PM, Michael Niedermayer wrote:
> > for the record, heres btw the 100 IP addresses from where the attack yesterday
> > happened: (i think timo said there where more addresses later but thats the list
> > when i looked)
> 
> These look like residential IPs from a botnet (all same ISP, so possibly compromised
> IoT device).

I hoped someone just made a honest mistake with their AI agents.

But if its a botnet
why would a botnet target ffmpegs bug tracker ?
Its expensive (in terms of computations) to solve anubis repeatedly.
A botnet is there to make some criminal a profit


> 
> Publishing these seems in poor taste.

Publishing is neccessary a first step so people can check if anyone did this
by mistake or if anyone knows where this came from.

Speaking of that. Do you have any idea, hunch or knowledge where this may
have come from ?
Or about anyone who might do this or pay a botnet operator to do this ?

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Forensics Was: [RFC] statictrac, trac and caching

[Derek Buitenhuis]

On 6/15/2025 4:58 PM, Michael Niedermayer wrote:
> I hoped someone just made a honest mistake with their AI agents.

Why are we assuming this is an AI agent and not a stupid DDoS?

> But if its a botnet
> why would a botnet target ffmpegs bug tracker ?

It is common on cybercrime forums to DDoS things to show your botnet
is legit when selling. You should read some Krebs.

> Its expensive (in terms of computations) to solve anubis repeatedly.
> A botnet is there to make some criminal a profit

Trac is an easy demo of their botnets abilities to solve Anubis or AI
load balancing or whatever, if I had to guess. Very low stakes, and
nobody is going to get police/states/FBI/whatever involved.

>> Publishing these seems in poor taste.
> 
> Publishing is neccessary a first step so people can check if anyone did this
> by mistake or if anyone knows where this came from.

So publish a /24 or something.

> Speaking of that. Do you have any idea, hunch or knowledge where this may
> have come from ?
> Or about anyone who might do this or pay a botnet operator to do this ?

Why would I?

- Derek
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[James Almer]

[-- Attachment #1.1.1: Type: text/plain, Size: 639 bytes --]

On 6/15/2025 10:42 AM, Michael Niedermayer wrote:
> Hi
> 
> On Sun, Jun 15, 2025 at 03:35:15PM +0200, 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.
> 
> for the record, heres btw the 100 IP addresses from where the attack yesterday
> happened: (i think timo said there where more addresses later but thats the list
> when i looked)

You could have just mentioned ranges 149.40.0.0/16, 149.52.62.0/24 and 
192.200.0.0/16 without giving specific addresses.


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Forensics Was: [RFC] statictrac, trac and caching

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1281 bytes --]

Hi James

On Sun, Jun 15, 2025 at 11:45:42AM -0300, James Almer wrote:
> On 6/15/2025 10:42 AM, Michael Niedermayer wrote:
> > Hi
> > 
> > On Sun, Jun 15, 2025 at 03:35:15PM +0200, 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.
> > 
> > for the record, heres btw the 100 IP addresses from where the attack yesterday
> > happened: (i think timo said there where more addresses later but thats the list
> > when i looked)
> 
> You could have just mentioned ranges 149.40.0.0/16, 149.52.62.0/24 and
> 192.200.0.0/16 without giving specific addresses.

yes but that makes it impossible to identify the source of this.
we WANT to identify the source.

If it was a mistake by someone, we want to make him aware of it so he
can fix his scripts or AI agents. Mistakes happen and thats ok

If its mallicious then we need to be aware of who it is, as mallicious
people can be very damaging

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Forensics Was: [RFC] statictrac, trac and caching

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 19930 bytes --]

On Sun, Jun 15, 2025 at 03:42:14PM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Sun, Jun 15, 2025 at 03:35:15PM +0200, 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.
> 
> for the record, heres btw the 100 IP addresses from where the attack yesterday
> happened: (i think timo said there where more addresses later but thats the list
> when i looked)
[...]

Heres some more statistics:
number of accesses from '149.52.62' per day
 208846 12/Jun
 436870 13/Jun
    284 14/Jun
  72784 15/Jun

from '192.200.193.[0-9]'
  65422 12/Jun
 134498 13/Jun
     96 14/Jun
  24660 15/Jun

from '192.200.220.[0-9]'
  75536 12/Jun
 154376 13/Jun
    112 14/Jun
  26482 15/Jun

from '149.40.7[45].[0-9]'
  63248 12/Jun
 133842 13/Jun
     78 14/Jun
  24259 15/Jun

heres a random sample from a single IP

[15/Jun/2025:00:00:33 +0300] "POST HTTP/2.0" 200 288 "https://trac.ffmpeg.org/attachment/ticket/10149/ffplay_homemade_multi_lang_m3u.log" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:00:36 +0300] "GET HTTP/2.0" 302 673 "https://trac.ffmpeg.org/attachment/ticket/10149/ffplay_homemade_multi_lang_m3u.log" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:00:39 +0300] "GET HTTP/2.0" 200 2028 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:00:40 +0300] "POST HTTP/2.0" 200 220 "https://trac.ffmpeg.org/attachment/ticket/10149/ffplay_homemade_multi_lang_m3u.log" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:00:36 +0300] "GET HTTP/2.0" 200 122468 "https://trac.ffmpeg.org/attachment/ticket/10149/ffplay_homemade_multi_lang_m3u.log" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:00:41 +0300] "GET HTTP/2.0" 302 653 "https://trac.ffmpeg.org/attachment/ticket/10149/ffplay_homemade_multi_lang_m3u.log" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:00:49 +0300] "GET HTTP/2.0" 200 2037 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:00:50 +0300] "POST HTTP/2.0" 200 211 "https://trac.ffmpeg.org/attachment/ticket/10149/ffplay_homemade_multi_lang_m3u.log" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:00:42 +0300] "GET HTTP/2.0" 200 122162 "https://trac.ffmpeg.org/attachment/ticket/10149/ffplay_homemade_multi_lang_m3u.log" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:00:51 +0300] "GET HTTP/2.0" 302 653 "https://trac.ffmpeg.org/attachment/ticket/10149/ffplay_homemade_multi_lang_m3u.log" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:00:52 +0300] "GET HTTP/2.0" 200 2037 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:00:52 +0300] "POST HTTP/2.0" 200 188 "https://trac.ffmpeg.org/attachment/ticket/10149/ffplay_homemade_multi_lang_m3u.log" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:00:57 +0300] "GET HTTP/2.0" 302 653 "https://trac.ffmpeg.org/attachment/ticket/10149/ffplay_homemade_multi_lang_m3u.log" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:00:51 +0300] "GET HTTP/2.0" 200 121743 "https://trac.ffmpeg.org/attachment/ticket/10149/ffplay_homemade_multi_lang_m3u.log" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:00:57 +0300] "GET HTTP/2.0" 200 121937 "https://trac.ffmpeg.org/attachment/ticket/10149/ffplay_homemade_multi_lang_m3u.log" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:01:27 +0300] "GET HTTP/2.0" 200 2028 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:01:30 +0300] "POST HTTP/2.0" 200 211 "https://trac.ffmpeg.org/timeline?from=2014-07-15T00%3A49%3A21Z&precision=second" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:01:34 +0300] "GET HTTP/2.0" 302 642 "https://trac.ffmpeg.org/timeline?from=2014-07-15T00%3A49%3A21Z&precision=second" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:01:35 +0300] "GET HTTP/2.0" 200 2046 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:01:35 +0300] "POST HTTP/2.0" 200 188 "https://trac.ffmpeg.org/attachment/ticket/2212/out.ass" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:01:37 +0300] "GET HTTP/2.0" 302 603 "https://trac.ffmpeg.org/attachment/ticket/2212/out.ass" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:01:38 +0300] "GET HTTP/2.0" 200 61375 "https://trac.ffmpeg.org/attachment/ticket/2212/out.ass" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:02:08 +0300] "GET HTTP/2.0" 200 1250 "https://trac.ffmpeg.org/timeline?from=2014-07-15T00%3A49%3A21Z&precision=second" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:02:08 +0300] "GET HTTP/2.0" 200 8678 "https://trac.ffmpeg.org/timeline?from=2014-07-15T00%3A49%3A21Z&precision=second" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:02:08 +0300] "GET HTTP/2.0" 200 535 "https://trac.ffmpeg.org/timeline?from=2014-07-15T00%3A49%3A21Z&precision=second" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:02:08 +0300] "GET HTTP/2.0" 200 11263 "https://trac.ffmpeg.org/timeline?from=2014-07-15T00%3A49%3A21Z&precision=second" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:02:08 +0300] "GET HTTP/2.0" 200 70122 "https://trac.ffmpeg.org/timeline?from=2014-07-15T00%3A49%3A21Z&precision=second" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:01:34 +0300] "GET HTTP/2.0" 200 28813 "https://trac.ffmpeg.org/timeline?from=2014-07-15T00%3A49%3A21Z&precision=second" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:02:47 +0300] "GET HTTP/2.0" 200 2028 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:02:47 +0300] "POST HTTP/2.0" 200 188 "https://trac.ffmpeg.org/ticket/131?format=rss" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:02:49 +0300] "GET HTTP/2.0" 302 580 "https://trac.ffmpeg.org/ticket/131?format=rss" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:02:49 +0300] "GET HTTP/2.0" 200 2717 "https://trac.ffmpeg.org/ticket/131?format=rss" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:02:55 +0300] "GET HTTP/2.0" 200 2037 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:02:56 +0300] "POST HTTP/2.0" 200 211 "https://trac.ffmpeg.org/attachment/ticket/10149/ffplay_homemade_multi_lang_m3u.log" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:03:47 +0300] "GET HTTP/2.0" 200 2015 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:03:48 +0300] "POST HTTP/2.0" 200 211 "https://trac.ffmpeg.org/attachment/ticket/10149/ffplay_homemade_multi_lang_m3u.log" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:03:50 +0300] "GET HTTP/2.0" 302 653 "https://trac.ffmpeg.org/attachment/ticket/10149/ffplay_homemade_multi_lang_m3u.log" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:03:50 +0300] "GET HTTP/2.0" 200 122762 "https://trac.ffmpeg.org/attachment/ticket/10149/ffplay_homemade_multi_lang_m3u.log" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:04:45 +0300] "GET HTTP/2.0" 200 2046 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:04:46 +0300] "POST HTTP/2.0" 200 211 "https://trac.ffmpeg.org/attachment/ticket/10149/ffplay_homemade_multi_lang_m3u.log" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:04:47 +0300] "GET HTTP/2.0" 302 653 "https://trac.ffmpeg.org/attachment/ticket/10149/ffplay_homemade_multi_lang_m3u.log" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:04:48 +0300] "GET HTTP/2.0" 200 121190 "https://trac.ffmpeg.org/attachment/ticket/10149/ffplay_homemade_multi_lang_m3u.log" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:04:52 +0300] "GET HTTP/2.0" 200 2028 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:04:52 +0300] "POST HTTP/2.0" 200 197 "https://trac.ffmpeg.org/attachment/ticket/10149/ffplay_homemade_multi_lang_m3u.log" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:04:56 +0300] "GET HTTP/2.0" 302 654 "https://trac.ffmpeg.org/attachment/ticket/10149/ffplay_homemade_multi_lang_m3u.log" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:05:01 +0300] "GET HTTP/2.0" 200 2037 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:05:02 +0300] "POST HTTP/2.0" 200 211 "https://trac.ffmpeg.org/attachment/ticket/10149/ffplay_homemade_multi_lang_m3u.log" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:04:56 +0300] "GET HTTP/2.0" 200 122123 "https://trac.ffmpeg.org/attachment/ticket/10149/ffplay_homemade_multi_lang_m3u.log" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:05:04 +0300] "GET HTTP/2.0" 302 654 "https://trac.ffmpeg.org/attachment/ticket/10149/ffplay_homemade_multi_lang_m3u.log" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:05:05 +0300] "GET HTTP/2.0" 200 122348 "https://trac.ffmpeg.org/attachment/ticket/10149/ffplay_homemade_multi_lang_m3u.log" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:05:11 +0300] "GET HTTP/2.0" 200 2037 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:05:12 +0300] "POST HTTP/2.0" 200 211 "https://trac.ffmpeg.org/attachment/ticket/10149/ffplay_homemade_multi_lang_m3u.log" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:05:13 +0300] "GET HTTP/2.0" 302 655 "https://trac.ffmpeg.org/attachment/ticket/10149/ffplay_homemade_multi_lang_m3u.log" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:05:14 +0300] "GET HTTP/2.0" 200 122704 "https://trac.ffmpeg.org/attachment/ticket/10149/ffplay_homemade_multi_lang_m3u.log" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:05:58 +0300] "GET HTTP/2.0" 200 2028 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:05:58 +0300] "POST HTTP/2.0" 200 188 "https://trac.ffmpeg.org/attachment/ticket/10149/ffplay_homemade_multi_lang_m3u.log" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:06:00 +0300] "GET HTTP/2.0" 302 654 "https://trac.ffmpeg.org/attachment/ticket/10149/ffplay_homemade_multi_lang_m3u.log" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:06:00 +0300] "GET HTTP/2.0" 200 121496 "https://trac.ffmpeg.org/attachment/ticket/10149/ffplay_homemade_multi_lang_m3u.log" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:06:15 +0300] "GET HTTP/2.0" 200 2037 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:06:16 +0300] "POST HTTP/2.0" 200 211 "https://trac.ffmpeg.org/attachment/ticket/10149/ffplay_homemade_multi_lang_m3u.log" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:07:03 +0300] "GET HTTP/2.0" 200 2037 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:07:04 +0300] "POST HTTP/2.0" 200 211 "https://trac.ffmpeg.org/timeline?from=2011-12-27T22%3A26%3A36Z&precision=second" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:07:05 +0300] "GET HTTP/2.0" 302 642 "https://trac.ffmpeg.org/timeline?from=2011-12-27T22%3A26%3A36Z&precision=second" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:07:20 +0300] "GET HTTP/2.0" 200 659 "https://trac.ffmpeg.org/timeline?from=2011-12-27T22%3A26%3A36Z&precision=second" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:07:20 +0300] "GET HTTP/2.0" 200 1175 "https://trac.ffmpeg.org/timeline?from=2011-12-27T22%3A26%3A36Z&precision=second" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:07:20 +0300] "GET HTTP/2.0" 200 812 "https://trac.ffmpeg.org/timeline?from=2011-12-27T22%3A26%3A36Z&precision=second" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:07:20 +0300] "GET HTTP/2.0" 200 8686 "https://trac.ffmpeg.org/timeline?from=2011-12-27T22%3A26%3A36Z&precision=second" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:07:20 +0300] "GET HTTP/2.0" 200 69829 "https://trac.ffmpeg.org/timeline?from=2011-12-27T22%3A26%3A36Z&precision=second" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:07:20 +0300] "GET HTTP/2.0" 200 11261 "https://trac.ffmpeg.org/timeline?from=2011-12-27T22%3A26%3A36Z&precision=second" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:07:06 +0300] "GET HTTP/2.0" 200 39399 "https://trac.ffmpeg.org/timeline?from=2011-12-27T22%3A26%3A36Z&precision=second" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:07:35 +0300] "GET HTTP/2.0" 200 2024 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:07:36 +0300] "POST HTTP/2.0" 200 211 "https://trac.ffmpeg.org/attachment/ticket/10149/ffplay_homemade_multi_lang_m3u.log" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:07:38 +0300] "GET HTTP/2.0" 302 662 "https://trac.ffmpeg.org/attachment/ticket/10149/ffplay_homemade_multi_lang_m3u.log" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:07:38 +0300] "GET HTTP/2.0" 200 122085 "https://trac.ffmpeg.org/attachment/ticket/10149/ffplay_homemade_multi_lang_m3u.log" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:07:45 +0300] "GET HTTP/2.0" 200 2037 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:07:46 +0300] "POST HTTP/2.0" 200 211 "https://trac.ffmpeg.org/attachment/ticket/10149/ffplay_homemade_multi_lang_m3u.log" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:07:47 +0300] "GET HTTP/2.0" 302 655 "https://trac.ffmpeg.org/attachment/ticket/10149/ffplay_homemade_multi_lang_m3u.log" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:07:47 +0300] "GET HTTP/2.0" 200 123014 "https://trac.ffmpeg.org/attachment/ticket/10149/ffplay_homemade_multi_lang_m3u.log" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
[15/Jun/2025:00:08:13 +0300] "GET HTTP/2.0" 200 2028 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[James Almer]

[-- Attachment #1.1.1: Type: text/plain, Size: 1245 bytes --]

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).


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[Kacper Michajlow]

On Sun, 15 Jun 2025 at 16:53, James Almer
<jamrial-at-gmail.com@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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[Marth64]

On Sun, Jun 15, 2025 at 10:57 AM Kacper Michajlow
<kasper93-at-gmail.com@ffmpeg.org> wrote:
> 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.

I do feel that a good portion of wiki technical documentation can
probably be moved to the main docs.
There are some good examples and information there that seem to me can
be crystallized into plain old texi.
While I'm neutral about Trac I think in a sense this could also help
in the sense of reducing server load for this somewhat static content.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1459 bytes --]

Hi Marth64

On Sun, Jun 15, 2025 at 11:06:47AM -0500, Marth64 wrote:
> On Sun, Jun 15, 2025 at 10:57 AM Kacper Michajlow
> <kasper93-at-gmail.com@ffmpeg.org> wrote:
> > 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.
> 
> I do feel that a good portion of wiki technical documentation can
> probably be moved to the main docs.

The wiki has the huge advantage that people can edit it easily

Editing the docs people have to do a git checkout, edit a file
with an editor, make a git commit read patch submission rules
submit a patch to ML or forge.

Thats alot stumbling blocks thrown in ones way


> There are some good examples and information there that seem to me can
> be crystallized into plain old texi.
> While I'm neutral about Trac I think in a sense this could also help
> in the sense of reducing server load for this somewhat static content.

yesterdays incident had like ~40k accesses on teh same file.
So moving 99% of content out of trac would not have helped if
that file was in teh 1%

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[Marth64]

Hello Michael,

On Sun, Jun 15, 2025 at 11:53 AM Michael Niedermayer
<michael@niedermayer.cc> wrote:
> The wiki has the huge advantage that people can edit it easily
>
> Editing the docs people have to do a git checkout, edit a file
> with an editor, make a git commit read patch submission rules
> submit a patch to ML or forge.
>
> Thats alot stumbling blocks thrown in ones way
I agree, I don't think or mean to throw away the wiki.
But more along the lines was thinking of upstreaming some of the more
mature examples and information there.
For example, this page is already covered in the docs:
https://trac.ffmpeg.org/wiki/HowToExtractAndRemoveClosedCaptions

I guess framed the thought in a too general fashion.
Maybe a little tidying is all I was wanting and is irrelevant of this
conversation so I'll compartmentalize it for later.

> > There are some good examples and information there that seem to me can
> > be crystallized into plain old texi.
> > While I'm neutral about Trac I think in a sense this could also help
> > in the sense of reducing server load for this somewhat static content.
>
> yesterdays incident had like ~40k accesses on teh same file.
> So moving 99% of content out of trac would not have helped if
> that file was in teh 1%

That's a fair and valid point.

Thank you,
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 2236 bytes --]

Hi Kacper

On Sun, Jun 15, 2025 at 05:57:09PM +0200, Kacper Michajlow wrote:
> On Sun, 15 Jun 2025 at 16:53, James Almer
> <jamrial-at-gmail.com@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.

yes


[...]

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

trac is up and working ATM, anubis difficulty was reduced and trac is
as fast as it was before the incident.

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1186 bytes --]

Hi Kacper

On Sun, Jun 15, 2025 at 05:57:09PM +0200, Kacper Michajlow wrote:
[...]

> 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.

While performance is just one metric, and i dont think its a good reason
to switch because of that.

Lets look at the numbers anyway, we had an average of about 1 million accesses
from the set of /24 IP ranges posted over the course of one day.
thats like 10 accesses per second _average_ over 24h

asking chatgpt, what the performance of various bug trackers are
on a single server. There is only a single one that chatgpt listed
can do 1+ million, that is Forgejo (with issues module)

now granted thats just an LLMs awnser but it doesnt give me confidence
that switching the tracker will solve this

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1673 bytes --]

Hi

On Sun, Jun 15, 2025 at 11:53:28AM -0300, James Almer 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?

Well, theres an incentive for LLMs and their human operator to crawl the static one,
as they succeed. with significantly less latency and less computational resources
thus less financial cost.

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
            conveniently.
New school: Use the highest level language in which the latest supercomputer
            can solve the problem without the user falling asleep waiting.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".