Re: [PATCH] Replace HTTP links with HTTPS ones: YAMA SECURITY MODULE

[Alexander A. Klimov]

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.

>