threads / discuss / 46024

Another git repo at kernel.org?

Subject: Another git repo at kernel.org?

## tl;dr

5 messages between May 22, 2017 and May 24, 2017.

replies: 4people: 4as markdown or json

Stefan Beller· May 22, 2017, 18:34 UTC · lore
Hi,

The Git community considers using submodules for some parts of the code (a third party lib, SHA1DC, computing SHA1s that warn about potential attachs, see shattered.io) [1].

We are also concerned about single point of failure there, so a repo at kernel.org mirroring the potential submodule[2] would be great.

I cc'd the git mailing list as we may want to have further discussion who shall have access to the new repo.

Thanks, Stefan

[1] https://public-inbox.org/git/20170520115429.12289-1-avarab@gmail.com/ [2] https://github.com/cr-marcstevens/sha1collisiondetection

Ævar Arnfjörð Bjarmason· May 22, 2017, 19:43 UTC · re: Stefan Beller · lore

Re: Another git repo at kernel.org?

On Mon, May 22, 2017 at 8:34 PM, Stefan Beller <sbeller@google.com> wrote:
Show 13 quoted lines
> The Git community considers using submodules for some parts of the
> code (a third party lib, SHA1DC, computing SHA1s that warn about
> potential attachs, see shattered.io) [1].
>
> We are also concerned about single point of failure there, so a repo
> at kernel.org
> mirroring the potential submodule[2] would be great.
>
> I cc'd the git mailing list as we may want to have further discussion who
> shall have access to the new repo.
>
> [1] https://public-inbox.org/git/20170520115429.12289-1-avarab@gmail.com/
> [2] https://github.com/cr-marcstevens/sha1collisiondetection

The access problem could be solved by none of us having access to the repo, if the git.kernel.org admins are willing to set up a mirror of the github repo, a cronjob running git-fetch with the appropriate parameters to just fetch the master (or everything, but only master is needed). Updating such a mirror with a daily cronjob would be more than enough.

Less seriously but worth pointing out: It could also be solved by just setting the user:password to foo:bar and publishing that in the description & setting the repo to non-fast-forward only. This will only be used by the git.git repo, which'll point at a specific sha1 in its history, wouldn't that be a nice demo of the whole "give the repo to your worst enemy but as long as you have the sha ... " parable Linus posted on-list back in the day... :)

Theodore Ts'o· May 23, 2017, 15:13 UTC · re: Ævar Arnfjörð Bjarmason · lore

Re: Another git repo at kernel.org?

So Junio owns the pub/scm/git/git.git tree on kernel.org, and he may already have access to create new repo's under the pub/scm/git hierarchy. In which case we might not need to bug the kernel.org administrators at all.

Also, I'll note that it is possible to set up some repo's such that a group of people have access to push to them. You'll see for example on git.kernel.org that certain repositories have as their owner "XFS FS Group", or "ARM64 Group" or "Intel Wireless Group".

Cheers,
					- Ted
Junio C Hamano· May 23, 2017, 23:32 UTC · re: Theodore Ts'o · lore

Re: Another git repo at kernel.org?

Theodore Ts'o <tytso@mit.edu> writes:
> So Junio owns the pub/scm/git/git.git tree on kernel.org, and he may
> already have access to create new repo's under the pub/scm/git
> hierarchy.  In which case we might not need to bug the kernel.org
> administrators at all.
Yes, sorry for a premature inquiry.
Stefan Beller· May 24, 2017, 00:15 UTC · re: Junio C Hamano · lore

Re: Another git repo at kernel.org?

On Tue, May 23, 2017 at 4:32 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 8 quoted lines
> Theodore Ts'o <tytso@mit.edu> writes:
>
>> So Junio owns the pub/scm/git/git.git tree on kernel.org, and he may
>> already have access to create new repo's under the pub/scm/git
>> hierarchy.  In which case we might not need to bug the kernel.org
>> administrators at all.
>
> Yes, sorry for a premature inquiry.

Thanks for bearing with my premature questions. I just went off from https://www.kernel.org/category/contact-us.html to see what the workflow would look like. Knowing that Junio owns the complete pub/scm/git namespace is a good data point for our discussion.

Sorry, Stefan

← back to recent threads