EPEL Fedora 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 594 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6 108 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11274/ssmtp-2.61-21.el6 50 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11865/quassel-0.9.1-1.el6 23 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12079/bip-0.8.9-1.el6 13 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12171/drupal7-7.24-1.el6 9 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-1/drupal6-6.29-1.el6 5 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12238/seamonkey-2.21-2.esr1.el6 1 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12290/zabbix20-2.0.9-2.el6 1 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12301/zabbix-1.8.18-2.el6 1 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12299/lynis-1.3.6-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing curlpp-0.7.3-5.el6 docker-io-0.7.1-1.el6 gimp-separate+-0.5.8-10.el6 mirrorbrain-2.17.0-4.el6 opus-1.1-1.el6 php-twig-Twig-1.15.0-1.el6 php-twig-ctwig-1.15.0-1.el6 puppet-2.7.23-2.el6 python-fmn-web-0.1.4-2.el6 qt5-qtbase-5.2.0-0.12.rc1.el6 qt5-qtdeclarative-5.2.0-0.11.rc1.el6 qt5-qtdoc-5.2.0-0.10.rc1.el6 qt5-qtgraphicaleffects-5.2.0-0.10.rc1.el6 qt5-qtimageformats-5.2.0-0.10.rc1.el6 qt5-qtmultimedia-5.2.0-0.10.rc1.el6 qt5-qtquick1-5.2.0-0.10.rc1.el6 qt5-qtquickcontrols-5.2.0-0.10.rc1.el6 qt5-qtscript-5.2.0-0.10.rc1.el6 qt5-qtsvg-5.2.0-0.10.rc1.el6 qt5-qttools-5.2.0-0.10.rc1.el6 qt5-qttranslations-5.2.0-0.10.rc1.el6 qt5-qtwebkit-5.2.0-0.10.rc1.el6 qt5-qtxmlpatterns-5.2.0-0.10.rc1.el6 Details about builds: curlpp-0.7.3-5.el6 (FEDORA-EPEL-2013-12311) A C++ wrapper for libcURL Update Information: Fixed config.h mess ChangeLog: * Thu Dec 5 2013 Veeti Paananen veeti.paana...@rojekti.fi - 0.7.3-5 - Remove config.h - Fix build flags References: [ 1 ] Bug #1038561 - curlpp-devel does not include curlpp/config.h https://bugzilla.redhat.com/show_bug.cgi?id=1038561 docker-io-0.7.1-1.el6 (FEDORA-EPEL-2013-12313) Automates deployment of containerized applications Update Information: update to upstream 0.7.1 ChangeLog: * Fri Dec 6 2013 Vincent Batts vba...@redhat.com - 0.7.1-1 - upstream release of v0.7.1 gimp-separate+-0.5.8-10.el6 (FEDORA-EPEL-2013-12318) Rudimentary CMYK support for The GIMP Update Information: New package containing rudimentary CMYK support for The GIMP. New package containing rudimentary CMYK support for The GIMP. References: [ 1 ] Bug #1038024 - Wrong directory for gimp-separate+ https://bugzilla.redhat.com/show_bug.cgi?id=1038024 [ 2 ] Bug #34 - wrong permissions of /usr/doc/gimp-manual* https://bugzilla.redhat.com/show_bug.cgi?id=34 [ 3 ] Bug #913289 - Review Request: gimp-separate+ - A plug-in providing rudimentary CMYK support for The GIMP https://bugzilla.redhat.com/show_bug.cgi?id=913289 [ 4 ] Bug #35 - Bugs in /etc/rc.d/init.d/gated script https://bugzilla.redhat.com/show_bug.cgi?id=35 mirrorbrain-2.17.0-4.el6 (FEDORA-EPEL-2013-12312) A download redirector and metalink generator Update Information: New package inclusion. References: [ 1 ] Bug #1035935 - Review Request: mirrorbrain - A download redirector and metalink generator https://bugzilla.redhat.com/show_bug.cgi?id=1035935
Re: FTBFS if -Werror=format-security flag is used
On 12/05/2013 07:43 PM, Jan Lieskovsky wrote: From: Ralf Corsepius Would you mind to explain why you guys are putting such an emphasize on -Wformat-security? Some possible ways how to look at it: * because when all reported packages are patched, it would remove one whole class of security flaws, Iff the tools being utilized were reliable and if the findings are fixed by skilled people, who really understand what they are doing. Both does NOT APPLY in Fedora. Fedora/RH's GCC produces false diagnoses and the average Fedora packager is not an experienced C-developer. = Feel free to apply -W if you feel like it, but do not use -Werror. Besides this: Appending -Werror to CFLAGS breaks configure scripts, which are applying compile-checks, to destinguish a system features. The fact nobody so far seems to be aware about this seriously worries me. Sure, there are some serious cases, but ... there are many more further spread issues in C/C++-sources which people have been ignoring ever since Fedora and RH Linux distros exist. If we did (as you said), it shouldn't be used as an excuse / argument for continuing doing so. One example: Go after type-size or with uninitialized variables issues. You'd be surprized how many packages are having serious issues with this, how difficult fixing these issues can be on occasion. The fatal trap lurking inside is 100% of all fixes appear to be trivial, while a small percentage actually isn't. Finding these is challenging to experienced coders/developers and definitely far beyond the skills of an average Fedora packager. IMO, -Wformat-security is almost negibile in comparison to these and you are making way too much noise about it than it deserves. http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=format+string [*] Yeah, a vulnerability - So what? I'd guess the number and severity of vulnerabilities caused by TmpOnTmpfs, defective SELinux-configurations and systemd are much severe, not worth mentioning those caused by e.g. dirty usage of type-sizes in C-code. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
Am 06.12.2013 10:37, schrieb Ralf Corsepius: IMO, -Wformat-security is almost negibile in comparison to these and you are making way too much noise about it than it deserves. http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=format+string [*] Yeah, a vulnerability - So what? I'd guess the number and severity of vulnerabilities caused by TmpOnTmpfs how should TmpOnTmpfs cause a vulerability? the opposite is true signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
ABRT in the comps group 'standard'
Hello, I'd like to add abrt-cli package to the comps group 'standard'. The package pulls core ABRT functionality for catching C/C++ crashes, uncaught Python exceptions, Kernel oopses and VMCore processing. There is a bugzilla bug requesting this change: https://bugzilla.redhat.com/show_bug.cgi?id=1025222 I'd like to hear your opinion about that. Regards, Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
On Fri, 2013-12-06 at 10:37 +0100, Ralf Corsepius wrote: On 12/05/2013 07:43 PM, Jan Lieskovsky wrote: From: Ralf Corsepius Would you mind to explain why you guys are putting such an emphasize on -Wformat-security? Some possible ways how to look at it: * because when all reported packages are patched, it would remove one whole class of security flaws, Iff the tools being utilized were reliable and if the findings are fixed by skilled people, who really understand what they are doing. Both does NOT APPLY in Fedora. Fedora/RH's GCC produces false diagnoses and the average Fedora packager is not an experienced C-developer. The intent is not for Fedora packagers to patch problems downstream, it is for them to report bugs upstream and have the problems fixed there. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
Am 06.12.2013 11:30, schrieb Adam Williamson: On Fri, 2013-12-06 at 10:37 +0100, Ralf Corsepius wrote: On 12/05/2013 07:43 PM, Jan Lieskovsky wrote: From: Ralf Corsepius Would you mind to explain why you guys are putting such an emphasize on -Wformat-security? Some possible ways how to look at it: * because when all reported packages are patched, it would remove one whole class of security flaws, Iff the tools being utilized were reliable and if the findings are fixed by skilled people, who really understand what they are doing. Both does NOT APPLY in Fedora. Fedora/RH's GCC produces false diagnoses and the average Fedora packager is not an experienced C-developer. The intent is not for Fedora packagers to patch problems downstream, it is for them to report bugs upstream and have the problems fixed there that's fine and a perfect solution if it happens in a timly manner but what is the plan if this does not work out for a unknown number of packages because upstream is not willing or able to fix it or only in a later release giving that the package is not buildable at all it should at least exists a clear rule to overwrite the flag for such cases because not buildable with -Werror=format-security should not result in throw a package out of the distribution or hold back a update which may fix a *real* security relevant bug but does not build signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ABRT in the comps group 'standard'
On 12/06/2013 09:56 AM, Jakub Filak wrote: Hello, I'd like to add abrt-cli package to the comps group 'standard'. The package pulls core ABRT functionality for catching C/C++ crashes, uncaught Python exceptions, Kernel oopses and VMCore processing. There is a bugzilla bug requesting this change: https://bugzilla.redhat.com/show_bug.cgi?id=1025222 I'd like to hear your opinion about that. I would say that abrt should not be installed et all unless user has agreed to it at install time. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F-20 Branched report: 20131206 changes
Compose started at Fri Dec 6 07:15:02 UTC 2013 Broken deps for armhfp -- [avro] avro-mapred-1.7.5-1.fc20.noarch requires hadoop-mapreduce avro-mapred-1.7.5-1.fc20.noarch requires hadoop-client [blueman] blueman-1.23-7.fc20.armv7hl requires obex-data-server = 0:0.4.3 blueman-1.23-7.fc20.armv7hl requires gvfs-obexftp [cloud-init] cloud-init-0.7.2-7.fc20.noarch requires dmidecode [cobbler] cobbler-2.4.0-2.fc20.noarch requires syslinux [fts] fts-server-3.1.1-1.fc20.armv7hl requires libactivemq-cpp.so.14 [ghc-hjsmin] ghc-hjsmin-devel-0.1.4.3-2.fc20.armv7hl requires ghc-devel(language-javascript-0.5.8-28fa88554adf134b03284de53334e91d) [gofer] ruby-gofer-0.75-4.fc20.noarch requires rubygem(qpid) = 0:0.16.0 [gtkd] gtkd-geany-tags-2.0.0-29.20120815git9ae9181.fc18.noarch requires gtkd = 0:2.0.0-29.20120815git9ae9181.fc18 [kawa] 1:kawa-1.11-5.fc19.armv7hl requires servlet25 [koji] koji-vm-1.8.0-2.fc20.noarch requires python-virtinst [kyua-cli] kyua-cli-0.5-3.fc19.armv7hl requires liblutok.so.0 kyua-cli-tests-0.5-3.fc19.armv7hl requires liblutok.so.0 [msp430-libc] msp430-libc-20120224-2.fc19.noarch requires msp430-gcc = 0:4.6.3 [nifti2dicom] nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtksys.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkWidgets.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkVolumeRendering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkViews.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkTextAnalysis.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkRendering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkParallel.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkInfovis.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkImaging.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkIO.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkHybrid.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGraphics.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGeovis.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGenericFiltering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkFiltering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkCommon.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkCharts.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libQVTK.so.5.10 [nocpulse-common] nocpulse-common-2.2.7-2.fc20.noarch requires perl(RHN::DBI) [openbox] gdm-control-3.5.2-2.fc20.armv7hl requires gnome-panel gnome-panel-control-3.5.2-2.fc20.armv7hl requires gnome-panel [openpts] openpts-0.2.6-7.fc20.armv7hl requires tboot [owncloud] owncloud-5.0.13-1.fc20.noarch requires php-pear(pear.symfony.com/Routing) [perl-Language-Expr] perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) [php-Assetic] php-Assetic-1.1.2-1.fc20.noarch requires php-pear(pear.symfony.com/Process) 0:3.0 php-Assetic-1.1.2-1.fc20.noarch requires php-pear(pear.symfony.com/Process) = 0:2.1 [php-Metadata] php-Metadata-1.5.0-1.fc20.noarch requires php-pear(pear.symfony.com/DependencyInjection) [php-SymfonyCmfRouting] php-SymfonyCmfRouting-1.1.0-1.fc20.noarch requires php-pear(pear.symfony.com/Routing) 0:3.0 php-SymfonyCmfRouting-1.1.0-1.fc20.noarch requires php-pear(pear.symfony.com/Routing) = 0:2.2 php-SymfonyCmfRouting-1.1.0-1.fc20.noarch requires php-pear(pear.symfony.com/HttpKernel) 0:3.0 php-SymfonyCmfRouting-1.1.0-1.fc20.noarch requires php-pear(pear.symfony.com/HttpKernel) = 0:2.2 php-SymfonyCmfRouting-1.1.0-1.fc20.noarch requires php-pear(pear.symfony.com/EventDispatcher) 0:3.0 php-SymfonyCmfRouting-1.1.0-1.fc20.noarch requires php-pear(pear.symfony.com/EventDispatcher) = 0:2.2 [php-doctrine-DoctrineDBAL] php-doctrine-DoctrineDBAL-2.3.4-4.fc20.noarch requires php-pear(pear.symfony.com/Console) 0:3.0 php-doctrine-DoctrineDBAL-2.3.4-4.fc20.noarch requires php-pear(pear.symfony.com/Console) = 0:2.0 [php-doctrine-DoctrineORM] php-doctrine-DoctrineORM-2.3.3-2.fc20.noarch requires php-pear(pear.symfony.com/Yaml) 0:3.0 php-doctrine-DoctrineORM-2.3.3-2.fc20.noarch requires php-pear(pear.symfony.com/Yaml) = 0:2.0 php-doctrine-DoctrineORM-2.3.3-2.fc20.noarch requires php-pear(pear.symfony.com/Console) 0:3.0 php-doctrine-DoctrineORM-2.3.3-2.fc20.noarch requires php-pear(pear.symfony.com/Console) = 0:2.0 [php-guzzle-Guzzle] php-guzzle-Guzzle-3.7.4-2.fc20.noarch requires php-pear(pear.symfony.com/EventDispatcher) = 0:2.1.0 [php-phpunit-DbUnit] php-phpunit-DbUnit-1.3.0-1.fc20.noarch requires
Re: FTBFS if -Werror=format-security flag is used
On 12/06/13 at 11:57am, Reindl Harald wrote: but what is the plan if this does not work out for a unknown number of packages because upstream is not willing or able to fix it or only in a later release giving that the package is not buildable at all Contingency mechanism: Revert changes to redhat-rpm-config package and do a mass build. https://fedoraproject.org/wiki/Changes/FormatSecurity#Contingency_Plan There is still plenty of time left before this flag is even enabled in rawhide configuration by default. https://fedorahosted.org/fesco/ticket/1185#comment:14 ... This does not mean that you can slack off (kidding). Let me know if you want some help with the patches. -- Dhiru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
On 12/06/2013 11:30 AM, Adam Williamson wrote: On Fri, 2013-12-06 at 10:37 +0100, Ralf Corsepius wrote: On 12/05/2013 07:43 PM, Jan Lieskovsky wrote: From: Ralf Corsepius Would you mind to explain why you guys are putting such an emphasize on -Wformat-security? Some possible ways how to look at it: * because when all reported packages are patched, it would remove one whole class of security flaws, Iff the tools being utilized were reliable and if the findings are fixed by skilled people, who really understand what they are doing. Both does NOT APPLY in Fedora. Fedora/RH's GCC produces false diagnoses and the average Fedora packager is not an experienced C-developer. The intent is not for Fedora packagers to patch problems downstream, it is for them to report bugs upstream and have the problems fixed there. What world are you living in? gcc fixes have always been fixed in Fedora first. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ABRT in the comps group 'standard'
On 12/06/2013 12:14 PM, Jóhann B. Guðmundsson wrote: I would say that abrt should not be installed et all unless user has agreed to it at install time. +1 My mother would be puzzled, if ABRT would popup on her Fedora box. -- Miroslav Suchy, RHCE, RHCDS Red Hat, Software Engineer, #brno, #devexp, #fedora-buildsys -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
On 12/06/2013 12:25 PM, Brendan Jones wrote: On 12/06/2013 11:30 AM, Adam Williamson wrote: On Fri, 2013-12-06 at 10:37 +0100, Ralf Corsepius wrote: On 12/05/2013 07:43 PM, Jan Lieskovsky wrote: From: Ralf Corsepius Would you mind to explain why you guys are putting such an emphasize on -Wformat-security? Some possible ways how to look at it: * because when all reported packages are patched, it would remove one whole class of security flaws, Iff the tools being utilized were reliable and if the findings are fixed by skilled people, who really understand what they are doing. Both does NOT APPLY in Fedora. Fedora/RH's GCC produces false diagnoses and the average Fedora packager is not an experienced C-developer. The intent is not for Fedora packagers to patch problems downstream, it is for them to report bugs upstream and have the problems fixed there. What world are you living in? gcc fixes have always been fixed in Fedora first. Please ignore all my replies in this thread. I am just busy and annoyed. This came at the wrong time. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
On 12/04/13 at 07:10pm, Brendan Jones wrote:
This is just a pain. Can someone explain to me why this is good?
Original Message
Subject: [Bug 1037125] hydrogen FTBFS if -Werror=format-security flag is
https://bugzilla.redhat.com/show_bug.cgi?id=1037125
Hi Brendan,
Can you *really* pass a QByteArray object directly to printf (and similar
functions)?
I have attached a patch to fix this FTBFS bug. I can't say if the fix is
right (I don't know the code in question). Please give it a thought.
...
I had originally planned on submitting patches too but I got caught up
in a new project of mine.
--
Dhiru
diff --git a/libs/hydrogen/src/object.cpp b/libs/hydrogen/src/object.cpp
index a75be58..3e3815d 100644
--- a/libs/hydrogen/src/object.cpp
+++ b/libs/hydrogen/src/object.cpp
@@ -239,9 +239,9 @@ void* loggerThread_func( void* param )
QString tmpString;
for( it = last = queue.begin() ; it != queue.end() ; ++it ) {
last = it;
- printf( it-toLocal8Bit() );
+ printf( %s, it-toLocal8Bit().data() );
if( pLogFile ) {
- fprintf( pLogFile, it-toLocal8Bit() );
+ fprintf( pLogFile, %s,
it-toLocal8Bit().data() );
fflush( pLogFile );
}
}
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
On 12/06/2013 12:59 PM, Dhiru Kholia wrote: On 12/04/13 at 07:10pm, Brendan Jones wrote: This is just a pain. Can someone explain to me why this is good? Original Message Subject: [Bug 1037125] hydrogen FTBFS if -Werror=format-security flag is https://bugzilla.redhat.com/show_bug.cgi?id=1037125 Hi Brendan, Can you *really* pass a QByteArray object directly to printf (and similar functions)? I have attached a patch to fix this FTBFS bug. I can't say if the fix is right (I don't know the code in question). Please give it a thought. ... I had originally planned on submitting patches too but I got caught up in a new project of mine. -- Dhiru Point taken. 10 FTBS's just makes my brain explode. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
On 12/06/2013 12:59 PM, Dhiru Kholia wrote: Can you *really* pass a QByteArray object directly to printf (and similar functions)? Yes, as the format string argument, because the user-defined conversion comparison operator to const char * kicks in. -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
On 12/06/2013 01:26 PM, Florian Weimer wrote: On 12/06/2013 12:59 PM, Dhiru Kholia wrote: Can you *really* pass a QByteArray object directly to printf (and similar functions)? Yes, as the format string argument, because the user-defined conversion comparison operator to const char * kicks in. Eh, conversion operator. (I'm adding an RPM version type to PostgreSQL right now, with proper comparison operators, hence the confusion.) -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ABRT in the comps group 'standard'
Dne 6.12.2013 12:39, Miroslav Suchý napsal(a): On 12/06/2013 12:14 PM, Jóhann B. Guðmundsson wrote: I would say that abrt should not be installed et all unless user has agreed to it at install time. +1 My mother would be puzzled, if ABRT would popup on her Fedora box. Your mother will be puzzled with crashing application as well. Better to explain ABRT and have less crashing applications then the opposite. Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ABRT in the comps group 'standard'
On Pá 6. prosinec 2013, 12:39:09 CET, Miroslav Suchý wrote: On 12/06/2013 12:14 PM, Jóhann B. Guðmundsson wrote: I would say that abrt should not be installed et all unless user has agreed to it at install time. I think abrt serves as good source of info in case of unexpected crashes, which is quite important to have stable system. So although being puzzled is not very nice, being disappointed by crashing applications is much worse from my point of view. So try to look at it from broader perspective - I see more benefits in having abrt installed. +1 My mother would be puzzled, if ABRT would popup on her Fedora box. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ABRT in the comps group 'standard'
On 12/06/2013 01:59 PM, Václav Pavlín wrote: I think abrt serves as good source of info in case of unexpected crashes, which is quite important to have stable system. So although being puzzled is not very nice, being disappointed by crashing applications is much worse from my point of view. So try to look at it from broader perspective - I see more benefits in having abrt installed. While this is true - my mother have no clue what Bugzilla means, and even what is bug report - well in her term it is phone call to me Son, some weird box pop up, what should I do? I already hit Esc and Enter and it still sit there. This is disadvantage of being popular. Not every user is power user. -- Miroslav Suchy, RHCE, RHCDS Red Hat, Software Engineer, #brno, #devexp, #fedora-buildsys -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ABRT in the comps group 'standard'
On 12/06/2013 12:51 PM, Vít Ondruch wrote: Dne 6.12.2013 12:39, Miroslav Suchý napsal(a): On 12/06/2013 12:14 PM, Jóhann B. Guðmundsson wrote: I would say that abrt should not be installed et all unless user has agreed to it at install time. +1 My mother would be puzzled, if ABRT would popup on her Fedora box. Your mother will be puzzled with crashing application as well. Better to explain ABRT and have less crashing applications then the opposite. ABRT does not fix the application for his mother JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
On 12/05/2013 08:27 PM, Kevin Kofler wrote: The vast majority of those warnings are actually false positives, not actual security issues. Putting my upstream hat on, if asked to fix such a false positive, I'd do one of: (a) close the bug as INVALID/NOTABUG/WONTFIX or (b) hardcode -Wno-error=format-security -Wno-format-security in my build setup and close the bug as FIXED. They are potential security issues, because ignoring them (especially via (b)) sets everyone up for a fail. For instance, today it may be a constant format string, but tomorrow someone will introduce it as a settable configuration parameter. Given that pretty much all those cases can be solved by either %s or | __attribute__((__format__(__printf, 1, 2))); it|would||really look petulant to|insist on (a) or (b).| || -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ABRT in the comps group 'standard'
On 12/06/2013 01:05 PM, Miroslav Suchý wrote: On 12/06/2013 01:59 PM, Václav Pavlín wrote: I think abrt serves as good source of info in case of unexpected crashes, which is quite important to have stable system. So although being puzzled is not very nice, being disappointed by crashing applications is much worse from my point of view. Again reports are one thing fixing is another... So try to look at it from broader perspective - I see more benefits in having abrt installed. While this is true - my mother have no clue what Bugzilla means, and even what is bug report - well in her term it is phone call to me Son, some weird box pop up, what should I do? I already hit Esc and Enter and it still sit there. This is disadvantage of being popular. Not every user is power user. As well as those user not being able to sanitize their log(s) so they might accidentally be submitting sensitive information... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ABRT in the comps group 'standard'
On 12/06/2013 02:06 PM, Jóhann B. Guðmundsson wrote: On 12/06/2013 12:51 PM, Vít Ondruch wrote: Dne 6.12.2013 12:39, Miroslav Suchý napsal(a): On 12/06/2013 12:14 PM, Jóhann B. Guðmundsson wrote: I would say that abrt should not be installed et all unless user has agreed to it at install time. +1 My mother would be puzzled, if ABRT would popup on her Fedora box. Your mother will be puzzled with crashing application as well. Better to explain ABRT and have less crashing applications then the opposite. ABRT does not fix the application for his mother JBG Well, I also guess that his mother won't install Fedora on her computer by her self, so Mirek could uncheck the ABRT and tell Anaconda not to install it... --Jirka -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
On 12/06/2013 10:43 AM, Reindl Harald wrote: Am 06.12.2013 10:37, schrieb Ralf Corsepius: IMO, -Wformat-security is almost negibile in comparison to these and you are making way too much noise about it than it deserves. http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=format+string [*] Yeah, a vulnerability - So what? I'd guess the number and severity of vulnerabilities caused by TmpOnTmpfs how should TmpOnTmpfs cause a vulerability? the opposite is true TmpOnTmpfs is magitudes smaller than a traditional /tmp on /. This causes programs/packages which are assuming an almost infinitely sized /tmp to easily fill up a small /tmp, and thus the system to choke. 2 Real world examples I've encountered with fedora 18 and 19: * https://bugzilla.redhat.com/show_bug.cgi?id=971878 This one usually kills an individual's system. * https://bugzilla.redhat.com/show_bug.cgi?id=1006658 This means one means using convert on webserver allows arbitrary users on the web to kill servers. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ABRT in the comps group 'standard'
On 12/06/2013 12:14 PM, Jóhann B. Guðmundsson wrote: On 12/06/2013 09:56 AM, Jakub Filak wrote: Hello, I'd like to add abrt-cli package to the comps group 'standard'. The package pulls core ABRT functionality for catching C/C++ crashes, uncaught Python exceptions, Kernel oopses and VMCore processing. There is a bugzilla bug requesting this change: https://bugzilla.redhat.com/show_bug.cgi?id=1025222 I'd like to hear your opinion about that. I would say that abrt should not be installed et all unless user has agreed to it at install time. +1 Abort needs to remain opt-in (and remain fully uninstallable) Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ABRT in the comps group 'standard'
On 12/06/2013 02:08 PM, Jóhann B. Guðmundsson wrote: On 12/06/2013 01:05 PM, Miroslav Suchý wrote: On 12/06/2013 01:59 PM, Václav Pavlín wrote: I think abrt serves as good source of info in case of unexpected crashes, which is quite important to have stable system. So although being puzzled is not very nice, being disappointed by crashing applications is much worse from my point of view. Again reports are one thing fixing is another... So try to look at it from broader perspective - I see more benefits in having abrt installed. While this is true - my mother have no clue what Bugzilla means, and even what is bug report - well in her term it is phone call to me Son, some weird box pop up, what should I do? I already hit Esc and Enter and it still sit there. This is disadvantage of being popular. Not every user is power user. As well as those user not being able to sanitize their log(s) so they might accidentally be submitting sensitive information... JBG ABRT can be configured to not bother users with reporting to bugzilla and only send a stripped information about the crash without any sensitive information [1]. So no need for users to sanitize their logs. --Jirka [1] https://github.com/abrt/faf/wiki/uReport -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ABRT in the comps group 'standard'
Dne 6.12.2013 14:05, Miroslav Suchý napsal(a): On 12/06/2013 01:59 PM, Václav Pavlín wrote: I think abrt serves as good source of info in case of unexpected crashes, which is quite important to have stable system. So although being puzzled is not very nice, being disappointed by crashing applications is much worse from my point of view. So try to look at it from broader perspective - I see more benefits in having abrt installed. While this is true - my mother have no clue what Bugzilla means, and even what is bug report - well in her term it is phone call to me Son, some weird box pop up, what should I do? I already hit Esc and Enter and it still sit there. This is disadvantage of being popular. Not every user is power user. If I am not mistaken, ABRT can send ureports without any need to use BZ. And in G3, there popups just small notification. So you exaggerate a bit. Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ABRT in the comps group 'standard'
On 12/06/2013 02:10 PM, Ralf Corsepius wrote: On 12/06/2013 12:14 PM, Jóhann B. Guðmundsson wrote: On 12/06/2013 09:56 AM, Jakub Filak wrote: Hello, I'd like to add abrt-cli package to the comps group 'standard'. The package pulls core ABRT functionality for catching C/C++ crashes, uncaught Python exceptions, Kernel oopses and VMCore processing. There is a bugzilla bug requesting this change: https://bugzilla.redhat.com/show_bug.cgi?id=1025222 I'd like to hear your opinion about that. I would say that abrt should not be installed et all unless user has agreed to it at install time. +1 Abort needs to remain opt-in (and remain fully uninstallable) Ralf Care to share the reason why? At least the first part.. --Jirka -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ABRT in the comps group 'standard'
On 12/06/2013 01:59 PM, Václav Pavlín wrote: So try to look at it from broader perspective - I see more benefits in having abrt installed. Such as confidential business information being forwarded to RedHat and being snooped by the NSA to forward it to your enterprise's competitor? You might not have realized it, but the world has changed and become very intolerant towards any phone home functions. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ABRT in the comps group 'standard'
On 12/06/2013 01:14 PM, Vít Ondruch wrote: Dne 6.12.2013 14:05, Miroslav Suchý napsal(a): On 12/06/2013 01:59 PM, Václav Pavlín wrote: I think abrt serves as good source of info in case of unexpected crashes, which is quite important to have stable system. So although being puzzled is not very nice, being disappointed by crashing applications is much worse from my point of view. So try to look at it from broader perspective - I see more benefits in having abrt installed. While this is true - my mother have no clue what Bugzilla means, and even what is bug report - well in her term it is phone call to me Son, some weird box pop up, what should I do? I already hit Esc and Enter and it still sit there. This is disadvantage of being popular. Not every user is power user. If I am not mistaken, ABRT can send ureports without any need to use BZ. And in G3, there popups just small notification. So you exaggerate a bit. Popups on all desktop we ship? And how about embedded/server ( abrt outside desktop installs ) And what purpose does abrt serve if there aren't people fixing the issue it reports on the other end... No abrt should be opt-in not opt-out at install time. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ABRT in the comps group 'standard'
On 12/06/2013 02:14 PM, Jiri Moskovcak wrote: On 12/06/2013 02:10 PM, Ralf Corsepius wrote: On 12/06/2013 12:14 PM, Jóhann B. Guðmundsson wrote: On 12/06/2013 09:56 AM, Jakub Filak wrote: Hello, I'd like to add abrt-cli package to the comps group 'standard'. The package pulls core ABRT functionality for catching C/C++ crashes, uncaught Python exceptions, Kernel oopses and VMCore processing. There is a bugzilla bug requesting this change: https://bugzilla.redhat.com/show_bug.cgi?id=1025222 I'd like to hear your opinion about that. I would say that abrt should not be installed et all unless user has agreed to it at install time. +1 Abort needs to remain opt-in (and remain fully uninstallable) Ralf Care to share the reason why? At least the first part.. To leave users a choice of minimizing the risks of exposing their confidential and private data. To me, personally, the recent incidents with abrt have qualified abrt as not trustworthy and as a data privacy risk. I've banned it from my machines, because I do not trust abrt anymore. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ABRT in the comps group 'standard'
On 06.12.2013 14:34, Ralf Corsepius wrote: On 12/06/2013 02:14 PM, Jiri Moskovcak wrote: On 12/06/2013 02:10 PM, Ralf Corsepius wrote: On 12/06/2013 12:14 PM, Jóhann B. Guðmundsson wrote: On 12/06/2013 09:56 AM, Jakub Filak wrote: Hello, I'd like to add abrt-cli package to the comps group 'standard'. The package pulls core ABRT functionality for catching C/C++ crashes, uncaught Python exceptions, Kernel oopses and VMCore processing. There is a bugzilla bug requesting this change: https://bugzilla.redhat.com/show_bug.cgi?id=1025222 I'd like to hear your opinion about that. I would say that abrt should not be installed et all unless user has agreed to it at install time. +1 Abort needs to remain opt-in (and remain fully uninstallable) Ralf Care to share the reason why? At least the first part.. To leave users a choice of minimizing the risks of exposing their confidential and private data. To me, personally, the recent incidents with abrt have qualified abrt as not trustworthy and as a data privacy risk. I've banned it from my machines, because I do not trust abrt anymore. Ralf ABRT does not send *any* information unless you agree to do it. Not even the anonymous reports. It is true that the settings could be in Anaconda and I think it belongs in there. But at the very moment this is not happening, so ABRT asks you on first launch. It is not ABRT's fault that the majority of users blindly clicks Next, Next, Next and enables the automatic sending. Additionally, if you want to prevent business information leak, do not connect your machines directly to the Internet. This approach has been working perfectly for many years and I don't think much has changed in that area lately. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ABRT in the comps group 'standard'
On Fri, Dec 06, 2013 at 01:06:14PM +, Jóhann B. Guðmundsson wrote: My mother would be puzzled, if ABRT would popup on her Fedora box. Your mother will be puzzled with crashing application as well. Better to explain ABRT and have less crashing applications then the opposite. ABRT does not fix the application for his mother We all do fix the application for his mother, after it's reported by ABRT or any other means :-) -- Later, Lukas lzap Zapletal irc: lzap #theforeman -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ABRT in the comps group 'standard'
On 12/06/2013 01:47 PM, Lukas Zapletal wrote: We all do fix the application for his mother, after it's reported by ABRT or any other means:-) No not really our distribution is filled with just packagers that dont know what to do with those reports... ABRT should not be installed by default people that know and what to provide feedback can install it afterwards. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
Am 06.12.2013 14:08, schrieb Ralf Corsepius: On 12/06/2013 10:43 AM, Reindl Harald wrote: Am 06.12.2013 10:37, schrieb Ralf Corsepius: IMO, -Wformat-security is almost negibile in comparison to these and you are making way too much noise about it than it deserves. http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=format+string [*] Yeah, a vulnerability - So what? I'd guess the number and severity of vulnerabilities caused by TmpOnTmpfs how should TmpOnTmpfs cause a vulerability? the opposite is true TmpOnTmpfs is magitudes smaller than a traditional /tmp on / yes, i am also not a fan of this default, see the list-archives people who know and care about tmpfs did it long ago for their workloads the improved performance is a urban legend for common workloads This causes programs/packages which are assuming an almost infinitely sized /tmp to easily fill up a small /tmp, and thus the system to choke. which is not really a *security* problem that's why you should have not listed it in that context 2 Real world examples I've encountered with fedora 18 and 19: * https://bugzilla.redhat.com/show_bug.cgi?id=971878 This one usually kills an individual's system. see my comment https://bugzilla.redhat.com/show_bug.cgi?id=971878#c1 still not a security problem per se * https://bugzilla.redhat.com/show_bug.cgi?id=1006658 This means one means using convert on webserver allows arbitrary users on the web to kill servers if arbitary users are allowed to call CLI applications from a webserver you have a security problem and that is for sure *not* TmpOnTmpfs signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
On 12/06/2013 02:07 PM, Przemek Klosowski wrote: On 12/05/2013 08:27 PM, Kevin Kofler wrote: The vast majority of those warnings are actually false positives, not actual security issues. Putting my upstream hat on, if asked to fix such a false positive, I'd do one of: (a) close the bug as INVALID/NOTABUG/WONTFIX or (b) hardcode -Wno-error=format-security -Wno-format-security in my build setup and close the bug as FIXED. They are potential security issues, because ignoring them (especially via (b)) sets everyone up for a fail. In case these errors are bogus? For instance, today it may be a constant format string, but tomorrow someone will introduce it as a settable configuration parameter. Given that pretty much all those cases can be solved by either %s or == Forcing C-coders to using a special coding style to silence a broken tools warning on what is legitimate and correct code? printf(string) is legitimate C, forcing printf(%s, string) is just silly. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ABRT in the comps group 'standard'
On 12/06/2013 02:34 PM, Ralf Corsepius wrote: On 12/06/2013 02:14 PM, Jiri Moskovcak wrote: On 12/06/2013 02:10 PM, Ralf Corsepius wrote: On 12/06/2013 12:14 PM, Jóhann B. Guðmundsson wrote: On 12/06/2013 09:56 AM, Jakub Filak wrote: Hello, I'd like to add abrt-cli package to the comps group 'standard'. The package pulls core ABRT functionality for catching C/C++ crashes, uncaught Python exceptions, Kernel oopses and VMCore processing. There is a bugzilla bug requesting this change: https://bugzilla.redhat.com/show_bug.cgi?id=1025222 I'd like to hear your opinion about that. I would say that abrt should not be installed et all unless user has agreed to it at install time. +1 Abort needs to remain opt-in (and remain fully uninstallable) Ralf Care to share the reason why? At least the first part.. To leave users a choice of minimizing the risks of exposing their confidential and private data. To me, personally, the recent incidents with abrt have qualified abrt as not trustworthy and as a data privacy risk. I've banned it from my machines, because I do not trust abrt anymore. Care to share what the recent incidents means? This information might be useful to avoid such incidents in the future. --Jirka Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ABRT in the comps group 'standard'
On 06.12.2013 14:51, Jóhann B. Guðmundsson wrote: On 12/06/2013 01:47 PM, Lukas Zapletal wrote: We all do fix the application for his mother, after it's reported by ABRT or any other means:-) No not really our distribution is filled with just packagers that dont know what to do with those reports... ABRT should not be installed by default people that know and what to provide feedback can install it afterwards. JBG So they know what to do with hand-made bugs, but do not know what to do with ABRT bugs? That seems like something that could be fixed on ABRT side. Otherwise your argument is invalid. Having an overall idea of how often do people encounter problems is quite useful regardless of the fact that the maintainer will never care. Being able to identify the most frustrating problems based on real stats is much better than rely on Severity field in Bugzilla that is in many cases blindly set to high/urgent (if the Bugzilla is even filed within a finite time frame). I agree that Bugzilla is not very suitable to receive a massive amount automatic reports, but that is a subject for another discussion [1]. If a packager really does not want to receive ABRT bugzillas for his component, he can easily tune libreport to create a not-reportable file which will disable the reporting feature [2]. This way he will not be bothered by bug reports and at the same time the stats about his application can be collected. Additionally this can give a clue that even if the application is crashing to a lot of people, the maintainer is not going to do much about that. Michal [1] https://fedoraproject.org/wiki/Infrastructure_Fedora_bug_tracker [2] http://mtoman.fedorapeople.org/raw/notreportable.png -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
On 12/06/2013 02:57 PM, Reindl Harald wrote: Am 06.12.2013 14:08, schrieb Ralf Corsepius: On 12/06/2013 10:43 AM, Reindl Harald wrote: Am 06.12.2013 10:37, schrieb Ralf Corsepius: IMO, -Wformat-security is almost negibile in comparison to these and you are making way too much noise about it than it deserves. http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=format+string [*] Yeah, a vulnerability - So what? I'd guess the number and severity of vulnerabilities caused by TmpOnTmpfs how should TmpOnTmpfs cause a vulerability? the opposite is true TmpOnTmpfs is magitudes smaller than a traditional /tmp on / yes, i am also not a fan of this default, see the list-archives people who know and care about tmpfs did it long ago for their workloads the improved performance is a urban legend for common workloads This causes programs/packages which are assuming an almost infinitely sized /tmp to easily fill up a small /tmp, and thus the system to choke. which is not really a *security* problem In first place it's a denial of service problem. Once /tmp is filled up all kind of weird issues pop up and are causing all kind of malfunctions. 2 Real world examples I've encountered with fedora 18 and 19: * https://bugzilla.redhat.com/show_bug.cgi?id=971878 This one usually kills an individual's system. see my comment https://bugzilla.redhat.com/show_bug.cgi?id=971878#c1 still not a security problem per se Correct, it's a DOS problem. * https://bugzilla.redhat.com/show_bug.cgi?id=1006658 This means one means using convert on webserver allows arbitrary users on the web to kill servers if arbitary users are allowed to call CLI applications from a webserver ?!? Calling cli-tools underneath of webservices is the norm on many webservers. Often these calls are wrapped into scripting languages, be they perl, python or php. you have a security problem and that is for sure *not* TmpOnTmpfs TmpOnTmpfs opens opportunities for DOS attacks which do not exist with TmpOnFS. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ABRT in the comps group 'standard'
On 12/06/2013 02:45 PM, Michal Toman wrote: On 06.12.2013 14:34, Ralf Corsepius wrote: On 12/06/2013 02:14 PM, Jiri Moskovcak wrote: ABRT does not send *any* information unless you agree to do it. Not even the anonymous reports. It is true that the settings could be in Anaconda and I think it belongs in there. But at the very moment this is not happening, so ABRT asks you on first launch. It is not ABRT's fault that the majority of users blindly clicks Next, Next, Next and enables the automatic sending. Additionally, if you want to prevent business information leak, do not connect your machines directly to the Internet. I am talking not talking about highsecurity machines. I am talking about abrt passing on password, ips, filenames etc, This approach has been working perfectly for many years and I don't think much has changed in that area lately. There were reports of abrt sending out private and confidential information to the net and reports of abrt sending reports without inspection. I've seen the later happening to myself. I've seen many crashes of abrt itself - I.e. abrt is not working perfectly at all. To cut a long story short: To me, abrt the plague: As a user, as a package maintainer and as sysadmin. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1018330] Please build for EPEL-6
https://bugzilla.redhat.com/show_bug.cgi?id=1018330 --- Comment #1 from Iain Arnell iarn...@gmail.com --- Unfortunately, I don't have time any more - please feel free to request branch and maintain yourself. -- 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=2VQvuwPSZsa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: ABRT in the comps group 'standard'
On 12/06/2013 04:07 PM, Ralf Corsepius wrote: On 12/06/2013 02:45 PM, Michal Toman wrote: On 06.12.2013 14:34, Ralf Corsepius wrote: On 12/06/2013 02:14 PM, Jiri Moskovcak wrote: ABRT does not send *any* information unless you agree to do it. Not even the anonymous reports. It is true that the settings could be in Anaconda and I think it belongs in there. But at the very moment this is not happening, so ABRT asks you on first launch. It is not ABRT's fault that the majority of users blindly clicks Next, Next, Next and enables the automatic sending. Additionally, if you want to prevent business information leak, do not connect your machines directly to the Internet. I am talking not talking about highsecurity machines. I am talking about abrt passing on password, ips, filenames etc, This approach has been working perfectly for many years and I don't think much has changed in that area lately. There were reports of abrt sending out private and confidential information to the net and reports of abrt sending reports without inspection. - were are those reports? I've seen the later happening to myself. I've seen many crashes of abrt itself - I.e. abrt is not working perfectly at all. - that's interesting observation and quality indicator, because I've seen the following components crash a lot: - gnome-shell - blueman - kernel - pulseaudion - firefox - tracker - nautilus .. quite a long list of other components . - so ABRT doesn't seem to perform any worse than the other components in Fedora... To cut a long story short: To me, abrt the plague: As a user, as a package maintainer and as sysadmin. To cut the long story short - Thank you very much for your specific examples of such behavior, it's very helpful and the ABRT devels can react properly and fix these problems. --Jirka Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
On 12/06/2013 12:26 PM, Dhiru Kholia wrote: On 12/06/13 at 11:57am, Reindl Harald wrote: but what is the plan if this does not work out for a unknown number of packages because upstream is not willing or able to fix it or only in a later release giving that the package is not buildable at all Contingency mechanism: Revert changes to redhat-rpm-config package and do a mass build. This would be a very rude abuse of governmental powers. https://fedoraproject.org/wiki/Changes/FormatSecurity#Contingency_Plan How about rowing back and bury this plan for the time being until GCC has become more reliable ? There is still plenty of time left before this flag is even enabled in rawhide configuration by default. IMO, this plan has failed - period. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Base] Fedora Base Design Working Group (2013-12-06) meeting minutes and logs
Main topic we covered today was the janitorial work for Base related packages to do a build requires cleanup in the coming months. I'll be sending out a separate email about that on Monday to explain the ins and outs and hopefully with a bit more info/queries/statistics about the whole idea. And as usual, if anyone wants to help/participate/comment etc feel free to get in contact with us. Meeting ended Fri Dec 6 15:56:13 2013 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2013-12-06/fedora_base_design_working_group.2013-12-06-15.01.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2013-12-06/fedora_base_design_working_group.2013-12-06-15.01.txt Log: http://meetbot.fedoraproject.org/fedora-meeting/2013-12-06/fedora_base_design_working_group.2013-12-06-15.01.log.html Please remember to CC: meetingminu...@lists.fedoraproject.org on your summary/minutes email. Thanks regards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Manager Core Services| Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch pknir...@redhat.com Wankelstrasse 5 | Web: http://www.redhat.com/ D-70563 Stuttgart, Germany -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
On Fri, 2013-12-06 at 02:21 +0100, Kevin Kofler wrote: QString line; line.fill( '-', 60 ); qDebug( line.ascii() ); As you can see, the format string being passed here is provably constant. So fix the compiler. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Test-Announce] systemd-208-9.fc20 package in f20 unsigned
Greetings. systemd-208-9.fc20 was pushed into the base fedora 20 repos last night (as it fixed a blocker bug for the upcoming release). However, it was not signed properly, so Fedora 20 prerelease users will see an error about the package not being signed. This has already been corrected and the signed package will be in tomorrow's branched compose. Please wait for that compose to update, or if you need to test that the blocker is fixed, you can use --nogpgcheck to upgrade to the new package. Thanks, kevin signature.asc Description: PGP signature ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: pl license change
Petr Pisar wrote: On 2013-12-04, Kevin Kofler kevin.kof...@chello.at wrote: Petr Pisar wrote: [snip] and GPLv2 and GPLv3+. Huh? WTF is upstream smoking there? Upstream releases a tar ball bundling a lot of subprojects. Thus the complicated license. I do a licence review each new release and I always find new licenses. This time I had to drop two files because of non-commercial requirement. My main complaint there was about the mix of incompatible GPL versions. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Reopening: Q: webfonts:
On Mon, Dec 2, 2013 at 8:33 AM, Petr Vobornik pvobo...@redhat.com wrote: This solution is much nicer and can be used by other font packages as well. Here's the new package: https://bugzilla.redhat.com/show_bug.cgi?id=1036754 Very awesome, thanks! I'll sponsor you and review. :-) Luckily, I pushed off the web assets stuff for F21, so I can now add embedding to the list of things to check and file bugs for when I do that for the licensing metadata. I'm going to be doing that real soon now, so if there are any other issues that all the fonts in the distro need to be checked for, please speak up soon! I'll also ask FPC to add a mention of this to the font guidelines so future fonts added to the distribution will have this bit set correctly. -T.C. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
Ralf Corsepius wrote: On 12/06/2013 12:26 PM, Dhiru Kholia wrote: There is still plenty of time left before this flag is even enabled in rawhide configuration by default. IMO, this plan has failed - period. +1 Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
PS: Przemek Klosowski wrote: | __attribute__((__format__(__printf, 1, 2))); is also compiler-specific, which some upstreams also won't like. Of course, it can be #ifdef-wrapped, but many upstreams try to avoid #ifdef as much as possible. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
Przemek Klosowski wrote: Given that pretty much all those cases can be solved by either %s or | __attribute__((__format__(__printf, 1, 2))); pretty much all maybe, but not all! See e.g. the examples I have given in the FESCo ticket: * a printf wrapper for logging which adds a timestamp in front of the format string, e.g. log(processed %d items, foo); which would be printed as 2013-12-06 19:00:00: processed 123 items to some logfile (using vfprintf with a format string like 2013-12-06 19:00:00: processed %d items concatenated at runtime). * translatable format strings, e.g. printf(translate(processed %d items), foo); Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ABRT in the comps group 'standard'
On Fri, Dec 6, 2013 at 10:56 AM, Jakub Filak jfi...@redhat.com wrote: I'd like to add abrt-cli package to the comps group 'standard'. The package pulls core ABRT functionality for catching C/C++ crashes, uncaught Python exceptions, Kernel oopses and VMCore processing. If -cli means no GUI, and thus no popups where the user can opt in to reporting data, what would the installed packages actually _do_ by default, without intentional configuration by user? Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
Adam Jackson wrote: On Fri, 2013-12-06 at 02:21 +0100, Kevin Kofler wrote: QString line; line.fill( '-', 60 ); qDebug( line.ascii() ); As you can see, the format string being passed here is provably constant. So fix the compiler. I don't think GCC will ever be able to prove that it is a constant. It would at least have to do intermodule inlining on the linked qstring.o to do that, which means qt3 would have to use the LTO support. Even then, I wouldn't count on it. Plus, if this construct were found in application code rather than in qt3 itself, GCC would even have to do the intermodule inlining on libqt-mt, which would also have negative consequences on binary compatibility. But knowing the contract of QString (Qt 3's in this case, but it's the same in Qt 4 and Qt 5), it's trivial for a human to prove it. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
Ben Boeckel wrote: Use the printf attribute on the function to fix this. That doesn't work if I have to prepend a date to my format string. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
mrnuke (mr.nuke...@gmail.com) said: Because packagers will just ignore it [...] I think this is a childish argument, but let's take it. So what? You're going to start stepping on people's lawns and change things just because you want to impose your greater good? Wow, nice mixed metaphor. Package maintenance is not a person's private domain; it's where we're signing up to maintain things as part of a community *as a service to the users that use what we produce*. Now, people do have different views on how some of these things may be handled, but the goals of Fedora have never been to focus primarily on the convenience of the packager - that's rather shortsighted. The point is to ensure that the software we provide to *users* doesn't contain security holes due to accident, intransigence, or other reasons. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
On Fri, Dec 6, 2013 at 4:50 PM, Ralf Corsepius rc040...@freenet.de wrote: On 12/06/2013 12:26 PM, Dhiru Kholia wrote: On 12/06/13 at 11:57am, Reindl Harald wrote: but what is the plan if this does not work out for a unknown number of packages because upstream is not willing or able to fix it or only in a later release giving that the package is not buildable at all Contingency mechanism: Revert changes to redhat-rpm-config package and do a mass build. This would be a very rude abuse of governmental powers. I don't understand how a plan for what to do if the change proves impossible or impractical is an abuse. There is still plenty of time left before this flag is even enabled in rawhide configuration by default. IMO, this plan has failed - period. Can we talk numbers instead of adjectives, please? Out of the ~400 packages (and much more cases of the warning), I have reviewed about 10 prior to voting on this, and _all_ were incorrect (not necessarily insecure, but incorrect). So far I've seen precisely 3 cases (not 3 packages) where there was a false positive (a printf format with a provably constant string). How prevalent is this really? If we ended up with -Werror=... _completely eliminating_ a class of programming bugs, now and for the future, and the cost were that ~5 packages out of 10k needed a workaround, that would be well worth it IMHO. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ABRT in the comps group 'standard'
Miroslav Suchý (msu...@redhat.com) said: On 12/06/2013 01:59 PM, Václav Pavlín wrote: I think abrt serves as good source of info in case of unexpected crashes, which is quite important to have stable system. So although being puzzled is not very nice, being disappointed by crashing applications is much worse from my point of view. So try to look at it from broader perspective - I see more benefits in having abrt installed. While this is true - my mother have no clue what Bugzilla means, and even what is bug report - well in her term it is phone call to me Son, some weird box pop up, what should I do? I already hit Esc and Enter and it still sit there. Well... 1) the abrt GUI is already included in multiple desktop environments 2) this request is about putting the daemon/recording functionality in the standard install; the GUI integration is a separate package In short: I do not think this proposed change affects the behavior of any of the desktops in terms of crash popups. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
On Fri, Dec 06, 2013 at 07:57:04PM +0100, Kevin Kofler wrote: Ralf Corsepius wrote: On 12/06/2013 12:26 PM, Dhiru Kholia wrote: There is still plenty of time left before this flag is even enabled in rawhide configuration by default. IMO, this plan has failed - period. +1 In the meantime, some of us fixed reported issues, got the patch merged upstream and rebuild affected packages. -- Tomasz Torcz Never underestimate the bandwidth of a station xmpp: zdzich...@chrome.plwagon filled with backup tapes. -- Jim Gray -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
On Fri, Dec 6, 2013 at 8:02 PM, Kevin Kofler kevin.kof...@chello.at wrote: See e.g. the examples I have given in the FESCo ticket: * a printf wrapper for logging which adds a timestamp in front of the format string, e.g. log(processed %d items, foo); which would be printed as 2013-12-06 19:00:00: processed 123 items to some logfile (using vfprintf with a format string like 2013-12-06 19:00:00: processed %d items concatenated at runtime). Yes, this is a legitimate problem. (A workaround would be to do vfprintf with the original format string and _then_ concatenate, and I agree that it's not quite satisfactory.) I'm guessing that this is a fairly unusual way to implement this functionality - but I don't have data. * translatable format strings, e.g. printf(translate(processed %d items), foo); __attribute__ ((format_arg)), which is how gcc already knows about gettext(). (Actually, the logging wrapper case might also be solvable by doing the concatenation in a function with this atttribute... I'm not sure that it's much better.) Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
On Fri, Dec 06, 2013 at 08:02:06PM +0100, Kevin Kofler wrote:
* translatable format strings, e.g.
printf(translate(processed %d items), foo);
Translatable strings are handled just fine.
Try e.g.:
extern int my_printf (void *my_object, const char *my_format, ...)
__attribute__ ((format (printf, 2, 3)));
extern char *my_dgettext (char *my_domain, const char *my_format)
__attribute__ ((format_arg (2)));
void *p; char *q;
void
foo ()
{
my_printf (p, my_dgettext (q, abcd));
}
e.g. libintl.h already uses the right attributes, so you don't
get errors for this.
Jakub
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
On Fri, Dec 06, 2013 at 02:27:05AM +0100, Kevin Kofler wrote: Michael scherer wrote: Let's rather ask the contrary, why is this so much a issue to communicate with upstream to fix things, and add patches ? The vast majority of those warnings are actually false positives, not actual security issues. Putting my upstream hat on, if asked to fix such a false positive, I'd do one of: (a) close the bug as INVALID/NOTABUG/WONTFIX or (b) hardcode -Wno-error=format-security -Wno-format-security in my build setup and close the bug as FIXED. Additionally, some code (like my package, qpid-cpp) uses code that's generated by another app like Swig. We have no control over what that code is. So enabling this as an error would be unresolvable by our project and we'd be blocked until the Swig team decided to change their code generation bits. -- Darryl L. Pierce mcpie...@gmail.com http://mcpierce.fedorapeople.org/ What do you care what people think, Mr. Feynman? pgp8crJQn5N10.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ABRT in the comps group 'standard'
On Fri, 2013-12-06 at 16:07 +0100, Ralf Corsepius wrote: This approach has been working perfectly for many years and I don't think much has changed in that area lately. There were reports of abrt sending out private and confidential information to the net and reports of abrt sending reports without inspection. There was one particular crash which was leaking passwords in a way that made it very difficult for abrt to catch. I think there were two or three (not the vague two or three, but precisely either two, or three) reports affected. Pedro Francisco very smartly caught this and we locked down the affected bugs ASAP. I have never seen abrt sending reports without inspection. It starts out by popping up notifications that let you send a FAF report (which AIUI contains only the summary backtrace, and doesn't need inspection as there's no chance of it containing sensitive user data). I think there's a checkbox to have it send those FAF reports without showing a notification. But I don't believe it's possible for it to send out a full-on backtrace without the user explicitly requesting it via abrt-gui or abrt-cli. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ABRT in the comps group 'standard'
On Fri, 2013-12-06 at 12:39 +0100, Miroslav Suchý wrote: On 12/06/2013 12:14 PM, Jóhann B. Guðmundsson wrote: I would say that abrt should not be installed et all unless user has agreed to it at install time. +1 My mother would be puzzled, if ABRT would popup on her Fedora box. That's not relevant to this discussion. We're talking about abrt-cli in @standard, which is a console utility. Your mother (i.e. an avatar for some inexperienced user) is unlikely to encounter it: it does not 'pop up' anywhere. (note, also, that since F19, abrt notifications don't run abrt-gui at all. They just notify you that something crashed. If you 'submit a report', it only sends it to faf. I don't much like this behaviour, but at least it's not confusing anyone's mother.) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ABRT in the comps group 'standard'
On Fri, 2013-12-06 at 13:18 +, Jóhann B. Guðmundsson wrote: And what purpose does abrt serve if there aren't people fixing the issue it reports on the other end... Well, that's easy enough to shoot down. https://bugzilla.redhat.com/buglist.cgi?bug_status=CLOSEDclassification=Fedoralimit=0list_id=1982726order=bug_id%20DESCquery_format=advancedresolution=ERRATAshort_desc=[abrt]short_desc_type=allwordssubstr 4,230 bugs with [abrt] in the summary have been closed as ERRATA since abrt was introduced. That's not nothing. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
On Fri, 2013-12-06 at 15:06 -0500, Darryl L. Pierce wrote: On Fri, Dec 06, 2013 at 02:27:05AM +0100, Kevin Kofler wrote: Michael scherer wrote: Let's rather ask the contrary, why is this so much a issue to communicate with upstream to fix things, and add patches ? The vast majority of those warnings are actually false positives, not actual security issues. Putting my upstream hat on, if asked to fix such a false positive, I'd do one of: (a) close the bug as INVALID/NOTABUG/WONTFIX or (b) hardcode -Wno-error=format-security -Wno-format-security in my build setup and close the bug as FIXED. Additionally, some code (like my package, qpid-cpp) uses code that's generated by another app like Swig. We have no control over what that code is. So enabling this as an error would be unresolvable by our project and we'd be blocked until the Swig team decided to change their code generation bits. So have you filed a bug against swig yet? ;) [ideally, attaching an example of the problematic generated code, and the inputs] Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ABRT in the comps group 'standard'
On Fri, Dec 06, 2013 at 12:08:22PM -0800, Adam Williamson wrote: On Fri, 2013-12-06 at 13:18 +, Jóhann B. Guðmundsson wrote: And what purpose does abrt serve if there aren't people fixing the issue it reports on the other end... Well, that's easy enough to shoot down. https://bugzilla.redhat.com/buglist.cgi?bug_status=CLOSEDclassification=Fedoralimit=0list_id=1982726order=bug_id%20DESCquery_format=advancedresolution=ERRATAshort_desc=[abrt]short_desc_type=allwordssubstr 4,230 bugs with [abrt] in the summary have been closed as ERRATA since abrt was introduced. That's not nothing. I can confirm that abrt reports have proven fruitful for systemd: quite a few crashes is special corner cases were caught and solved this way. Abrt reports contains full tracebacks *and* open-files lists, which can be great help. Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ABRT in the comps group 'standard'
On Fri, 2013-12-06 at 20:06 +0100, Miloslav Trmač wrote: On Fri, Dec 6, 2013 at 10:56 AM, Jakub Filak jfi...@redhat.com wrote: I'd like to add abrt-cli package to the comps group 'standard'. The package pulls core ABRT functionality for catching C/C++ crashes, uncaught Python exceptions, Kernel oopses and VMCore processing. If -cli means no GUI, and thus no popups where the user can opt in to reporting data, what would the installed packages actually _do_ by default, without intentional configuration by user? Mirek abrt-cli is a virtual package which pulls all necessary packages for detection of C/C++ coredumps, Python exceptions and Kernel oopses. The package also pulls abrt-tui package which provides 'abrt-cli' executable which allows users to list all detected problems, report a problem, delete a problem and something more. root user is notified about detected problems via email. ABRT also provides console notifications shipped in abrt-console-notification package. The package installs a small script which prints a count of detected problems when someone logs in to the shell. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
On Thu, Dec 05, 2013 at 07:40:36PM -0600, mrnuke wrote: On 12/05/2013 11:38 AM, Michael scherer wrote: On Wed, Dec 04, 2013 at 08:25:54PM -0600, mrnuke wrote: This change is Sofa King stupid. Why couldn't we have just enabled the warning without turning it into an error, THEN let packagers work with upstream in fixing those warnings? Regulate, not ban. Because packagers will just ignore it [...] I think this is a childish argument, but let's take it. So what? You're going to start stepping on people's lawns and change things just because you want to impose your greater good? In fact, I already do, I add checks in rpmlint for what I think to the greater good. And in other times and places, I even forced people to fix some rpmlint errors in their packages, just based on my own judgement, or their packages would not be uploaded. And while you may think this is childish, I have some data to back my assertion that some people ignore until there is a enforcement. For example, I have seen no one except me requesting CVE for potential security problems that rpmlint do see since 6 months ( missing-call-to-setgroups-before-setuid, missing-call-to-chdir-with-chroot ). Even during reviews, that's just ignored because this is not mandatory to fix ( for example https://bugzilla.redhat.com/show_bug.cgi?id=976770 ). ( and I did a run on the whole set of Fedora packages, so I know that I was not lucky and found the only single rpm with a problem ). Let's rather ask the contrary, why is this so much a issue to communicate with upstream to fix things, and add patches ? -Werror is not needed for communication. It is not about communication. This is about a small group of people imposing their MY WAY!!!. Like there is a small group of people imposing packages guidelines, so I fail to see your point exactly. [...] really fail to see why there is people complaining. You run the assumption that all upstreams are paradise, heavenly, and friendly. And you also run the assumption that upstreams will never introduce such bugs in the future, never leaving packagers with the headache of patching things up. That's already part of the life of packagers. For example, suddenly, gcc decide to be stricter and suddenly, some VCS written in C++ decide to not compile anymore, so you have to spend 1 full day just to make it compile. ( of course, totally fictious example that didn't happen to me several years ago ). There is enough software not building anymore and dropped after mass rebuild to show that such problem are not really so uncommon. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ABRT in the comps group 'standard'
On Fri, 2013-12-06 at 13:51 +, Jóhann B. Guðmundsson wrote: No not really our distribution is filled with just packagers that dont know what to do with those reports... So you're saying: Our maintainers can't fix bugs, why bother filing them at all?? That doesn't make sense to me at all. Maintainers that can fix bugs do. Ones that can't forward them upstream for the developers to look at. I remember this being brought up elsewhere already. Maintainers not knowing much about their packages isn't a tooling problem. +1 for abrt-cli in standard. Both my parents are completely novice users that run Fedora. They don't know what abrt is or what bugreporting is. If an abrt message pops up, they read that it said ... crash... and then they ignore it. It doesn't do any harm. -- Thanks, Warm regards, Ankur (FranciscoD) http://fedoraproject.org/wiki/User:Ankursinha Join Fedora! Come talk to us! http://fedoraproject.org/wiki/Fedora_Join_SIG signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
Am 06.12.2013 15:59, schrieb Ralf Corsepius: On 12/06/2013 02:57 PM, Reindl Harald wrote: if arbitary users are allowed to call CLI applications from a webserver ?!? Calling cli-tools underneath of webservices is the norm on many webservers. Often these calls are wrapped into scripting languages, be they perl, python or php. what ?!? if you allow call any CLI command on a webserver you have a serious problem - period in case of PHP open_basedir is your friend and without disable_functions it is completly worthless, so don't mix wrong configured webservers with the topic disable_functions = apache_child_terminate, chown, dl, exec, fileinode, get_current_user, getmypid, getmyuid, getrusage, highlight_file, link, mail, openlog, passthru, pclose, pcntl_alarm, pcntl_errno, pcntl_exec, pcntl_fork, pcntl_get_last_error, pcntl_getpriority, pcntl_setpriority, pcntl_signal_dispatch, pcntl_signal, pcntl_sigprocmask, pcntl_sigtimedwait, pcntl_sigwaitinfo, pcntl_strerror, pcntl_wait, pcntl_waitpid, pcntl_wexitstatus, pcntl_wifexited, pcntl_wifsignaled, pcntl_wifstopped, pcntl_wstopsig, pcntl_wtermsig, pfsockopen, popen, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid, proc_close, proc_get_status, proc_nice, proc_open, proc_terminate, shell_exec, show_source, socket_accept, socket_bind, symlink, syslog, system you have a security problem and that is for sure *not* TmpOnTmpfs TmpOnTmpfs opens opportunities for DOS attacks which do not exist with TmpOnFS if i have to chose between a *self* DOS because wrong webserver-capabilities and code execution what -Werror=format-security should prevent from i take the DOS and on a sane configured webserver you have a dedicated /tmp partition what means TmpOnTmpfs doesn not matter at all signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
fre 2013-12-06 klockan 15:06 -0500 skrev Darryl L. Pierce: On Fri, Dec 06, 2013 at 02:27:05AM +0100, Kevin Kofler wrote: Michael scherer wrote: Let's rather ask the contrary, why is this so much a issue to communicate with upstream to fix things, and add patches ? The vast majority of those warnings are actually false positives, not actual security issues. Putting my upstream hat on, if asked to fix such a false positive, I'd do one of: (a) close the bug as INVALID/NOTABUG/WONTFIX or (b) hardcode -Wno-error=format-security -Wno-format-security in my build setup and close the bug as FIXED. Additionally, some code (like my package, qpid-cpp) uses code that's generated by another app like Swig. We have no control over what that code is. So enabling this as an error would be unresolvable by our project and we'd be blocked until the Swig team decided to change their code generation bits. Don't use swig as an excuse not to fix things. Of all the packages I maintain, only one was affected by this issue. That one was easily solvable by deleting the bundled swig generated code in the sources and have the build regenerate it with a newer swig version that doesn't produce broken code. My other packages once used to have quite a few of these, but since Debian has had -Werror=format-security as the default for quite some time now those were already fixed in order to compile on Debian. So adding this as the default for Fedora now will not nearly be as disruptive as it was when it was added as a default on Debian. We are coming late to the game here. Mattias smime.p7s Description: S/MIME cryptographic signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
On 12/07/2013 03:39 AM, Reindl Harald wrote: Am 06.12.2013 15:59, schrieb Ralf Corsepius: On 12/06/2013 02:57 PM, Reindl Harald wrote: if arbitary users are allowed to call CLI applications from a webserver ?!? Calling cli-tools underneath of webservices is the norm on many webservers. Often these calls are wrapped into scripting languages, be they perl, python or php. what ?!? if you allow call any CLI command on a webserver you have a serious problem - period Have a nice life - End of Thread. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Broken dependencies: perl-Language-Expr
perl-Language-Expr has broken dependencies in the F-20 tree: On x86_64: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) 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-Language-Expr
perl-Language-Expr has broken dependencies in the rawhide tree: On x86_64: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) 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
[perl-Net-SSLeay] Fix usage of OBJ_cmp in the test suite (CPAN RT#91215)
commit a16de53dba34ad8e145c3ac22acf8153b6852861
Author: Paul Howarth p...@city-fan.org
Date: Fri Dec 6 14:05:04 2013 +
Fix usage of OBJ_cmp in the test suite (CPAN RT#91215)
Net-SSLeay-1.55-OBJ_cmp.patch | 12
perl-Net-SSLeay.spec |9 -
2 files changed, 20 insertions(+), 1 deletions(-)
---
diff --git a/Net-SSLeay-1.55-OBJ_cmp.patch b/Net-SSLeay-1.55-OBJ_cmp.patch
new file mode 100644
index 000..889a952
--- /dev/null
+++ b/Net-SSLeay-1.55-OBJ_cmp.patch
@@ -0,0 +1,12 @@
+Index: t/local/36_verify.t
+===
+--- t/local/36_verify.t(revision 387)
t/local/36_verify.t(working copy)
+@@ -60,6 +60,6 @@
+ my $asn_object2 = Net::SSLeay::OBJ_txt2obj('1.2.3.4', 0);
+ ok(Net::SSLeay::OBJ_cmp($asn_object2, $asn_object) == 0, 'OBJ_cmp');
+ $asn_object2 = Net::SSLeay::OBJ_txt2obj('1.2.3.5', 0);
+-ok(Net::SSLeay::OBJ_cmp($asn_object2, $asn_object) == 1, 'OBJ_cmp');
++ok(Net::SSLeay::OBJ_cmp($asn_object2, $asn_object) != 0, 'OBJ_cmp');
+
+ ok(1, 'Finishing up');
diff --git a/perl-Net-SSLeay.spec b/perl-Net-SSLeay.spec
index 02bca94..2ef9310 100644
--- a/perl-Net-SSLeay.spec
+++ b/perl-Net-SSLeay.spec
@@ -1,11 +1,12 @@
Name: perl-Net-SSLeay
Version: 1.55
-Release: 5%{?dist}
+Release: 6%{?dist}
Summary: Perl extension for using OpenSSL
Group: Development/Libraries
License: OpenSSL
URL: http://search.cpan.org/dist/Net-SSLeay/
Source0:
http://search.cpan.org/CPAN/authors/id/M/MI/MIKEM/Net-SSLeay-%{version}.tar.gz
+Patch2:Net-SSLeay-1.55-OBJ_cmp.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
BuildRequires: openssl, openssl-devel
# === Module Build ===
@@ -52,6 +53,9 @@ so you can write servers or clients for more complicated
applications.
%prep
%setup -q -n Net-SSLeay-%{version}
+# Fix usage of OBJ_cmp in the test suite (CPAN RT#91215)
+%patch2
+
# Fix permissions in examples to avoid bogus doc-file dependencies
chmod -c 644 examples/*
@@ -92,6 +96,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/Net::SSLeay::Handle.3pm*
%changelog
+* Fri Dec 6 2013 Paul Howarth p...@city-fan.org - 1.55-6
+- Fix usage of OBJ_cmp in the test suite (CPAN RT#91215)
+
* Sun Dec 1 2013 Paul Howarth p...@city-fan.org - 1.55-5
- Drop the kwalitee test for now as it's too fussy for the current code
--
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-6.fc21
The lightweight tag 'perl-Net-SSLeay-1.55-6.fc21' was created pointing to: a16de53... Fix usage of OBJ_cmp in the test suite (CPAN RT#91215) -- 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
[Bug 1000318] Please build perl-MooseX-Role-Parameterized for EPEL
https://bugzilla.redhat.com/show_bug.cgi?id=1000318 --- Comment #1 from Iain Arnell iarn...@gmail.com --- Sorry for the delay. I don't have time to maintain more packages in EPEL at the minute. Please feel free to branch and maintain it yourself. -- 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=zzcdoUNrnia=cc_unsubscribe -- 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
