On 5/1/22 05:46, Henrik K wrote:
> 
> If you look at current MIRRORED.BY, that's how it already done.
> 
> Only 3.3 skips any non-http:// lines.  So 3.3 rule updates need to be
> officially deprecated before changing last http-mirror.  And amazingly there
> are still active users as seen from the "if has()" reports..
> 
on my mirror ~10% requests have http user-agent sa-update/svn*/3.3.x, this is 
not a correct calculated percent
because some users are checking the mirrors more often then others.

 Giovanni


> I'll leave general timetable for the list consensus, it's up to the
> volunteers..
> 
> On Sat, Apr 30, 2022 at 09:55:26PM -0400, Kevin A. McGrail wrote:
>> That's quite interesting, Dave.  Thanks.
>>
>> Henrik, do we have a way of supporting both http and https?  So like one
>> config line is http and another is https?  Then we can ask mirrors to start
>> moving to https with a goal perhaps of next May?
>>
>> Regards,
>>
>> KAM
>>
>> On 4/29/2022 12:27 AM, Dave Warren wrote:
>>> On 2022-04-28 07:30, Bill Cole wrote:
>>>> I see no reason to make HTTPS mandatory for mirrors at this point.
>>>> It does mean an extra layer that can break and the impersonation
>>>> attacks that it enables would be extremely complicated to mount, so
>>>> may be entirely theoretical. I would rather keep unencrypted
>>>> mirrors for the sake of availability than drive away helpful
>>>> collaborators just because they haven't had a free hour recently to
>>>> make HTTPS work.
>>>
>>> I don't care either way, but it is literally more work for me to
>>> maintain a HTTP mirror than not.
>>>
>>> Why? My web server configuration all starts with a default "HTTP? 301
>>> redirect to HTTPS" rule, so getting HTTP content to bypass that is
>>> literally more lines of configuration, and extra testing when upgrading
>>> software or moving stuff around.
>>>
>>> It isn't a big deal. The "work" is already done, and I mirror
>>> torbrowser and sometimes tails as well and there is a stronger use-case
>>> for maintaining HTTP indefinitely there, so adding one more hostname to
>>> the "okay, serve it with http too" list isn't even on my radar of
>>> things to care about.
>>>
>>> I do care about encryption in general though.
>>>
>>> HTTPS is an inconsequential amount of overhead and has been for a
>>> decade or so (from my perspective). And I have trouble imagining any
>>> machine that is simultaneously powerful enough to run SpamAssassin and
>>> also finds the overhead of HTTPS as consequential.
>>>
>>> As noted elsewhere in the thread, I'm one of the mirrors that offers
>>> HTTPS already, this is because it is already part of my provisioning
>>> system when I add a site and like allowing HTTP at all, it would be
>>> more work to carve out an exception.
>>>
>>> I have no preference or vote in either direction here specifically, but
>>> for my part I consider HTTP legacy and am a strong believer in
>>> replacing HTTP services with a static 301 response and calling it a
>>> day.
>>
>> -- 
>> Kevin A. McGrail
>> [email protected]
>>
>> Member, Apache Software Foundation
>> Chair Emeritus Apache SpamAssassin Project
>> https://www.linkedin.com/in/kmcgrail - 703.798.0171

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply via email to