Re: Another git repo at kernel.org?

2017-05-23 Thread Stefan Beller 
On Tue, May 23, 2017 at 4:32 PM, Junio C Hamano  wrote:
> Theodore Ts'o  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

Re: Another git repo at kernel.org?

2017-05-23 Thread Junio C Hamano 
Theodore Ts'o  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.

Re: Another git repo at kernel.org?

2017-05-23 Thread Theodore Ts'o 
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

Re: Another git repo at kernel.org?

2017-05-22 Thread Ævar Arnfjörð Bjarmason 
On Mon, May 22, 2017 at 8:34 PM, Stefan Beller  wrote:
> 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-ava...@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... :)

Another git repo at kernel.org?

2017-05-22 Thread Stefan Beller 
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-ava...@gmail.com/
[2] https://github.com/cr-marcstevens/sha1collisiondetection