On 13/02/2025 13:07, Soft Works wrote:
-----Original Message-----
From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of
Tobias Rapp
Sent: Donnerstag, 13. Februar 2025 12:05
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
On 13/02/2025 01:24, Romain Beauxis wrote:
Le mer. 12 févr. 2025 à 18:17, Soft Works
<softworkz-at-hotmail....@ffmpeg.org> a écrit :
Hm, please help me understand what kind of spam we're talking about
here. I can't imagine somebody would take the effort for selling some pills to
ffmpeg developers. When it's about advertising anything, that's not the kind
of reach those people are typically looking for.
Or is it about misusing repos for storage of illegal content? The largest file
currently is just 953kB, so we could enforce a limit small enough to make it
unattractive for this purpose (unlike GitHub with 100MB per file).
We could also disallow repos with custom content (i.e. only forks of ffmpeg
are allowed as repo content).
Then I wonder, where would be the harm? Some thousand unused forks of
ffmpeg shouldn't be a problem - but maybe I'm overseeing something?
There are all sorts of copyrightable material that can be embedded
into a git repo.
Also payloads for malicious software.
etc.
Given that this all amounts to manpower from the operator, it's
totally understandable that they would like to be conservative about
opening it up.
Hi Tobias,
I'd like to add that with CI enabled there is the possibility that users
of the platform abuse it to get some processing resources for free
(crypto mining). From what I remember this was an issue for the GitLab
instance at FreeDesktop.org.
That's indeed a problem, also with GitHub actions for which reasons, CI builds
on PRs are disabled by default (and enabling it is a very hidden option). It
becomes risky because multiple factors come into play:
- The definitions for CI builds are part of the repo content, so it was easy to
change that for doing something entirely different and submitting this as PR
- The build runners are aiming to give you full control and abilities to make
them useful for all cases, so you have root access, passwordless sudo, full
network access at high bandwidths (at least in case of GH Actions and Azure
DevOps)
- The hosters cannot make any assumptions about your CI builds: how long it
usually takes, which resources are required and whch kind of things you're
executing, so the only thing they are doing is to isolate those VMs and let
each job run on a fresh VM image.
- As a user of these services you actually don't need to care much about it,
except for one thing: when you have any secrets in place that are needed to
accessing other services or when the that the job uses for repo access has
other permissions that could be used in some malicious way
In case of ffmpeg it's not that risky, because we know exactly what's needed
and whatnot, so constraints can be applied to build machines like:
- limiting the maximum execution time
on a super-slow (free tier) Google cloud VM, ffmpeg build plus FATE takes
about 20min, so it can be limited to 30min
- restricting network access
an ffmpeg build doesn't require network access to arbitrary destinations, so
this can be locked down as well
Amazon has axed their free tier, and the GCE free-tier is too small with
just 1GB of RAM, 5GB of storage and 1GB of traffic per month.
With these two measures, the CI builds are pretty useless already for any
malicious operations.
Oh, just while writing this reminded me that for the ffstaging
(GitHub-sync-to-ML) setup I had applied and been granted 10 parallel build jobs
without (monthly total) limit on Azure DevOps. Each job can run for 6h max, but
you can start a new one then. This means 10 build machines can run in parallel
24/7 all time.
Since the application was "for building ffmpeg PRs" it would be perfectly fine
to use this capacity for our CI builds.
Feel free to set up Forgejo runners on those VMs and link them up, you
should be able to generate a token in your user settings.
That way, we also do not need to be that much concerned about potential abuse. 😉
sw
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
