linux-kernel - Re: [PATCH] Replace HTTP links with HTTPS ones: Documentation/process

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]

Message-ID: <b7ba0047-8993-d3bf-327c-1fb70bc0282c@al2klimov.de>
Date:   Sun, 21 Jun 2020 16:30:25 +0200
From:   "Alexander A. Klimov" <grandmaster@...klimov.de>
To:     Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc:     Jonathan Corbet <corbet@....net>,
        Randy Dunlap <rdunlap@...radead.org>,
        Tony Fischetti <tony.fischetti@...il.com>,
        Chris Packham <chris.packham@...iedtelesis.co.nz>,
        Mauro Carvalho Chehab <mchehab+samsung@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        Arnd Bergmann <arnd@...db.de>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Borislav Petkov <bp@...e.de>, Will Deacon <will@...nel.org>,
        "Chang S. Bae" <chang.seok.bae@...el.com>,
        Joe Perches <joe@...ches.com>,
        Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@...el.com>,
        Kees Cook <keescook@...omium.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Jacob Huisman <jacobhuisman@...nelthusiast.com>,
        Federico Vaga <federico.vaga@...a.pv.it>,
        Jonathan Neuschäfer <j.neuschaefer@....net>,
        Konstantin Ryabitsev <konstantin@...uxfoundation.org>,
        Linux Doc Mailing List <linux-doc@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        clang-built-linux <clang-built-linux@...glegroups.com>
Subject: Re: [PATCH] Replace HTTP links with HTTPS ones: Documentation/process

Am 21.06.20 um 15:46 schrieb Miguel Ojeda:
> Hi Alexander,
> 
> On Sun, Jun 21, 2020 at 3:37 PM Alexander A. Klimov
> <grandmaster@...klimov.de> wrote:
>>
>> Rationale:
>> Reduces attack surface on kernel devs opening the links for MITM
>> as HTTPS traffic is much harder to manipulate.
>>
>> Deterministic algorithm:
>> For each file:
>>    If not .svg:
>>      For each line:
>>        If doesn't contain `\bxmlns\b`:
>>          For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
>>            If both the HTTP and HTTPS versions
>>            return 200 OK and serve the same content:
>>              Replace HTTP with HTTPS.
>>
>> Signed-off-by: Alexander A. Klimov <grandmaster@...klimov.de>
>> ---
> 
> Looks fine, although it would be nice to have a link to the discussion
Which discussion? 93431e0607e5 ? IMAO the patches don't depend on each 
other.

> (using a `Link: ` line to `lore.kernel.org`). Also having the script
> in the kernel would be nice for future re-runs (e.g. you could add it
> as a first patch in the series).
IMAO:

* The script should not be neccessary once all of my changes[1] arrive 
in torvalds/master. Instead reviewers should say like C'mon dude, what's 
this new plain-HTTP link doing in your patch? We have 2020! Look at e.g. 
93431e0607e5 .

* The program language agnostic algo description of mine should be 
enough. If it's not enough, I shall improve the description.

* Today I've added "If not .svg:". Imagine Torvalds merges the script, 
closes the merge window *and then* someone runs it on a random subsystem 
and discovers a missing condition. Do they have to patch the script, 
wait for the patch to arrive in torvalds/master *and then* patch the 
(other) subsystem, so they can refer to the now patched script? W/o a 
such central "rule on how to HTTPSify links" they'd just describe 
*their* algo. Or (even better) there wouldn't be much more insecure 
links, so the algo could be omitted.

After all please show me one of the big bosses (Torvalds, K-H, ...) 
who'd tolerate to have a...

* written w/o focus on maintainability
* not documented at all
* *Golang* file

... in the kernel tree.

If I correctly understand, you kernel devs write code so that if even 
the maintainer leaves the project, another one could just take over.

How many kernel devs would read and understand (all of them I guess) 
*and maintain that Go script* of mine?

[1]
➜  linux git:(master) git stash show --shortstat
  1857 files changed, 2664 insertions(+), 2664 deletions(-)
➜  linux git:(master)

> 
> Other than that:
> 
> Acked-by: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
> 
> Cheers,
> Miguel
>