EPEL Fedora 5 updates-testing report
The following Fedora EPEL 5 Security updates need testing:
Age URL
412
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5630/bugzilla-3.2.10-5.el5
307
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-6608/Django-1.1.4-2.el5
113
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-0366/openconnect-4.08-1.el5
46
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-5517/git-1.8.2.1-1.el5
14
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-5968/transifex-client-0.9-1.el5
10
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-5990/mod_security-2.6.8-4.el5
10
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-5991/cgit-0.9.2-1.el5
10
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-5996/socat-1.7.2.2-1.el5
6
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-6047/nrpe-2.14-3.el5
3
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-6086/libguestfs-1.20.8-1.el5
2
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-6089/ssmtp-2.61-20.el5
0
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-10388/perl-Module-Signature-0.73-1.el5
0
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-10389/rrdtool-1.2.27-4.el5
The following builds have been pushed to Fedora EPEL 5 updates-testing
perl-Module-Signature-0.73-1.el5
python-virtualenv-1.7.2-2.el5
rrdtool-1.2.27-4.el5
Details about builds:
perl-Module-Signature-0.73-1.el5 (FEDORA-EPEL-2013-10388)
CPAN signature management utilities and modules
Update Information:
This update ensures that digest modules are only loaded from absolute paths in
@INC, avoiding a potential arbitrary code execution problem (CVE-2013-2145).
There are also a variety of internal package clean-ups.
ChangeLog:
* Fri Jun 7 2013 Paul Howarth p...@city-fan.org - 0.73-1
- Update to 0.73
- Support for gpg under these alternate names: gpg gpg2 gnupg gnupg2
- Don't check gpg version if gpg does not exist
- Constrain the user-specified digest name to /^\w+\d+$/
- Only allow loading Digest::* from absolute paths in @INC (CVE-2013-2145)
- This release by AUDREYT - update source URL
- Include Andreas Koenig's GPG key in the SRPM and import it in %prep so
that we don't need to get it from a keyserver in %check
- Make building non-interactive
- Specify all dependencies
- Don't need to remove empty directories from the buildroot
- Drop %defattr, redundant since rpm 4.4
- Use %{_fixperms} macro rather than our own chmod incantation
References:
[ 1 ] Bug #971096 - CVE-2013-2145 perl-Module-Signature: arbitrary code
execution when verifying SIGNATURE
https://bugzilla.redhat.com/show_bug.cgi?id=971096
python-virtualenv-1.7.2-2.el5 (FEDORA-EPEL-2013-10396)
Tool to create isolated Python environments
Update Information:
* Switch to an older version of virtualenv because the 1.9.x branch doesn't
work with python-2.4
References:
[ 1 ] Bug #969395 - virtualenv does not work anymore because Python 2.4
support was dropped in virtualenv 1.9
https://bugzilla.redhat.com/show_bug.cgi?id=969395
rrdtool-1.2.27-4.el5 (FEDORA-EPEL-2013-10389)
Round Robin Database Tool to store and display time-series data
Update Information:
This is an update that adds explicit check to the imginfo format. It may
prevent crash/exploit of user space applications which pass user supplied
format to the library call without checking.
References:
[ 1 ] Bug #969311 - CVE-2013-2131 rrdtool: crashes on format string exploit
[epel-5]
https://bugzilla.redhat.com/show_bug.cgi?id=969311
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Orphaning some python packages and perl-Class-CSV
- Original Message - From: David Malcolm dmalc...@redhat.com Sent: Friday, June 7, 2013 6:01:48 PM * python-sqlparse * python3-postgresql Taken. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging alien, debhelper and po-debconf
On Dom, 2013-06-02 at 20:56 +0100, Sérgio Basto wrote: On Ter, 2013-05-07 at 14:07 +0300, Oron Peled wrote: On Wednesday 01 May 2013 22:21:20 Richard W.M. Jones wrote: On Wed, May 01, 2013 at 03:00:34AM +0100, Sérgio Basto wrote: https://bugzilla.redhat.com/show_bug.cgi?id=591190 I'm prepared to take debhelper. But: (1) It looks like the latest package is over 1 year old. I think a newer package should be presented (in this bug or in a newly opened one). (2) Can debhelper be used to make .deb's on a Fedora host? If it works, that would currently be very interesting to me. I'll start with (2): * I can build .deb's on Fedora using pbuilder/pdebuild. * Here is the tree of RR for making it work: https://bugzilla.redhat.com/showdependencytree.cgi?id=591388 * Credit goes to Jeroen van Meeuwen. I just joined to help move it forward [ with very little success so far, mind you :-( ] * And yes, I think it makes Fedora a better development platform if you can use it to build both rpm's and deb's (on Debian, you can do both). Now to (1)... Ouch: * The stalling of po-debconf is my fault, but see today's update to rhbz#591389 (I'm fixing my ways...) * If we resolve it quickly, the next is debhelper (rhbz#591190). IMO the main blocker there is finding someone committed to review (I'm willing to maintain it). There's another problem in the chain (dpkg too old), but hopefully it will be OK soon (maintainer updated today the BR and said he would fix it RSN) * I uploaded a temporary pbuilder SRPM: http://oron.fedorapeople.org/deb-package/pbuilder-0.213-1.fc18.src.rpm - It's up-to-date (Debian/wheezy) - But I didn't have time to clean it up for review. Hope to do this in the next few days and update the RR. So maybe we finally have a chance to move this along before the dedicated bug zappers would zap it (no criticism -- they work hard to clean the mess we leave behind us). Unrelated note: * I've been using schroot(1) a lot in the last years on both Debian/Fedora to maintain multiple clean build environments of different OS. * However, one of the most useful features -- snapshots via LVM -- is not usable in Fedora due to rhbz#600636 * That bug-report is stalled since 2010, and exactly a year passed since I sent a tested patch... OK, back to work now. Hi, I'm going , if no problem, begin F18 cycle build this 7 packages: dpkg debconf po-debconf debhelper alien dh-make pbuilder 1st build dpkg and debconf https://koji.fedoraproject.org/koji/packageinfo?packageID=9963 dpkg-1.16.10-4 for devel , f19 and f18 https://koji.fedoraproject.org/koji/packageinfo?packageID=13893 debconf-1.5.49-2.fc18 for devel , f19 and f18 after build po-debconf (depends on debconf) https://koji.fedoraproject.org/koji/packageinfo?packageID=16122 we need rebuild po-debconf for devel , f19 and f18 , for new debconf-1.5.49 I put debconf in buildroot-override bodhi --buildroot-override=debconf-1.5.49-2.fc18 --duration=5 --notes=For po-debconf, debhelper, alien and dh-make after build debhelper ( depends on dpkg and po-debconf ) next is put po-debconf in build root , to build debhelper after build alien (depends on debhelper) and dh-make (depends on debhelper ) next is put debhelper in build root , to build alien and dh-make after review and build pbuilder (depends on dh-make, debhelper and po-debconf ) Oron, I don't have commit permissions for po-debconf and debhelper so you can give me that and with buildroot-override we can finish this weekend . Best regards and thanks, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20130608 changes
Compose started at Sat Jun 8 08:15:03 UTC 2013 Broken deps for x86_64 -- [bind10] bind10-1.0.0-3.fc20.i686 requires liblog4cplus-1.1.so.5 bind10-1.0.0-3.fc20.x86_64 requires liblog4cplus-1.1.so.5()(64bit) bind10-dhcp-1.0.0-3.fc20.i686 requires liblog4cplus-1.1.so.5 bind10-dhcp-1.0.0-3.fc20.x86_64 requires liblog4cplus-1.1.so.5()(64bit) bind10-dns-1.0.0-3.fc20.i686 requires liblog4cplus-1.1.so.5 bind10-dns-1.0.0-3.fc20.x86_64 requires liblog4cplus-1.1.so.5()(64bit) [ekiga] ekiga-4.0.1-1.fc19.x86_64 requires libedata-book-1.2.so.17()(64bit) [gdb-heap] gdb-heap-0.5-12.fc19.x86_64 requires glibc(x86-64) = 0:2.17 [gooddata-cl] gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java [kawa] 1:kawa-1.11-5.fc19.x86_64 requires servlet25 [koji] koji-vm-1.8.0-1.fc20.noarch requires python-virtinst [lancet] lancet-1.0.1-6.fc19.noarch requires ant-nodeps = 0:1.7.1 [lutok] lutok-devel-0.2-4.fc19.i686 requires lua-devel 0:5.2 lutok-devel-0.2-4.fc19.x86_64 requires lua-devel 0:5.2 [openbox] gdm-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel gnome-panel-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel [ovirt-engine] ovirt-engine-notification-service-3.1.0-1.fc19.noarch requires classpathx-mail [ovirt-guest-agent] ovirt-guest-agent-gdm-plugin-1.0.6-6.fc19.x86_64 requires libgdmsimplegreeter.so.1()(64bit) [oyranos] oyranos-libs-0.4.0-7.fc19.i686 requires libraw.so.5 oyranos-libs-0.4.0-7.fc19.x86_64 requires libraw.so.5()(64bit) [perl-Bio-ASN1-EntrezGene] perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) [perl-Bio-SamTools] perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq) [python-TraitsBackendQt] python-TraitsBackendQt-3.5.0-5.fc19.noarch requires python-TraitsGUI [python-flask-admin] python-flask-admin-1.0.5-3.fc20.noarch requires python-wtf-peewee [qpid-cpp] qpid-cpp-server-xml-0.20-6.fc20.x86_64 requires libxqilla.so.5()(64bit) [scala] scala-2.9.2-2.fc19.noarch requires osgi(org.scala-ide.scala.library) [spacewalk-web] spacewalk-dobby-1.9.22-2.fc19.noarch requires perl(Spacewalk::Setup) [spring] spring-94.1-1.fc20.x86_64 requires libassimp.so.2()(64bit) [tex-simplecv] tex-simplecv-doc-1.6-12.fc19.noarch requires texlive-texmf-doc [tuna] tuna-0.11-1.fc20.noarch requires python-linux-procfs = 0:0.4.6 [zarafa] libmapi-7.0.13-1.fc19.i686 requires libicalss.so.0 libmapi-7.0.13-1.fc19.i686 requires libical.so.0 libmapi-7.0.13-1.fc19.x86_64 requires libicalss.so.0()(64bit) libmapi-7.0.13-1.fc19.x86_64 requires libical.so.0()(64bit) php-mapi-7.0.13-1.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64 php-mapi-7.0.13-1.fc19.x86_64 requires php(api) = 0:20100412-x86-64 zarafa-ical-7.0.13-1.fc19.x86_64 requires libicalss.so.0()(64bit) zarafa-ical-7.0.13-1.fc19.x86_64 requires libical.so.0()(64bit) Broken deps for i386 -- [bind10] bind10-1.0.0-3.fc20.i686 requires liblog4cplus-1.1.so.5 bind10-dhcp-1.0.0-3.fc20.i686 requires liblog4cplus-1.1.so.5 bind10-dns-1.0.0-3.fc20.i686 requires liblog4cplus-1.1.so.5 [ekiga] ekiga-4.0.1-1.fc19.i686 requires libedata-book-1.2.so.17 [gdb-heap] gdb-heap-0.5-12.fc19.i686 requires glibc(x86-32) = 0:2.17 [gooddata-cl] gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java [kawa] 1:kawa-1.11-5.fc19.i686 requires servlet25 [koji] koji-vm-1.8.0-1.fc20.noarch requires python-virtinst [lancet] lancet-1.0.1-6.fc19.noarch requires ant-nodeps = 0:1.7.1 [lutok] lutok-devel-0.2-4.fc19.i686 requires lua-devel 0:5.2 [openbox] gdm-control-3.5.0-11.20121001git782b28.fc19.i686 requires gnome-panel gnome-panel-control-3.5.0-11.20121001git782b28.fc19.i686 requires gnome-panel [ovirt-engine] ovirt-engine-notification-service-3.1.0-1.fc19.noarch requires classpathx-mail [ovirt-guest-agent] ovirt-guest-agent-gdm-plugin-1.0.6-6.fc19.i686 requires libgdmsimplegreeter.so.1 [oyranos] oyranos-libs-0.4.0-7.fc19.i686 requires libraw.so.5 [perl-Bio-ASN1-EntrezGene] perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) [perl-Bio-SamTools] perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::PrimarySeq) [python-TraitsBackendQt] python-TraitsBackendQt-3.5.0-5.fc19.noarch requires python-TraitsGUI [python-flask-admin] python-flask-admin-1.0.5-3.fc20.noarch requires
F-19 Branched report: 20130608 changes
Compose started at Sat Jun 8 09:15:02 UTC 2013 Broken deps for x86_64 -- [deltacloud-core] deltacloud-core-rhevm-1.1.3-1.fc19.noarch requires rubygem(rbovirt) = 0:0.0.18 [dragonegg] dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19 [freeipa] freeipa-server-strict-3.2.0-2.fc19.x86_64 requires krb5-server = 0:1.11.2 [gooddata-cl] gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java [kawa] 1:kawa-1.11-5.fc19.x86_64 requires servlet25 [koji] koji-vm-1.8.0-1.fc19.noarch requires python-virtinst [libkolab] php-kolab-0.4.1-3.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64 php-kolab-0.4.1-3.fc19.x86_64 requires php(api) = 0:20100412-x86-64 [llvm] clang-3.3-0.4.rc2.fc19.i686 requires libstdc++-devel = 0:4.8.0 clang-3.3-0.4.rc2.fc19.i686 requires gcc = 0:4.8.0 clang-3.3-0.4.rc2.fc19.x86_64 requires libstdc++-devel = 0:4.8.0 clang-3.3-0.4.rc2.fc19.x86_64 requires gcc = 0:4.8.0 [nodejs-tilelive] nodejs-tilelive-4.4.3-2.fc19.noarch requires npm(optimist) 0:0.4 [openbox] gdm-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel gnome-panel-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel [ovirt-engine] ovirt-engine-notification-service-3.1.0-1.fc19.noarch requires classpathx-mail [ovirt-guest-agent] ovirt-guest-agent-gdm-plugin-1.0.6-6.fc19.x86_64 requires libgdmsimplegreeter.so.1()(64bit) [perl-Bio-ASN1-EntrezGene] perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) [perl-Bio-SamTools] perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq) [python-TraitsBackendQt] python-TraitsBackendQt-3.5.0-5.fc19.noarch requires python-TraitsGUI [scala] scala-2.9.2-2.fc19.noarch requires osgi(org.scala-ide.scala.library) [spacewalk-web] spacewalk-dobby-1.9.22-2.fc19.noarch requires perl(Spacewalk::Setup) [zarafa] php-mapi-7.0.13-1.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64 php-mapi-7.0.13-1.fc19.x86_64 requires php(api) = 0:20100412-x86-64 Broken deps for i386 -- [deltacloud-core] deltacloud-core-rhevm-1.1.3-1.fc19.noarch requires rubygem(rbovirt) = 0:0.0.18 [dragonegg] dragonegg-3.1-19.fc19.i686 requires gcc = 0:4.7.2-9.fc19 [freeipa] freeipa-server-strict-3.2.0-2.fc19.i686 requires krb5-server = 0:1.11.2 [gooddata-cl] gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java [kawa] 1:kawa-1.11-5.fc19.i686 requires servlet25 [koji] koji-vm-1.8.0-1.fc19.noarch requires python-virtinst [libkolab] php-kolab-0.4.1-3.fc19.i686 requires php(zend-abi) = 0:20100525-x86-32 php-kolab-0.4.1-3.fc19.i686 requires php(api) = 0:20100412-x86-32 [llvm] clang-3.3-0.4.rc2.fc19.i686 requires libstdc++-devel = 0:4.8.0 clang-3.3-0.4.rc2.fc19.i686 requires gcc = 0:4.8.0 [nodejs-tilelive] nodejs-tilelive-4.4.3-2.fc19.noarch requires npm(optimist) 0:0.4 [openbox] gdm-control-3.5.0-11.20121001git782b28.fc19.i686 requires gnome-panel gnome-panel-control-3.5.0-11.20121001git782b28.fc19.i686 requires gnome-panel [ovirt-engine] ovirt-engine-notification-service-3.1.0-1.fc19.noarch requires classpathx-mail [ovirt-guest-agent] ovirt-guest-agent-gdm-plugin-1.0.6-6.fc19.i686 requires libgdmsimplegreeter.so.1 [perl-Bio-ASN1-EntrezGene] perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) [perl-Bio-SamTools] perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::PrimarySeq) [python-TraitsBackendQt] python-TraitsBackendQt-3.5.0-5.fc19.noarch requires python-TraitsGUI [scala] scala-2.9.2-2.fc19.noarch requires osgi(org.scala-ide.scala.library) [spacewalk-web] spacewalk-dobby-1.9.22-2.fc19.noarch requires perl(Spacewalk::Setup) [zarafa] php-mapi-7.0.13-1.fc19.i686 requires php(zend-abi) = 0:20100525-x86-32 php-mapi-7.0.13-1.fc19.i686 requires php(api) = 0:20100412-x86-32 New package: glassfish-annotation-api-1.2-3.fc19 Common Annotations API Specification (JSR 250) New package: java-dirq-1.3-3.fc19 Directory based queue New package: nodejs-defined-0.0.0-1.fc19 Return the first argument that is '!== undefined' New package: nodejs-jsonify-0.0.0-1.fc19 JSON without touching any globals New package: nodejs-paperboy-0.0.5-1.fc19 A node.js module for delivering static files New package: nodejs-through-2.3.4-1.fc19 Simplified stream construction for Node.js New package: phrel-1.0.1-1.fc19 Per Host
Re: Bad file access on the rise
On Saturday, June 08, 2013 06:33:11 AM Matthew Garrett wrote: On Fri, Jun 07, 2013 at 07:03:24PM -0600, Stephen John Smoogen wrote: On 7 June 2013 12:29, Matthew Garrett mj...@srcf.ucam.org wrote: So why not add a mechanism to permit applications to indicate that certain accesses they make should be ignored by audit? Just so people know, this is like one of the the oldest auditing argument in the world. I have had programmers say that since the 1990's. [The standard counter story is that user program X says don't audit anything I do in /etc. The programmer counters with adding in a black list of directories that can't be audited, this gets countered by something else and eventually you have a process where programs that have a GPG signature that has been accepted as valid by the audit program can say which of the white listed files it wants opened without audit are dealt with... and then some other programmer comes in and shows the 20,000 lines of need to be audited code replaces 40 lines of C code in the programs that were causing the problem.] Well, http://www.stigviewer.com/check/V-29067 implies that filtering of audit records is a reasonable thing to do. What this requirement is talking about is that we must provide something like ausearch. OK, we do that. What I am telling you is that the OS has changed in a bad way in the last year or two. It has _never_ been this noisy for auditing. Look at this: # aureport --start this-week --key --summary Key Summary Report === total key === 73520 access 562 module-load 149 module-unload 135 bypass 132 system-locale 132 container-config 113 time-change 110 identity 100 data-injection 88 container-create 88 export 58 register-injection 44 code-injection 29 power-abuse 22 modules-del 22 modules-add 22 MAC-policy The bad access events dominate the event log. I have no expectation that arbitrary user applications should be able to do whatever they want without leaving an audit trail, but I don't see what that has to do with system applications. Root has the ability to modify the selinux policy, so root (and packages installed by root) should have the ability to modify the set of behaviours that trigger audit records. Its not quite like this. What I need is the OS to be well behaved under normal conditions so that when problems come along they are easily spotted. Fedora has been a fairly well behaved OS over the years. I have had to get a few apps fixed in the past and the maintainers have always been accommodating. But this time I am finding we have a serious problem worse than in the past. Thanks, -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bad file access on the rise
On Saturday, June 08, 2013 06:36:38 AM Matthew Garrett wrote: On Fri, Jun 07, 2013 at 05:24:30PM -0400, Steve Grubb wrote: Hmm...sounds like kernel change. But in the meantime, most of the offenders I see seem to have something to do with loading icons Sounds like code that doesn't differentiate between files that are in user-local directories and system-global directories. That's something that could presumably be fixed, but it seems like a bunch of effort. From the code I saw previously, it seems like just changing the function being called to the variant without noatime in its name. The comments in the code Colin pointed to say this: * gs_file_read_noatime: * @file: a #GFile * @cancellable: a #GCancellable * @error: a #GError * * Like g_file_read(), but try to avoid updating the file's * access time. This should be used by background scanning * components such as search indexers, antivirus programs, etc. And evince, firefox, or openoffice are not any of those ^^. :-) Other than a heuristic based on whether a path is in the user's home directory or not, the only way to avoid this is to stat before opening - and that's obviously prone to failure. Does opening with noatime really make a measurable difference (assuming it worked)? I suspect not since what we have now is 2 syscalls. It would probably be faster to load icons without trying to set NOATIME. Thanks, -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bad file access on the rise
On Sat, Jun 08, 2013 at 09:34:22AM -0400, Steve Grubb wrote: Other than a heuristic based on whether a path is in the user's home directory or not, the only way to avoid this is to stat before opening - and that's obviously prone to failure. Does opening with noatime really make a measurable difference (assuming it worked)? I suspect not since what we have now is 2 syscalls. It would probably be faster to load icons without trying to set NOATIME. PLUS, we are mounting filesystems with relatime anyway. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bad file access on the rise
On Saturday, June 08, 2013 09:34:22 AM Steve Grubb wrote:
Does opening with noatime really make a measurable difference (assuming it
worked)? I suspect not since what we have now is 2 syscalls. It would
probably be faster to load icons without trying to set NOATIME.
Answering my own question
#include stdio.h
#define __USE_GNU
#include fcntl.h
#include unistd.h
#include string.h
void noatime(void)
{
int fd = open(/usr/share/icons/hicolor/48x48/apps/firefox.png,
O_RDONLY|O_NOATIME);
if (fd=0)
close(fd);
else {
fd = open(/usr/share/icons/hicolor/48x48/apps/firefox.png,
O_RDONLY);
if (fd=0)
close(fd);
}
}
void atime(void)
{
int fd = open(/usr/share/icons/hicolor/48x48/apps/firefox.png,
O_RDONLY);
if (fd=0)
close(fd);
}
int main(int argc, char *argv[])
{
int i, mode=0;
if (argc == 2 strcmp(noatime, argv[1]) == 0)
mode = 1;
for (i=0; i5000; i++) {
if (mode)
noatime();
else
atime();
}
return 0;
}
As a normal user:
$ time ./test noatime
real0m12.645s
user0m0.003s
sys 0m0.159s
$ time ./test atime
real0m0.019s
user0m0.002s
sys 0m0.016s
Way faster doing a normal open. As root:
# time ./test noatime
real0m0.019s
user0m0.000s
sys 0m0.019s
# time ./test atime
real0m0.019s
user0m0.001s
sys 0m0.017s
No real difference between them.
-Steve
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bad file access on the rise
On 06/08/2013 09:53 AM, Steve Grubb wrote:
On Saturday, June 08, 2013 09:34:22 AM Steve Grubb wrote:
Does opening with noatime really make a measurable difference (assuming it
worked)? I suspect not since what we have now is 2 syscalls. It would
probably be faster to load icons without trying to set NOATIME.
Answering my own question
#include stdio.h
#define __USE_GNU
#include fcntl.h
#include unistd.h
#include string.h
void noatime(void)
{
int fd = open(/usr/share/icons/hicolor/48x48/apps/firefox.png,
O_RDONLY|O_NOATIME);
if (fd=0)
close(fd);
else {
fd = open(/usr/share/icons/hicolor/48x48/apps/firefox.png,
O_RDONLY);
if (fd=0)
close(fd);
}
}
void atime(void)
{
int fd = open(/usr/share/icons/hicolor/48x48/apps/firefox.png,
O_RDONLY);
if (fd=0)
close(fd);
}
int main(int argc, char *argv[])
{
int i, mode=0;
if (argc == 2 strcmp(noatime, argv[1]) == 0)
mode = 1;
for (i=0; i5000; i++) {
if (mode)
noatime();
else
atime();
}
return 0;
}
As a normal user:
$ time ./test noatime
real 0m12.645s
user 0m0.003s
sys 0m0.159s
$ time ./test atime
real 0m0.019s
user 0m0.002s
sys 0m0.016s
Way faster doing a normal open. As root:
Bad test. The first run took the hit for getting the file info into
page cache, after that, everything was run from cache and you got the
second result above and the results below. You have to make sure that
from run to run the cache state of the file in question is identical.
# time ./test noatime
real 0m0.019s
user 0m0.000s
sys 0m0.019s
# time ./test atime
real 0m0.019s
user 0m0.001s
sys 0m0.017s
No real difference between them.
-Steve
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bad file access on the rise
On Saturday, June 08, 2013 09:57:03 AM Doug Ledford wrote: Bad test. The first run took the hit for getting the file info into page cache, after that, everything was run from cache and you got the second result above and the results below. You have to make sure that from run to run the cache state of the file in question is identical. Try it yourself. :-) I know what you are saying and run the test probably 8 times before posting results. I also have the audit rule loaded...so removing it: [sgrubb@x2 noatime]$ time ./test noatime real0m0.031s user0m0.006s sys 0m0.024s [sgrubb@x2 noatime]$ time ./test noatime real0m0.033s user0m0.002s sys 0m0.032s [sgrubb@x2 noatime]$ time ./test noatime real0m0.036s user0m0.002s sys 0m0.031s [sgrubb@x2 noatime]$ time ./test atime real0m0.023s user0m0.001s sys 0m0.021s [sgrubb@x2 noatime]$ time ./test atime real0m0.022s user0m0.003s sys 0m0.019s [sgrubb@x2 noatime]$ time ./test atime real0m0.023s user0m0.002s sys 0m0.019s Without the audit rules, it is faster. But again opening with noatime attempted is measurably slower. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bad file access on the rise
On 06/08/2013 10:10 AM, Steve Grubb wrote: On Saturday, June 08, 2013 09:57:03 AM Doug Ledford wrote: Bad test. The first run took the hit for getting the file info into page cache, after that, everything was run from cache and you got the second result above and the results below. You have to make sure that from run to run the cache state of the file in question is identical. Try it yourself. :-) I know what you are saying and run the test probably 8 times before posting results. I also have the audit rule loaded...so removing it: [sgrubb@x2 noatime]$ time ./test noatime real 0m0.031s user 0m0.006s sys 0m0.024s [sgrubb@x2 noatime]$ time ./test noatime real 0m0.033s user 0m0.002s sys 0m0.032s [sgrubb@x2 noatime]$ time ./test noatime real 0m0.036s user 0m0.002s sys 0m0.031s [sgrubb@x2 noatime]$ time ./test atime real 0m0.023s user 0m0.001s sys 0m0.021s [sgrubb@x2 noatime]$ time ./test atime real 0m0.022s user 0m0.003s sys 0m0.019s [sgrubb@x2 noatime]$ time ./test atime real 0m0.023s user 0m0.002s sys 0m0.019s Without the audit rules, it is faster. But again opening with noatime attempted is measurably slower. Yes, but none of these results show the .12s time that your first noatime test run showed in your original post. If you are now saying that atime is faster than noatime by about .005 to .010s, then these results seem to show that. But your original post was from .019 to .12, or a difference of .10+s. That was cache load time, not just the syscall difference. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bad file access on the rise
On Saturday, June 08, 2013 10:13:45 AM Doug Ledford wrote: Yes, but none of these results show the .12s time that your first noatime test run showed in your original post. If you are now saying that atime is faster than noatime by about .005 to .010s, then these results seem to show that. But your original post was from .019 to .12, or a difference of .10+s. That was cache load time, not just the syscall difference. I chalk that up to the audit system. The audit system tries real hard to stay out of the way since the vast majority of syscalls are not interesting. But if you trigger an event, it has to get recorded in gory detail and that takes time. (The first run did trigger 5000 audit events, the others didn't.) This is another reason (but not the main reason) we need to try to avoid triggering events in a normally operating machine. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bad file access on the rise
On Sat, Jun 08, 2013 at 09:53:39AM -0400, Steve Grubb wrote: No real difference between them. Make sure that you're testing this on a partition mounted with strictatime. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bad file access on the rise
On Sat, 2013-06-08 at 09:25 -0400, Steve Grubb wrote: Its not quite like this. What I need is the OS to be well behaved under normal conditions so that when problems come along they are easily spotted. Fedora has been a fairly well behaved OS over the years. I have had to get a few apps fixed in the past and the maintainers have always been accommodating. But this time I am finding we have a serious problem worse than in the past. Well, you're defining something as 'bad behaviour' fairly arbitrarily - or at least controversially: not everyone agrees with your definition. Continuing to simply assert that the behaviour is bad is not driving the conversation forward, you're just repeating a position that others have already raised objections to. Those who are disputing your position are not saying 'this behaviour is not happening', they are saying 'we disagree with your definition of bad behaviour'. If it's not 'bad behaviour', the fact that it didn't happen before is fairly irrelevant. I could come up with any arbitrary 'test' for some action that Fedora 19 does that Fedora 18 does not; that doesn't mean I can then show up on the list waving my test results about and declaring that there's a problem. First there has to be solid agreement that I'm actually testing for something we shouldn't be doing. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for Bikeshedding: remote auth at install time
Kickstart is fine for centrally managed devices. They've got experienced sysadmins who don't mind getting dirty with configuration files. The real kicker is people who manage their own device: not just BYOD but also part-time sysadmins who can't run the corporate distribution. These people can suck substantial time from deep support at the help desk. For those people there does needs to be an easy way for them to configure a network authenticating account. But there's no need for that to be in the installation dialogues. Considering that IT support might approach them well after installation and say our policy is that machine authenticate against the Corporate Blah rather than have local authentication there's a strong argument for being able to do this well away from installation. I'd also strongly encourage a design which makes it easy for a corporate-issued RPM to configure the authentication. For an example of something wonderful, NetworkManager has a one-file-per-ssid design so its easy for a RPM to drop in the configuration files for the corporate wireless. I'd really like a company to be able to have a set of noarch RPMS which put in place the minimum configuration for use within the organisation. -glen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bad file access on the rise
On 06/08/2013 10:29 AM, Steve Grubb wrote: On Saturday, June 08, 2013 10:13:45 AM Doug Ledford wrote: Yes, but none of these results show the .12s time that your first noatime test run showed in your original post. If you are now saying that atime is faster than noatime by about .005 to .010s, then these results seem to show that. But your original post was from .019 to .12, or a difference of .10+s. That was cache load time, not just the syscall difference. I chalk that up to the audit system. The audit system tries real hard to stay out of the way since the vast majority of syscalls are not interesting. But if you trigger an event, it has to get recorded in gory detail and that takes time. (The first run did trigger 5000 audit events, the others didn't.) This is another reason (but not the main reason) we need to try to avoid triggering events in a normally operating machine. OK, that makes more sense. So the audit events on a 5000 loop take up the .10 seconds in time difference. Fine, I'll grant that this legitimately belongs in the time difference then. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bad file access on the rise
On 06/08/2013 02:35 PM, Adam Williamson wrote: On Sat, 2013-06-08 at 09:25 -0400, Steve Grubb wrote: Its not quite like this. What I need is the OS to be well behaved under normal conditions so that when problems come along they are easily spotted. Fedora has been a fairly well behaved OS over the years. I have had to get a few apps fixed in the past and the maintainers have always been accommodating. But this time I am finding we have a serious problem worse than in the past. Well, you're defining something as 'bad behaviour' fairly arbitrarily - or at least controversially: not everyone agrees with your definition. Speaking as a former sysadmin responsible for intrusion detection, this is not a controversial definition at all (namely that anything that creates audit events without a reasonably just cause is 'bad behavior'). It is the only sane definition of 'bad behavior'. Anything that makes an admin go chasing ghosts for no good reason is most definitely 'bad behavior', and every single audit event on a system must be identifiable by the admins before you know your system is secure. Continuing to simply assert that the behaviour is bad is not driving the conversation forward, you're just repeating a position that others have already raised objections to. Those who are disputing your position are not saying 'this behaviour is not happening', they are saying 'we disagree with your definition of bad behaviour'. If it's not 'bad behaviour', the fact that it didn't happen before is fairly irrelevant. I could come up with any arbitrary 'test' for some action that Fedora 19 does that Fedora 18 does not; that doesn't mean I can then show up on the list waving my test results about and declaring that there's a problem. First there has to be solid agreement that I'm actually testing for something we shouldn't be doing. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for Bikeshedding: remote auth at install time
On Sun, 2013-06-09 at 09:24 +0930, Glen Turner wrote: Kickstart is fine for centrally managed devices. They've got experienced sysadmins who don't mind getting dirty with configuration files. The real kicker is people who manage their own device: not just BYOD but also part-time sysadmins who can't run the corporate distribution. These people can suck substantial time from deep support at the help desk. For those people there does needs to be an easy way for them to configure a network authenticating account. But there's no need for that to be in the installation dialogues. Considering that IT support might approach them well after installation and say our policy is that machine authenticate against the Corporate Blah rather than have local authentication there's a strong argument for being able to do this well away from installation. I'd also strongly encourage a design which makes it easy for a corporate-issued RPM to configure the authentication. For an example of something wonderful, NetworkManager has a one-file-per-ssid design so its easy for a RPM to drop in the configuration files for the corporate wireless. I'd really like a company to be able to have a set of noarch RPMS which put in place the minimum configuration for use within the organisation. Thanks. Those are some good thoughts, but since I'm just the test monkey, I'm on a strict focus: 'blocker or not blocker'. I'm sure the devs working on remote auth configuration would be interested in your thoughts, though! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bad file access on the rise
On Sat, Jun 08, 2013 at 08:28:48PM -0400, Doug Ledford wrote: On 06/08/2013 02:35 PM, Adam Williamson wrote: Well, you're defining something as 'bad behaviour' fairly arbitrarily - or at least controversially: not everyone agrees with your definition. Speaking as a former sysadmin responsible for intrusion detection, this is not a controversial definition at all (namely that anything that creates audit events without a reasonably just cause is 'bad behavior'). It is the only sane definition of 'bad behavior'. Anything that makes an admin go chasing ghosts for no good reason is most definitely 'bad behavior', and every single audit event on a system must be identifiable by the admins before you know your system is secure. I don't think anyone wants these accesses to generate audit records. The question is whether the right way to fix that is to avoid those accesses in the first place or to provide a mechanism so that legitimate accesses don't generate audit records. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Broken dependencies: perl-Bio-ASN1-EntrezGene
perl-Bio-ASN1-EntrezGene has broken dependencies in the rawhide tree: On x86_64: perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) On i386: perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Bio-SamTools
perl-Bio-SamTools has broken dependencies in the rawhide tree: On x86_64: perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq) On i386: perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::PrimarySeq) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Net-SSLeay-1.55.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Net-SSLeay: 473b8d66ca69d5784bb0e428721f58e0 Net-SSLeay-1.55.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Net-SSLeay] Update to 1.55
commit 8ed2ca85ed22a8d0e8df9a4cd5b9a28fd9687a29
Author: Paul Howarth p...@city-fan.org
Date: Sat Jun 8 22:35:20 2013 +0100
Update to 1.55
- New upstream release 1.55
- added support for TLSV1_1 and TLSV1_2 methods with
SSL_CTX_tlsv1_1_new(),
SSL_CTX_tlsv1_2_new(), TLSv1_1_method() and TLSv1_2_method(), where
available in the underlying openssl
- added CRL support functions X509_CRL_get_ext(),
X509_CRL_get_ext_by_NID(),
X509_CRL_get_ext_count()
- fixed a problem that could cause content with a value of '0' to be
incorrectly encoded by do_httpx3 and friends (CPAN RT#85417)
- added support for SSL_get_tlsa_record_byname() required for DANE
support in
openssl-1.0.2 and later
- testing with openssl-1.0.2-stable-SNAP-20130521
- added X509_NAME_new and X509_NAME_hash
perl-Net-SSLeay.spec | 16 +++-
sources |2 +-
2 files changed, 16 insertions(+), 2 deletions(-)
---
diff --git a/perl-Net-SSLeay.spec b/perl-Net-SSLeay.spec
index cc670ee..3a880a7 100644
--- a/perl-Net-SSLeay.spec
+++ b/perl-Net-SSLeay.spec
@@ -1,5 +1,5 @@
Name: perl-Net-SSLeay
-Version: 1.54
+Version: 1.55
Release: 1%{?dist}
Summary: Perl extension for using OpenSSL
Group: Development/Libraries
@@ -92,6 +92,20 @@ rm -rf %{buildroot}
%{_mandir}/man3/Net::SSLeay::Handle.3pm*
%changelog
+* Sat Jun 8 2013 Paul Howarth p...@city-fan.org - 1.55-1
+- update to 1.55
+ - added support for TLSV1_1 and TLSV1_2 methods with SSL_CTX_tlsv1_1_new(),
+SSL_CTX_tlsv1_2_new(), TLSv1_1_method() and TLSv1_2_method(), where
+available in the underlying openssl
+ - added CRL support functions X509_CRL_get_ext(), X509_CRL_get_ext_by_NID(),
+X509_CRL_get_ext_count()
+ - fixed a problem that could cause content with a value of '0' to be
+incorrectly encoded by do_httpx3 and friends (CPAN RT#85417)
+ - added support for SSL_get_tlsa_record_byname() required for DANE support in
+openssl-1.0.2 and later
+ - testing with openssl-1.0.2-stable-SNAP-20130521
+ - added X509_NAME_new and X509_NAME_hash
+
* Sat Mar 23 2013 Paul Howarth p...@city-fan.org - 1.54-1
- update to 1.54
- added support for SSL_export_keying_material where present (i.e. in OpenSSL
diff --git a/sources b/sources
index d7f0a27..fad0ded 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-26e758fff1c90cb00e9358fea7e1e22f Net-SSLeay-1.54.tar.gz
+473b8d66ca69d5784bb0e428721f58e0 Net-SSLeay-1.55.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Net-SSLeay] Created tag perl-Net-SSLeay-1.55-1.fc20
The lightweight tag 'perl-Net-SSLeay-1.55-1.fc20' was created pointing to: 8ed2ca8... Update to 1.55 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Authen-Simple
perl-Authen-Simple has broken dependencies in the epel-6 tree: On ppc64: perl-Authen-Simple-0.4-5.el6.noarch requires perl(Crypt::PasswdMD5) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-WWW-GoodData
perl-WWW-GoodData has broken dependencies in the epel-5 tree: On ppc: perl-WWW-GoodData-1.6-1.el5.noarch requires perl(Getopt::Long) = 0:2.36 On i386: perl-WWW-GoodData-1.6-1.el5.noarch requires perl(Getopt::Long) = 0:2.36 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-WWW-GoodData
perl-WWW-GoodData has broken dependencies in the epel-5 tree: On ppc: perl-WWW-GoodData-1.6-1.el5.noarch requires perl(Getopt::Long) = 0:2.36 On i386: perl-WWW-GoodData-1.6-1.el5.noarch requires perl(Getopt::Long) = 0:2.36 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
