Linus Torvalds [off-list ref] writes:

On Tue, Nov 14, 2017 at 1:33 PM, Tobin C. Harding [off-list ref] wrote:

quoted

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.

git does not accept self-signed certs by default, at least in recent
versions.

Though you can do a trust-on-first-use type thing, by downloading the
cert and telling git where to find it.

So https does provide additional security vs git:// IMHO. There is some
verification of the server and your data is encrypted on the wire.

It's not like it would be trivial to MITM a git fetch to insert a
malicious Makefile change, but it's also not *hard*.

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.

That's true, but only when you're pulling a signed tag, which for most
people is not the common case.

...

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).

Which you mention here.

cheers