Follow

git's sha256 support is now apparently fully usable for new repositories. And not supported by github or their ilk

So, if you don't want your new program to get uploaded by someone to github (and ingested into their copilot copyright-bypass tool), you could start the project with

git init --object-format=sha256

not supported by cgit either yet it seems, but plain old git over http works fine for cloning such sha256 repos

@joeyh huh, didn’t know that was already in git. Neat! (though the manpage does note it’s still experimental & backwards-compatablilty might be broken in the future)

looks like libgit2 is already working on supporting it though (link on … rolls eyes … github, of course), so I guess once that’s done it won’t be long until github can read those repos too …

@joeyh Maybe they'll roll out support for an MS-developed hash that nobody else will never support and will have a full collision break inside a year.

@codeberg what do we need to fix in @gitea to make it work? who knows how to do that? @6543?

@meena @codeberg @gitea

With our current nogogit backend, it would mainly update some regex

@meena @codeberg @gitea

But since we do have this things kinda all over the place ... it can get quite "interesting"

github.com/go-gitea/gitea/issu

@joeyh Oooo, is there a git-config option to make that the default for new repos?

@joeyh The man page in 2.36.1 reads “THIS OPTION IS EXPERIMENTAL!” and recommends using it “for testing purposes” only. Still, that’s good news!

@joeyh All the gory design details are at:
git-scm.com/docs/hash-function

I wonder if it’ll be possible to have “hybrid” repos, where new objects in an old repo will be both SHA1- and SHA256-addressable. Seems like it *should* be possible.

@txt_file @joeyh Not yet. SHA256 object IDs do not make any sense for us until the format is fully supported and stable and in relatively widespread use. Implementing support for it too early in our code base could lead to needless compatibility issues down the line.

This is not a very big deal. I don't expect attacks based on SHA1 would be trivial to pull off for outsiders against our implementation. Once our custom server exists, all protocol communication will run over SSH (including traffic between mirrors, and anonymous fetches). I don't have plans to support plaintext git:// or http/https on the server side, which would allow insertion of attacker-controlled data into the protocol (harder to do with https, though not impossible for anyone able to issue official certs).

@joeyh Is there a way to set SHA256 as default via ~/.config/git?

Sign in to participate in the conversation
Octodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!