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 <[email protected]>
---
Continuing my work started at 93431e0607e5.
See also: git log --oneline '--author=Alexander A. Klimov <[email protected]>' 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 (just) HTTPSified:
Just clearly say so and I'll *undo my change*.
See also: https://lkml.org/lkml/2020/6/27/64
If there are any valid, but yet not changed URLs:
See: https://lkml.org/lkml/2020/6/26/837
If you apply the patch, please let me know.
Sorry again to all maintainers who complained about subject lines.
Now I realized that you want an actually perfect prefixes,
not just subsystem ones.
I tried my best...
And yes, *I could* (at least half-)automate it.
Impossible is nothing! :)
Documentation/networking/rds.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/networking/rds.rst b/Documentation/networking/rds.rst
index 44936c27ab3a..c80d832509e2 100644
--- a/Documentation/networking/rds.rst
+++ b/Documentation/networking/rds.rst
@@ -11,7 +11,7 @@ This readme tries to provide some background on the hows and whys of RDS,
and will hopefully help you find your way around the code.
In addition, please see this email about RDS origins:
-http://oss.oracle.com/pipermail/rds-devel/2007-November/000228.html
+https://oss.oracle.com/pipermail/rds-devel/2007-November/000228.html
RDS Architecture
================
--
2.27.0
On Sun, Jul 19, 2020 at 05:58:45PM +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 <[email protected]>
> ---
> Continuing my work started at 93431e0607e5.
> See also: git log --oneline '--author=Alexander A. Klimov <[email protected]>' 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 (just) HTTPSified:
> Just clearly say so and I'll *undo my change*.
> See also: https://lkml.org/lkml/2020/6/27/64
>
> If there are any valid, but yet not changed URLs:
> See: https://lkml.org/lkml/2020/6/26/837
>
> If you apply the patch, please let me know.
>
> Sorry again to all maintainers who complained about subject lines.
> Now I realized that you want an actually perfect prefixes,
> not just subsystem ones.
> I tried my best...
> And yes, *I could* (at least half-)automate it.
> Impossible is nothing! :)
>
>
> Documentation/networking/rds.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Why can't it be done in one mega-patch?
It is insane to see patch for every file/link.
We have more than 4k files with http:// in it.
➜ kernel git:(m/hw-cleanup) git grep -c http: | tr -d ':[:digit:]' | sort | uniq |wc -l
4292
>
> diff --git a/Documentation/networking/rds.rst b/Documentation/networking/rds.rst
> index 44936c27ab3a..c80d832509e2 100644
> --- a/Documentation/networking/rds.rst
> +++ b/Documentation/networking/rds.rst
> @@ -11,7 +11,7 @@ This readme tries to provide some background on the hows and whys of RDS,
> and will hopefully help you find your way around the code.
>
> In addition, please see this email about RDS origins:
> -http://oss.oracle.com/pipermail/rds-devel/2007-November/000228.html
> +https://oss.oracle.com/pipermail/rds-devel/2007-November/000228.html
>
> RDS Architecture
> ================
> --
> 2.27.0
>
On Mon, 20 Jul 2020 07:56:26 +0300
Leon Romanovsky <[email protected]> wrote:
> > Documentation/networking/rds.rst | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Why can't it be done in one mega-patch?
> It is insane to see patch for every file/link.
>
> We have more than 4k files with http:// in it.
Do *you* want to review that megapatch? The number of issues that have
come up make it clear that these patches do, indeed, need review...
jon
On Mon, Jul 20, 2020 at 07:58:48AM -0600, Jonathan Corbet wrote:
> On Mon, 20 Jul 2020 07:56:26 +0300
> Leon Romanovsky <[email protected]> wrote:
>
> > > Documentation/networking/rds.rst | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > Why can't it be done in one mega-patch?
> > It is insane to see patch for every file/link.
> >
> > We have more than 4k files with http:// in it.
>
> Do *you* want to review that megapatch? The number of issues that have
> come up make it clear that these patches do, indeed, need review...
Can you point me to the issues?
What can go wrong with such a simple replacement?
I can review per-folder patches if it helps.
Thanks
>
> jon
On Mon, 20 Jul 2020 17:07:16 +0300
Leon Romanovsky <[email protected]> wrote:
> > Do *you* want to review that megapatch? The number of issues that have
> > come up make it clear that these patches do, indeed, need review...
>
> Can you point me to the issues?
> What can go wrong with such a simple replacement?
Some bits of the conversation:
https://lore.kernel.org/lkml/[email protected]/
https://lore.kernel.org/lkml/[email protected]/
https://lore.kernel.org/lkml/[email protected]/
https://lore.kernel.org/lkml/[email protected]/
https://lore.kernel.org/lkml/202007081531.085533FC5@keescook/
etc.
jon
On Mon, Jul 20, 2020 at 08:36:35AM -0600, Jonathan Corbet wrote:
> On Mon, 20 Jul 2020 17:07:16 +0300
> Leon Romanovsky <[email protected]> wrote:
>
> > > Do *you* want to review that megapatch? The number of issues that have
> > > come up make it clear that these patches do, indeed, need review...
> >
> > Can you point me to the issues?
> > What can go wrong with such a simple replacement?
>
> Some bits of the conversation:
>
> https://lore.kernel.org/lkml/[email protected]/
> https://lore.kernel.org/lkml/[email protected]/
> https://lore.kernel.org/lkml/[email protected]/
> https://lore.kernel.org/lkml/[email protected]/
> https://lore.kernel.org/lkml/202007081531.085533FC5@keescook/
>
> etc.
After reading your links and especially this one.
https://lore.kernel.org/lkml/[email protected]/
I don't understand why are we still seeing these patches?
I gave to the author comments too, which were ignored.
https://patchwork.kernel.org/patch/11644683/#23466547
Thanks
>
> jon
Am 20.07.20 um 18:48 schrieb Leon Romanovsky:
> On Mon, Jul 20, 2020 at 08:36:35AM -0600, Jonathan Corbet wrote:
>> On Mon, 20 Jul 2020 17:07:16 +0300
>> Leon Romanovsky <[email protected]> wrote:
>>
>>>> Do *you* want to review that megapatch? The number of issues that have
This question is... interesting.
And no, I would not.
>>>> come up make it clear that these patches do, indeed, need review...
>>>
>>> Can you point me to the issues?
>>> What can go wrong with such a simple replacement?
>>
>> Some bits of the conversation:
>>
>> https://lore.kernel.org/lkml/[email protected]/
>> https://lore.kernel.org/lkml/[email protected]/
>> https://lore.kernel.org/lkml/[email protected]/
>> https://lore.kernel.org/lkml/[email protected]/
>> https://lore.kernel.org/lkml/202007081531.085533FC5@keescook/
>>
>> etc.
>
> After reading your links and especially this one.
> https://lore.kernel.org/lkml/[email protected]/
> I don't understand why are we still seeing these patches?
>
> I gave to the author comments too, which were ignored.
> https://patchwork.kernel.org/patch/11644683/#23466547
I've added SPDXing (the automated way of course ;) ) to my todo list.
>
> Thanks
>
>>
>> jon
On Mon, Jul 20, 2020 at 11:34:00PM +0200, Alexander A. Klimov wrote:
>
>
> Am 20.07.20 um 18:48 schrieb Leon Romanovsky:
> > On Mon, Jul 20, 2020 at 08:36:35AM -0600, Jonathan Corbet wrote:
> > > On Mon, 20 Jul 2020 17:07:16 +0300
> > > Leon Romanovsky <[email protected]> wrote:
> > >
> > > > > Do *you* want to review that megapatch? The number of issues that have
> This question is... interesting.
> And no, I would not.
You are EXPECTED to review your work prior sending to the mailing list.
>
> > > > > come up make it clear that these patches do, indeed, need review...
> > > >
> > > > Can you point me to the issues?
> > > > What can go wrong with such a simple replacement?
> > >
> > > Some bits of the conversation:
> > >
> > > https://lore.kernel.org/lkml/[email protected]/
> > > https://lore.kernel.org/lkml/[email protected]/
> > > https://lore.kernel.org/lkml/[email protected]/
> > > https://lore.kernel.org/lkml/[email protected]/
> > > https://lore.kernel.org/lkml/202007081531.085533FC5@keescook/
> > >
> > > etc.
> >
> > After reading your links and especially this one.
> > https://lore.kernel.org/lkml/[email protected]/
> > I don't understand why are we still seeing these patches?
> >
> > I gave to the author comments too, which were ignored.
> > https://patchwork.kernel.org/patch/11644683/#23466547
> I've added SPDXing (the automated way of course ;) ) to my todo list.
OMG, why don't you listen? We don't want your automatic patches.
Thanks
>
> >
> > Thanks
> >
> > >
> > > jon
Am 21.07.20 um 08:05 schrieb Leon Romanovsky:
> On Mon, Jul 20, 2020 at 11:34:00PM +0200, Alexander A. Klimov wrote:
>>
>>
>> Am 20.07.20 um 18:48 schrieb Leon Romanovsky:
>>> On Mon, Jul 20, 2020 at 08:36:35AM -0600, Jonathan Corbet wrote:
>>>> On Mon, 20 Jul 2020 17:07:16 +0300
>>>> Leon Romanovsky <[email protected]> wrote:
>>>>
>>>>>> Do *you* want to review that megapatch? The number of issues that have
>> This question is... interesting.
>> And no, I would not.
>
> You are EXPECTED to review your work prior sending to the mailing list.
I meant I wouldn't review *one big* patch.
I didn't mean my actually sent smaller ones.
>
>>
>>>>>> come up make it clear that these patches do, indeed, need review...
>>>>>
>>>>> Can you point me to the issues?
>>>>> What can go wrong with such a simple replacement?
>>>>
>>>> Some bits of the conversation:
>>>>
>>>> https://lore.kernel.org/lkml/[email protected]/
>>>> https://lore.kernel.org/lkml/[email protected]/
>>>> https://lore.kernel.org/lkml/[email protected]/
>>>> https://lore.kernel.org/lkml/[email protected]/
>>>> https://lore.kernel.org/lkml/202007081531.085533FC5@keescook/
>>>>
>>>> etc.
>>>
>>> After reading your links and especially this one.
>>> https://lore.kernel.org/lkml/[email protected]/
>>> I don't understand why are we still seeing these patches?
>>>
>>> I gave to the author comments too, which were ignored.
>>> https://patchwork.kernel.org/patch/11644683/#23466547
>> I've added SPDXing (the automated way of course ;) ) to my todo list.
>
> OMG, why don't you listen? We don't want your automatic patches.
Wrong.
*Some of you* don't want my automatic patches.
And *some others* already applied them and said thanks.
>
> Thanks
>
>>
>>>
>>> Thanks
>>>
>>>>
>>>> jon
On Tue, Jul 21, 2020 at 08:43:00AM +0200, Alexander A. Klimov wrote:
>
>
> Am 21.07.20 um 08:05 schrieb Leon Romanovsky:
> > On Mon, Jul 20, 2020 at 11:34:00PM +0200, Alexander A. Klimov wrote:
> > >
> > >
> > > Am 20.07.20 um 18:48 schrieb Leon Romanovsky:
> > > > On Mon, Jul 20, 2020 at 08:36:35AM -0600, Jonathan Corbet wrote:
> > > > > On Mon, 20 Jul 2020 17:07:16 +0300
> > > > > Leon Romanovsky <[email protected]> wrote:
> > > > >
> > > > > > > Do *you* want to review that megapatch? The number of issues that have
> > > This question is... interesting.
> > > And no, I would not.
> >
> > You are EXPECTED to review your work prior sending to the mailing list.
> I meant I wouldn't review *one big* patch.
> I didn't mean my actually sent smaller ones.
>
> >
> > >
> > > > > > > come up make it clear that these patches do, indeed, need review...
> > > > > >
> > > > > > Can you point me to the issues?
> > > > > > What can go wrong with such a simple replacement?
> > > > >
> > > > > Some bits of the conversation:
> > > > >
> > > > > https://lore.kernel.org/lkml/[email protected]/
> > > > > https://lore.kernel.org/lkml/[email protected]/
> > > > > https://lore.kernel.org/lkml/[email protected]/
> > > > > https://lore.kernel.org/lkml/[email protected]/
> > > > > https://lore.kernel.org/lkml/202007081531.085533FC5@keescook/
> > > > >
> > > > > etc.
> > > >
> > > > After reading your links and especially this one.
> > > > https://lore.kernel.org/lkml/[email protected]/
> > > > I don't understand why are we still seeing these patches?
> > > >
> > > > I gave to the author comments too, which were ignored.
> > > > https://patchwork.kernel.org/patch/11644683/#23466547
> > > I've added SPDXing (the automated way of course ;) ) to my todo list.
> >
> > OMG, why don't you listen? We don't want your automatic patches.
> Wrong.
> *Some of you* don't want my automatic patches.
> And *some others* already applied them and said thanks.
Sure, it is automatic.
Anyway, good luck, may the force be with you!.
Thanks
>
> >
> > Thanks
> >
> > >
> > > >
> > > > Thanks
> > > >
> > > > >
> > > > > jon