From: Mark Gaiser <markg85@gmail.com> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Subject: Re: [FFmpeg-devel] Would a crypto file be acceptable? Date: Tue, 27 Dec 2022 19:24:56 +0100 Message-ID: <CAPd6JnGvD6etEN0wM34rjMEKK=67jnniEyc-qTbR8S5GXfSTxg@mail.gmail.com> (raw) In-Reply-To: <22bb1fc7df0f82b34ebc4bec622c2c84f23d9571.camel@haerdin.se> On Mon, Dec 26, 2022 at 12:18 PM Tomas Härdin <git@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-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".
next prev parent reply other threads:[~2022-12-27 18:25 UTC|newest] Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-12-21 15:44 Mark Gaiser 2022-12-21 16:00 ` Mark Gaiser 2022-12-22 19:14 ` Gregor Riepl 2022-12-23 1:26 ` Mark Gaiser 2022-12-23 17:45 ` Gregor Riepl 2022-12-22 10:40 ` Nicolas George 2022-12-22 15:53 ` Mark Gaiser 2022-12-22 17:50 ` Hendrik Leppkes 2022-12-23 11:04 ` Tomas Härdin 2022-12-23 16:31 ` Mark Gaiser 2022-12-23 16:33 ` Nicolas George 2022-12-23 17:00 ` Mark Gaiser 2022-12-23 17:38 ` Nicolas George 2022-12-26 10:58 ` Tomas Härdin 2022-12-26 11:00 ` Nicolas George 2022-12-26 11:18 ` Tomas Härdin 2022-12-26 11:24 ` Nicolas George 2022-12-27 18:24 ` Mark Gaiser [this message] 2022-12-27 21:40 ` Michael Niedermayer 2022-12-27 22:46 ` Mark Gaiser 2022-12-28 14:27 ` Ronald S. Bultje 2022-12-28 16:13 ` Mark Gaiser 2022-12-28 16:22 ` Nicolas George 2022-12-28 16:27 ` Mark Gaiser 2022-12-28 16:30 ` Nicolas George 2022-12-28 16:58 ` Mark Gaiser 2022-12-29 14:04 ` Ronald S. Bultje 2022-12-28 21:02 ` Michael Niedermayer 2022-12-29 14:51 ` Mark Gaiser 2022-12-29 22:34 ` Michael Niedermayer
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAPd6JnGvD6etEN0wM34rjMEKK=67jnniEyc-qTbR8S5GXfSTxg@mail.gmail.com' \ --to=markg85@gmail.com \ --cc=ffmpeg-devel@ffmpeg.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel This inbox may be cloned and mirrored by anyone: git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \ ffmpegdev@gitmailbox.com public-inbox-index ffmpegdev Example config snippet for mirrors. AGPL code for this site: git clone https://public-inbox.org/public-inbox.git