mailing list mirror (one of many)
 help / Atom feed
From: Stefan Beller <>
To: Junio C Hamano <>
Cc: Ævar Arnfjörð Bjarmason <>,
	"" <>,
	Marc Stevens <>,
	Michael Kebe <>, Jeff King <>,
	Brandon Williams <>
Subject: Re: [PATCH v2 0/2] Update sha1dc from upstream & optionally make it a submodule
Date: Mon, 22 May 2017 15:48:45 -0700
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, May 22, 2017 at 3:27 PM, Junio C Hamano <> wrote:
> Ævar Arnfjörð Bjarmason  <> writes:
>> I liked the suggestion to make the URL a relative path, but this would
>> require you to maintain a mirror in the same places you push git.git
>> to, is that something you'd be willing to do?
> After thinking about this a bit more, I know what I think we want a
> bit better.
> Relative URL (e.g. ../sha1collisiondetection that sits next to the
> copy of git.git) may be a good way to go.  I can arrange to create
> necessary repository next to git.git on and but I
> need to double check about other places

And here we see another deficit with a single URL:
We have to abide by the same scheme at all hosting endpoints.

For example consider the host
that mirrors from It would be able to bind the
submodule at
i.e. it would look like a subdirectory of the main git repo.

This is not an issue for our desired usecase, as all hosts can comply
with the scheme that you outlined (url=../sha1...), but worth noting that
in the long term we may want to have the ability to "configure" each
remote individually by having out-of-history config options. I think we
would want to solve that via a "refs/meta/gitmodules" branch that can be
adapted per remote. (original idea from jrnieder@)

> Whether the submodule is referenced by a relative URL from the main
> project, the submodule should not come directly from the upstream,
> and various mirrors that sit next to git.git should not be blind and
> automated "mirrors".

That sounds reasonable for our sanity.

> This is because I do not want us to trust the
> security measures of repository.
> The consumers already need to trust and by
> ensuring is managed the same way, they do
> not have to trust anything extra.

The trust would be transitive, as the said submodule is referenced via
sha1, so all malicious actions upstream could perform are:
* denial of service: (by remove a commit that we pointed at in our history)
* denial of service 2: add a huge blob to their repo, such that anyone
  obtaining the submodule not carefully is annoyed by a super large repo.
* add additional malicious data (such as illegal numbers and algorithms)
  to a branch, which would be obtained by users cloning the submodule

> Another reason is that we want to make sure all commits in the
> submodule that we bind to the superproject (i.e. git.git) are always
> in the submodule, regardless of what our upstream does, and one way
> to do so is to have control over _our_ canonical repository for the
> submodule.

By having all repos under one entity of trust, we would not need to discuss
all kinds of possible attacks as above.

>  In normal times, it will faithfully follow the upstream
> without doing anything else, but we'd keep the option of anchoring a
> submodule commit that is referenced by the superproject history with
> our own tag, if it is ever rewound away in the upstream history for
> whatever reason.

That makes sense.


  reply index

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-18 21:28 [PATCH 0/3] " Ævar Arnfjörð Bjarmason
2017-05-18 21:28 ` [PATCH 1/3] sha1dc: update from upstream Ævar Arnfjörð Bjarmason
2017-05-18 21:28 ` [PATCH 2/3] sha1dc: use sha1collisiondetection as a submodule Ævar Arnfjörð Bjarmason
2017-05-20 11:13   ` Junio C Hamano
2017-05-20 11:54     ` [PATCH v2 0/2] Update sha1dc from upstream & optionally make it " Ævar Arnfjörð Bjarmason
2017-05-22 22:27       ` Junio C Hamano
2017-05-22 22:48         ` Stefan Beller [this message]
2017-05-23  3:22           ` Junio C Hamano
2017-05-23 10:55         ` Ævar Arnfjörð Bjarmason
2017-05-23 13:06           ` Junio C Hamano
2017-05-25 10:44             ` Ævar Arnfjörð Bjarmason
2017-05-25 23:31               ` Junio C Hamano
2017-05-20 11:54     ` [PATCH v2 1/2] sha1dc: update from upstream Ævar Arnfjörð Bjarmason
2017-05-20 11:54     ` [PATCH v2 2/2] sha1dc: optionally use sha1collisiondetection as a submodule Ævar Arnfjörð Bjarmason
2017-05-22  1:33       ` Junio C Hamano
2017-05-22  2:48         ` Junio C Hamano
2017-05-22  8:27           ` Ævar Arnfjörð Bjarmason
2017-05-22  8:48             ` Junio C Hamano
2017-05-25 10:47     ` [PATCH 2/3] sha1dc: " Ævar Arnfjörð Bjarmason
2017-05-18 21:28 ` [PATCH 3/3] sha1dc: remove the unused sha1dc/ directory Ævar Arnfjörð Bjarmason

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link mailing list mirror (one of many)

Archives are clonable:
	git clone --mirror
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:

 note: .onion URLs require Tor:
       or Tor2web:

AGPL code for this site: git clone public-inbox