On 8/3/2025 5:31 PM, Michael Niedermayer wrote:
> 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
> 

I can change the setting from "Rebase and merge to FF Only", though that 
would be very tedious to deal with for everyone involved.

Forgejo can keep commit signatures intact if proper keys are configured 
for the users.

I wasn't even aware we used signed commits. Never seen them anywhere 
before. I don't even have a key I could sign commits with.