Re: [RFC] General Resolution to deploy tag2upload
On Wed, 12 Jun 2024 at 10:14, Helmut Grohne <helmut@subdivi.de> wrote:
>
> On Wed, Jun 12, 2024 at 06:50:44AM +0200, Ansgar 🙀 wrote:
> > In addition it reintroduces trust in weak cryptographic hashes which
> > effort was spent to remove.
>
> Thanks for reminding. While I've seen arguments in favour of the
> weaknesses of sha1 not affecting our use much, the xz-incident changes
> the weights of those arguments for me. I am now wondering whether we can
> be more proactive about changing the hash function used by git. For new
> repositories, this seems as simple as git init --object-format=sha256.
> Doing so will make repositories inaccessible to people running buster or
> older and I guess we can live with that limitation. It is not clear to
> me how repositories are converted. To me it seems plausible to deny use
> of sha1 hashes with debpush at this time (even though that is not
> implemented right now).
>
> I note that use of weak hashes in the current tag2upload is not a
> fundamental blocker but something that I expect proponents to work on in
> case the GR passes. Would one of the proponents confirm that they see
> this as worth spending their time on (on the condition that the GR
> passes)?
A side note, but related: recently I had the (dis)pleasure of having
to deal with a git repository that was switched to sha256 (SUSE's
Gitea instance). The conversion is destructive, and breaks, for
example, git submodules functionality (a sha1 repository cannot use
sha256 submodules). So I'd be very careful in assuming repositories
can be converted later.
It would seem to me to be much, much safer to do this from day one:
wait for Gitlab to introduce sha256 (they are bound to, as there's
really no choice), then add a tag2upload namespace that forces all
repos under it to use sha256, and use it from the get-go.
Converting later I am afraid would risk causing a huge amount of pain,
from the experience dealing with this.
Reply to: