Re: HTTPS for mirrors
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.
Re: checkSAupdateMirrors.sh on sa-vm.apache.org - 0 mirrors DOWN, 2 mirrors STALE
On 2022-04-27 06:29, Henrik K wrote: On Tue, Apr 26, 2022 at 12:28:44AM -0600, Dave Warren wrote: On 2022-04-25 22:18, aut...@sa-vm.apache.org wrote: http://sa-update.razx.cloud/ (172.67.206.130): UP (STALE since 1650939481, 2 hours) http://sa-update.razx.cloud/ (104.21.69.80): UP (STALE since 1650939481, 2 hours) Weird. Fixed for now, but I'll monitor tomorrow since it looks like it got stuck a couple times. Any solution for this problem? This time I am trying actually deploying the solution, not just testing a solution and calling it a day. The problem is between the web server storing the files and a caching layer. Requests for the actual files would be served correctly, but non-immutable files like the MIRROR* stuff was being served out of date for a period of time (not forever). This time it might actually be fixed-fixed. Sorry for all the extra mailing list noise.
Re: HTTPS for mirrors
On Wed, Apr 27, 2022 at 05:34:57PM +0300, Henrik K wrote: > > Btw I just updated DNS to https too: > mirrors.updates.spamassassin.org. > "https://spamassassin.apache.org/updates/MIRRORED.BY; Actually it's now: mirrors.updates.spamassassin.org. "https://spamassassin.apache.org/updates/MIRRORED.BY; mirrors.updates.spamassassin.org. "http://sa-update.spamassassin.org/MIRRORED.BY; Not sure why before it relied only on apache.org as a single point of failure. Multiple records have been supported atleast from 3.3, so why not have two project maintained servers there..
checkSAupdateMirrors.sh on sa-vm.apache.org - 0 mirrors DOWN, 2 mirrors STALE
https://sa-update.mailfud.org/ (5.196.88.134): UP (CURRENT) http://sa-update.dnswl.org/ (116.203.4.105): UP (CURRENT) https://www.sa-update.pccc.com/ (69.171.29.42): UP (CURRENT) http://sa-update.space-pro.be/ (176.28.55.20): UP (CURRENT) http://sa-update.ena.com/ (96.4.1.5): UP (CURRENT) http://sa-update.ena.com/ (96.5.1.5): UP (CURRENT) https://sa-update.razx.cloud/ (104.21.69.80): UP (STALE since 1651187881, 3 hours) https://sa-update.razx.cloud/ (172.67.206.130): UP (STALE since 1651187881, 3 hours) http://sa-update.fossies.org/ (144.76.163.196): UP (CURRENT) http://sa-update.verein-clean.net/ (37.252.124.130): UP (CURRENT) http://sa-update.verein-clean.net/ (37.252.120.157): UP (CURRENT) https://sa-update-asf.snb.it/ (151.80.178.91): UP (CURRENT) http://sa-update.spamassassin.org/ (64.142.56.146): UP (CURRENT)
checkSAupdateMirrors.sh on sa-vm.apache.org - 0 mirrors DOWN, 2 mirrors STALE
https://sa-update.mailfud.org/ (5.196.88.134): UP (CURRENT) http://sa-update.dnswl.org/ (116.203.4.105): UP (CURRENT) https://www.sa-update.pccc.com/ (69.171.29.42): UP (CURRENT) http://sa-update.space-pro.be/ (176.28.55.20): UP (CURRENT) http://sa-update.ena.com/ (96.4.1.5): UP (CURRENT) http://sa-update.ena.com/ (96.5.1.5): UP (CURRENT) https://sa-update.razx.cloud/ (172.67.206.130): UP (STALE since 1651187881, 2 hours) https://sa-update.razx.cloud/ (104.21.69.80): UP (STALE since 1651187881, 2 hours) http://sa-update.fossies.org/ (144.76.163.196): UP (CURRENT) http://sa-update.verein-clean.net/ (37.252.120.157): UP (CURRENT) http://sa-update.verein-clean.net/ (37.252.124.130): UP (CURRENT) https://sa-update-asf.snb.it/ (151.80.178.91): UP (CURRENT) http://sa-update.spamassassin.org/ (64.142.56.146): UP (CURRENT)
checkSAupdateMirrors.sh on sa-vm.apache.org - 0 mirrors DOWN, 2 mirrors STALE
https://sa-update.mailfud.org/ (5.196.88.134): UP (CURRENT) http://sa-update.dnswl.org/ (116.203.4.105): UP (CURRENT) https://www.sa-update.pccc.com/ (69.171.29.42): UP (CURRENT) http://sa-update.space-pro.be/ (176.28.55.20): UP (CURRENT) http://sa-update.ena.com/ (96.4.1.5): UP (CURRENT) http://sa-update.ena.com/ (96.5.1.5): UP (CURRENT) https://sa-update.razx.cloud/ (104.21.69.80): UP (STALE since 1651177081, 3 hours) https://sa-update.razx.cloud/ (172.67.206.130): UP (STALE since 1651177081, 3 hours) http://sa-update.fossies.org/ (144.76.163.196): UP (CURRENT) http://sa-update.verein-clean.net/ (37.252.120.157): UP (CURRENT) http://sa-update.verein-clean.net/ (37.252.124.130): UP (CURRENT) https://sa-update-asf.snb.it/ (151.80.178.91): UP (CURRENT) http://sa-update.spamassassin.org/ (64.142.56.146): UP (CURRENT)
checkSAupdateMirrors.sh on sa-vm.apache.org - 0 mirrors DOWN, 2 mirrors STALE
https://sa-update.mailfud.org/ (5.196.88.134): UP (CURRENT) http://sa-update.dnswl.org/ (116.203.4.105): UP (CURRENT) https://www.sa-update.pccc.com/ (69.171.29.42): UP (CURRENT) http://sa-update.space-pro.be/ (176.28.55.20): UP (CURRENT) http://sa-update.ena.com/ (96.5.1.5): UP (CURRENT) http://sa-update.ena.com/ (96.4.1.5): UP (CURRENT) https://sa-update.razx.cloud/ (104.21.69.80): UP (STALE since 1651177081, 2 hours) https://sa-update.razx.cloud/ (172.67.206.130): UP (STALE since 1651177081, 2 hours) http://sa-update.fossies.org/ (144.76.163.196): UP (CURRENT) http://sa-update.verein-clean.net/ (37.252.124.130): UP (CURRENT) http://sa-update.verein-clean.net/ (37.252.120.157): UP (CURRENT) https://sa-update-asf.snb.it/ (151.80.178.91): UP (CURRENT) http://sa-update.spamassassin.org/ (64.142.56.146): UP (CURRENT)
checkSAupdateMirrors.sh on sa-vm.apache.org - 0 mirrors DOWN, 2 mirrors STALE
https://sa-update.mailfud.org/ (5.196.88.134): UP (CURRENT) http://sa-update.dnswl.org/ (116.203.4.105): UP (CURRENT) https://www.sa-update.pccc.com/ (69.171.29.42): UP (CURRENT) http://sa-update.space-pro.be/ (176.28.55.20): UP (CURRENT) http://sa-update.ena.com/ (96.5.1.5): UP (CURRENT) http://sa-update.ena.com/ (96.4.1.5): UP (CURRENT) https://sa-update.razx.cloud/ (172.67.206.130): UP (STALE since 1651166282, 2 hours) https://sa-update.razx.cloud/ (104.21.69.80): UP (STALE since 1651166282, 2 hours) http://sa-update.fossies.org/ (144.76.163.196): UP (CURRENT) http://sa-update.verein-clean.net/ (37.252.120.157): UP (CURRENT) http://sa-update.verein-clean.net/ (37.252.124.130): UP (CURRENT) https://sa-update-asf.snb.it/ (151.80.178.91): UP (CURRENT) http://sa-update.spamassassin.org/ (64.142.56.146): UP (CURRENT)
checkSAupdateMirrors.sh on sa-vm.apache.org - 0 mirrors DOWN, 2 mirrors STALE
https://sa-update.mailfud.org/ (5.196.88.134): UP (CURRENT) http://sa-update.dnswl.org/ (116.203.4.105): UP (CURRENT) https://www.sa-update.pccc.com/ (69.171.29.42): UP (CURRENT) http://sa-update.space-pro.be/ (176.28.55.20): UP (CURRENT) http://sa-update.ena.com/ (96.4.1.5): UP (CURRENT) http://sa-update.ena.com/ (96.5.1.5): UP (CURRENT) https://sa-update.razx.cloud/ (172.67.206.130): UP (STALE since 1651166282, 1 hours) https://sa-update.razx.cloud/ (104.21.69.80): UP (STALE since 1651166282, 1 hours) http://sa-update.fossies.org/ (144.76.163.196): UP (CURRENT) http://sa-update.verein-clean.net/ (37.252.120.157): UP (CURRENT) http://sa-update.verein-clean.net/ (37.252.124.130): UP (CURRENT) https://sa-update-asf.snb.it/ (151.80.178.91): UP (CURRENT) http://sa-update.spamassassin.org/ (64.142.56.146): UP (CURRENT)
checkSAupdateMirrors.sh on sa-vm.apache.org - 0 mirrors DOWN, 2 mirrors STALE
https://sa-update.mailfud.org/ (5.196.88.134): UP (CURRENT) http://sa-update.dnswl.org/ (116.203.4.105): UP (CURRENT) https://www.sa-update.pccc.com/ (69.171.29.42): UP (CURRENT) http://sa-update.space-pro.be/ (176.28.55.20): UP (CURRENT) http://sa-update.ena.com/ (96.5.1.5): UP (CURRENT) http://sa-update.ena.com/ (96.4.1.5): UP (CURRENT) https://sa-update.razx.cloud/ (172.67.206.130): UP (STALE since 1651155481, 3 hours) https://sa-update.razx.cloud/ (104.21.69.80): UP (STALE since 1651155481, 3 hours) http://sa-update.fossies.org/ (144.76.163.196): UP (CURRENT) http://sa-update.verein-clean.net/ (37.252.120.157): UP (CURRENT) http://sa-update.verein-clean.net/ (37.252.124.130): UP (CURRENT) https://sa-update-asf.snb.it/ (151.80.178.91): UP (CURRENT) http://sa-update.spamassassin.org/ (64.142.56.146): UP (CURRENT)
checkSAupdateMirrors.sh on sa-vm.apache.org - 0 mirrors DOWN, 2 mirrors STALE
https://sa-update.mailfud.org/ (5.196.88.134): UP (CURRENT) http://sa-update.dnswl.org/ (116.203.4.105): UP (CURRENT) https://www.sa-update.pccc.com/ (69.171.29.42): UP (CURRENT) http://sa-update.space-pro.be/ (176.28.55.20): UP (CURRENT) http://sa-update.ena.com/ (96.5.1.5): UP (CURRENT) http://sa-update.ena.com/ (96.4.1.5): UP (CURRENT) https://sa-update.razx.cloud/ (172.67.206.130): UP (STALE since 1651155481, 2 hours) https://sa-update.razx.cloud/ (104.21.69.80): UP (STALE since 1651155481, 2 hours) http://sa-update.fossies.org/ (144.76.163.196): UP (CURRENT) http://sa-update.verein-clean.net/ (37.252.124.130): UP (CURRENT) http://sa-update.verein-clean.net/ (37.252.120.157): UP (CURRENT) https://sa-update-asf.snb.it/ (151.80.178.91): UP (CURRENT) http://sa-update.spamassassin.org/ (64.142.56.146): UP (CURRENT)
Re: HTTPS for mirrors
On Thu, Apr 28, 2022 at 09:30:21AM -0400, Bill Cole wrote: > > and the impersonation attacks that it enables would be extremely > complicated to mount, so may be entirely theoretical. Of course it is. It's probably thousand times more likely that a mirror itself is hacked and it's files replaced. But don't you love to see a warm and fuzzy secure lock on your connection?
checkSAupdateMirrors.sh on sa-vm.apache.org - 0 mirrors DOWN, 2 mirrors STALE
https://sa-update.mailfud.org/ (5.196.88.134): UP (CURRENT) http://sa-update.dnswl.org/ (116.203.4.105): UP (CURRENT) https://www.sa-update.pccc.com/ (69.171.29.42): UP (CURRENT) http://sa-update.space-pro.be/ (176.28.55.20): UP (CURRENT) http://sa-update.ena.com/ (96.4.1.5): UP (CURRENT) http://sa-update.ena.com/ (96.5.1.5): UP (CURRENT) https://sa-update.razx.cloud/ (172.67.206.130): UP (STALE since 1651144681, 3 hours) https://sa-update.razx.cloud/ (104.21.69.80): UP (STALE since 1651144681, 3 hours) http://sa-update.fossies.org/ (144.76.163.196): UP (CURRENT) http://sa-update.verein-clean.net/ (37.252.124.130): UP (CURRENT) http://sa-update.verein-clean.net/ (37.252.120.157): UP (CURRENT) https://sa-update-asf.snb.it/ (151.80.178.91): UP (CURRENT) http://sa-update.spamassassin.org/ (64.142.56.146): UP (CURRENT)
Re: HTTPS for mirrors
On 2022-04-28 at 06:40:58 UTC-0400 (Thu, 28 Apr 2022 12:40:58 +0200 (CEST)) Fossies Administrator is rumored to have said: On Wed, 27 Apr 2022, Henrik K wrote: There's really no reason these days for not using https. Only three mirrors work with it right now: sa-update.razx.cloud sa-update.pccc.com sa-update.mailfud.org Could maybe others prepare for it? sa-update seems to happily use https:// mirrors starting from 3.4.0, so there shouldn't be any reason not to update these. Btw I just updated DNS to https too: mirrors.updates.spamassassin.org. "https://spamassassin.apache.org/updates/MIRRORED.BY; Apparently spamassassin.apache.org has had https-redirect for a long time, which broke the old checkSAupdateMirrors.sh script too. Unfortunately my server fossies.org currently uses a commercial certificate only usable for the names "fossies.org" and "www.fossies.org" but not for "sa-update.fossies.org" and some first general tests some months ago using Let's Encrypt were not yet successful. It is easy enough to adjust the URL for your mirror to align with a certificate that works. There's nothing magical about the 'sa-update' hostname. FWIW, I've had the best LE experience using the "acme.sh" tool (https://github.com/acmesh-official/acme.sh) rather than the Python-based Certbot tool. It has support for LE and for some other free certificate services. Since I don't know when I have time for a new attempt (probably summer/autumn after a big hardware migration) and the https request seems understandable you may remove the server "sa-update.fossies.org" if meaningful (relatively easy to get over, since it only has a weight of 1). 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. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
checkSAupdateMirrors.sh on sa-vm.apache.org - 0 mirrors DOWN, 2 mirrors STALE
https://sa-update.mailfud.org/ (5.196.88.134): UP (CURRENT) http://sa-update.dnswl.org/ (116.203.4.105): UP (CURRENT) https://www.sa-update.pccc.com/ (69.171.29.42): UP (CURRENT) http://sa-update.space-pro.be/ (176.28.55.20): UP (CURRENT) http://sa-update.ena.com/ (96.4.1.5): UP (CURRENT) http://sa-update.ena.com/ (96.5.1.5): UP (CURRENT) https://sa-update.razx.cloud/ (104.21.69.80): UP (STALE since 1651144681, 2 hours) https://sa-update.razx.cloud/ (172.67.206.130): UP (STALE since 1651144681, 2 hours) http://sa-update.fossies.org/ (144.76.163.196): UP (CURRENT) http://sa-update.verein-clean.net/ (37.252.120.157): UP (CURRENT) http://sa-update.verein-clean.net/ (37.252.124.130): UP (CURRENT) https://sa-update-asf.snb.it/ (151.80.178.91): UP (CURRENT) http://sa-update.spamassassin.org/ (64.142.56.146): UP (CURRENT)
Re: HTTPS for mirrors
On 2022-04-28 at 07:36:45 UTC-0400 (Thu, 28 Apr 2022 14:36:45 +0300) Henrik K is rumored to have said: On Thu, Apr 28, 2022 at 07:26:41AM -0400, Kevin A. McGrail wrote: We discussed this a year or two ago. The data on there is not sensitive and is cryptographically verified by spamassassin before being used. Can you name a single reason the data needs to be encrypted in transit? Targeted host impersonation attacks. Even if an attacker couldn't inject a signed package using the right key this way, they could prevent updates by injecting an old package with a new name or arbitrary signed packages using an impersonating key. I think it is only prudent to treat SA rules and config as code, and assume that a malicious actor who can inject arbitrary rules and config can take over a machine, particularly on machines using spamd (often running as root so that it can support per-user rules.) We've closed the obvious paths for that, but I don't think we can or should assume that the worst thing bad rules can do is make SA mislabel mail (bad enough in itself.) It's only verified if the user chooses to do so, is not downloading stuff manually or whatever. Regardless, can YOU name a single reason why transmitted data should not be encrypted in the year 2022, as it's trivial to do so? Strange debate from a security expert. We've already seen one described in this thread by a mirror admin. It is apparently non-trivial to set up and maintain a working certificate configuration. Host authentication is the one compelling reason for using HTTPS with public data, so being lenient in certificate validation is not a solution. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: HTTPS for mirrors
On Thu, Apr 28, 2022 at 07:41:56AM -0400, Kevin A. McGrail wrote: > By default, the data is cryptographically verified. An admin has to > specifically turn off that feature. > > There's little benefits of using HTTPS in this specific setting and it's > just an extra requirement on our volunteer mirrors. It will add time, CPU > load, and even a small amount of bandwidth increase. All to achieve nothing. > > >From a security analysis, this is public data so it's a very low risk with > no data toxicity. > > I just don't see the benefit. As a security expert, I also make sure to > focus my time where it's best utilized. So I am recommending that you and > I can spend our time elsewhere as well as our mirror volunteers :-) I spent few hours to prove that it works and simple to activate, making things more future proof. No one is forcing mirrors to migrate (sad to say I'm not a dictator), but I'd suggest everyone does. Even my Intel Atom server handles all the SSL with few percent CPU load - talking about the CPU/bandwidth wastes more time..
Re: HTTPS for mirrors
By default, the data is cryptographically verified. An admin has to specifically turn off that feature. There's little benefits of using HTTPS in this specific setting and it's just an extra requirement on our volunteer mirrors. It will add time, CPU load, and even a small amount of bandwidth increase. All to achieve nothing. >From a security analysis, this is public data so it's a very low risk with no data toxicity. I just don't see the benefit. As a security expert, I also make sure to focus my time where it's best utilized. So I am recommending that you and I can spend our time elsewhere as well as our mirror volunteers :-) -KAM On Thu, Apr 28, 2022, 07:36 Henrik K wrote: > On Thu, Apr 28, 2022 at 07:26:41AM -0400, Kevin A. McGrail wrote: > > We discussed this a year or two ago. The data on there is not sensitive > and > > is cryptographically verified by spamassassin before being used. Can you > > name a single reason the data needs to be encrypted in transit? KAM > > It's only verified if the user chooses to do so, is not downloading stuff > manually or whatever. Regardless, can YOU name a single reason why > transmitted data should not be encrypted in the year 2022, as it's trivial > to do so? Strange debate from a security expert. > >
Re: HTTPS for mirrors
On Thu, Apr 28, 2022 at 07:26:41AM -0400, Kevin A. McGrail wrote: > We discussed this a year or two ago. The data on there is not sensitive and > is cryptographically verified by spamassassin before being used. Can you > name a single reason the data needs to be encrypted in transit? KAM It's only verified if the user chooses to do so, is not downloading stuff manually or whatever. Regardless, can YOU name a single reason why transmitted data should not be encrypted in the year 2022, as it's trivial to do so? Strange debate from a security expert.
Re: HTTPS for mirrors
We discussed this a year or two ago. The data on there is not sensitive and is cryptographically verified by spamassassin before being used. Can you name a single reason the data needs to be encrypted in transit? KAM On Thu, Apr 28, 2022, 07:17 Henrik K wrote: > On Thu, Apr 28, 2022 at 12:40:58PM +0200, Fossies Administrator wrote: > > On Wed, 27 Apr 2022, Henrik K wrote: > > > > > > > > There's really no reason these days for not using https. > > > > > > Only three mirrors work with it right now: > > > > > > sa-update.razx.cloud > > > sa-update.pccc.com > > > sa-update.mailfud.org > > > > > > Could maybe others prepare for it? sa-update seems to happily use > https:// > > > mirrors starting from 3.4.0, so there shouldn't be any reason not to > update > > > these. > > > > > > Btw I just updated DNS to https too: > > > mirrors.updates.spamassassin.org. " > https://spamassassin.apache.org/updates/MIRRORED.BY; > > > > > > Apparently spamassassin.apache.org has had https-redirect for a long > time, > > > which broke the old checkSAupdateMirrors.sh script too. > > > > Unfortunately my server fossies.org currently uses a commercial > certificate > > only usable for the names "fossies.org" and "www.fossies.org" but not > for > > "sa-update.fossies.org" and some first general tests some months ago > using > > Let's Encrypt were not yet successful. > > > > Since I don't know when I have time for a new attempt (probably > > summer/autumn after a big hardware migration) and the https request seems > > understandable you may remove the server "sa-update.fossies.org" > > if meaningful (relatively easy to get over, since it only has a weight > of 1). > > I don't see it as a huge problem if we leave few mirrors as http:// - it > enables ancient 3.3 clients to still get some updates.. dunno if that's > good or bad. Maybe let's try to convert all "this year"? > > Btw about mirror weights, how were they decided? Basically weight=1 means > there's a 1/50 chance to get a request, or 10 times less than the weight=10 > mirrors. Is everyone happy about the amount of traffic they receive? I'll > probably bump mine up a bit since I have no traffic limits/costs.. > > sa-update.verein-clean.net (1/4.8 chance) > sa-update.spamassassin.org (1/4.8 chance) > www.sa-update.pccc.com (1/9.6 chance) > sa-update.ena.com (1/9.6 chance) > sa-update.razx.cloud (1/9.6 chance) > sa-update-asf.snb.it (1/9.6 chance) > sa-update.dnswl.org (1/16.0 chance) > sa-update.mailfud.org (1/16.0 chance) > sa-update.space-pro.be (1/47.2 chance) > sa-update.fossies.org (1/47.4 chance) > > Cheers, > Henrik >
checkSAupdateMirrors.sh on sa-vm.apache.org - 0 mirrors DOWN, 2 mirrors STALE
https://sa-update.mailfud.org/ (5.196.88.134): UP (CURRENT) http://sa-update.dnswl.org/ (116.203.4.105): UP (CURRENT) https://www.sa-update.pccc.com/ (69.171.29.42): UP (CURRENT) http://sa-update.space-pro.be/ (176.28.55.20): UP (CURRENT) http://sa-update.ena.com/ (96.5.1.5): UP (CURRENT) http://sa-update.ena.com/ (96.4.1.5): UP (CURRENT) https://sa-update.razx.cloud/ (172.67.206.130): UP (STALE since 1651133881, 3 hours) https://sa-update.razx.cloud/ (104.21.69.80): UP (STALE since 1651133881, 3 hours) http://sa-update.fossies.org/ (144.76.163.196): UP (CURRENT) http://sa-update.verein-clean.net/ (37.252.120.157): UP (CURRENT) http://sa-update.verein-clean.net/ (37.252.124.130): UP (CURRENT) https://sa-update-asf.snb.it/ (151.80.178.91): UP (CURRENT) http://sa-update.spamassassin.org/ (64.142.56.146): UP (CURRENT)
Re: HTTPS for mirrors
On Thu, Apr 28, 2022 at 12:40:58PM +0200, Fossies Administrator wrote: > On Wed, 27 Apr 2022, Henrik K wrote: > > > > > There's really no reason these days for not using https. > > > > Only three mirrors work with it right now: > > > > sa-update.razx.cloud > > sa-update.pccc.com > > sa-update.mailfud.org > > > > Could maybe others prepare for it? sa-update seems to happily use https:// > > mirrors starting from 3.4.0, so there shouldn't be any reason not to update > > these. > > > > Btw I just updated DNS to https too: > > mirrors.updates.spamassassin.org. > > "https://spamassassin.apache.org/updates/MIRRORED.BY; > > > > Apparently spamassassin.apache.org has had https-redirect for a long time, > > which broke the old checkSAupdateMirrors.sh script too. > > Unfortunately my server fossies.org currently uses a commercial certificate > only usable for the names "fossies.org" and "www.fossies.org" but not for > "sa-update.fossies.org" and some first general tests some months ago using > Let's Encrypt were not yet successful. > > Since I don't know when I have time for a new attempt (probably > summer/autumn after a big hardware migration) and the https request seems > understandable you may remove the server "sa-update.fossies.org" > if meaningful (relatively easy to get over, since it only has a weight of 1). I don't see it as a huge problem if we leave few mirrors as http:// - it enables ancient 3.3 clients to still get some updates.. dunno if that's good or bad. Maybe let's try to convert all "this year"? Btw about mirror weights, how were they decided? Basically weight=1 means there's a 1/50 chance to get a request, or 10 times less than the weight=10 mirrors. Is everyone happy about the amount of traffic they receive? I'll probably bump mine up a bit since I have no traffic limits/costs.. sa-update.verein-clean.net (1/4.8 chance) sa-update.spamassassin.org (1/4.8 chance) www.sa-update.pccc.com (1/9.6 chance) sa-update.ena.com (1/9.6 chance) sa-update.razx.cloud (1/9.6 chance) sa-update-asf.snb.it (1/9.6 chance) sa-update.dnswl.org (1/16.0 chance) sa-update.mailfud.org (1/16.0 chance) sa-update.space-pro.be (1/47.2 chance) sa-update.fossies.org (1/47.4 chance) Cheers, Henrik
Re: HTTPS for mirrors
On Wed, 27 Apr 2022, Henrik K wrote: There's really no reason these days for not using https. Only three mirrors work with it right now: sa-update.razx.cloud sa-update.pccc.com sa-update.mailfud.org Could maybe others prepare for it? sa-update seems to happily use https:// mirrors starting from 3.4.0, so there shouldn't be any reason not to update these. Btw I just updated DNS to https too: mirrors.updates.spamassassin.org. "https://spamassassin.apache.org/updates/MIRRORED.BY; Apparently spamassassin.apache.org has had https-redirect for a long time, which broke the old checkSAupdateMirrors.sh script too. Unfortunately my server fossies.org currently uses a commercial certificate only usable for the names "fossies.org" and "www.fossies.org" but not for "sa-update.fossies.org" and some first general tests some months ago using Let's Encrypt were not yet successful. Since I don't know when I have time for a new attempt (probably summer/autumn after a big hardware migration) and the https request seems understandable you may remove the server "sa-update.fossies.org" if meaningful (relatively easy to get over, since it only has a weight of 1). Regards Jens -- FOSSIES - The Fresh Open Source Software archive mainly for Internet, Engineering and Science https://fossies.org/
checkSAupdateMirrors.sh on sa-vm.apache.org - 0 mirrors DOWN, 2 mirrors STALE
https://sa-update.mailfud.org/ (5.196.88.134): UP (CURRENT) http://sa-update.dnswl.org/ (116.203.4.105): UP (CURRENT) https://www.sa-update.pccc.com/ (69.171.29.42): UP (CURRENT) http://sa-update.space-pro.be/ (176.28.55.20): UP (CURRENT) http://sa-update.ena.com/ (96.4.1.5): UP (CURRENT) http://sa-update.ena.com/ (96.5.1.5): UP (CURRENT) https://sa-update.razx.cloud/ (172.67.206.130): UP (STALE since 1651133881, 2 hours) https://sa-update.razx.cloud/ (104.21.69.80): UP (STALE since 1651133881, 2 hours) http://sa-update.fossies.org/ (144.76.163.196): UP (CURRENT) http://sa-update.verein-clean.net/ (37.252.120.157): UP (CURRENT) http://sa-update.verein-clean.net/ (37.252.124.130): UP (CURRENT) https://sa-update-asf.snb.it/ (151.80.178.91): UP (CURRENT) http://sa-update.spamassassin.org/ (64.142.56.146): UP (CURRENT)
Cron /usr/local/spamassassin/automc/svn/trunk/build/mkupdates/run_nightly 2>&1 | tee /var/www/automc.spamassassin.org/mkupdates/mkupdates.txt
+ promote_active_rules + pwd /usr/local/spamassassin/automc/svn/trunk + svn co https://svn.apache.org/repos/asf/spamassassin/trunk/rules https://svn.apache.org/repos/asf/spamassassin/trunk/rulesrc Checked out revision 1900353. Checked out revision 1900353. + /usr/bin/perl build/mkupdates/listpromotable HTTP get: https://ruleqa.spamassassin.org/last-net?xml=1 HTTP get: https://ruleqa.spamassassin.org/1-days-ago?xml=1 HTTP get: https://ruleqa.spamassassin.org/2-days-ago?xml=1 HTTP get: https://ruleqa.spamassassin.org/3-days-ago?xml=1 HTTP get: https://ruleqa.spamassassin.org/4-days-ago?xml=1 HTTP get: https://ruleqa.spamassassin.org/5-days-ago?xml=1 day 5 contains a --net mass-check! offsetting by an extra day HTTP get: https://ruleqa.spamassassin.org/6-days-ago?xml=1 + mv rules/active.list.new rules/active.list + svn diff rules + cat /var/www/ruleqa.spamassassin.org/reports/LATEST Index: rules/active.list === --- rules/active.list (revision 1900353) +++ rules/active.list (working copy) @@ -1,6 +1,6 @@ # DO NOT EDIT: file generated by build/mkupdates/listpromotable # active ruleset list, automatically generated from https://ruleqa.spamassassin.org/ -# with results from: last-net: net-darxus net-ena-week0 net-ena-week1 net-ena-week2 net-ena-week3 net-ena-week4 net-giovanni-ham net-giovanni-spam net-giovanni-spammy net-grenier net-hege net-jhardin net-llanga net-mmiroslaw-mails-ham net-mmiroslaw-mails-spam net-pds net-spamsponge net-thendrikx; day 1: darxus ena-week0 ena-week1 ena-week2 ena-week3 ena-week4 giovanni-ham giovanni-spam giovanni-spammy grenier hege jhardin llanga mmiroslaw-mails-ham mmiroslaw-mails-spam pds thendrikx; day 2: darxus ena-week0 ena-week1 ena-week2 ena-week3 ena-week4 giovanni-ham giovanni-spam giovanni-spammy grenier hege jhardin llanga mmiroslaw-mails-ham mmiroslaw-mails-spam pds spamsponge thendrikx; day 3: darxus ena-week0 ena-week1 ena-week2 ena-week3 ena-week4 giovanni-ham giovanni-spam giovanni-spammy grenier hege jhardin llanga mmiroslaw-mails-ham mmiroslaw-mails-spam spamsponge thendrikx; day 4: darxus ena-week0 ena-week1 ena-week2 ena-week3 ena-week4 giovanni-ham giovanni-spam giovanni-spammy g renier hege jhardin llanga mmiroslaw-mails-ham mmiroslaw-mails-spam pds spamsponge thendrikx; day 5: darxus ena-week0 ena-week1 ena-week2 ena-week3 ena-week4 giovanni-ham giovanni-spam giovanni-spammy hege llanga mmiroslaw-mails-ham mmiroslaw-mails-spam pds spamsponge thendrikx +# with results from: last-net: net-darxus net-ena-week0 net-ena-week1 net-ena-week2 net-ena-week3 net-ena-week4 net-giovanni-ham net-giovanni-spam net-giovanni-spammy net-grenier net-hege net-jhardin net-llanga net-mmiroslaw-mails-ham net-mmiroslaw-mails-spam net-pds net-spamsponge net-thendrikx; day 1: darxus ena-week0 ena-week1 ena-week2 ena-week3 ena-week4 giovanni-ham giovanni-spam giovanni-spammy grenier hege jhardin llanga mmiroslaw-mails-ham mmiroslaw-mails-spam pds thendrikx; day 2: darxus ena-week0 ena-week1 ena-week2 ena-week3 ena-week4 giovanni-ham giovanni-spam giovanni-spammy grenier hege jhardin llanga mmiroslaw-mails-ham mmiroslaw-mails-spam pds thendrikx; day 3: darxus ena-week0 ena-week1 ena-week2 ena-week3 ena-week4 giovanni-ham giovanni-spam giovanni-spammy grenier hege jhardin llanga mmiroslaw-mails-ham mmiroslaw-mails-spam pds spamsponge thendrikx; day 4: darxus ena-week0 ena-week1 ena-week2 ena-week3 ena-week4 giovanni-ham giovanni-spam giovanni-spammy grenier hege jhardin llanga mmiroslaw-mails-ham mmiroslaw-mails-spam spamsponge thendrikx; day 5: darxus ena-week0 ena-week1 ena-week2 ena-week3 ena-week4 giovanni-ham giovanni-spam giovanni-spammy grenier hege jhardin llanga mmiroslaw-mails-ham mmiroslaw-mails-spam pds spamsponge thendrikx # tflags publish AC_BR_BONANZA @@ -182,9 +182,6 @@ # tflags publish BITCOIN_IMGUR -# good enough -BITCOIN_MALF_HTML - # tflags net BITCOIN_MALWARE @@ -251,7 +248,7 @@ # good enough BODY_SINGLE_URI -# tflags net +# tflags publish BODY_URI_ONLY # tflags publish @@ -429,9 +426,6 @@ FACEBOOK_IMG_NOT_RCVD_FB # good enough -FAKE_REPLY_B - -# good enough FAKE_REPLY_C # tflags publish @@ -473,7 +467,7 @@ # tflags net FORGED_SPF_HELO -# tflags net +# tflags publish FORM_FRAUD # tflags publish @@ -561,9 +555,6 @@ FROM_MISSP_PHISH # tflags net -FROM_MISSP_REPLYTO - -# tflags net FROM_MISSP_SPF_FAIL # good enough @@ -879,6 +870,9 @@ JH_SPAMMY_PATTERN02 # tflags net +KHOP_FAKE_EBAY + +# tflags net KHOP_HELO_FCRDNS # tflags publish @@ -929,6 +923,9 @@ # tflags publish MANY_SPAN_IN_TEXT +# tflags net +MAY_BE_FORGED + # tflags publish MILLION_HUNDRED @@ -1098,9 +1095,6 @@ PDS_DBL_URL_TNB_RUNON # tflags net -PDS_FROM_2_EMAILS - -# tflags net PDS_HELO_SPF_FAIL # good enough @@ -1604,13 +1598,13 @@ # tflags publish TARINGANET_IMG_NOT_RCVD_TN -# tflags publish +# tflags net TEQF_USR_IMAGE -#
checkSAupdateMirrors.sh on sa-vm.apache.org - 0 mirrors DOWN, 2 mirrors STALE
https://sa-update.mailfud.org/ (5.196.88.134): UP (CURRENT) http://sa-update.dnswl.org/ (116.203.4.105): UP (CURRENT) https://www.sa-update.pccc.com/ (69.171.29.42): UP (CURRENT) http://sa-update.space-pro.be/ (176.28.55.20): UP (CURRENT) http://sa-update.ena.com/ (96.5.1.5): UP (CURRENT) http://sa-update.ena.com/ (96.4.1.5): UP (CURRENT) https://sa-update.razx.cloud/ (172.67.206.130): UP (STALE since 1651123081, 3 hours) https://sa-update.razx.cloud/ (104.21.69.80): UP (STALE since 1651123081, 3 hours) http://sa-update.fossies.org/ (144.76.163.196): UP (CURRENT) http://sa-update.verein-clean.net/ (37.252.124.130): UP (CURRENT) http://sa-update.verein-clean.net/ (37.252.120.157): UP (CURRENT) https://sa-update-asf.snb.it/ (151.80.178.91): UP (CURRENT) http://sa-update.spamassassin.org/ (64.142.56.146): UP (CURRENT)
checkSAupdateMirrors.sh on sa-vm.apache.org - 0 mirrors DOWN, 2 mirrors STALE
https://sa-update.mailfud.org/ (5.196.88.134): UP (CURRENT) http://sa-update.dnswl.org/ (116.203.4.105): UP (CURRENT) https://www.sa-update.pccc.com/ (69.171.29.42): UP (CURRENT) http://sa-update.space-pro.be/ (176.28.55.20): UP (CURRENT) http://sa-update.ena.com/ (96.5.1.5): UP (CURRENT) http://sa-update.ena.com/ (96.4.1.5): UP (CURRENT) https://sa-update.razx.cloud/ (104.21.69.80): UP (STALE since 1651123081, 2 hours) https://sa-update.razx.cloud/ (172.67.206.130): UP (STALE since 1651123081, 2 hours) http://sa-update.fossies.org/ (144.76.163.196): UP (CURRENT) http://sa-update.verein-clean.net/ (37.252.120.157): UP (CURRENT) http://sa-update.verein-clean.net/ (37.252.124.130): UP (CURRENT) https://sa-update-asf.snb.it/ (151.80.178.91): UP (CURRENT) http://sa-update.spamassassin.org/ (64.142.56.146): UP (CURRENT)
