GNU bug report logs - #46182
[PATCH] lint: Add 'check-git-protocol' checker.

Previous Next

Full log

View this message in rfc822 format

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Simon Tournier <zimon.toutoune <at> gmail.com>
Cc: 46182 <at> debbugs.gnu.org, Leo Famulari <leo <at> famulari.name>
Subject: [bug#46182] [PATCH] lint: Add 'check-git-protocol' checker.
Date: Fri, 20 Oct 2023 11:37:56 -0400

Hi,

Simon Tournier <zimon.toutoune <at> gmail.com> writes:

> Hi Maxim,
>
> On Thu, 19 Oct 2023 at 22:22, Maxim Cournoyer <maxim.cournoyer <at> gmail.com> wrote:
>
>> Thinking about this change though; why is it bad to fetch from git
>> places?  There may be repos out there where it's the only offered way,
>> and as long as we're talking fixed output derivations, it seems moot
>> whether you use HTTPS, HTTP or X to retrieve the files (unless you are
>> worried about your traffic being monitored, but that's not in scope, I'd
>> say).
>
> Why would not it be in scope?
>
> Being able to strongly verify (sha256) that the content you fetch is the
> data you expect does not imply that the protocol for communicating
> cannot be exploited for other means.
>
> Well, git:// protocol is not supported by well-known forges.  Quoting
> Pro Git book:
>
>         The Cons
>
>         Due to the lack of TLS or other cryptography, cloning over
>         git:// might lead to an arbitrary code execution vulnerability,
>         and should therefore be avoided unless you know what you are
>         doing.
>
>         https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols
>
> And I do not have enough imagination to find a way to exploit the git://
> protocol.  However, it appears to me a good practise to warn when this
> protocol is used.  Somehow, a lint message is a recommendation – a good
> practise – and not an absolute truth. :-)
>
> In short, from my point of view, the general rule reads: avoid git://
> protocol if you can.  Obviously, if you cannot because it is the only
> offered way by some repositories, then let make an exception; but it
> does mean that’s a good practise.

OK, fair.  I remove my objection, but I dislike warnings when they
cannot be acted upon (e.g. 'no coverage in software heritage' -- OK
neat, but I can't do anything about it, and it may not even support that
tarball ingestion yet).

-- 
Thanks,
Maxim

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.