Thanks, Henrik. I'm agnostic on this change but I thought it was
interesting it took Dave some trouble to setup http vs https.
On 4/30/2022 11:46 PM, 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..
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
kmcgr...@apache.org
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171
--
Kevin A. McGrail
kmcgr...@apache.org
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171
