Am 09.07.20 um 00:54 schrieb Kees Cook:
On Wed, Jul 08, 2020 at 08:22:03PM +0200, Alexander A. Klimov wrote:
Am 08.07.20 um 10:05 schrieb Kees Cook:
On Wed, Jul 08, 2020 at 09:33:46AM +0200, Alexander A. Klimov 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 neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
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@xxxxxxxxxxxx>
---
Continuing my work started at 93431e0607e5.
See also: git log --oneline '--author=Alexander A. Klimov <grandmaster@xxxxxxxxxxxx>' v5.7..master
(Actually letting a shell for loop submit all this stuff for me.)
If there are any URLs to be removed completely or at least not HTTPSified:
Just clearly say so and I'll *undo my change*.
As written here...
I interpreted that as "any URLs [changed by this patch]". I wanted no
URLs you changed to be removed nor not HTTPSified.
See also: https://lkml.org/lkml/2020/6/27/64
(You seem to be saying "any URLs [in the file]".)
If there are any valid, but yet not changed URLs:
See: https://lkml.org/lkml/2020/6/26/837
The URL I commented on was not valid and not changed by your patch.
If you apply the patch, please let me know.
Documentation/admin-guide/LSM/Yama.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/LSM/Yama.rst b/Documentation/admin-guide/LSM/Yama.rst
index d0a060de3973..64fd62507ae5 100644
--- a/Documentation/admin-guide/LSM/Yama.rst
+++ b/Documentation/admin-guide/LSM/Yama.rst
@@ -21,7 +21,7 @@ of their attack without resorting to user-assisted phishing.
This is not a theoretical problem. SSH session hijacking
(http://www.storm.net.nz/projects/7) and arbitrary code injection
This link is dead. It is likely best replaced by:
... I'd undo this change.
You sent me a patch to update URLs, gave me (seemingly) explicit
instructions about which things would cause you to undo individual
changes, none of which seemed to trigger, so I offered an improvement,
that would add another HTTPS URL -- which is entirely within your stated
desires to have "[one] commit ... per one thing [you've]i done" for
a patch where the Subject is literally "Replace HTTP links with HTTPS
ones", for which I suggested an improvement.
But as it's the only one here, just forget this patch.
You seem hostile to accepting feedback on how this patch could be
improved. It's one thing to use automation to help generate patches,
and I understand your apparent desires to keep it automated, but that
is not always how patch development turns out.
Your instructions appear to take a long way to just say "here's a patch,
take it or leave it" which seems pretty anti-collaborative to me.
No, no and no.
If you look up other discussions (especially the very first one) on such
patches, you'll see that *I react to change requests with improved*
(shortened) patches.
*I do them manually* and I've no problem with doing things manually, I
just automate everything that is possible.
*I don't demand to accept my patches as-is.* The only thing I demand is
letting me focus on one thing at a time.
https://lkml.org/lkml/2020/6/27/64
You requested reanimatig a dead link. That's a legit thing, but it's
*another* thing. Another than (the yet not done task of mine of) just
HTTPSifying URLs.
And as it's the only URL here, of course the whole patch makes no sense
anymore. If I'd replace the URL as you said, I'd make a *new patch* with
a *new title* and just send it --in-reply-to here. And my statement
"just forget [the old] patch" would still stand.
Also IMAO in this particular case *I don't deserve* to be the author of
the new patch as *you did all the work* for it – i.e. figured out the
replacement URL.
