On Mon, Dec 26, 2022 at 12:18 PM Tomas Härdin <g...@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@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
