From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.ffmpeg.org (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTPS id CB7314C488 for ; Sun, 3 Aug 2025 15:31:52 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTP id BCECE68C30B; Sun, 3 Aug 2025 18:31:48 +0300 (EEST) Received: from relay16.mail.gandi.net (relay16.mail.gandi.net [217.70.178.236]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTPS id DE786687BE7 for ; Sun, 3 Aug 2025 18:31:41 +0300 (EEST) Received: by mail.gandi.net (Postfix) with ESMTPSA id C6BEE449C6 for ; Sun, 3 Aug 2025 15:31:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niedermayer.cc; s=gm1; t=1754235101; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=G8X3W5iMkdgL2C6t40hceByu9TEtNX8pdkHfsqyu5mE=; b=J0ldofZADA0TPVpxsBXCY/Dj0yy8j9ZMywrSA6KFK8FS9mKT7pdUlQH8Boc0mF23JNGF9I H86VsF1WXPVcbChTqHZsuxOE35ZIHyXzo/VbxYu+sEsur54br94zxw59IYeoB8Ryv8gOxa 2H6BAN9dNMPNuFdkjFttXT5GrA/uOMcYKsdpHd0GNR+uLmK2rFb95vAriMmqzKgHZxfJmX PVq0LmXxFOx3huBxosIT/sk02Q2pclOpfduQsglVC6quOxgXpsVLlipnai7dvYzcMOqLYG 7/bpDGHxGmu56NrxCiXhC7tcuT3APkLrN8yQyHlVRyDBIb+0sym8/SQcYOf51Q== Date: Sun, 3 Aug 2025 17:31:39 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20250803153139.GC29660@pb2> MIME-Version: 1.0 X-GND-State: clean X-GND-Score: -85 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgddutdelkedvucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuifetpfffkfdpucggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenfghrlhcuvffnffculdduhedmnecujfgurhepfffhvffukfggtggusehgtderredttddvnecuhfhrohhmpefoihgthhgrvghlucfpihgvuggvrhhmrgihvghruceomhhitghhrggvlhesnhhivgguvghrmhgrhigvrhdrtggtqeenucggtffrrghtthgvrhhnpeduhfduveejiefftedtudeghfdtveevtdeludekgfetgfettedttefgieetjefhfeenucffohhmrghinheplhhkmhhlrdhorhhgnecukfhppeeguddrieeirdeihedrudejieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeeguddrieeirdeihedrudejiedphhgvlhhopehlohgtrghlhhhoshhtpdhmrghilhhfrhhomhepmhhitghhrggvlhesnhhivgguvghrmhgrhigvrhdrtggtpdhnsggprhgtphhtthhopedupdhrtghpthhtohepfhhfmhhpvghgqdguvghvvghlsehffhhmphgvghdrohhrgh Subject: [FFmpeg-devel] rebasing security X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: multipart/mixed; boundary="===============1708388583770051029==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============1708388583770051029== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jXmZHHkpRiIcYzhg" Content-Disposition: inline --jXmZHHkpRiIcYzhg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 --jXmZHHkpRiIcYzhg Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEKAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCaI+A1wAKCRBhHseHBAsP q/dtAJ465TZSGEB9ys5q7XP0MF8gr2xQHgCgmWhBK8nyb03qCV4uTVzzXpVacvE= =NSTX -----END PGP SIGNATURE----- --jXmZHHkpRiIcYzhg-- --===============1708388583770051029== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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". --===============1708388583770051029==--