[Bug 1673051] New: Upgrade perl-Test-Kwalitee to 1.28
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1673051
Bug ID: 1673051
Summary: Upgrade perl-Test-Kwalitee to 1.28
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-Test-Kwalitee
Assignee: paul(a)city-fan.org
Reporter: jplesnik(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: paul(a)city-fan.org, perl-devel(a)lists.fedoraproject.org,
tremble(a)tremble.org.uk
Target Milestone: ---
Classification: Fedora
Latest Fedora delivers 1.27 version. Upstream released 1.28. When you have free
time, please upgrade it.
--
You are receiving this mail because:
You are on the CC list for the bug.
4 years, 1 month
[Bug 1632660] TLSv1.3 - enable post-handshake auth
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1632660
Petr Pisar <ppisar(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ppisar(a)redhat.com
--- Comment #4 from Petr Pisar <ppisar(a)redhat.com> ---
Paul, if you don't mind, I will apply that patch. I have an intermittent test
for that that I will include. (It uses openssl tool, once IO-Socket-SSL obtains
server-side support for PHA the test will be rewritten without the openssl
tool.)
--
You are receiving this mail because:
You are on the CC list for the bug.
4 years, 1 month
[Bug 1670047] New: xtables.lock is not removed
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1670047
Bug ID: 1670047
Summary: xtables.lock is not removed
Product: Fedora
Version: 29
Hardware: x86_64
OS: Linux
Status: NEW
Component: perl-IPTables-libiptc
Severity: medium
Assignee: ppisar(a)redhat.com
Reporter: balwierz(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: perl-devel(a)lists.fedoraproject.org, ppisar(a)redhat.com
Target Milestone: ---
Classification: Fedora
Description of problem:
IPTables-libiptc perl module does not deal with xtables lock file
(/run/xtables.lock) properly. Upon a call of IPTables::libiptc::init() a lock
file is created. But this lock file is not removed after commit(). It is
actually being recreated after each iptables_do_command() call.
As a result, any script using this module will get stuck on the second
invocation of iptables_do_command, as the lock file will be already created at
this time. It will wait forever for a release of this lock file which would
never happen.
Version-Release number of selected component (if applicable):
0.52-27.fc29
How reproducible:
Always
Steps to Reproduce:
1.a) Run the simple perl code:
use IPTables::libiptc;
my $filter = IPTables::libiptc::init('filter');
$filter->commit(); #an empty commit
2.a) ls /run/xtables.lock
1.b) If you add iptables_do_command() the script will never finish:
$| = 1;
use IPTables::libiptc;
my $filter = IPTables::libiptc::init('filter');
print "debug: after init\n";
$filter->iptables_do_command(['--flush', "OUTPUT"]);
print "debug: after the first flush\n";
$filter->iptables_do_command(['--flush', "OUTPUT"]); # a wait occurs here
print "debug: after the second flush\n";
$filter->commit();
Actual results:
a) Lock file persists after the script has finished.
b) Lock file prevents script from being finished. The messages printed:
debug: after init
debug: after the first flush
Another app is currently holding the xtables lock; still -9s 0us time ahead
to have a chance to grab the lock...
Another app is currently holding the xtables lock; still -19s 0us time ahead
to have a chance to grab the lock...
[...]
Expected results:
No self-locking behaviour.
xtables.lock removed after all objects called ->commit() or the script has
finished.
Additional info:
- From my inspection perl-IPTables-libiptc has the most recent patch against
iptables 1.6.1, which is older than 1.8.0 shipped with FC29.
- There was no such problem in FC26 which ships older iptables 1.6.x
- The same version is in rawhide, but I have not tested it
--
You are receiving this mail because:
You are on the CC list for the bug.
4 years, 1 month