linux-kernel - Re: [PATCH] Replace HTTP links with HTTPS ones: documentation

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: <20200517134544.7d649bbb@lwn.net>
Date:   Sun, 17 May 2020 13:45:44 -0600
From:   Jonathan Corbet <corbet@....net>
To:     "Alexander A. Klimov" <grandmaster@...klimov.de>
Cc:     linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Replace HTTP links with HTTPS ones: documentation

On Sat, 16 May 2020 14:27:40 +0200
"Alexander A. Klimov" <grandmaster@...klimov.de> wrote:

> ... for security reasons.
> 
> No breaking changes as either the HTTP vhost redirects to HTTPS
> or both vhosts redirect to the same location
> or both serve the same content.

We're getting closer, but...

 - There is still too much stuff here.  Remember that somebody has to look
   at and review this stuff.

 - A quick check shows that a fair number of these links are broken or
   redirect to somewhere else.  What is the value of adding "https" to a
   broken link?

 - Various documents have maintainers who are likely to be interested in
   changes and should be copied; that is what the get_maintainer.pl script
   is for.  If that generates a massive list of recipients, that's a cue
   that your patch is too large.

If you really want to push this forward, please:

 - narrow down further.  Start with, say, Documentation/maintainer and
   just do that.

 - Make sure every link you touch actually works.  If they don't, don't
   just add "https", figure out what the link should be or, if no
   applicable link exists, delete them.

 - Justify the changes in the changelog; "for security reasons" is not, by
   itself, particularly convincing.  What security threat are you
   addressing here?

Then, maybe, we'll have patches that can be reviewed and applied.

Thanks,

jon