[Bug 1006931] New: perl-Filesys-SmbClient missing flag compatibility with samba4
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1006931
Bug ID: 1006931
Summary: perl-Filesys-SmbClient missing flag compatibility with
samba4
Product: Fedora
Version: 18
Component: perl-Filesys-SmbClient
Severity: medium
Assignee: fedorapkg(a)rule.lv
Reporter: aebenjam(a)opentext.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fedorapkg(a)rule.lv, perl-devel(a)lists.fedoraproject.org
Description of problem:
Unable to use kerberos via Filesys::SmbClient
Version-Release number of selected component (if applicable):
Filesys-SmbClient-3.2
How reproducible:
Create a new Filesys::SmbClient in perl with the option
flags => SMB_CTX_FLAG_USE_KERBEROS
Does not invoke the use of KERBEROS.
Furthermore, making the perl module manually reveals the missing option, and
the code in the header file notes the new mechanism by which kerberos is
enabled. Note that, when using the provided rpm, the invocation fails silently
back to password - which runs the risk of locking your account out as the
password is not likely provided.
Steps to Reproduce:
my $smb = new Filesys::SmbClient(
username => "user",
password => "", # working, via kerberos
workgroup => "DOMAIN",
flags => SMB_CTX_FLAG_USE_KERBEROS,
debug => 10);
Actual results:
Attempts password based login.
Expected results:
Uses existing kerberos credentials.
Additional info:
See /usr/include/samba-4.0/libsmbclient.h for new method of management.
--
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=UG4DnM5BZ8&a=cc_unsubscribe
8 years, 4 months
[Bug 997645] New: gtk colored buttons
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=997645
Bug ID: 997645
Summary: gtk colored buttons
Product: Fedora
Version: 18
Component: perl-Gtk2
Assignee: tcallawa(a)redhat.com
Reporter: aebenjam(a)opentext.com
QA Contact: extras-qa(a)fedoraproject.org
CC: perl-devel(a)lists.fedoraproject.org,
tcallawa(a)redhat.com
Description of problem: perl-gtk2 applications that set the background color
for buttons aren't producing colored output.
Version-Release number of selected component (if applicable):
perl-Gtk2-1.247-1.fc18.x86_64
How reproducible:
Create a trivial perl-gtk application with a coloured button.
Steps to Reproduce:
1. see below for code example to run
Actual results:
Button is created, but no colour.
Expected results:
Coloured button. (Red.)
Additional info:
Note: this worked as expected in Fedora 17. (perl-Gtk2-1.241-2.fc17.i686)
Sample colored button code:
#!/bin/perl
use Gtk2 qw/-init/;
my $window = Gtk2::Window->new;
$window->set_title("Window!");
my $button = Gtk2::Button->new("Coloured _button");
# does not affect text
$button->modify_bg(normal => Gtk2::Gdk::Color->new(0xffff, 0, 0));
$window->add($button);
$window->show_all;
Gtk2->main;
--
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=oIE2F6zBK1&a=cc_unsubscribe
8 years, 4 months
[Bug 1094440] New: perl-libwww-perl: incorrect handling of SSL certificate verification
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1094440
Bug ID: 1094440
Summary: perl-libwww-perl: incorrect handling of SSL
certificate verification
Product: Security Response
Component: vulnerability
Keywords: Security
Severity: high
Priority: high
Assignee: security-response-team(a)redhat.com
Reporter: vdanen(a)redhat.com
CC: jkurik(a)redhat.com, mmaslano(a)redhat.com,
perl-devel(a)lists.fedoraproject.org,
perl-maint-list(a)redhat.com, ppisar(a)redhat.com,
psabata(a)redhat.com
It was reported [1] that libwww-perl (LWP), when using IO::Socket::SSL (the
default) and when the HTTPS_CA_DIR or HTTPS_CA_FILE environment variables were
set, would disable server certificate verification. Judging by the commit [2],
the intention was to disable only hostname verification for compatibility with
Crypt::SSLeay, but the resultant effect is that SSL_verify_mode is set to 0.
This code was introduced in LWP::Protocol::https in version 6.04, so earlier
versions are not vulnerable.
Potential patches [3],[4] are being discussed upstream [5].
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746579
[2]
https://github.com/dagolden/lwp-protocol-https/commit/bcc46ce2dab53d2e2ba...
[3]
https://github.com/noxxi/lwp-protocol-https/commit/1b924708663f457a4f7c25...
[4]
https://github.com/noxxi/lwp-protocol-https/commit/6b5c876de80451ee54de5d...
[5] https://github.com/libwww-perl/lwp-protocol-https/pull/14
Statement:
This issue did not affect the versions of perl-libwww-perl as shipped with Red
Hat Enterprise Linux 5 and 6.
--
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=6oOhABRd7w&a=cc_unsubscribe
8 years, 5 months
[Bug 430177] New: clamd.d/amavisd.conf configuration directives require boolean arguments
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/show_bug.cgi?id=430177
Summary: clamd.d/amavisd.conf configuration directives require
boolean arguments
Product: Fedora EPEL
Version: el5
Platform: All
OS/Version: Linux
Status: NEW
Severity: low
Priority: low
Component: amavisd-new
AssignedTo: steve(a)silug.org
ReportedBy: rayvd(a)bludgeon.org
QAContact: extras-qa(a)fedoraproject.org
CC: fedora-perl-devel-list(a)redhat.com
After installing amavisd-new-2.4.5-1.el5 from epel-testing I get the following
when running service clamd.amavisd start:
# service clamd.amavisd start
Starting clamd.amavisd: ERROR: Parse error at line 2: Option LogSyslog requires
boolean argument.
ERROR: Can't open/parse the config file /etc/clamd.d/amavisd.conf
[FAILED]
Turns out FixStaleSocket also requires a boolean argument.
I appended a 'yes' to both of these configuration directives and everything is
working fine now.
This is in tandem with clamav-server-0.92-4.1.el5 from epel.
--
Configure bugmail: https://bugzilla.redhat.com/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.
8 years, 5 months
[Bug 1107543] New: Perl core-dumps if a hash is tied to SDBM_File before spawning a thread
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1107543
Bug ID: 1107543
Summary: Perl core-dumps if a hash is tied to SDBM_File before
spawning a thread
Product: Fedora
Version: 19
Component: perl
Severity: medium
Assignee: jplesnik(a)redhat.com
Reporter: ppisar(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: cweyl(a)alumni.drew.edu, iarnell(a)gmail.com,
jplesnik(a)redhat.com, kasal(a)ucw.cz,
perl-devel(a)lists.fedoraproject.org, ppisar(a)redhat.com,
psabata(a)redhat.com, rc040203(a)freenet.de,
tbowling(a)redhat.com, tcallawa(a)redhat.com
+++ This bug was initially created as a clone of Bug #1107542 +++
+++ This bug was initially created as a clone of Bug #1104827 +++
Description of problem:
Perl script using SDBM_File module is core dumping. Seems to match this
upstream bug: https://rt.perl.org/Public/Bug/Display.html?id=61912#txn-515026
[...]
Steps to Reproduce:
Create reproducer test script sdbm_test.pl containing the following lines, as
described in the upstream bug report:
#!/usr/bin/perl
use strict;
use Fcntl;
use SDBM_File;
use threads;
use threads::shared;
my %dbtest;
tie(%dbtest, 'SDBM_File', "test.db", O_RDWR|O_CREAT, 0666);
for (1 .. 2)
{
my $thr = threads->new(\&testThread, $_);
$thr->detach();
}
sleep 4;
sub testThread
{
my $n = shift;
print "thread #" . $n . " started\n";
}
Make script executable and run which produces the following output:
[root@util6vm ~]# chmod u+x sdbm_test.pl
[root@util6vm ~]# ./sdbm_test.pl
Expected results:
No errors.
Actual results:
thread #1 started
thread #2 started
*** glibc detected *** /usr/bin/perl: double free or corruption (out):
0x0000000000e2c2c0 ***
======= Backtrace: =========
/lib64/libc.so.6[0x3d2ca76166]
/lib64/libc.so.6[0x3d2ca78c93]
/usr/lib64/perl5/auto/SDBM_File/SDBM_File.so(XS_SDBM_File_DESTROY+0xc0)[0x7f9d58fb06f0]
[...]
--- Additional comment from Petr Pisar on 2014-06-05 05:56:58 GMT ---
This happens with any perl, even the development version.
----
All Fedoras are affected.
--
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=sO59ARuC6M&a=cc_unsubscribe
8 years, 5 months
[Bug 783346] New: Perl-MIME-Lite is already in RHEL6
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.
Summary: Perl-MIME-Lite is already in RHEL6
https://bugzilla.redhat.com/show_bug.cgi?id=783346
Summary: Perl-MIME-Lite is already in RHEL6
Product: Fedora EPEL
Version: el6
Platform: Unspecified
OS/Version: Unspecified
Status: NEW
Severity: unspecified
Priority: unspecified
Component: perl-MIME-Lite
AssignedTo: steve.traylen(a)cern.ch
ReportedBy: bochecha(a)fedoraproject.org
QAContact: extras-qa(a)fedoraproject.org
CC: fedora-perl-devel-list(a)redhat.com,
mmcgrath(a)redhat.com, steve.traylen(a)cern.ch
Classification: Fedora
Story Points: ---
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Description of problem:
This package is already in RHEL6, as such, shouldn't it be dropped from EPEL6?
# yum whatprovides 'perl(MIME::Lite)'
Loaded plugins: changelog, merge-conf, rhnplugin
perl-MIME-Lite-3.027-2.el6.noarch : MIME::Lite - low-calorie MIME generator
Repo : epel
Matched from:
Other : perl(MIME::Lite)
perl-MIME-Lite-3.027-2.el6.noarch : MIME::Lite - low-calorie MIME generator
Repo : rhel-x86_64-server-optional-6
Matched from:
Other : perl(MIME::Lite)
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
8 years, 5 months
[Bug 1062576] New: memory leak when including a file with "use utf8"
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1062576
Bug ID: 1062576
Summary: memory leak when including a file with "use utf8"
Product: Fedora
Version: 19
Component: perl
Severity: medium
Assignee: jplesnik(a)redhat.com
Reporter: lav(a)yars.free.net
QA Contact: extras-qa(a)fedoraproject.org
CC: cweyl(a)alumni.drew.edu, iarnell(a)gmail.com,
jplesnik(a)redhat.com, kasal(a)ucw.cz,
perl-devel(a)lists.fedoraproject.org, ppisar(a)redhat.com,
psabata(a)redhat.com, rc040203(a)freenet.de,
tcallawa(a)redhat.com
Description of problem:
Every time perl includes a file with "use utf8" and text constants it leaks
memory.
Version-Release number of selected component (if applicable):
perl-5.16.3-266.fc19.x86_64
How reproducible:
always
Steps to Reproduce:
1. run the test program below
2. watch as memory usage grows
Here is the test program:
-------------------------
my $mem = 0;
sub report_memory () {
my $next_mem = qx[ps -p $$ -o size=]+0;
printf "%+8d = %8d K\n", $next_mem-$mem, $next_mem; $mem = $next_mem;
}
for (0..1e5) {
do 'x.inc';
report_memory unless $_ % 1e4;
}
-------------------------
x.inc contains:
-------------------------
use utf8;
$x='x';
-------------------------
--
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=l7ghbj1UQE&a=cc_unsubscribe
8 years, 6 months
[Bug 1129850] New: Perl debugger commands that depend on Padwalker no longer work
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1129850
Bug ID: 1129850
Summary: Perl debugger commands that depend on Padwalker no
longer work
Product: Fedora
Version: 20
Component: perl
Severity: high
Assignee: jplesnik(a)redhat.com
Reporter: alan(a)clueserver.org
QA Contact: extras-qa(a)fedoraproject.org
CC: cweyl(a)alumni.drew.edu, iarnell(a)gmail.com,
jplesnik(a)redhat.com, kasal(a)ucw.cz,
perl-devel(a)lists.fedoraproject.org, ppisar(a)redhat.com,
psabata(a)redhat.com, rc040203(a)freenet.de,
tcallawa(a)redhat.com
Description of problem:
When using the Perl command line debugger the "y" and "X" commands no longer
work. (They fail silently.)
Version-Release number of selected component (if applicable):
perl-5.18.2-289.fc20
perl-PadWalker-1.98-1.fc20.x86_64
How reproducible:
Every time.
Steps to Reproduce:
1. Debug a test program with "perl -d testprog.pl
2. Use "n" and enter a few lines until a variable you want to examine is
loaded.
3. Use "y" or "X" on that variable.
Actual results:
Nothing returned.
Expected results:
The contents of the variable should be displayed.
Additional info:
The "p" command will print a variable, it is very narrow in scope. It will not
display the contents of an entire hash variable like "X" or "y" will. ("y"
shows the contents of the variable for all types in the current package. "X"
does the same for global variables. Neither work at this point.
--
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=VpjaTqvTg7&a=cc_unsubscribe
8 years, 6 months