On 13.02.2025 01:40, Soft Works wrote:
-----Original Message-----
From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of
Romain Beauxis
Sent: Donnerstag, 13. Februar 2025 01:25
To: FFmpeg development discussions and patches <ffmpeg-
de...@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
Le mer. 12 févr. 2025 à 18:17, Soft Works
<softworkz-at-hotmail....@ffmpeg.org> a écrit :
-----Original Message-----
From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of
Timo
Rothenpieler
Sent: Donnerstag, 13. Februar 2025 00:34
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
On 13.02.2025 00:07, Soft Works wrote:
-----Original Message-----
From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of
Timo
Rothenpieler
Sent: Mittwoch, 12. Februar 2025 22:33
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull
requests
On 12.02.2025 22:22, Stephen Hutchinson wrote:
Are all accounts restricted to owning a maximum of 0 repositories by
default, or is it set to 0 only for those that sign up through one of
the external logins?
It's set to 0 by default, to avoid spammers uploading junk, or just
people (ab)using it for non-ffmpeg things.
You can open issues and comment on existing PRs.
And also create PRs using the AGit workflow:
https://forgejo.org/docs/latest/user/agit-support/
For those who are too lazy to look it up:
The "Agit workflow" requires you to use non-standard Git "push-
options"
(either -o or --push-options):
git push origin HEAD:refs/for/master -o topic="topic-branch" \
-o title="Title of the PR" \
-o description="# The PR Description
This can be **any** markdown content.\n
- [x] Ok"
This means essentially that our attempt to move away from the e-mail-
based
submission procedure to something easy and user-friendly, would end up
in
replacing the current rarely-known mechanism with another even more
rare
and obscure procedure which would (again) force everybody to use the Git
command line because it's (again) not supported by any tooling except Git
CLI.
I'm afraid, but from my point of view, this doesn't match the objective.
The only alternative is to completely lock down the instance, and not
allow new users at all without manual approval of each and every one.
People can just ask to be allowed to fork, but by default, allowing it
is not feasible.
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.
That's why I mentioned that a file size limit could prevent this. With a 2 MB
limit per file, it becomes totally unattractive for this kind of abuse.
That doesn't seem feasible to implement, given it's git.
Not even sure how to implement such a limit at all with git.
Some hook would need to check every file on push, which I don't think is
something that readily exists.
And even then, there will be ways around it if someone is motivated enough.
Given that this all amounts to manpower from the operator
AFAIK, you are only responsible to take stuff down once you get notified, you
don't need to actively look for anything.
I still wouldn't want to be the one hosting who knows what of illegal
shit on our servers.
Also keep in mind that if they fork the FFmpeg repo, and then push
something big and bad into that fork, it ends up in the same backing
storage of git objects.
So it's not even trivial to just delete it again, and bar access to it.
You can ask Videolan about how a fully open Gitlab instance went for them.
Also payloads for malicious software.
Okay, but when it's in a repo, what happens next? I mean why would somebody
store that in a repo? What would be the goal?
Also, I wonder how this would be different from attachments on https://trac.ffmpeg.org ?
There's no requirement for user "approval" as well..
We're just relatively lucky that trac is pretty uncommon and spambots
targetting are more rare.
Also, our custom-baked captcha for trac has so far remained undefeated.
Before it was implemented, trac also had a lot of spambots.
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".
