linux-kernel - Re: git pull

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 15 Nov 2017 21:51:21 +1100
From:   Michael Ellerman <mpe@...erman.id.au>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        "Tobin C. Harding" <me@...in.cc>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        kernelnewbies@...nelnewbies.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "open list\:DOCUMENTATION" <linux-doc@...r.kernel.org>
Subject: Re: git pull

Linus Torvalds <torvalds@...ux-foundation.org> writes:

> On Tue, Nov 14, 2017 at 1:33 PM, Tobin C. Harding <me@...in.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.

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