search

gittuf / gittuf

A security layer for Git repositories
https://gittuf.dev
Apache License 2.0
465 stars 34 forks source link

To use the RSL or not to use the RSL #668

Open adityasaky opened 1 day ago

adityasaky commented 1 day ago

Add a description

In many flows, we identify the tip of a reference from its latest entry in the RSL. For example, when creating an approval attestation for a change from feature being merged into main, we compute the expected merge tree using the commits identified in the latest RSL entries for both branches. @wlynch pointed out that this may be incorrect in cases where the RSL has not been updated, perhaps locally for the approver.

Using the RSL mitigates reference state attacks against the refs in question, so I'm inclined to keep using the RSL and try and maximize RSL entry creation across the board so the latest entry matches the ref as expected. But, do we want to provide a flag? Is there a flow where an approver wants to approve a change from commit Y on the feature branch even though the latest RSL entry is for commit X? Doesn't this indicate that the feature branch has moved when it shouldn't have?

Relevant log output if the discussion pertains to existing gittuf functionality

Code of Conduct

JustinCappos commented 18 hours ago

I need to understand this case better, but in general, my feeling is the RSL should always represent an append-only log of up-to-date actions. This is important to stop the repository, etc. from doing all the various branch attacks. Unless there is some critical usability issue this raises, I'm in favor of not changing the invariant that we leverage the RSL as much as possible.

On Thu, Nov 21, 2024 at 2:02 PM Aditya Sirish @.***> wrote:

Add a description

In many flows, we identify the tip of a reference from its latest entry in the RSL. For example, when creating an approval attestation for a change from feature being merged into main, we compute the expected merge tree using the commits identified in the latest RSL entries for both branches. @wlynch https://github.com/wlynch pointed out that this may be incorrect in cases where the RSL has not been updated, perhaps locally for the approver.

Using the RSL mitigates reference state attacks against the refs in question, so I'm inclined to keep using the RSL and try and maximize RSL entry creation across the board so the latest entry matches the ref as expected. But, do we want to provide a flag? Is there a flow where an approver wants to approve a change from commit Y on the feature branch even though the latest RSL entry is for commit X? Doesn't this indicate that the feature branch has moved when it shouldn't have? Relevant log output if the discussion pertains to existing gittuf functionality

Code of Conduct

  • I agree to follow this project's Code of Conduct

— Reply to this email directly, view it on GitHub https://github.com/gittuf/gittuf/issues/668, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGROD6GEBHTSWXRMDS3KSL2BYU5JAVCNFSM6AAAAABSHWTLHSVHI2DSMVQWIX3LMV43ASLTON2WKOZSGY4DANJWGU4DAMA . You are receiving this because you are subscribed to this thread.Message ID: @.***>