Re: [PROPOSAL] Enhancements to sa-update, discussion.. possibly for 4.1

[email protected] Fri, 18 Jul 2025 18:29:27 +0200
Newsgroups	gmane.mail.spam.spamassassin.devel
Message-ID	<[email protected]>
On 7/17/25 7:38 PM, Michael Peddemors wrote:
> Proposal for sa-update changes.
> 
> As some of you may know, we have been running a custom sa-update for about 10 years, in order to more efficiently (and more safely) use multiple channels for SA rules, including our own and upstream rules.
> 
> We have wanted to of course give back these changes, and it has been recently suggested that we do this again, however before we try to push a large change out, it was suggested that we open a discussion on why the changes are in place.
> 
> NOTE: personally, we believe that using sa-update to initialize from package distributed rule base (flat files) complicates the structure of sa-update, and sa-update should be reserved for updating against remote channels.  We also propose that those two functionalities be separated, (eg sa-init vs sa-update) as sa-update is generally only  used by package maintainers and developers.
> 
> Proposal Overview:
> 
> * Multiple Sources should be available to all users of spamassassin (channels)
> 
> * The use of multiple sources suggests the use of /etc/spamassassin/channels.d/
> 
> * Each  Channel will have different trust and safety concerns, so they need separate control files.
> 
> This allows the opportunity to enhance sa-update to be more flexible on a per channel basis, eg should the channel try to use IPv6, which GPG keys are appropriate for each channel, flexible enable/disable of channel updates, better 'merge' based on active channels, force https, separate authentication per channel (in cases there are paid channels out there) and trust levels, eg should you allow an un-trusted mirror to use plugins, which could be a security risk.
> 
>   If the community agrees that the above are something we can all agree on, then it would make it worthwhile for us to start tbe process of submitting our changes as pull requests.
> 
>   For the record, here is a sample of a channel configuration file we currently use in all our deployments. Note, we allow both styles of comments. While this works in our protected environments, possibly auth information should be separated, but we simply prefer to restrict access to the channels.d directory.
> 
> NOTE: we took the simplistic approach of native control file parsing in SA, however given that packaged control files could have
> configuration items that change from time to time, a better method of loading control files was always in our road map, but never a priority
> (possibly enforcing an allowed list of control items)
> 
RedHat has a similar approach and they use a sa-update.cron bash script for this purpose, I haven't checked their implementation yet but I would like to maintain compatibility.
  Cheers
   Giovanni

> 
> 
>   ------- channels.d/updates.spamassassin.org -----
>   # Please do not use trailing comments
> # This configuration is for the standard SA Upstream packages
> # NOTE: There should/is be a native way to find new gpgkeys if they are updated
> ;
> # Not sure that 'fname' is the best term for this
> channel=updates.spamassassin.org
> use=y
> ;use-ipv6=no
> use-gpg=y
> ; You MUST specify 'trusted' keys in one of the following two options
> gpgkey=<REDACCTED>
> ;gpgkeyfile
> # Fixme! This should default to the channel name
> gpghomedir=/etc/spamassassin/sa-update-keys
> force-https=n
> #use-auth-token=SAMPLENAME
> ; watch out for passwords containing '='
> #use-auth-password=SAMPLEPASS
> refresh-mirrors=n
> allow-plugins=y
> ----------------
> 
> 
> Comments welcome..
> Oh, and another PS? Given many RBL operators are now using API keys, suggest that a little love be given to the rbldns plugin, to more safely store, use and combine API keys in the queries..
> 
> 
> 
> 
>
OpenPGP_signature.asc (application/pgp-signature, 840 B)