From: Michael Niedermayer <michael@niedermayer.cc> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Subject: [FFmpeg-devel] rebasing security Date: Sun, 3 Aug 2025 17:31:39 +0200 Message-ID: <20250803153139.GC29660@pb2> (raw) [-- Attachment #1.1: Type: text/plain, Size: 1434 bytes --] Hi The "on server rebase" process that we are using with forgejo looks a bit insecure Previously we wrote code, discussed and then signed and pushed In this setup the code coming from a developer is not manipulatable because noone else can sign it Even if its not signed, stuff would light up if the server suddenly changed your pushed commits, as local and remote would not match The current workflow is to create a merge request and up to that we are good. The problem, the code is then sometimes rebased on the server, this removes all signatures and allows arbitrary changes to happen. And that is, after all reviews. in the ML based system, a supply chain attack would have to hit author and all reviewers. With webapp rebasing a point after the reviews can introduce a change stealthy The solutions are obvious: 1. ignore security and supply chain attacks 2. use merges not rebases on the server 3. rebase locally, use fast forward only 4. verify on server rebases whats the oppinon of people about merging instead of rebasing ? Theres also non security arguments in favor of merges: https://lkml.org/lkml/2008/2/12/627 That said, i think "verify on server rebases" is possible, just not something i have heard off before. am i missing something ? thx -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire [-- 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".
next reply other threads:[~2025-08-03 15:31 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2025-08-03 15:31 Michael Niedermayer [this message] 2025-08-03 15:38 ` Timo Rothenpieler 2025-08-03 15:43 ` James Almer 2025-08-03 18:08 ` Michael Niedermayer 2025-08-03 19:02 ` Michael Niedermayer 2025-08-03 20:01 ` Timo Rothenpieler 2025-08-03 20:29 ` Michael Niedermayer 2025-08-03 20:34 ` Timo Rothenpieler
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=20250803153139.GC29660@pb2 \ --to=michael@niedermayer.cc \ --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