All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: "Tobin C. Harding" <me@tobin.cc>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	kernelnewbies@kernelnewbies.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>
Subject: Re: git pull
Date: Tue, 14 Nov 2017 13:46:17 -0800	[thread overview]
Message-ID: <CA+55aFyMxkS=8JzZ+ROOAFkwR45EKBnQ0GUMQS4f+r_-fFWiEA@mail.gmail.com> (raw)
In-Reply-To: <20171114213320.GB905@eros>

On Tue, Nov 14, 2017 at 1:33 PM, Tobin C. Harding <me@tobin.cc> wrote:
>
> Linus do you care what protocol? I'm patching Documentation and since
> the point is creating pull requests for you 'some people' don't matter.

I actually tend to prefer the regular git:// protocol and signed tags.

It's true that https should have the proper certificate and perhaps
help with DNS spoofing, but I'm not convinced that git won't just
accept self-signed random certs, and I basically don't think we should
trust that.

In contrast, using ssh I would actually trust, but it's not convenient
and involves people sending things that aren't necessarily publicly
available.

So instead, I prefer just using git:// and not trying to fool people
into thinking the protocol is secure - the security should come from
the signed tag.

And then people can do this:

  [url "ssh://git@gitolite.kernel.org"]
      insteadOf = https://git.kernel.org
      insteadOf = http://git.kernel.org
      insteadOf = git://git.kernel.org

which makes git.kernel.org addresses use ssh, and avoid the whole
possible DNS spoofing problem.

That said, I actually would prefer even kernel.org repositories to
just send pull requests with signed tags, despite the protocol itself
being secure for that (and only that).

Other hosts I will simply not trust without it because I can't do the above.

Side note: there's an unrelated advantage of using "git://" over
"https://". It means that people who do automation see that it's a git
repo. It also means, for example, that people that highlight https://
URL's and perhaps use them for spam marking hopefully don't do that
with git:// format.

              Linus

WARNING: multiple messages have this Message-ID (diff)
From: torvalds@linux-foundation.org (Linus Torvalds)
To: kernelnewbies@lists.kernelnewbies.org
Subject: git pull
Date: Tue, 14 Nov 2017 13:46:17 -0800	[thread overview]
Message-ID: <CA+55aFyMxkS=8JzZ+ROOAFkwR45EKBnQ0GUMQS4f+r_-fFWiEA@mail.gmail.com> (raw)
In-Reply-To: <20171114213320.GB905@eros>

On Tue, Nov 14, 2017 at 1:33 PM, Tobin C. Harding <me@tobin.cc> wrote:
>
> Linus do you care what protocol? I'm patching Documentation and since
> the point is creating pull requests for you 'some people' don't matter.

I actually tend to prefer the regular git:// protocol and signed tags.

It's true that https should have the proper certificate and perhaps
help with DNS spoofing, but I'm not convinced that git won't just
accept self-signed random certs, and I basically don't think we should
trust that.

In contrast, using ssh I would actually trust, but it's not convenient
and involves people sending things that aren't necessarily publicly
available.

So instead, I prefer just using git:// and not trying to fool people
into thinking the protocol is secure - the security should come from
the signed tag.

And then people can do this:

  [url "ssh://git at gitolite.kernel.org"]
      insteadOf = https://git.kernel.org
      insteadOf = http://git.kernel.org
      insteadOf = git://git.kernel.org

which makes git.kernel.org addresses use ssh, and avoid the whole
possible DNS spoofing problem.

That said, I actually would prefer even kernel.org repositories to
just send pull requests with signed tags, despite the protocol itself
being secure for that (and only that).

Other hosts I will simply not trust without it because I can't do the above.

Side note: there's an unrelated advantage of using "git://" over
"https://". It means that people who do automation see that it's a git
repo. It also means, for example, that people that highlight https://
URL's and perhaps use them for spam marking hopefully don't do that
with git:// format.

              Linus

  reply	other threads:[~2017-11-14 21:46 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-13 23:11 git pull Tobin C. Harding
2017-11-14 11:05 ` Greg Kroah-Hartman
2017-11-14 11:05   ` Greg Kroah-Hartman
2017-11-14 12:00   ` Ulf Hansson
2017-11-14 12:00     ` Ulf Hansson
2017-11-14 12:09     ` Greg Kroah-Hartman
2017-11-14 12:09       ` Greg Kroah-Hartman
2017-11-14 18:04   ` Linus Torvalds
2017-11-14 18:04     ` Linus Torvalds
2017-11-14 21:33   ` Tobin C. Harding
2017-11-14 21:33     ` Tobin C. Harding
2017-11-14 21:46     ` Linus Torvalds [this message]
2017-11-14 21:46       ` Linus Torvalds
2017-11-15 10:51       ` Michael Ellerman
2017-11-15 10:51         ` Michael Ellerman
2017-11-16 20:36       ` Linus Torvalds
2017-11-16 20:36         ` Linus Torvalds
2017-11-20  5:37         ` Junio C Hamano
2017-11-20  6:04           ` Linus Torvalds
2017-11-14 21:42   ` Tobin C. Harding
2017-11-14 21:42     ` Tobin C. Harding
  -- strict thread matches above, loose matches on Subject: below --
2012-04-12 14:47 GIT pull cvalusek
2012-04-12 15:03 ` Matthieu Moy
2012-04-12 15:07   ` Michael Witten
2012-04-12 16:58 ` Johannes Sixt
2012-04-12 17:29 ` cvalusek
2010-05-17 21:51 git pull matteo brutti
2010-05-18 16:31 ` Nicolas Sebrecht
2010-05-19 11:03 ` hasen j
2010-01-19  8:01 robin
2010-01-19  8:09 ` robin
2010-01-19 18:37   ` Paul Wilson
2010-01-23  7:22     ` Khem Raj
2010-01-19 20:13   ` Bjørn Forsman

Reply instructions:

You may reply publicly 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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to='CA+55aFyMxkS=8JzZ+ROOAFkwR45EKBnQ0GUMQS4f+r_-fFWiEA@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=kernelnewbies@kernelnewbies.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=me@tobin.cc \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.