[FFmpeg-devel] The "bad" Patch

[FFmpeg-devel] The "bad" Patch

[softworkz .]

Hello everybody,

it's about 14 days ago, on Thursday, 2025-05-15, when I had applied 
my "Execution Graph Printing" patchset after 12 revisions and 3 
reminder e-mails sent to the ML.
The patch 15/15 had a controversial reception from other FFmpeg
developers, ranging from friendly concerns up to aggressive blown-up 
comments, some with elements of defamation, false accusations which
were blindly repeated even after I had rectified them.


It has been difficult to navigate for me, as there were very 
different kinds of arguments, and not all of them were of a type
that would have justified immediate reversion. Also, I cannot 
consider people as trustworthy while they are going crazy. I had
hoped for entering a discussion to explain the details, but once 
the mob had formed and I had realized that a reasonable discussion 
is not possible, I chose to revert that patch.

All-in-all, what remains from that situation is a very wrong 
picture, that I cannot leave unresolved. I had only decided to
wait those 14 days, in order to allow for some cooldown. But 
now it's really time for clearing a few things up.

I had noticed a number of misunderstandings about the patch (many 
don't even seem to have looked at it). I don't mean to say that 
everybody misunderstood everything, it was rather mixed and there
has also been one very valid comment regarding the way how the temp
folder was determined. 



Misunderstanding 1: What is being launched?
===========================================

It appears that many had only read the headlines and assumed the code 
would launch the executable of a browser in a new process.
Those who said that system() is not the right way to launch such a 
process, are absolutely right. But that's not what's happening.

What's really happening: It is invoking a common shell script/command
(named xdg-open) which is handling the request and opens the configured
application when required, or when already running, it causes it to open
the provided file or url. xdg-open does that for many file types, it's
not just for opening urls and is a de-facto standard on Linux, similar
to ShellExecute() on Windows.


Misunderstanding 2: Opening URLs is a big issue and taboo for CLI tools
=======================================================================

In fact, so many applications are doing it, that it's almost pointless
to name any. Almost all GUI applications are showing URLs somewhere on
which you can click to open in the browser, if not part of the actual
functionality, then at least in some Help>About dialog.
Many text editors are detecting URLs and allow launching them in the 
browser in some way. The same applies to text in terminal application
windows quite often.
All these are launching the URLs through xdg-open. It's not a big
thing and in no way special.

Neither is it unusual for Linux CLI tools to launch URLs in a browser,
some prominent examples are docker (Docker), aws (Amazon) or gh (GitHub).

Some had reacted as if a CLI that would do browser-launching
would be so toxic and unacceptable that they would never use it.
Well - think again, because then you'd need to stop using: Git

Even Git does it - and you're all using it.


Misunderstanding 3: I would not be knowing what I'm doing
=========================================================

Some had alluded that I would not be knowing about possible dangers
when invoking a shell, like injection attacks. But that's really far 
from the truth. One of the first things I did when I started working
with FFmpeg more than a decade ago was creating a huge .net lib,
partially auto-created with about 2k classes, precisely reflecting
ffmpeg's codecs, muxers, filters, protocols, etc - with all their
options replicated in detail with proper types, value constraints
and enums. That lib has a single purpose only: Building valid 
and safe FFmpeg command lines on all platforms. A simple shell 
escape is not the only form of injection attacks and - without
giving any recipes - FFmpeg command lines are an attractive
target for such attacks. Bottom line: No matter how you are 
launching something - via shell or by starting a process - it is
always important to make sure the parameters that you are passing
anywhere are valid and sane.


"Bad" API?
==========

As far as I'm seeing it, an API can hardly be intrinsically bad.
It depends on the case and the parameters that are passed.
With the wrong parameters, bad things can happen with many APIs.

So, let's take a look at the command string that is actually run:

xdg-open '...path...' </dev/null 1>/dev/null 2>&1 &


The path is built from two parts combined, temp path and generated
file name, e.g.

/tmp/ffmpeg_graph_2025-05-28_06-53-23_550.html


There's nothing in the resulting command that is depending on 
user input and could be manipulated in some way.

So, what's actually bad about this invocation? Where's the risk?

While searching for an answer, I've seen many uses of system()
in Linux tools (less, Vim, linuxmint; Python's os.system() maps
directly to glibc's system() and is used everywhere) - and I've 
seen even more which are doing the exact same things as glibc
does internally (launching sh).

I fully understand that care needs to be taken when invoking a
shell. It should raise a flag - absolutely. But the next step
must be careful evaluation rather than going crazy.
I really don't see why it should be categorized as "forbidden",
especially not for a very clear and narrow case like here.


So far, the system() API in glibc has only been talked about 
as a black box - a "bad" black box. Making claims about
something unknown is always easy - but not useful for 
discussion, and hence I've moved that out of the way:
I have updated and reposted the "bad" patch, alongside a 
second patch which substitutes the system() call with the 
actual source code from glibc 2.31 that is used on Linux 
systems. Now, it's no longer a black box.


And so, here's my question to all those who had told me how
forbidden, unacceptable and 'no-no' the use of the system()
API would be:

Could you please explain to me in detail what exactly is 
bad about using that API in THIS WAY and in THIS CONTEXT?

Which bad things can happen and how exactly?

Thanks
sw


Please note:

I have no intentions towards getting this merged.

It's a valid opinion when you think that "ffmpeg shouldn't
launch a browser" or similar - but that's not the topic.
This is merely a technical question.

_______________________________________________
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] The "bad" Patch

[Rémi Denis-Courmont]

Hi,

Whatever glibc does or doesn't do is kinda irrelevant. FFmpeg is supposed to be portable and that makes `system()` a non-starter given how bad it *can* be.

With that said, and with my CC hat on, if you would consider a portably safer alternative, I can only say that considering what strong objections there were, and who made them, the only way forward (if any) is to solicit the TC.

(I am not necessarily against spawn/fork+exec but I am also *not* a TC member.)

Br,
_______________________________________________
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] The "bad" Patch

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Rémi
> Denis-Courmont
> Sent: Mittwoch, 28. Mai 2025 19:34
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] The "bad" Patch
> 
> Hi,
> 
> Whatever glibc does or doesn't do is kinda irrelevant. FFmpeg is
> supposed to be portable and that makes `system()` a non-starter given
> how bad it *can* be.

On Windows it runs ShellExecute, on Mac it does nothing.
We're talking about Linux only - which was the focus of the comments.



> With that said, and with my CC hat on, if you would consider a
> portably safer alternative, I can only say that considering what
> strong objections there were, and who made them, the only way forward
> (if any) is to solicit the TC.

I don't want this patch to be merged. 

And this cannot be wiped away by referring to any general sayings. The
patch is very specific and when somebody makes drastic comments like the
ones that were made, then I expect that these were made based on thorough
evaluation and consideration.

Now, I'm asking those persons to lay out their considerations at a 
technical level, specific to the code in that patch - or apologize for 
their invalid assessments.

I will gladly repeat those comments, one after another, including who
made each one.

Thank you
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".

Re: [FFmpeg-devel] The "bad" Patch

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> softworkz .
> Sent: Mittwoch, 28. Mai 2025 20:01
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] The "bad" Patch
> 
> 
> 
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Rémi
> > Denis-Courmont
> > Sent: Mittwoch, 28. Mai 2025 19:34
> > To: FFmpeg development discussions and patches <ffmpeg-
> > devel@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] The "bad" Patch
> >
> > Hi,
> >
> > Whatever glibc does or doesn't do is kinda irrelevant. FFmpeg is
> > supposed to be portable and that makes `system()` a non-starter
> given
> > how bad it *can* be.
> 
> On Windows it runs ShellExecute, on Mac it does nothing.
> We're talking about Linux only - which was the focus of the comments.
> 
> 
> 
> > With that said, and with my CC hat on, if you would consider a
> > portably safer alternative, I can only say that considering what
> > strong objections there were, and who made them, the only way
> forward
> > (if any) is to solicit the TC.
> 
> I don't want this patch to be merged.
> 
> And this cannot be wiped away by referring to any general sayings. The
> patch is very specific and when somebody makes drastic comments like
> the
> ones that were made, then I expect that these were made based on
> thorough
> evaluation and consideration.
> 
> Now, I'm asking those persons to lay out their considerations at a
> technical level, specific to the code in that patch - or apologize for
> their invalid assessments.

Probably nobody will have the moral courage to apologize, anyway.

Not being able to explain their assessments will suffice.

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

Re: [FFmpeg-devel] The "bad" Patch

[Marton Balint]

On Wed, 28 May 2025, softworkz . wrote:

> Please note:
>
> I have no intentions towards getting this merged.
>
> It's a valid opinion when you think that "ffmpeg shouldn't
> launch a browser" or similar - but that's not the topic.
> This is merely a technical question.

"ffmpeg should not launch a browser" or "this feature is out of scope for 
the ffmpeg" has technical aspects too, like we do not want to increase 
maintenance burden with features which can be done easily with basic 
scripting.

Regards,
Marton
_______________________________________________
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] The "bad" Patch

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Marton Balint
> Sent: Mittwoch, 28. Mai 2025 20:28
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] The "bad" Patch
> 
> 
> 
> On Wed, 28 May 2025, softworkz . wrote:
> 
> > Please note:
> >
> > I have no intentions towards getting this merged.
> >
> > It's a valid opinion when you think that "ffmpeg shouldn't
> > launch a browser" or similar - but that's not the topic.
> > This is merely a technical question.
> 
> "ffmpeg should not launch a browser" or "this feature is out of scope
> for
> the ffmpeg" has technical aspects too, like we do not want to increase
> maintenance burden with features which can be done easily with basic
> scripting.

That's one of the reasons for choosing system() and not have tons
of process launch code just to run a shell script.

Anyway, what you are saying is surely something that needs to be considered
and decided, but it's not something which makes it a "bad patch"
requiring immediate reversion, huge drama, a crazy mob, defamation,
with all its consequences.

That's why I meant it is not a relevant point in this "bad patch" context

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

Re: [FFmpeg-devel] The "bad" Patch

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> softworkz .
> Sent: Mittwoch, 28. Mai 2025 17:25
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: [FFmpeg-devel] The "bad" Patch

[..]

That nobody has responded is not much surprising, but don't worry, 
all actors will get covered.



Let's start with the origin and see how this story got poisoned in the first place

On IRC, 2025-05-15

21:25 <ramiro> oh, wow. are we really calling system(cmd)?
      => yes. it's done for reasons that I could explain if somebody would ask me
[..]
21:43 <jamrial> was this reviewed at all?
21:48 <BtbN> Not properly I guess, it is/was a huge patchset, and reviewing it is annoying with that Github-Forwarder
[..]
21:49 <BtbN> Why on earth does it even need to open a browser?
21:49 <BtbN> Just print the bloody url
21:52 <BtbN> And yeah, that commit message is super odd. On the ML I see a bunch of unresolved comments as well.
      => Hadn't looked properly. Later he named messages from revision 3 (but it was at v12 already)
[..]
21:53 <jamrial> someone was a bit too eager to push i guess
21:53 <jamrial> michaelni: maybe don't give push access to people so quickly...
[..]
22:16 <jkqxz> At least if you pass the sg option then it accidentally overwrites the user-supplied file name so it 
      can't be used directly for shell injection.
      => of course: when I do the right thing, it must be accidentally...
[..]


This is how mob-building works at a small-scale level.
Nobody might have had bad intentions in the first place.
But BtbN was already primed by his aversion towards the GitGitGadget submission I use, 
and that gave a direction, the others followed.
It still doesn't mean bad intentions, they had good will in fact.

But they had lost respect towards me at large - which had consequences.
This can be seen in their subsequent behavior:


James Almer (jamrial) 
=====================

Mailing List

"Absolutely not, wtf. Calling an external application like this?
Revert this patch or remove this effect immediately."
[He didn't even take the effort to put the comment at a place that corresponds to "like this?"]

"And there are still unresolved comments you didn't take into account 
before pushing this set."

[I responded that's not the case]

"No, there's no need to involve the TC when everyone is telling you that 
something is wrong. You pushed this set before even addressing all reviews."

[Repeated the same false claim, despite my response]


=> My questions to James

- Do you think it was right to spread out that false information without 
  validating yourself?
  I mean publicly - where many will be reading it and it will stick in their
  memory - possible for a long time.

- Do you think your reaction was adequate, not even really looking at the 
  patch like a developer and going crazy on the ML instead?
  Especially, when considering that nobody had objected in the same way when
  it would have had the equivalent code of system() in the patch?

- How would you have behaved when the patch would have been from somebody else
  (e.g. Andreas)?




Ramiro
======

He didn't let himself turn that much in the direction of the others.
He tried to be friendly and mediate. Just the ChatGPT texts were a bit odd.

=> Only one question to Ramiro

- How do you see the situation now, that you know that nobody would
  have objected (like this) when it would have had the inlined 
  implementation of system()?



Timo Rothenpieler (BtbN)
========================

When I make a mistake or do unjust to anybody, then I apologize clearly and
sincerely. 
But I also don't like demanding for apologies. Demanded apologies are more
a matter of humiliating someone and that's not my interest. Only sincere
apologies have a value in my eyes.

I hope he realizes at least how the false information that he had spread
had caused the situation to turn into a really bad direction.


=> Questions to Timo

- You have been the first and foremost strongest opponent of using the system
  API, even when others said that it's no longer a red flag when it's not done
  in lib code; you named things for why it's bad and must be reverted.
  Now that we see the full picture of the code, please explain your position:
  Is it still a "no-go" or not?
  If yes, could you please explain to me in detail what exactly is 
  bad about using that API in THIS WAY and in THIS CONTEXT?
  Which bad things can happen and how exactly?




Mark Thompson
=============

He's an exception. I think he is probably only one who has really looked at the 
code. He had made the single - and by far - most valid point at that time.
(about the temp directory determination).
He was friendly, respectful and professional.

Thanks Mark, much appreciated!
(I have no questions)


Best regards
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".

Re: [FFmpeg-devel] The "bad" Patch

[Nicolas George]

softworkz . (HE12025-05-29):
> That nobody has responded is not much surprising

Yes, nobody responded after less than twelve hours, that must be a
conspiracy.

-- 
  Nicolas George
_______________________________________________
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] The "bad" Patch

[Nicolas George]

softworkz . (HE12025-05-28):
>						 Also, I cannot 
> consider people as trustworthy while they are going crazy.

Oh, yes, I dare say insulting your betters is the best strategy.

I have no qualms saying « your betters » since I was barely involved in
this discussion.

> Misunderstanding 1: What is being launched?
> ===========================================

Explaining that there are a lot more code involved in this feature than
just a web browser is not the winning argument you think it is, quite
the opposite.

People have pointed to you the use of system() because it is an focal
point of all the wrong things, an easy way to get into the documentation
and learn about the issues of what you are doing.

> As far as I'm seeing it, an API can hardly be intrinsically bad.

This is just an incredibly shortsighted statement. Somebody capable of
saying something like that cannot be trusted with the design of an API.

> I have no intentions towards getting this merged.

Good. Maye get over yourself and find a safe way of implementing it
instead of using it as an excuse to play the victim.

Also, for pity's sake, stop sucking all the air from this mailing-list.

-- 
  Nicolas George, willing to endorse the necessary bad role here
_______________________________________________
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] The "bad" Patch

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Nicolas George
> Sent: Donnerstag, 29. Mai 2025 16:44
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] The "bad" Patch
> 
> softworkz . (HE12025-05-28):
> >						 Also, I cannot
> > consider people as trustworthy while they are going crazy.
> 
> Oh, yes, I dare say insulting your betters is the best strategy.

I'm afraid to see you struggling with language issues. To explain it in 
simple words: We all can have moments where we might get 
crazy about something. That's why it would be unfair and insulting 
to say that people who are getting crazy are not trustworthy.

What has been said instead, is that people who've gone crazy are not 
trustworthy IN THAT MOMENT (=> "while").


> > Misunderstanding 1: What is being launched?
> > ===========================================
> 
> People have pointed to you the use of system() because it is an focal
> point of all the wrong things

Oh - when you have knowledge about "all the wrong things", then I'm sure
it won't take you - the knowledgeable senior mentor member - much
effort, to educate me - the unexperienced novice developer, who had - in his 
ignorance and lack of knowledge - accidentally chosen to use a "bad" API.
Please be specific by explaining what is wrong about the specific use case and language,
and which bad things could happen!?


> an easy way [is] to get into the
> documentation and learn about the issues of what you are doing.

This gives just testimony that you've never read that documentation.


> > I have no intentions towards getting this merged.
> 
> Good. Maybe get over yourself and find a safe way of implementing it

Nay. Which part is not understandable in my reply?


> instead of using it as an excuse to play the victim.

That's in fact a great new thing that I've learned just recently here:

What an incredibly ingenious attack it is to attack someone by
saying they should not play "the victim".


[2nd email]
> > That nobody has responded is not much surprising
> Yes, nobody responded after less than twelve hours, that must be a
> conspiracy.

Not at all - but if none have responded after 12h, how likely
would it remain to be for the 

have been to get responses from everybody?
I.e., the probability for all replying under the condition that
nobody would have replied within the first 12h.

Wasn't "Math" a kind of hobby of yours? (evening school?)
Maybe you can ask your teacher about how this works.


> Also, for pity's sake, stop sucking all the air from this mailing-list.

Oh well, this is just the prologue. The main chapter is yet to come.
But I'll give it a little time for the questions. These are serious and 
not of rhetorical nature.


Regards,
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".

Re: [FFmpeg-devel] The "bad" Patch

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of softworkz .
> Sent: Donnerstag, 29. Mai 2025 04:59
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] The "bad" Patch


Two and a half days have passed and nobody has answered any of the questions
from my previous post. This speaks for itself.

What really happened, is that some had seen my use of system() and 
since this is commonly known as a "dangerous" API when not used carefully,
they did lazy judgement without due diligence and without detailed 
assessment.
The judgement was based on commonplace knowledge instead: 
system() => is-bad => patch is bad


Looking at the specific case and way of usage (and how system() works
internally) would have revealed that this doesn't apply here. 

=> The patch was NOT bad at all
=> All review comments were addressed when it was pushed

(the second part is evident anyway)



More Facts
==========

Patches 1-12 had no issues.
Yes, patches 13 and 14 had minor issues - but nothing more.
(You think these were big issues? Let me know and I'll collect a list
of issues in commits that you have pushed and which weren't 
all perfect).

In 2025, I have 42 commits in total, no issues came up for any
others. It's 89 commits in total, the first one from 2016. It's not 
a huge figure, but I'm in no way new to FFmpeg.

Some had alluded that I wouldn't have a track record of more 
"complex" patches. Indeed, many of those that I have in public 
ffmpeg are smaller ones (but by far not all trivial). 
In addition, there are still two really complex examples to look at:

1. The first 9 commits by 'Artem Galim'. That was about adding D3D11 
   support for QSV on Windows. 95% of that is code that I had 
   written and used 2.5 years before already and eventually handed
   over to Intel.
   (can be proven in several ways)
   
2. Subtitle Filtering Patchset
   Even though it didn't get merged (it was about nits, not quality), 
   many are using it and I regularly get mails asking for a rebased
   version. Also, it is running on a number of machines all over 
   the world, which has a lot of zeros.


Why am I writing all this?
==========================

Because the only reasonable way to counter defamation like it had
occurred is providing facts.

And one of those facts is that there was no bad patch!

(to be continued)

Best regards,
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".

Re: [FFmpeg-devel] The "bad" Patch

[Mark Thompson]

On 31/05/2025 12:44, softworkz . wrote:
>> -----Original Message-----
>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of softworkz .
>> Sent: Donnerstag, 29. Mai 2025 04:59
>> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
>> Subject: Re: [FFmpeg-devel] The "bad" Patch
> 
> 
> Two and a half days have passed and nobody has answered any of the questions
> from my previous post. This speaks for itself.
> 
> What really happened, is that some had seen my use of system() and 
> since this is commonly known as a "dangerous" API when not used carefully,
> they did lazy judgement without due diligence and without detailed 
> assessment.
> The judgement was based on commonplace knowledge instead: 
> system() => is-bad => patch is bad
> 
> 
> Looking at the specific case and way of usage (and how system() works
> internally) would have revealed that this doesn't apply here. 
> 
> => The patch was NOT bad at all
> => All review comments were addressed when it was pushed
> 
> (the second part is evident anyway)

The actions being taken in your patch (including but not limited to calling system()) were dangerous and the patch failed to prevent exploitation of the new features.

I think the point you are missing boils down to: what is the threat model of ffmpeg?

Your patch is built on the assumption that ffmpeg will only ever be run on single-user systems where many things can be trusted, but this is not the case.

In reality, ffmpeg is often used on multi-user systems and called in strange ways from network services where many inputs are not trusted.

In particular:
* ffmpeg cannot trust anything which does not come from a known-trusted source (in practice this means it can trust little beyond its own binary).
* ffmpeg must not assume that it is the only user on the system (anything which can be touched by another user at runtime may be modified).
* ffmpeg should not in general trust the environment (it may be launched from a service which has allowed nasty things to be injected into the environment), though this may be allowed in specific well-known cases.
* ffmpeg should not excessively trust its command-line arguments, as the caller may not have properly vetted them (in practice some nasty cases have to be allowed for the program to work at all).

The main thing that it must prevent is any sort of code execution in the context of the current user, whether that be binary code in the current process or by launching another process running code which came from an untrusted source.

Your patch was dangerous in at least the following ways:
* It interacts with temporary directories in unsafe ways.
* It trusts values coming from the environment.
* It runs a shell with arguments which could have come from an untrusted source.

The last one of those is completely unacceptable and I believe it lead people to reject the patch out of hand without considering anything else.

Some example exploits:
* Another user on a shared system observes the user of the common temporary directory.  They create a file with the predictable name before your code does, then manipulate its contents.  The command to open it then runs code under the attacker's control as the victim user.
* The attacker manipulates the environment to inject their own code into the call to system(), running shell commands as the victim user (I gave a specific example of this in a previous email).

This list is not exhaustive at all, so please do not treat it as a set of specific things to fix - there are very likely other paths for the attacker to achieve code execution in the context of the current user that I am not sufficiently clever to think of as the patch is not written in a secure and robust way.

More generally, I am unsure whether anyone here believes themselves competent to review a patch which securely and robustly performs these sorts of very dangerous actions (I do not believe myself to be), so in practice ffmpeg developers will prefer to never include any code which performs such actions.

Thanks,

- Mark

_______________________________________________
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] The "bad" Patch

[softworkz .]

(this is the 2nd last message)



Final Chapter
=============

Some people here don't like me - that's okay. I'm honest, direct,
I say what I'm thinking, often not very diplomatic, and I know which  
results it causes sometimes. 
But that a few people kind-of tried campaigning against me - even 
neglecting facts against better knowledge - that came to me as a 
surprise, given that I'm not attacking anybody personally
(except Nicolas, who's begging for it). I don't know what I've done
which might have pulled a trigger for some, so I can't comment.


Let's get to the cast of the final chapter:

- Lynne
- Nicolas George
- Kieran Kunyar

They were acting as some kind of boosters, blowing up and spreading
things, including false facts or distorted views of the situation.



Lynne
=====

I had sensed a hostile attitude for some time which became
eventually visible here, one week before patchset was pushed:

Quotes:

IRC, 2025-05-08
11:20 <Lynne> I think it was too early to give softworkz push access

What's remarkable is that I haven't pushed anything between 
2025-05-03 and 2025-05-15. I had just sent patches to the ML that 
day.. - so, this statement cannot have been about a pushed commit.


I might be mistaken, but it very much looked to me like she had 
just been waiting until I'd make some (seeming) mistake.
After I had pushed the patchset:


IRC, 2025-05-16
11:25 <Lynne> softworkz: you've been refusing to use proper submission
procedures, tried to introduce your own, you've pushed bad patches and
did not even consider that calling external programs from a binary
directly was inherently bad.

11:26 <Lynne> I don't think you deserve your push privileges

11:27 <Lynne> softworkz: last month you even had to publicly ask on
the mailing list about a policy which pretty much everyone understood


A full load thrown at me, all points having turned out to be pointless,
also accusing me for asking a question on the mailing list - like a kind 
of failed attempt for finding once another bad thing I would have done.

Ref "bad patch": this conversation
Ref "proper submission procedures":
https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2025-May/343806.html
Ref "Question on the Mailing List":
https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2025-May/343107.html


When I'd be asked what a bad patch is - then I'd say that a patch that
is pushed, which breaks FATE is definitely a "bad patch". 
As we know now that my patch 15/15 was NOT bad and I've never 
pushed a commit that breaks FATE, this means that _my_ 
"bad-patch-count" is zero. 
While not everybody has a count of zero, I'm not going to make 
a big thing out of it.



Nicolas George
==============

He appears to be desperately looking for a slave developer who is
looking up to him and follows his instructions. Why he doesn't
realize that I'm the least suitable person on the planet for 
this figment, is a mystery to me.
I'm still surprised that he made it into this cast. Normally,
he is running his own show without jumping on others' trains. 
Seems he couldn't resist to this opportunity. 
I'm pretty sure he had looked at the patchset. He followed the
development and revisions more than anybody else and made a
lot of comments, to several commits and was involved in the 
discussions about the AVTextFormat API.

Quotes:

2025-05-22
I think giving softworkz the authority to decide if his own 
patches are ready for inclusion was premature.

2025-05-16
[to Michael] In particular I think you granted Git access too soon. 
A track record of multiple non-trivial patches and useful reviews 
should have been necessary.


=> He knows my subtitle filtering patchset and he has seen many
   reviews I did in earlier years.
   
=> So, this is just feigned ignorance, disguised under the 
   guise of reason.



Kieran Kunhya
=============

I don't know much about him, other than sometimes making aggressive
posts. He came right out of nowhere and started campaigning against 
me and the whole patchset. Obviously, he had never looked at 
it before.

Quotes:

2025-05-22
I really wonder how you can't be embarrassed sending what imo is the
worst patchset in the history of the project.

2025-05-22
A patchset so bad, people who quit the project like Derek came back
to clean up your mess.


Almost hilarious, if it wouldn't be a serious matter with a clear 
intention to defame me.



(next message will be the final)

Best regards,
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".

Re: [FFmpeg-devel] The "bad" Patch

[softworkz .]

CONCLUSIONS
===========

Meanwhile it should have become clear that this conversation is not about
whether the 15/15 patchset gets or should have gotten included or not.
It's about the things that happened around it and how they happened:

=> False statements like I would have pushed without addressing all reviews

=> A patch that was quickly brandmarked even though almost nobody had looked at it
   without any discussion and assessment

=> Claims like "softworkz is pushing bad patches"

=> softworkz shouldn't have been given commit rights

=> it's the worst patchset in the history of the project


That chain of events is what is just not acceptable.
It is in no way adequate or appropriate.

Everybody who has been part of that chain should think about this.
I'm sure that many didn't have the intention to achieve this outcome.

But unfortunately, there's one or another who has worked on moving this
forward in a way to achieve that outcome exactly.
To those persons, I want to be very clear: Trying those things on me will
never work out, as I will always try 10 times harder against it and the
result for those will be very different and more impactful in case anybody
would ever try again to strategically and purposefully and against better
knowledge defame or discredit me.


I don't want all this. I don't want to deal with such things, I just want 
to collaborate in a friendly and professional way. Anybody - without 
exception - who is getting back to me in a friendly way will receive a 
friendly response, no matter what happened yesterday. I have no hard feelings
in this at all - it's just work and it has been pretty annoying that
I had to write all those messages. Still, I cannot leave all those untrue
statements lying around without context.

You will see a number of messages which are linking to this conversation
from other conversations. I apologize in advance for that spam, but it 
wasn't me who created the situation.


Best regards,
softworkz

_______________________________________________
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] The "bad" Patch

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Mark
> Thompson
> Sent: Samstag, 31. Mai 2025 18:21
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] The "bad" Patch
> 
> On 31/05/2025 12:44, softworkz . wrote:
> >> -----Original Message-----
> >> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of softworkz
> .
> >> Sent: Donnerstag, 29. Mai 2025 04:59
> >> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> >> Subject: Re: [FFmpeg-devel] The "bad" Patch
> >
> >
> > Two and a half days have passed and nobody has answered any of the questions
> > from my previous post. This speaks for itself.
> >
> > What really happened, is that some had seen my use of system() and
> > since this is commonly known as a "dangerous" API when not used carefully,
> > they did lazy judgement without due diligence and without detailed
> > assessment.
> > The judgement was based on commonplace knowledge instead:
> > system() => is-bad => patch is bad
> >
> >
> > Looking at the specific case and way of usage (and how system() works
> > internally) would have revealed that this doesn't apply here.
> >
> > => The patch was NOT bad at all
> > => All review comments were addressed when it was pushed
> >
> > (the second part is evident anyway)


Hi Mark,

thanks a lot for your reply, much appreciated.

When you have read the last two (final) messages of this conversation, it
should have become clear that what I'm up to has never been whether the 
patch would get merged/reverted or not. It is about the way how it happened.
Without anybody looking closer (except yours at least), the patch was 
brandmarked as "bad" >> sw is pushing bad patches >> and everything that
followed.


Everything you wrote (below) is totally valid and needs careful consideration.
Such considerations and discussion have just never happened. When the outcome 
would have been that it cannot be done safely enough, that would have been 
totally fine as well, I never had the idea that this must get into FFmpeg 
by all means. 


> I think the point you are missing boils down to: what is the threat model of
> ffmpeg?
> 
> Your patch is built on the assumption that ffmpeg will only ever be run on
> single-user systems where many things can be trusted, but this is not the
> case.

No, that hasn't been my assumption. 


> In reality, ffmpeg is often used on multi-user systems and called in strange
> ways from network services where many inputs are not trusted.

None of such systems have xdg-open


> In particular:
> * ffmpeg cannot trust anything which does not come from a known-trusted source
> (in practice this means it can trust little beyond its own binary).
> * ffmpeg must not assume that it is the only user on the system (anything
> which can be touched by another user at runtime may be modified).
> * ffmpeg should not in general trust the environment (it may be launched from
> a service which has allowed nasty things to be injected into the environment),
> though this may be allowed in specific well-known cases.
> * ffmpeg should not excessively trust its command-line arguments, as the
> caller may not have properly vetted them (in practice some nasty cases have to
> be allowed for the program to work at all).

All valid, for sure.


> The main thing that it must prevent is any sort of code execution in the
> context of the current user, whether that be binary code in the current
> process or by launching another process running code which came from an
> untrusted source.
> 
> Your patch was dangerous in at least the following ways:
> * It interacts with temporary directories in unsafe ways.
> * It trusts values coming from the environment.
> * It runs a shell with arguments which could have come from an untrusted
> source.

That's three bullets, but a single thing and the one from which I had 
already said this was the one flaw it had. It's fixed in the updated version:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/d44acee0a6f1021669f57641b1f1875d8dbe51c5.1748445849.git.ffmpegagent@gmail.com/
Series: https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=14631

The reason why I've fixed it, is again not about getting it merged but
about the question: Now that this part is fixed, what is still bad
about using system()?

That's the single question I'm asking, because the rejection was 
about use of system(), not about the temp folder routine (you were the
only one who's even seen it, even though the file wasn't really
big).


> Some example exploits:
> * Another user on a shared system observes the user of the common temporary
> directory.  They create a file with the predictable name before your code
> does, then manipulate its contents.  The command to open it then runs code
> under the attacker's control as the victim user.

- The file name is built from the local time with milliseconds. Pretty hard to
  hit
- In v2, a temp-directory specific to the current user is created. Other users
  have no access
- The file is an html file which will be launched by a browser from file:///
  url, means it is treated with extra safety and isolation. There's hardly anything
  you could achieve these days from a local html page

> * The attacker manipulates the environment to inject their own code into the
> call to system(), running shell commands as the victim user (I gave a specific
> example of this in a previous email).

Yes, that's fixed, no more env variables are used at all. This was the 
one flaw it actually had.


> This list is not exhaustive at all, so please do not treat it as a set of
> specific things to fix - there are very likely other paths for the attacker to
> achieve code execution in the context of the current user that I am not
> sufficiently clever to think of as the patch is not written in a secure and
> robust way.
> More generally, I am unsure whether anyone here believes themselves competent
> to review a patch which securely and robustly performs these sorts of very
> dangerous actions (I do not believe myself to be), so in practice ffmpeg
> developers will prefer to never include any code which performs such actions.

Many other CLI tools are launching browsers, so that's not really rocket 
science like you're trying to allude to. I still agree to the degree that
there's always a "you-never-know factor". At that point, it's much more effective
and secure to bring additional factors into the game. These could be like:


1. Requiring a one-time setup

For example, on first use of the feature, it says "please run once with sudo to
enable the feature". When done, it writes some file somewhere with the uid for
which it should be allowed and appropriate permissions.

2. Requiring user input 

Like a key press to launch, after which it is enabled for a while to auto-launch

3. Checking console env for whether it's an interactive session 

Not sure to which extent that's possible and safe

4. Check uid

Don't do it when 0

5. Check existence of xdg-open and/or browser

possibly even content of xdg-open


------------

Of course I haven't done any of this, because I had expected that there 
would be a review/discussion to determine a direction. 

Or the outcome would have been a "No, we don't want this". Also fine.


Just the actual outcome was very wrong.

Thanks a lot for writing back!

Best regards,
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".

Re: [FFmpeg-devel] The "bad" Patch

[Kieran Kunhya via ffmpeg-devel]

>
> Let's get to the cast of the final chapter:
>
> - Lynne
> - Nicolas George
> - Kieran Kunyar
>
> The fact all of us (who normally disagree on various technical topics)
agree about the deficiencies of your patch speaks volumes.

Kieran

>
_______________________________________________
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] The "bad" Patch

[Leo Izen]

On 5/28/25 11:24, softworkz . wrote:
> Hello everybody,
> 
> it's about 14 days ago, on Thursday, 2025-05-15, when I had applied
> my "Execution Graph Printing" patchset after 12 revisions and 3
> reminder e-mails sent to the ML.

Please, as a bystander here who was not involved in the review or the 
discussion thereof, this is kind of email complaining about specific 
people is basically spam.

If you have issues with specific members please report them to the CC. A 
callout post on the public mailing list is not doing anybody any favors, 
including for yourself.

- Leo Izen (Traneptora)


_______________________________________________
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] The "bad" Patch

[Marvin Scholz]

On 31 May 2025, at 21:31, Leo Izen wrote:

> On 5/28/25 11:24, softworkz . wrote:
>> Hello everybody,
>>
>> it's about 14 days ago, on Thursday, 2025-05-15, when I had applied
>> my "Execution Graph Printing" patchset after 12 revisions and 3
>> reminder e-mails sent to the ML.
>
> Please, as a bystander here who was not involved in the review or the discussion thereof, this is kind of email complaining about specific people is basically spam.
>
> If you have issues with specific members please report them to the CC. A callout post on the public mailing list is not doing anybody any favors, including for yourself.
>

I second this.

> - Leo Izen (Traneptora)
>
>
> _______________________________________________
> 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 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] The "bad" Patch

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Leo Izen
> Sent: Samstag, 31. Mai 2025 21:31
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] The "bad" Patch
> 
> 
> On 5/28/25 11:24, softworkz . wrote:
> > Hello everybody,
> >
> > it's about 14 days ago, on Thursday, 2025-05-15, when I had applied
> > my "Execution Graph Printing" patchset after 12 revisions and 3
> > reminder e-mails sent to the ML.
> 
> Please, as a bystander here who was not involved in the review or the
> discussion thereof, this is kind of email complaining about specific
> people is basically spam.
> 
> If you have issues with specific members please report them to the CC. A
> callout post on the public mailing list is not doing anybody any favors,
> including for yourself.

It's not about interpersonal issues. It's about defaming information
that has been posted publicly and I take the liberty to consume at 
least the same amount of public surface than the aforementioned.

I am very sorry for the inconvenience this is causing.

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

Re: [FFmpeg-devel] The "bad" Patch

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of softworkz .
> Sent: Samstag, 31. Mai 2025 22:09
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] The "bad" Patch
> 
> 
> 
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Leo Izen
> > Sent: Samstag, 31. Mai 2025 21:31
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] The "bad" Patch
> >
> >
> > On 5/28/25 11:24, softworkz . wrote:
> > > Hello everybody,
> > >
> > > it's about 14 days ago, on Thursday, 2025-05-15, when I had applied
> > > my "Execution Graph Printing" patchset after 12 revisions and 3
> > > reminder e-mails sent to the ML.
> >
> > Please, as a bystander here who was not involved in the review or the
> > discussion thereof, this is kind of email complaining about specific
> > people is basically spam.
> >
> > If you have issues with specific members please report them to the CC. A
> > callout post on the public mailing list is not doing anybody any favors,
> > including for yourself.
> 
> It's not about interpersonal issues. It's about defaming information
> that has been posted publicly and I take the liberty to consume at
> least the same amount of public surface than the aforementioned.
> 
> I am very sorry for the inconvenience this is causing.
> 
> Thanks
> sw
> _______________________________________________

To clear up what's going to happen: There will be a few referencing 
messages in the next 2h - and then it's all done.

Thanks for your understanding
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".

Re: [FFmpeg-devel] The "bad" Patch

[Mark Thompson]

On 31/05/2025 19:28, softworkz . wrote:
>> -----Original Message-----
>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Mark
>> Thompson
>> Sent: Samstag, 31. Mai 2025 18:21
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] The "bad" Patch
>>
>> On 31/05/2025 12:44, softworkz . wrote:
>>>> -----Original Message-----
>>>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of softworkz
>> .
>>>> Sent: Donnerstag, 29. Mai 2025 04:59
>>>> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
>>>> Subject: Re: [FFmpeg-devel] The "bad" Patch
>>>
>>>
>>> Two and a half days have passed and nobody has answered any of the questions
>>> from my previous post. This speaks for itself.
>>>
>>> What really happened, is that some had seen my use of system() and
>>> since this is commonly known as a "dangerous" API when not used carefully,
>>> they did lazy judgement without due diligence and without detailed
>>> assessment.
>>> The judgement was based on commonplace knowledge instead:
>>> system() => is-bad => patch is bad
>>>
>>>
>>> Looking at the specific case and way of usage (and how system() works
>>> internally) would have revealed that this doesn't apply here.
>>>
>>> => The patch was NOT bad at all
>>> => All review comments were addressed when it was pushed
>>>
>>> (the second part is evident anyway)
> 
> 
> Hi Mark,
> 
> thanks a lot for your reply, much appreciated.
> 
> When you have read the last two (final) messages of this conversation, it
> should have become clear that what I'm up to has never been whether the 
> patch would get merged/reverted or not. It is about the way how it happened.
> Without anybody looking closer (except yours at least), the patch was 
> brandmarked as "bad" >> sw is pushing bad patches >> and everything that
> followed.
> 
> 
> Everything you wrote (below) is totally valid and needs careful consideration.
> Such considerations and discussion have just never happened. When the outcome 
> would have been that it cannot be done safely enough, that would have been 
> totally fine as well, I never had the idea that this must get into FFmpeg 
> by all means. 
> 
> 
>> I think the point you are missing boils down to: what is the threat model of
>> ffmpeg?
>>
>> Your patch is built on the assumption that ffmpeg will only ever be run on
>> single-user systems where many things can be trusted, but this is not the
>> case.
> 
> No, that hasn't been my assumption. 
> 
> 
>> In reality, ffmpeg is often used on multi-user systems and called in strange
>> ways from network services where many inputs are not trusted.
> 
> None of such systems have xdg-open

xdg-open is in most default install of Linux distributions (indeed, that's why you use it), so I don't think it is a reasonable assumption that it would not be there.

>> In particular:
>> * ffmpeg cannot trust anything which does not come from a known-trusted source
>> (in practice this means it can trust little beyond its own binary).
>> * ffmpeg must not assume that it is the only user on the system (anything
>> which can be touched by another user at runtime may be modified).
>> * ffmpeg should not in general trust the environment (it may be launched from
>> a service which has allowed nasty things to be injected into the environment),
>> though this may be allowed in specific well-known cases.
>> * ffmpeg should not excessively trust its command-line arguments, as the
>> caller may not have properly vetted them (in practice some nasty cases have to
>> be allowed for the program to work at all).
> 
> All valid, for sure.
> 
> 
>> The main thing that it must prevent is any sort of code execution in the
>> context of the current user, whether that be binary code in the current
>> process or by launching another process running code which came from an
>> untrusted source.
>>
>> Your patch was dangerous in at least the following ways:
>> * It interacts with temporary directories in unsafe ways.
>> * It trusts values coming from the environment.
>> * It runs a shell with arguments which could have come from an untrusted
>> source.
> 
> That's three bullets, but a single thing and the one from which I had 
> already said this was the one flaw it had. It's fixed in the updated version:
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/d44acee0a6f1021669f57641b1f1875d8dbe51c5.1748445849.git.ffmpegagent@gmail.com/
> Series: https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=14631
> 
> The reason why I've fixed it, is again not about getting it merged but
> about the question: Now that this part is fixed, what is still bad
> about using system()?
> 
> That's the single question I'm asking, because the rejection was 
> about use of system(), not about the temp folder routine (you were the
> only one who's even seen it, even though the file wasn't really
> big).

Doing this sort of thing in a secure and robust way is well-known to be a difficult problem.

It does not seem unreasonable for people to treat the appearance of a vulnerable call to system() like seeing self-rolled cryptography: the submitter is almost certainly either incompetent or malicious, and can be safely ignored.

In some cases they may in fact be capable and benign, but it is up to the submitter to show when doing that that they understand all of the issues and have properly dealt all of them.  You did not do this, and indeed your implementation was easily exploited.

>> Some example exploits:
>> * Another user on a shared system observes the user of the common temporary
>> directory.  They create a file with the predictable name before your code
>> does, then manipulate its contents.  The command to open it then runs code
>> under the attacker's control as the victim user.
> 
> - The file name is built from the local time with milliseconds. Pretty hard to
>   hit

No, trivial to hit given that creating a file and watching whether it gets touched (inotify) are very low cost operations.

> - In v2, a temp-directory specific to the current user is created. Other users
>   have no access

Your new method does not work because the attacker could have created the temporary directory (world-writeable) before the ffmpeg process does.

> - The file is an html file which will be launched by a browser from file:///
>   url, means it is treated with extra safety and isolation. There's hardly anything
>   you could achieve these days from a local html page

Is there some general citation for this?

I would naively expect browsers to assign greater trust to local rather than remote files and possibly allow some additional capabilities to scripts running in them, but I admit I have no familiarity with this area so I may be completely wrong.

>> * The attacker manipulates the environment to inject their own code into the
>> call to system(), running shell commands as the victim user (I gave a specific
>> example of this in a previous email).
> 
> Yes, that's fixed, no more env variables are used at all. This was the 
> one flaw it actually had.

Some further thoughts on your new patch which you will undoubtably have already considered:

* What happens if the system argument string exceeds the allowed command argument length?

* What happens if /bin/sh is not bash?

* What happens if the attacker successfully contrives a transient out-of-memory condition during any of the calls to av_bprintf()?  (As they can do on a shared machine.)

(The Windows implementation is not changed and does not look robust, I assume you have not revised it.)

>> This list is not exhaustive at all, so please do not treat it as a set of
>> specific things to fix - there are very likely other paths for the attacker to
>> achieve code execution in the context of the current user that I am not
>> sufficiently clever to think of as the patch is not written in a secure and
>> robust way.
>> More generally, I am unsure whether anyone here believes themselves competent
>> to review a patch which securely and robustly performs these sorts of very
>> dangerous actions (I do not believe myself to be), so in practice ffmpeg
>> developers will prefer to never include any code which performs such actions.
> 
> Many other CLI tools are launching browsers, so that's not really rocket 
> science like you're trying to allude to.

I agree.  Rocketry seems to be generally reliable and successful when compared to computer security, where people forever find new vulnerabilities in supposedly secure and audited programs.

I would hope that other CLI tools doing this have carefully documented the circumstances in which they do so to ensure that they don't get used in cases where it might cause problems.

>                                          I still agree to the degree that
> there's always a "you-never-know factor". At that point, it's much more effective
> and secure to bring additional factors into the game. These could be like:
> 
> 
> 1. Requiring a one-time setup
> 
> For example, on first use of the feature, it says "please run once with sudo to
> enable the feature". When done, it writes some file somewhere with the uid for
> which it should be allowed and appropriate permissions.
> 
> 2. Requiring user input 
> 
> Like a key press to launch, after which it is enabled for a while to auto-launch
> 
> 3. Checking console env for whether it's an interactive session 
> 
> Not sure to which extent that's possible and safe
> 
> 4. Check uid
> 
> Don't do it when 0
> 
> 5. Check existence of xdg-open and/or browser
> 
> possibly even content of xdg-open
> 
> 
> ------------
> 
> Of course I haven't done any of this, because I had expected that there 
> would be a review/discussion to determine a direction. 
> 
> Or the outcome would have been a "No, we don't want this". Also fine.

I think this outcome is the clear answer at this point.

My point here is really that I don't believe the security implications of the patch were considered at all in the initial submission, and are still not being treated properly in the revised version.  While some responses may not have been ideally formulated they were directionally correct.

Thanks,

- Mark

_______________________________________________
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] The "bad" Patch

[Michael Niedermayer]

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

On Sat, May 31, 2025 at 05:34:14PM +0000, softworkz . wrote:
> CONCLUSIONS
> ===========
> 
> Meanwhile it should have become clear that this conversation is not about
> whether the 15/15 patchset gets or should have gotten included or not.
> It's about the things that happened around it and how they happened:
> 
> => False statements like I would have pushed without addressing all reviews
> 
> => A patch that was quickly brandmarked even though almost nobody had looked at it
>    without any discussion and assessment
> 
> => Claims like "softworkz is pushing bad patches"
> 
> => softworkz shouldn't have been given commit rights
> 
> => it's the worst patchset in the history of the project
> 
> 
> That chain of events is what is just not acceptable.
> It is in no way adequate or appropriate.
> 
> Everybody who has been part of that chain should think about this.
> I'm sure that many didn't have the intention to achieve this outcome.
> 
> But unfortunately, there's one or another who has worked on moving this
> forward in a way to achieve that outcome exactly.
> To those persons, I want to be very clear: Trying those things on me will
> never work out, as I will always try 10 times harder against it and the
> result for those will be very different and more impactful in case anybody
> would ever try again to strategically and purposefully and against better
> knowledge defame or discredit me.
> 
> 
> I don't want all this. I don't want to deal with such things, I just want 
> to collaborate in a friendly and professional way. Anybody - without 
> exception - who is getting back to me in a friendly way will receive a 
> friendly response, no matter what happened yesterday. I have no hard feelings
> in this at all - it's just work and it has been pretty annoying that
> I had to write all those messages. Still, I cannot leave all those untrue
> statements lying around without context.
> 
> You will see a number of messages which are linking to this conversation
> from other conversations. I apologize in advance for that spam, but it 
> wasn't me who created the situation.

Not sure if 90% of people agree or 90% disagree with me but
Id like you to be in the next community committee. (together with marth64)

Because it seems you seriously care about stoping defamations and the
general sozial backstabbing that has appeared in the recent decade

and also documenting precissely what everyone said.

Just seems these attributes would be valuable for the community committee

thx

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

Avoid a single point of failure, be that a person or equipment.

[-- 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] The "bad" Patch

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Michael
> Niedermayer
> Sent: Montag, 2. Juni 2025 01:22
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] The "bad" Patch
> 
> On Sat, May 31, 2025 at 05:34:14PM +0000, softworkz . wrote:
> > CONCLUSIONS
> > ===========
> >
> > Meanwhile it should have become clear that this conversation is not about
> > whether the 15/15 patchset gets or should have gotten included or not.
> > It's about the things that happened around it and how they happened:
> >
> > => False statements like I would have pushed without addressing all reviews
> >
> > => A patch that was quickly brandmarked even though almost nobody had looked
> at it
> >    without any discussion and assessment
> >
> > => Claims like "softworkz is pushing bad patches"
> >
> > => softworkz shouldn't have been given commit rights
> >
> > => it's the worst patchset in the history of the project
> >
> >
> > That chain of events is what is just not acceptable.
> > It is in no way adequate or appropriate.
> >
> > Everybody who has been part of that chain should think about this.
> > I'm sure that many didn't have the intention to achieve this outcome.
> >
> > But unfortunately, there's one or another who has worked on moving this
> > forward in a way to achieve that outcome exactly.
> > To those persons, I want to be very clear: Trying those things on me will
> > never work out, as I will always try 10 times harder against it and the
> > result for those will be very different and more impactful in case anybody
> > would ever try again to strategically and purposefully and against better
> > knowledge defame or discredit me.
> >
> >
> > I don't want all this. I don't want to deal with such things, I just want
> > to collaborate in a friendly and professional way. Anybody - without
> > exception - who is getting back to me in a friendly way will receive a
> > friendly response, no matter what happened yesterday. I have no hard
> feelings
> > in this at all - it's just work and it has been pretty annoying that
> > I had to write all those messages. Still, I cannot leave all those untrue
> > statements lying around without context.
> >
> > You will see a number of messages which are linking to this conversation
> > from other conversations. I apologize in advance for that spam, but it
> > wasn't me who created the situation.
> 
> Not sure if 90% of people agree or 90% disagree with me but
> Id like you to be in the next community committee. (together with marth64)
> 
> Because it seems you seriously care about stoping defamations and the
> general sozial backstabbing that has appeared in the recent decade
> 
> and also documenting precissely what everyone said.
> 
> Just seems these attributes would be valuable for the community committee
> 

Hi Michael,

thanks a lot for the friendly words. Essentially, I do care about community 
behavior and even more about being truthful and honest.
I'm not sure whether I would be a suitable member for the CC. I think these
positions need to occupied by persons who are trusted by many in the 
community and I'm well aware that some have reservations towards me - which 
I can perfectly understand. I have been loud at times and voiced minority
opinions. Others may have longer lists 😊

In general, there are many qualities I have to offer, but I would say that
mediation and diplomatic negotiations are not in a top position there.
From what I've seen some of the current CC members writing, those guys are
much more suitable for the job than I would be.

But thanks for suggesting me,
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".

Re: [FFmpeg-devel] The "bad" Patch

[softworkz .]

An additional note:


While there are opinionated elements of course, I have tried to keep 
everything factually correct in this series of messaged to the best
of my knowledge. 

If somebody thinks that I would have told anything that is clearly 
untrue, please let me know. 
Then I will correct and clarify it and apologize with the affected 
one(s) - like every sane person does.

Being truthful and sincere is essential and a high value. Especially
in such environments. That's what I'm aiming for and I don't want to
do unjust to anybody.
---

It has been said so many times by so many people that FFmpeg is 
the most toxic community of all.
Now - this is probably the first time that this toxicity has been 
documented in detail - in this conversation.


(written yesterday, before Michael's message, alluding to the same)
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".

Re: [FFmpeg-devel] The "bad" Patch

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Mark
> Thompson
> Sent: Samstag, 31. Mai 2025 22:26
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] The "bad" Patch
> 

Hello Mark,


(I've re-ordered some parts to unclutter the conversation)


> It does not seem unreasonable for people to treat the appearance of a
> vulnerable call to system() like seeing self-rolled cryptography: the
> submitter is almost certainly either incompetent or malicious, and can be
> safely ignored.

That's great because this gets to the essence of what we're talking
about and here I beg to differ:

My point is that exactly this way of judgement you are describing 
is itself a sign of incompetence instead.

This isn't meant to be a rhetoric or flaming statement. It follows from
the simple and confirmed reasoning that hardly anybody would have 
recognized or objected when I would have included the internal implementation
of system() instead. This invalidates the former in total.

But "incompetence" was your word. I wouldn't call it like that because 
I do not want to insult anybody and I do not deem anybody here to be.
Rather would I call it "lazy judgement", as that's what's happened:

One said: "I've seen system()"
And a choir started singing: "Bad, bad, revert, revert" - without 
looking at the code, without own judgement and consideration.

(except yours and possibly others who didn't sing)


> In some cases they may in fact be capable and benign

Thanks for confirming this explicitly.


> but it is up to the submitter to show when doing that that they understand 
> all of the issues and have properly dealt all of them. 

This code is what I had posted for review. I have sufficient experience 
with FFmpeg submissions to know that it is just stupid to work days
on something where there's a chance to get rejected anyway, so it
was done to be fairly safe but without specific effort on hardening.


> You did not do this, and indeed your
> implementation was easily exploited.

Oh, how do you come to that idea? I have conceded that it's better 
not to rely on any environment variable - but what you've shown is
not an exploit:

$ export TMPDIR="'; rm -rf / ;'\\\\"
$ ./ffmpeg -sg -i /dev/null -f null -

as then you could do

$ rm -rf /

right away.


A system (more precisely: user session) where an attacker has 
the ability to set arbitrary env variables to arbitrary values
must already be considered as compromised. 

Setting variables like..

LD_PRELOAD, LD_LIBRARY_PATH, LD_AUDIT, PYTHONPATH
PATH, SHELL, EDITOR, PAGER, SSH_ASKPASS, GIT_SSH
LOCPATH, TERMINFO, ICONV_PATH, NODE_OPTIONS

..is more than enough for an attacker to get anywhere they want
and without need to go through an FFmpeg feature

Regarding realistic exploitability of this, we are talking about very 
specific niche cases like for example:

- an attacker cannot set arbitrary env variables, but TMPDIR only
- and they can control the FFmpeg command line that is executed

When these things coincide, then it could be exploited.
There are surely other variants, but in total still a very small attack
surface (I'm excluding cases with arbitrary env manipulation, because 
FFmpeg/-sg is not needed for anything then).

So, to conclude on this: "easily exploitable" => no way
but still a valid point as I had already conceded.

---

> My point here is really that I don't believe the security implications of the
> patch were considered at all in the initial submission

Like said above, I haven't spent extra time on this as I wasn't sure where
it might go. The primary consideration for the initial submission 
was: How to execute?

For Windows it was clear, but for Linux I had looked around how others are 
doing it. Where system was not used, there was always a lot of code involved,
which made me afraid for two reasons:

1. I wasn't sure about the range of platform support - i.e. where to draw
   the lines between one or another implementation
2. I could already visualize the potential objections from others against
   so much process management code.

Eventually, I looked at glibc's system() code, first the latest code
using clone or clone3 which I hadn't seen much usages of in the wild, and 
then I went back to an earlier version (which matches my Ubuntu VM), and I
realized that this is pretty much the same code that I'm seeing at other 
places where shell invocations are done.
This seemed perfect to me: same procedure like others use, but with a single 
line of code.

And that's how I knew that using system() is okay.

I'm not a frequent Linux platform developer, so I didn't know that people
would freak out about it, but I did my homework, which led to the weird 
situation that I could claim that system() isn't worse than what everybody 
else is doing while many others were acting like it would be even something 
that allows privileged execution.

Such things can happen, but it should not happen in the way it did, 
combined with so much disrespect and everything that followed.

In the latter regard - again - you have been a shiny exception,
and highly appreciate that!


PS: This is a perfect finish, so I'll respond to the details in a 
separate mail.

Thank you,
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".

Re: [FFmpeg-devel] The "bad" Patch

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Mark
> Thompson
> Sent: Samstag, 31. Mai 2025 22:26
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] The "bad" Patch
> 

Hi Mark,


Here are my answers to the remaining points:


> >> In reality, ffmpeg is often used on multi-user systems and called in
> strange
> >> ways from network services where many inputs are not trusted.
> >
> > None of such systems have xdg-open
> 
> xdg-open is in most default install of Linux distributions (indeed, that's why
> you use it), so I don't think it is a reasonable assumption that it would not
> be there.

xdg-open is part of the xdg-util package which is typically installed when
there's a Desktop Environment or certain individual UI applications.
It's normally not included in server, container or minimal installations.

No need to argue that it's not a 100% reliable indication, but still good
as one element of a group of indicators.



> > - The file name is built from the local time with milliseconds. Pretty hard
> to
> >   hit
> 
> No, trivial to hit given that creating a file and watching whether it gets
> touched (inotify) are very low cost operations.

Just to reiterate (as I cut off above too close): An attacker would need to 
have access to the same system as the target user.

It would need to 

- Create & Delete 1000 files per second
  or perform 1000 renames per second
- This number is independent from the number of files ("window") that you
  keep at a time. You can't make that window too small, because the file name
  is created before the graph is built, so maybe 500 or 1000 to be safe
  The latter would provide a tolerance of 1 second.
- Even when you use just 100 files at a time (covering 100ms), you still 
  need to do 1000 create/rm or 1000 renames per second
- The number of inotify instances is usually limited on systems, so 
  you can only monitor the folder. 
- Monitoring a folder with 1000 or 2000 file changes per second with inotiy
  is no longer cheap (afaik), even when you limit the events by event mask
- This has consequences and affects the system:
  - It creates 3.6 or 7.2 Millions of file system journal entries per hour
    (for a journalling fs)
  - Even though the files may have 0 bytes, this causes continuous disk 
    activity and might affect other fs operations
  - I have no time to try it out, but especially on slow systems, this
    is probably well noticeable 

Anyway, that's all pointless due to the below:


> > - In v2, a temp-directory specific to the current user is created. Other
> users
> >   have no access
> 
> Your new method does not work because the attacker could have created the
> temporary directory (world-writeable) before the ffmpeg process does.

Right, it should maybe call stat after creation, but due to the below, there's
not much to achieve anyway.


> > - The file is an html file which will be launched by a browser from file:///
> >   url, means it is treated with extra safety and isolation. There's hardly
> anything
> >   you could achieve these days from a local html page
> 
> Is there some general citation for this?
> 
> I would naively expect browsers to assign greater trust to local rather than
> remote files and possibly allow some additional capabilities to scripts
> running in them, but I admit I have no familiarity with this area so I may be
> completely wrong.

In fact, it's the other way round, contrary to what one would expect. On
one side, there have been loads of exploits in this regard in the past, but
in combination with other "security changes" that Chromium (and all browsers
derived from it) have introduced over the years, I have gained the strong
impression that Google are purposefully trying do this (at least also) to
force more and more things move to the cloud.

Content from local file urls is the least trusted origin in contemporary 
browsers. It has upset me too many times in the past years, that content from
whichever malicious site is trusted more than content from the file system,
just for having an SSL cert, which anybody can have these days.
It's hardly possible anymore to view something from (non-ssl) servers in your 
local network when origins are mixed, and again, the hacked site with ssl 
is considered "secure" and local network machines (http) as "unsafe" and 
file urls even more.
When you want to open an XML file from the file system which specifies an
xslt stylesheet in the same folder - browsers don't load it anymore.
But they load it when it's available from an https url. That's crazy,
because locally, I can be sure that it doesn't change, but from a remote
server, it can change at any time and is out of your control. Still they 
are calling this "secure" because it has ssl.
Their latest nonsense is to restrict access to http hosts with private
network IP addresses (sigh).



> Some further thoughts on your new patch which you will undoubtably have
> already considered:

> * What happens if the system argument string exceeds the allowed command
> argument length?

This is not possible, because the maximum length is:

/var/tmp/ffmpeg-4294967296/ffmpeg_graph_0000-00-00_00-00-00_000.htm


> * What happens if /bin/sh is not bash?

The command is not bash-specific, any Posix shell should do it. Tested with
bash and dash.


> * What happens if the attacker successfully contrives a transient out-of-
> memory condition during any of the calls to av_bprintf()?  (As they can do on
> a shared machine.)

The maximum length of the path is 68, and 110 for the command. The AVBPrints are
stack-allocated and have something like 1kB, which should be more than sufficient
for doing av_bprintf() without allocating additional memory.


> (The Windows implementation is not changed and does not look robust, I assume
> you have not revised it.)

Correct - as said, it's all and only about the system() incovation.


> > Many other CLI tools are launching browsers, so that's not really rocket
> > science like you're trying to allude to.
> 
> I agree.  Rocketry seems to be generally reliable and successful when compared
> to computer security, where people forever find new vulnerabilities in
> supposedly secure and audited programs.
> 
> I would hope that other CLI tools doing this have carefully documented the
> circumstances in which they do so to ensure that they don't get used in cases
> where it might cause problems.

Git: Nope

git web--browse --help
git web--browse https://ffmpeg.org


GitHub CLI: Nope

https://cli.github.com/manual/gh_browse
gh browse --repo ffmpeg/ffmpeg


Neither are making a big thing out of it and the same applies to all other 
cases I had seen.


Thanks,
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".

Re: [FFmpeg-devel] The "bad" Patch

[Nicolas George]

Michael Niedermayer (HE12025-06-02):
> Id like you to be in the next community committee. (together with marth64)

Sorry, but Are you out of your mind?

> Because it seems you seriously care about stoping defamations and the
> general sozial backstabbing that has appeared in the recent decade

“Seems” is the important word here.

Regards,

-- 
  Nicolas George
_______________________________________________
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] The "bad" Patch

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Nicolas
> George
> Sent: Montag, 2. Juni 2025 09:58
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] The "bad" Patch
> 
> Michael Niedermayer (HE12025-06-02):
> > Id like you to be in the next community committee. (together with marth64)
> 
> Sorry, but Are you out of your mind?
> 
> > Because it seems you seriously care about stoping defamations and the
> > general sozial backstabbing that has appeared in the recent decade
> 
> “Seems” is the important word here.
> 
> Regards,
> 
> --
>   Nicolas George
> _______________________________________________


Yes, the "seems" is accurate in your perception - but you are also 
the only one with that perception.

This is because you are the one (and only one) for whom I make an 
exception. All rules are lifted, so that I can adequately respond 
to your inevitable, sometimes more and sometimes less hidden insults.

This means that you are the only person here which I'm deliberately
and intentionally insulting. It's a quid-pro-quo, and I think 
we're even in this regard.
But there's an important distinction: It's always that you serve
and I return. It never originates from my side.

If you write friendly, I return friendly, but as you are unable to 
write even three consecutive sentences which are sincerely friendly
and without any half-hidden, disguised, alluded or implied indirect
or direct insults, you just never get to see a friendly response 
from me.

Sometimes it makes fun to respond to your disgusting scribblings
with a text that you deserve.
But overall, I would much prefer when you would write, without 
all those despicable side lines - simple and friendly like a 
normal person would do.

Best regards
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".

Re: [FFmpeg-devel] The "bad" Patch

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of softworkz .
> Sent: Montag, 2. Juni 2025 11:31
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] The "bad" Patch
> 
> 
> 
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Nicolas
> > George
> > Sent: Montag, 2. Juni 2025 09:58
> > To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] The "bad" Patch
> >
> > Michael Niedermayer (HE12025-06-02):
> > > Id like you to be in the next community committee. (together with marth64)
> >
> > Sorry, but Are you out of your mind?
> >
> > > Because it seems you seriously care about stoping defamations and the
> > > general sozial backstabbing that has appeared in the recent decade
> >
> > “Seems” is the important word here.
> >
> > Regards,
> >
> > --
> >   Nicolas George
> > _______________________________________________
> 
> 
> Yes, the "seems" is accurate in your perception - but you are also
> the only one with that perception.
> 
> This is because you are the one (and only one) for whom I make an
> exception. All rules are lifted, so that I can adequately respond
> to your inevitable, sometimes more and sometimes less hidden insults.
> 
> This means that you are the only person here which I'm deliberately
> and intentionally insulting. It's a quid-pro-quo, and I think
> we're even in this regard.
> But there's an important distinction: It's always that you serve
> and I return. It never originates from my side.
> 
> If you write friendly, I return friendly, but as you are unable to
> write even three consecutive sentences which are sincerely friendly
> and without any half-hidden, disguised, alluded or implied indirect
> or direct insults, you just never get to see a friendly response
> from me.
> 
> Sometimes it makes fun to respond to your disgusting scribblings
> with a text that you deserve.
> But overall, I would much prefer when you would write, without
> all those despicable side lines - simple and friendly like a
> normal person would do.
> 
> Best regards
> sw
> _______________________________________________


An afterthought:

Somehow I used to believe that it would be clear to everybody, 
and never thought about it more - but maybe it isn't that obvious
like I used to assume:

The way I'm responding to NG is in no way how I am personally. 
I am writing that way because I _can_ write that way and I think
he deserves to be responded that way, even more after the CC had
officially stated that they concluded that there's nothing they
can do about it.

But this has nothing to do with myself, there's no other
person in the world to which I wrote or write like this. It's 
a very exclusive subscription, holding up a mirror to provide a
glimpse into his own deviance.

softworkz




_______________________________________________
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] The "bad" Patch

[Nicolas George]

softworkz . (HE12025-06-02):
> The way I'm responding to NG is in no way how I am personally. 
> I am writing that way because I _can_ write that way and I think
> he deserves to be responded that way, even more after the CC had
> officially stated that they concluded that there's nothing they
> can do about it.

In other words, you admit to enacting your own justice.

-- 
  Nicolas George
_______________________________________________
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] The "bad" Patch

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Nicolas
> George
> Sent: Montag, 2. Juni 2025 12:50
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] The "bad" Patch
> 
> softworkz . (HE12025-06-02):
> > The way I'm responding to NG is in no way how I am personally.
> > I am writing that way because I _can_ write that way and I think
> > he deserves to be responded that way, even more after the CC had
> > officially stated that they concluded that there's nothing they
> > can do about it.
> 
> In other words, you admit to enacting your own justice.
> 
> --
>   Nicolas George
> _______________________________________________


You don't want to play the victim now, do you?


[a great response that I've learned from Yours Truly]

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

Re: [FFmpeg-devel] The "bad" Patch

[Michael Niedermayer]

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

Hi Nicolas

On Mon, Jun 02, 2025 at 09:57:34AM +0200, Nicolas George wrote:
> Michael Niedermayer (HE12025-06-02):
> > Id like you to be in the next community committee. (together with marth64)
> 
> Sorry, but Are you out of your mind?

probably ;)
is that surprising after so many years here ?


> 
> > Because it seems you seriously care about stoping defamations and the
> > general sozial backstabbing that has appeared in the recent decade
> 
> “Seems” is the important word here.

we can never know before we try.

I do think softworkz would add some qualities to the CC, which the CC
is lacking. The same way that marth64 adds some qualities which everyone
else is lacking.

Will that change the world, no i dont think so. But i think it would be
an improvement

The CC needs someone who is good at mediating (or what you call it) thats
marth64
And the CC needs someone who can recognize defamation and document it
accurately. Ive not seen anyone except softworkz document things as he did.

I simply think that having a CC with 5 expert mediators is worse
than having 5 people with diverse abilities. As long as everyone is
reasonable calm, neutral and unbiased. And of course at least one member
needs to be very good at mediating

thx

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

Take away the freedom of one citizen and you will be jailed, take away
the freedom of all citizens and you will be congratulated by your peers
in Parliament.

[-- 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] The "bad" Patch

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Michael
> Niedermayer
> Sent: Montag, 2. Juni 2025 21:35
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] The "bad" Patch
> 

Hi,

> The CC needs someone who is good at mediating (or what you call it) thats
> marth64

+1


> And the CC needs someone who can recognize defamation and document it
> accurately. Ive not seen anyone except softworkz document things as he did.

Admittedly, the motivation was high, since I've been in focus. Naturally,
I had been upset about specific persons at the beginning, but the more I 
had reconstructed the sequence of events, I realized that the way how 
things had developed and escalated further, was more complex and driven
by many actors, most of which never had much bad intentions and acted
without being aware about the consequences of their own actions.
Asked about it, I'm sure most of them would think and say that they would
have had nothing to do with it at all and it wasn't their own fault.
But in a community, when several people do just little wrong 
individually, this can sum up very quickly and easily.

The motivations behind documenting the events are multifold:

- When we better understand the origins and mechanisms of how that 
  "toxicity" is formed and unfolds, then we might better be able to
  take measures to reduce it in the future

- When each individual is able to see and understand their own actions
  within the full context, it allows them to reflect about how their
  own actions (even if just minimal) have contributed to the eventual
  outcome

- In the same way, people who weren't involved at all can learn from
  understanding those situations

The latter applies to myself as well, I'm sometimes writing faster than
thinking, which can lead to unintended consequences and there could 
very well be another case where I might have been documented as an 
actor. I don't consider myself standing out in this regard.

One fundamental difference though - and something that is badly 
missing in this community is the ability to admit one's own mistakes
and apologize as is appropriate. I always do that and the ML archive
gives testimony that this is true. It's an indication of integrity,
honesty and strength of personality and social competence.
Failing to do so is one of the seeds of toxicity towards each other.

To me, it seems that people are afraid that this could be taken as
weakness or incompetence - which is a fundamental misconception.
Even in technical discussions, I see that people rather stop 
responding than admitting, when they realize they were wrong about
something. But the opposite is true: not admitting is weak
behavior.


> > Because it seems you seriously care about stoping defamations and the
> > general sozial backstabbing that has appeared in the recent decade
> 
> “Seems” is the important word here.

I have been writing about these things here often before, in the 
hope that it makes people think about and reflect their own behavior.

If it would be true that it just "seems" that I would care, then I'd 
be curious about for which other reasons I'd be doing it then?


Best regards,
softworkz

_______________________________________________
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] The "bad" Patch

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Nicolas
> George
> Sent: Montag, 2. Juni 2025 12:50
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] The "bad" Patch
> 
> softworkz . (HE12025-06-02):
> > The way I'm responding to NG is in no way how I am personally.
> > I am writing that way because I _can_ write that way and I think
> > he deserves to be responded that way, even more after the CC had
> > officially stated that they concluded that there's nothing they
> > can do about it.
> 
> In other words, you admit to enacting your own justice.
> 
> --
>   Nicolas George
> _______________________________________________

The actual answer is this:

No. It's an act of civil courage in defense of the community.
By drawing the focus of all your negativity on myself, I'm protecting
other community members who would otherwise get hurt by your behavior
and are not able to defend themselves accordingly.

softworkz
_______________________________________________
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] The "bad" Patch

[Michael Niedermayer]

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

Hi

On Mon, Jun 02, 2025 at 09:22:29PM +0000, softworkz . wrote:
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Michael
> > Niedermayer
> > Sent: Montag, 2. Juni 2025 21:35
> > To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] The "bad" Patch
> > 
> 
> Hi,
> 
> > The CC needs someone who is good at mediating (or what you call it) thats
> > marth64
> 
> +1
> 
> 
> > And the CC needs someone who can recognize defamation and document it
> > accurately. Ive not seen anyone except softworkz document things as he did.
> 
> Admittedly, the motivation was high, since I've been in focus. Naturally,
> I had been upset about specific persons at the beginning, but the more I 
> had reconstructed the sequence of events, I realized that the way how 
> things had developed and escalated further,

> was more complex and driven
> by many actors, most of which never had much bad intentions and acted
> without being aware about the consequences of their own actions.

+1
I believe 99.9% of people have good intentions on this ML not 100% though


> Asked about it, I'm sure most of them would think and say that they would
> have had nothing to do with it at all and it wasn't their own fault.
> But in a community, when several people do just little wrong 
> individually, this can sum up very quickly and easily.
> 
> The motivations behind documenting the events are multifold:
> 

> - When we better understand the origins and mechanisms of how that 
>   "toxicity" is formed and unfolds, then we might better be able to
>   take measures to reduce it in the future

+1

I belive documenting things is the first step in solving them.


[...]

> 
> To me, it seems that people are afraid that this could be taken as
> weakness or incompetence - which is a fundamental misconception.
> Even in technical discussions, I see that people rather stop 
> responding than admitting, when they realize they were wrong about
> something. But the opposite is true: not admitting is weak
> behavior.

Theres alot of variation here i think
from not even internally admiting to people who do admit publically they
where wrong.

and also people stoping responding when a discussion becomes too toxic
(as in "dont feed the trolls")

thx

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

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein

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