I think it is time that this be addressed, in a way that all maintainers
might be satisfied. We should probably invite everyone to discuss this
on a single ticket.
Some Discussion Points:
* sa-install vs sa-update
There are several areas in sa-update that are specific to
testing/installing/using local rule repos, that should not be in sa-update.
* sa-update multi-channel support
Apologies everyone, never enough hours in the day, but we should have
gotten our customized sa-update out to the general public by now.
/etc/spamassassin/channels.d/
/etc/spamassassin/channels.d/wiz-mm-trusty-sa.linuxmagic.com
/etc/spamassassin/channels.d/updates.spamassassin.org
/etc/spamassassin/channels.d/README
/etc/spamassassin/channels.d/wiz-lm-trusty-sa.linuxmagic.com
# Configuration File for use with LinuxMagic's updated sa-update program
# Please do not use trailing comments
#
# This configuration is for the standard SA Upstream packages
# NOTE: There should/is be a better.safer.native way to find new gpgkeys
# if/when they are updated
;
;
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=26C900A46DD40CD5AD24F6D7DEE01987265FA05B
0C2B1D7175B852C64B3CDC716C55397824F434CE
5E541DC959CB8BAC7C78DFDC4056A61A5244EC45
;gpgkeyfile
# TODO! This should default to the channel name
gpghomedir=/etc/spamassassin/sa-update-keys
force-https=n
# Auth Credentials if required by the mirrors
# watch out for passwords containing '='
;use-auth-token=UNSPECIFIED
;use-auth-password=UNSPECIFIED
refresh-mirrors=n
allow-plugins=y
* This could easily support both SHA1 and SHA256, or any other mechanism
Security standards should be set by the mirror/repo provider for trust
Is it really up to 'upstream' to specify what a 'trusted' rule set
should be?
On 2020-02-01 6:20 a.m., bugzilla-dae...@spamassassin.apache.org wrote:
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7618
--- Comment #22 from Sidney Markowitz <sid...@sidney.com> ---
(In reply to Kevin A. McGrail from comment #19)
Some PMC members have raised flags and I'd like them to have the opportunity
to discuss and see if they can determine there is no security risk and if a
variance request makes sense. I'm a 0 on that effort and 3.4.2 was release
in 2018 with 3.4.1 in 2015.
I didn't see any flags raised since the decisions that were made in September
2018. Nobody objected to the March 1, 2020 date that was announced in the
release of 3.4.3 and 3.4.4. The only objection was to point out that the word
"signature" should be "checksum", but that doesn't invalidate the announcement.
Are there command line parameters to ignore the sums with 3.4.0 & 3.4.1 that
we can recommend people use?
No. There is one to ignore the GPG signature, but sa-update before 3.4.2 will
exit with a channel failed message if no SHA-1 checksum file can be downloaded.
This will make March 1, 2020 a hard deadline for running sa-update in versions
older than 3.4.2. The only workaround would be to patch sa-update like RedHat
is proposing to do in https://bugzilla.redhat.com/show_bug.cgi?id=1787382
BTW, I don't think RedHat's approach is a good idea. We have made sure that
rule updates work with old versions, including conditionals as necessary, but
with this change the backwards compatibility will no longer be tested and IMO
should not be counted on.
An unofficial channel could also just repackage the rules and provide a
sha-1 sig if there is demand for it.
That's the right way to do it if anyone really wants to set one up. However,
that will still depend on rule developers making sure that the rules stay
backward compatible. Can we count on sufficient testing for that?
I have updated the verbiage on the index and news page on the website. I'm
not the only one to refer to them as signatures though
(https://en.wikipedia.org/wiki/SHA-1)
Nope, the wikipedia article talks about *use* of SHA-1 in computing signatures.
A signature is a cryptographic hash checksum that is encrypted with a private
key. The checksum by itself is not a signature.
I have a reminder from Dec on my to-list to stop sha-1 checksums and will
lead the effort with SA Sysadmins to implement it.
Anything I missed, Sidney?
+1 on that from me
--
"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 Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada
This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.
