Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests

[Soft Works <softworkz-at-hotmail.com@ffmpeg.org>]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@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.com@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

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. 
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-request@ffmpeg.org with subject "unsubscribe".