[Bug 1230219] New: perl-Plack-1.0036 is available
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1230219
Bug ID: 1230219
Summary: perl-Plack-1.0036 is available
Product: Fedora
Version: rawhide
Component: perl-Plack
Assignee: rc040203(a)freenet.de
Reporter: rc040203(a)freenet.de
QA Contact: extras-qa(a)fedoraproject.org
CC: perl-devel(a)lists.fedoraproject.org,
rc040203(a)freenet.de
Upstream released Plack-1.0036
Unfortunately this update introduced a couple dependencies on further
perl-modules which are not yet available in Fedora.
--
You are receiving this mail because:
You are on the CC list for the bug.
7Â years, 8Â months
[Bug 1268777] New: CVE-2015-7686 perl-Email-Address: denial of service when parsing crafted email address list
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1268777
Bug ID: 1268777
Summary: CVE-2015-7686 perl-Email-Address: denial of service
when parsing crafted email address list
Product: Security Response
Component: vulnerability
Keywords: Security
Severity: medium
Priority: medium
Assignee: security-response-team(a)redhat.com
Reporter: mprpic(a)redhat.com
CC: perl-devel(a)lists.fedoraproject.org,
perl-maint-list(a)redhat.com, rob.myers(a)gtri.gatech.edu,
tcallawa(a)redhat.com
A flaw in the parsing of email address lists was found in perl-Email-Address:
Algorithmic complexity vulnerability in Address.pm in the Email-Address module
1.908 and earlier for Perl allows remote attackers to cause a denial of service
(CPU consumption) via a crafted string containing a list of e-mail addresses in
conjunction with parenthesis characters that can be associated with nested
comments. NOTE: the default configuration in 1.908 mitigates this vulnerability
but misparses certain realistic comments.
Further information:
http://seclists.org/oss-sec/2015/q3/644
http://seclists.org/oss-sec/2015/q4/22
--
You are receiving this mail because:
You are on the CC list for the bug.
7Â years, 9Â months
[Bug 1268778] New: CVE-2015-7686 perl-Email-Address: denial of service when parsing crafted email address list [fedora-all]
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1268778
Bug ID: 1268778
Summary: CVE-2015-7686 perl-Email-Address: denial of service
when parsing crafted email address list [fedora-all]
Product: Fedora
Version: 22
Component: perl-Email-Address
Keywords: Security, SecurityTracking
Severity: medium
Priority: medium
Assignee: tcallawa(a)redhat.com
Reporter: mprpic(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: perl-devel(a)lists.fedoraproject.org,
tcallawa(a)redhat.com
Blocks: 1268777 (CVE-2015-7686)
This is an automatically created tracking bug! It was created to ensure
that one or more security vulnerabilities are fixed in affected versions
of Fedora.
For comments that are specific to the vulnerability please use bugs filed
against the "Security Response" product referenced in the "Blocks" field.
For more information see:
http://fedoraproject.org/wiki/Security/TrackingBugs
When submitting as an update, use the fedpkg template provided in the next
comment(s). This will include the bug IDs of this tracking bug as well as
the relevant top-level CVE bugs.
Please also mention the CVE IDs being fixed in the RPM changelog and the
fedpkg commit message.
NOTE: this issue affects multiple supported versions of Fedora. While only
one tracking bug has been filed, please correct all affected versions at
the same time. If you need to fix the versions independent of each other,
you may clone this bug as appropriate.
[bug automatically created by: add-tracking-bugs]
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1268777
[Bug 1268777] CVE-2015-7686 perl-Email-Address: denial of service when
parsing crafted email address list
--
You are receiving this mail because:
You are on the CC list for the bug.
7Â years, 9Â months
[Bug 1101265] New: perl-libwww-perl: incorrect handling of SSL certificate verification [fedora-all]
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1101265
Bug ID: 1101265
Summary: perl-libwww-perl: incorrect handling of SSL
certificate verification [fedora-all]
Product: Fedora
Version: 20
Component: perl-LWP-Protocol-https
Keywords: FutureFeature
Severity: high
Priority: high
Assignee: ppisar(a)redhat.com
Reporter: ppisar(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: jpazdziora(a)redhat.com, jplesnik(a)redhat.com,
mmaslano(a)redhat.com, mzazrivec(a)redhat.com,
perl-devel(a)lists.fedoraproject.org, ppisar(a)redhat.com,
psabata(a)redhat.com
+++ This bug was initially created as a clone of Bug #1094442 +++
[...]
--- Additional comment from Jan Pazdziora on 2014-05-26 10:55:43 GMT ---
(In reply to Petr Pisar from comment #9)
> Thank you for the report. However there are two mistakes:
>
> (1) The IO::Socket::SSL::new option is "SSL_verifycn_scheme", not
> "SSL_verifycn_schema". Thus you could not find it in the documentation.
Ahh, sorry about that
.
> (2) The 6.04-3 behavior was flawed. As you can read in the upstream bug
> report, the "SSL_verify_mode" option is about checking hostname. It's not
> intended to control certificate validation. The same applies to
> "PERL_LWP_SSL_VERIFY_HOSTNAME" environment variable. 6.04-4 has restored the
> behavior which presented before 6.04.
So what is the way for making HTTP requests to websites with self-signed
certificates from perl, if the user does not care about the CA chain
validation?
In other way, what is the way for making LWP behave the same way it used to
behave with pre-6 version?
--- Additional comment from Petr Pisar on 2014-05-26 11:20:51 GMT ---
There is no LWP environment variable or command line option to control that
currently.
It's possible to pass ssl_opts => {SSL_verify_mode =>
IO::Socket::SSL::SSL_VERIFY_NONE} to LWP::UserAgent::new if you write your own
LWP application.
This is also discussed in the upstream report.
The reason why the PERL_LWP_SSL_VERIFY_HOSTNAME seemed to work before is the
IO::Socket::SSL < 1.950 defaulted to SSL_VERIFY_NONE. This has not been true
since Fedora 20. Unfortunately Fedora 20 delivered the flawed
LWP::Protocol::https, so it was not visible.
I agree with you that there should be way how to disable the certificate
validation externally.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=vNjL2yMVw5&a=cc_unsubscribe
7Â years, 9Â months
[Bug 1281886] New: selinux causes RT to prevent httpd from starting
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1281886
Bug ID: 1281886
Summary: selinux causes RT to prevent httpd from starting
Product: Fedora
Version: 22
Component: rt
Assignee: rc040203(a)freenet.de
Reporter: tibbs(a)math.uh.edu
QA Contact: extras-qa(a)fedoraproject.org
CC: perl-devel(a)lists.fedoraproject.org,
rc040203(a)freenet.de, tibbs(a)math.uh.edu
This is really just a heads up, and should probably be reassigned to
selinux-policy, but I wanted to run it by you to make sure it's not an RT issue
first.
Basically, httpd updated last night, which means it restarted. Unfortunately
this failed:
Nov 13 09:57:43 rt2.math.uh.edu httpd[23688]: AH00526: Syntax error on line 29
of /etc/httpd/conf.d/virt-rt.conf:
Nov 13 09:57:43 rt2.math.uh.edu httpd[23688]: Cannot write to
'/var/log/rt/rt.log': Permission denied at
/usr/share/perl5/vendor_perl/Log/Dispatch/File.pm line 107.\n
Line 29 is the Plack setup, which fails; there's nothing actually wrong with
the syntax of the apache configuration file.
<Perl>
use Plack::Handler::Apache2;
Plack::Handler::Apache2->preload("/usr/sbin/rt-server");
</Perl>
And it can't read /var/log/rt.log because of:
time->Fri Nov 13 03:33:30 2015
type=AVC msg=audit(1447407210.438:3285): avc: denied { open } for pid=12191
comm="/usr/sbin/rt-se" path="/var/log/rt/rt.log" dev="dm-1" ino=393970
scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:var_log_t:s0
tclass=file permissive=0
setenforce 0 fixes it, of course, and after that there are no additional AVCs.
My guess is that this broke with a selinux policy update (the last one was
selinux-policy-targeted-3.13.1-128.18.fc22.noarch on October 29th) but nothing
actually failed until httpd restarted last night.
--
You are receiving this mail because:
You are on the CC list for the bug.
7Â years, 9Â months
Removing perl from build root
by Petr Pisar
Fedora's minimal build root contains perl. There is a reasonable request
<https://bugzilla.redhat.com/show_bug.cgi?id=1158860> to
remove the perl in order to minimize the build root. (The x86_64 F25 build
root occupies 527 MB now, 20 MB of that are perl packages.)
The reason why perl is there is the rpm-build package. The Requires dependency
tree looks like:
rpm-build
perl-generators
perl(:MODULE_COMPAT_5.22.1)
perl(Fedora::VSP)
perl
perl-macros
system-rpm-config (a Provide)
redhat-rpm-config
perl-srpm-macros
While perl-srpm-macros's presence is intended, perl-generators' presence is
unwanted.
On technical level, the reason is the rpm-build binary package requires
perl-generators explicitely. It's there for backward compatibility. Simply
removing the dependency removes perl from minimal build root.
But the compatibility is important. Without perl-generators in a build root no
Perl dependencies are generated into binary packages. To fix it, every Perl
package must build-require perl-generators.
This change will go through a Fedora system wide change process and Perl
packaging guidelines update. I'd like to implement it in Fedora 25.
Few weeks ago, me, Contyk and Jitka were thinking about the new packaging
guidelines. We concluded that the guidelines should contain only the necessary
minimum and best practices should be documented on freely updatable wiki page.
We found these interesting packages:
perl-generators requires perl and some other modules
perl /usr/bin/perl
perl-libs libperl.so and essencial modules and perl(:MODULE_COMPAT_)
perl-devel requires gcc for header files
perl-macros requires perl(:MODULE_COMPAT_) now
perl-srpm-macros no dependencies
Guidelines should describe that:
(1) You must build-require perl-generators if you install a Perl code to
ensure run-time depencies are automatically generated.
Then there are other rules that are actually implied by the generic guidelines
(require everything what you use) that could or could not go the the
guidelines as:
(2) You must build-require perl-macros if you use a macro provided by them.
(3) You must build-require perl if you execute the perl interpreter at
build-time.
(4) You must build-require perl-devel if you build XS code.
Questionable are %__perl and %perl_vendorlib-like macros, what macros are
provided by perl-srpm-macros and what macros are provided by perl-srpm-macros.
%__perl and %perl_vendorlib macros come from rpm. Former rpm Fedora
maintainer claimed he want to own the macros forever. But the truth is they
do not work without installed perl. And rpm does not require perl.
The division between perl-macros and perl-srpm-macros is, in my vision,
defined by requirement on perl interpreter. perl-srpm-macros will never
require perl. The question is where to put all the neat macros I published on
this mailing list in the previous month (the version normalization etc.).
The version normalization will go into perl-srpm-macros as it it necessary for
creating source RPM packages. If we implement normalization in F25, we should
mention it in the guidelines:
(5) Perl module versions must be normalized with %perl_v macro
like "BuildRequires: perl(Module) >= %{perl_v 1.2}".
We could also make the guidelines less how-to and more descriptive by
explaining the normalization algorithm and allowing packagers to do the
normalization manually (like listing run-time dependencies manually). But I'm
not sure if it were helpful.
Back to the build-requires. I can add "BuildRequires: perl-generators" into
all spec files that run-requires or provides perl(). This can be performed
even without mass rebuild.
I'd like to hear if this approach (adding "BuildRequires: perl-generators"
everywhere) is fine. For example, a spec file for architecture specific
package would need:
BuildRequires: perl for "perl Makefile.PL"
BuildRequires: perl-devel for building XS code
BuildRequires: perl-generators for generating dependencies
BuildRequires: perl-macros for %?perl_default_filter
It looks like a lot of copy and paste code. On the other hand, It allows to
write spec files that do not need all the Perl packaging features. For
example, an package that only installs a perl script can be happy with only:
BuildRequires: perl-generators for generating dependencies
-- Petr
7Â years, 9Â months
[Bug 1155218] New: Possible precedence issue with control flow operator
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1155218
Bug ID: 1155218
Summary: Possible precedence issue with control flow operator
Product: Fedora
Version: rawhide
Component: perl-Mail-Sender
Assignee: tcallawa(a)redhat.com
Reporter: rc040203(a)freenet.de
QA Contact: extras-qa(a)fedoraproject.org
CC: perl-devel(a)lists.fedoraproject.org,
tcallawa(a)redhat.com
Description of problem:
When running perl-Log-Dispatch-2.44's testsuite on rawhide, I am facing this
warning:
...
Possible precedence issue with control flow operator at
/usr/share/perl5/vendor_perl/Mail/Sender.pm line 2679.
...
Version-Release number of selected component (if applicable):
perl-Mail-Sender-0.8.21-6.fc22
I am not observing this warning with perl-Mail-Sender-0.8.23, which makes me
believe this issue already has been resolved upstream.
Therefore, I am going to upgrade perl-Mail-Sender to 0.8.23.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=U1QQiGJzYI&a=cc_unsubscribe
7Â years, 9Â months
[Bug 1136865] New: perl-CHI-0.58-2.fc22 FTBFS randomly: 40 is not between 59 and 99
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1136865
Bug ID: 1136865
Summary: perl-CHI-0.58-2.fc22 FTBFS randomly: 40 is not between
59 and 99
Product: Fedora
Version: rawhide
Component: perl-CHI
Assignee: rc040203(a)freenet.de
Reporter: ppisar(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: perl-devel(a)lists.fedoraproject.org,
rc040203(a)freenet.de
perl-CHI-0.58-2.fc22 failed to build for me in F22 like this:
# 40 is not between 59 and 99
# Failed test 'File:l1_cache size = 40'
# at /builddir/build/BUILD/CHI-0.58/blib/lib/CHI/t/Driver.pm line 1556.
# (in
CHI::t::Driver::Subcache::mirror_cache->test_size_awareness_with_subcach
es)
# 2 is not between 3 and 5
# Failed test 'File:l1_cache keys = 2'
# at /builddir/build/BUILD/CHI-0.58/blib/lib/CHI/t/Driver.pm line 1558.
# (in
CHI::t::Driver::Subcache::mirror_cache->test_size_awareness_with_subcach
es)
# Looks like you failed 2 tests of 436.
t/smoke-Driver-Subcache-mirror_cache.t ..
Dubious, test returned 2 (wstat 512, 0x200)
Failed 2/436 subtests
(less 1 skipped subtest: 433 okay)
I believe this is a race visible on a slow machine (cache entry expiration) but
I cannot reproduce it. The same failure can be seen on CPAN test matrix
<http://www.cpantesters.org/cpan/report/6110b488-9577-11e3-ae04-8631d666d1b8>.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=c62HeF4rv5&a=cc_unsubscribe
7Â years, 9Â months