[FFmpeg-devel] Would a crypto file be acceptable?

[Mark Gaiser]

On Mon, Dec 26, 2022 at 12:18 PM Tomas Härdin <git at haerdin.se> wrote:

> mån 2022-12-26 klockan 12:00 +0100 skrev Nicolas George:
> > Tomas Härdin (12022-12-26):
> > > That we want to avoid having keys in the command line is not
> > > unreasonable. A -keyfile argument for crypto: might be appropriate.
> >
> > You are confusing two threads, the issue of credentials visible in
> > the
> > command line is for another proposal. This here is about giving
> > options
> > without giving options, which is a recurring topic.
>
> Right. And trying to smuggle in command line options via a file feels
> made for exploitation..
>

Why so skeptical in that negative demotivating tone?

Isn't any media file "sneaking in options"?
M3U is one, though more of a meta file, it itself doesn't actually store
video data.
MKV is one. It can have wildly different content which defines how the file
is decided/presented.
.. and so you have literally every file ffmpeg supports.

What I'm proposing is conceptually no different than m3u.
I'm even adding in a version to, from a parsing point of view, have some
points to require to be in that file and only handle those that are
"spec-definned".
The file isn't magically going to add in more options that ffmpeg would
blindly swallow, that was never the intention!

My intent with this thread was to start a constructive chat about how to
create a "container format" for encrypted data that we could all agree on.
It would allow encrypted file handling for tools that embed ffmpeg.
A feature that sooner or later will be needed if decentralized storage is
going to be a big thing.

I for example would have liked to know if adding in a key in that file
would be acceptable.
Or if that must be like M3U meaning the key comes from a server and is
never stored in that file.

I suppose the question really is:
1. Should I discuss it further here? With the idea to get to a defined file
format to implement that we agree on!
2. Should I just go for it, make it without further feedback, perhaps show
how it works in a video some months from now. Then try to get this accepted
as PR that implements it (no further feedback requested)? That would be too
late imho hence wanting to discuss it _before_ developing it.

I'm all ears!


>
> /Tomas
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>