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

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)



  ------- 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..





-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Reg. TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada