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

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi,

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

> Hi Maxim,
>
> On Thu, 19 Oct 2023 at 22:22, Maxim Cournoyer <maxim.cournoyer@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