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: <CANiq72=Y+beqZ8Dmieo_GKbyaLN8Nf1n3bVntj_o90Cn-nADRQ@mail.gmail.com>
Date:   Mon, 22 Jun 2020 01:43:12 +0200
From:   Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To:     "Alexander A. Klimov" <grandmaster@...klimov.de>
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

Hi Alexander,

On Sun, Jun 21, 2020 at 4:30 PM Alexander A. Klimov
<grandmaster@...klimov.de> wrote:
>
> Which discussion? 93431e0607e5 ? IMAO the patches don't depend on each
> other.

The one we had the other day. It does not matter that the patches
depend on each other. It is information for whoever sees this commit.

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

In an ideal world, yes, but that won't happen unless enforced somehow.

Nevertheless, even in such a case, it would be best to have a script
to check the entire tree from time to time.

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

Then you are asking the next person to re-do the work.

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

I don't follow. They can patch the script if they want (or not), but
even if they do patch it, they don't need to wait for the patch to land.

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

It is a script, not part of the kernel building process. We already
have Perl, Python, C++, Makefile, Coccinelle...

But yes, it would be better to write it in a language that we already
have rather than add another. In particular, there is no need for a
compiled language for a script.

> 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?

What is the problem reading and maintaining a Go script
(notwithstanding the point above)?

Cheers,
Miguel