lkml.org 
[lkml]   [2020]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] CREDITS: replace HTTP links with HTTPS ones and add myself
On Fri, 10 Jul 2020 21:43:42 +0200
"Alexander A. Klimov" <grandmaster@al2klimov.de> wrote:

> Regarding the links:
>
> 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.
>
> Regarding the addition of myself:

A couple of things here...

> Rationale:
> * 93431e0607e5

This is ... not particularly self-explanatory. Is that meant to be a
commit reference? If so, you would want to use the normal format.

> * the replaced links in this patch

If you are going to do something like make an addition to the file, you
need to do that separately from a cleanup patch.

But somebody has to say this: I don't think we have any sort of laid-down
policy for what it takes to be mentioned in CREDITS, but I don't think that
your work thus far clears whatever bar we might set. We don't immortalize
every person who submits some cleanup patches, or this file would be a long
one indeed. If you would like to be remembered for your kernel work, I
would respectfully suggest that you move beyond mechanical cleanups into
higher-level work.

One other little thing that jumped out at me:

> N: Alan Cox
> -W: http://www.linux.org.uk/diary/
> +W: https://www.linux.org.uk/diary/
> D: Linux Networking (0.99.10->2.0.29)
> D: Original Appletalk, AX.25, and IPX code
> D: 3c501 hacker

That link just redirects to linux.com, which is probably not what Alan had
in mind. Replacing the link with one into the wayback machine (or perhaps
just removing it entirely) would seem like a more useful change than adding
HTTPS to a link that clearly does not reach the intended destination.

Thanks,

jon

\
 
 \ /
  Last update: 2020-07-10 23:46    [W:0.189 / U:0.328 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site