[Bug 184319] New: Spamassassin and SELinux
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184319
Summary: Spamassassin and SELinux
Product: Fedora Core
Version: fc4
Platform: i386
OS/Version: Linux
Status: NEW
Severity: normal
Priority: normal
Component: spamassassin
AssignedTo: wtogami(a)redhat.com
ReportedBy: rsandu(a)softhome.net
CC: fedora-perl-devel-
list@redhat.com,felicity@kluge.net,jm(a)jmason.org,parkerm
@pobox.com,reg+redhat@sidney.com,wtogami(a)redhat.com
Description of problem:
As described in SpamAssassin's man page, the program must create user_prefs in
$HOME/.spamassassin, where $HOME is the homedirectory of the user spamassassin
is run under.
When spamc is invoked from Postfix's master.cf file (as described at
http://wiki.apache.org/spamassassin/IntegratedSpamdInPostfix) and SELinux is
enabled, Spamassassin can't create user_prefs file in /home/someuser, even if
"someuser" was created on purpose.
Version-Release number of selected component (if applicable):
spamassassin-3.0.4-2.fc4
selinux-policy-targeted-1.27.1-2.22
postfix-2.2.2-2
(stock Fedora Core 4 + updates March 06, 2006)
How reproducible:
Always.
Steps to Reproduce:
1. Invoke Spamassassin as a filter, from Postfix, as described in
http://wiki.apache.org/spamassassin/IntegratedSpamdInPostfix, with SELinux
enabled. Postfix users should be virtual users.
Actual results:
The process can't write user_prefs under /home/someuser.
Expected results:
A predefined system user should be created when installing Spamassassin (by the
rpm), with an appropiate, FHS-compliant homedirectory, in order to provide a
place to create user_prefs, when Postfix users are virtual users and SELinux is
enabled.
Spamassassin docs should indicate the correct way to proceed/configure in such
cases.
Additional info:
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
17 years, 10 months
[Bug 178580] New: /etc/sysconfig/spamassasin is always modified
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178580
Summary: /etc/sysconfig/spamassasin is always modified
Product: Fedora Core
Version: devel
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: normal
Component: spamassassin
AssignedTo: wtogami(a)redhat.com
ReportedBy: wtogami(a)redhat.com
CC: fedora-perl-devel-
list@redhat.com,felicity@kluge.net,jm(a)jmason.org,parkerm
@pobox.com,reg+redhat@sidney.com,wtogami(a)redhat.com
QA discovered that /etc/sysconfig/spamassasin is being replaced during every
package intallation or upgrade.
# -a and --auto-whitelist options were removed from 3.0.0
# prevent service startup failure
perl -p -i -e 's/(["\s]-\w+)a/$1/ ; s/(["\s]-)a(\w+)/$1$2/ ; s/(["\s])-a\b/$1/'
/etc/sysconfig/spamassassin
perl -p -i -e 's/ --auto-whitelist//' /etc/sysconfig/spamassassin
Since FC3 spamassassin.spec %post contained this to remove user added options
during an upgrade from pre-3.0 SA that caused the new version to fail. QA
discovered that this perl syntax actually creates another file and deletes the
original file. This means that even if no change happens, the file has a
different timestamp and selinux security context.
Impact:
Not much, but it should be fixed some time in the future.
Fix:
This probably involves testing before doing the modification in order to avoid
an unnecessary replacement. In the replacement case chcon is needed in order to
maintain the correct selinux context.
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
17 years, 10 months
Fwd: libxml1 going away
by Chris Weyl
FYI...
---------- Forwarded message ----------
From: Bill Nottingham <notting(a)redhat.com>
Date: May 29, 2006 1:19 PM
Subject: Re: libxml1 going away
To: List for Fedora Package Maintainers <fedora-maintainers(a)redhat.com>
Jesse Keating (jkeating(a)redhat.com) said:
> libxml1 has reached its end of days.
>
> Gtk-Perl
> R-gnomeGUI
>
> Both have listed deps on libxml1. Can these be moved to libxml2? We're
> really really really rather not bring libxml1 into Extras. I would like
> to have libxml1 removed from the distribution by Test 1.
The way to fix this is to port those to GTK+2/GNOME 2, not just from
libxml1 to libxml2.
Bill
--
Fedora-maintainers mailing list
Fedora-maintainers(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-maintainers
--
Chris Weyl
Ex astris, scientia
17 years, 10 months
[Bug 175459] wrong coding
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
Summary: wrong coding
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175459
mmaslano(a)redhat.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Pointless warning message |wrong coding
Version|fc4 |fc5
Status|REOPENED |ASSIGNED
Component|groff |perl
AssignedTo|mmaslano(a)redhat.com |jvdias(a)redhat.com
QAContact|mikem(a)redhat.com |dkl(a)redhat.com
CC| |fedora-perl-devel-
| |list(a)redhat.com
------- Additional Comments From mmaslano(a)redhat.com 2006-05-29 08:43 EST -------
Manual page for perlcn isn't in UTF-8.
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
17 years, 11 months
Upstream changing Licenses [Was: perl-Locale-Maketext-Simple.spec]
by Ralf Corsepius
On Wed, 2006-05-24 at 17:49 -0700, Steven Pritchard wrote:
> Author: steve
>
> Update of /cvs/extras/rpms/perl-Locale-Maketext-Simple/FC-4
> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv6828
>
> Modified Files:
> .cvsignore perl-Locale-Maketext-Simple.spec sources
> Log Message:
> Update to 0.16.
> License has changed to MIT.
Steve,
do you think upstream is legitimated to do so?
I am facing the same situation with perl-Locale-Maketext-Lexicon (from
the same author). There, upstream has changed the license from
GPL/Artistic to MIT.
IMO, by having done so, upstream probably has violated the law, because,
in general, they cannot change the license a package unless they own the
copyright of all parts a package consists of.
Locale::Maketext::Simple only lists one author, with
Locale::Maketext::Lexicon, the situation seems unclear:
http://search.cpan.org/src/AUTRIJUS/Locale-Maketext-Lexicon-0.61/AUTHORS
lists 20-25 contributors, while the source code only lists one
individual (the CPAN maintainer).
I am not certain on how to handle the situation. To be on the safe side,
I considering to regard my perl-Locale-Maketext-Lexicon rpm as
derivative work of the original work and consider to ship it under the
GPL only.
The fundamental questions would be:
* Who owns contributions to code in CPAN having been released under
GPL/Artistic before?
IMO: If the "contribution is copyrightable", the contributor. He is
contributing under the licenses the original author had granted. The
original author is not legitimated to change the license on such
contributions without explicit permission.
* Is the maintainer of CPAN modules legitimated to change a license from
GPL/Artistic to MIT?
Here, I am not sure about the implications of the Artistic license.
Opinions? What to do?
Ralf
17 years, 11 months
The next time you need to build a stack of modules...
by Steven Pritchard
There is a new option in cpanspec 1.66 (which should land in Extras
soon), --follow. The next time you need to build a package for a
module, you might want to try something like this:
cpanspec -v --follow Some::Module
When you specify --follow, cpanspec checks every BuildRequires that
can be automatically determined from the module to see if it is
available on the system ("rpm -q --whatprovides perl($module)") or in
the configured repositories ("repoquery --whatprovides
perl($module)"). If not, it adds it to the list of modules to
process.
I just tried this with OpenFrame (something I manually built all the
dependencies for a while back), and it looks like I'm down to 5
required modules that aren't in Extras already.
Steve
--
Steven Pritchard - K&S Pritchard Enterprises, Inc.
Email: steve(a)kspei.com http://www.kspei.com/
Phone: (618)398-3000 Mobile: (618)567-7320
17 years, 11 months
Extras QA?
by Chris Weyl
Question --
I've been noticing that in extra's owners.list, a number of packages
have this list's address as one of the QA emails. Should I be setting
this on perl packages I own in extras? If so, is this something that
ought to go in the Packaging/Perl wiki page?
-Chris
--
Chris Weyl
Ex astris, scientia
17 years, 11 months
