-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Warren Togami writes:
> Justin Mason wrote:
> > PACKAGING (CENTRALISED):
> >
> > input: SVN, the "active set" only
> > output: packages
> >
> > - TODO: need a password-less method to sign packages
> >
> > - automated test suite for packages before they're published
> >
> > - The package will contain both new rules, and rules that were part of
> > "core" for the 3.1.0 release. To avoid the latter conflicting with
> > rules
> > in the 3.1.x release, we will produce a 3.1.x point release that
> > deletes
> > the ruleset from /usr/share/spamassassin, and immediately runs
> > "sa-update"!
> >
>
> Could you please clarify what this means? We have the following general
> restrictions on any package we ship in Fedora. I don't know much about
> the current proposed implementation, but the way it is worded in this
> paragraph, it may be incompatible with these restrictions.
>
> 1) Download scores during buildtime
> For security reasons build systems should rely only on local sources and
> not rely on the network. The build payload is also not reproducible if
> it relies on network inputs.
>
> 2) Download scores upon package install
> We cannot assume that users have networking during package installation.
>
> 3) Automatic sa-update by default
> We cannot ship a package that makes outgoing network calls without
> explicit setting of the sysadmin. For the same reason, our spamd
> service is not started by default, and our evolution default config uses
> only local tests when it uses spamassassin. Explicit enabling of the
> spamassassin service or modifying evolution's configuration then allows
> network querying.
OK, we're rethinking this; it no longer seems necessary for it
to be a requirement, and you have good points there.
What about this?
- basic "spamassassin" package (rpm/deb) contains no active-set rules
- there's another package which contains the active-set rules, in the
location where "sa-update" can later overwrite them
- both packages co-depend on each other.
The second package can be updated either via distro packaging methods --
apt-get/yum, or can be overwritten using "sa-update".
Regarding the sa-update update interval, don't worry about that too much;
we can implement that if necessary.
- --j.
> We would need to ship Fedora/RHEL's spamassasin with a default set of
> scores shipped in our package for payload reproducibility. It is up to
> the system's user whether they want to run sa-update or not. Note that
> this does not mean that the scores we ship need be computed at the time
> of a release. Our package updates could contain a newer set.
>
> Is there any plan for exactly how sa-update will be run periodically?
> In order to avoid overloading the data source, it should run at random
> intervals.
>
> http://cvs.fedora.redhat.com/viewcvs/devel/clamav/?root=extras
> Fedora Extras clamav package has an ugly but effective example of
> randomized interval updating. Perhaps the sysadmin could activate a
> separate sa-update daemon, or sa-update could be run periodically by
> spamd itself? Just some ideas...
>
> Warren Togami
> [EMAIL PROTECTED]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Exmh CVS
iD8DBQFDnI2hMJF5cimLx9ARAis3AKC2Gu1jGZzr/1Cfw0nrndUTSSgbLACfduQB
2vC8f3fl+ViANzeqRILqVtA=
=1zJq
-----END PGP SIGNATURE-----
