Re: EPEL Orphaned packages with vulnerabilities
On Tue, Aug 19, 2014 at 03:02:27PM +0200, Karel Volný wrote: > the person who cares about the security bugs could have been the one to > patch - it is not uncommon that things are fixed by other people than the > owner (e.g. qmmp, that is owned by me, got recently updated in F20 by Rex > Dieter because of some PulseAudio stuff ..) Yes, it is not necessarily the maintainer that needs to take care of stuff, but the maintainer should at least ask for help or coordinate this. > I thought we've always advertised EPEL as "best effort", so I'd dismiss such > assumptions as unfounded ... well, I know this is not nice, but I see it as > the best (i.e. least bad) option, as we don't have the capacity to deal with > every single problem in the (enterprise linux) world > so ... suppose someone will follow > http://fedoraproject.org/wiki/Package_SCM_admin_requests#Package_Change_Requests_for_existing_packages > > but it won't fix the cves ... what now, will it get back anyways? > I'm not a good candidate, I'm not a programmer ... I understand the things > enough to cherry pick a patch that can be applied directly, but I can hardly > rewrite the patch for a different code of some old version, especially when > I'm completely unfamiliar with the sources; probably I'd be able to handle > it somehow in the end, but for a price of a lot of time that I'd need to use > for other things (hey, I have a family waiting for me :-)) > > from what I understand from the bugzilla, everything got fixed upstream so > rebase would be the least-effor solution that basically anyone (including > me) could handle > > however, we don't like to do rebases in EPEL ... would it be viable in this > situation? > > - at least on EL5 it would mean the need to rebuild the dependant packages > ... but we need to rebuild them anyways as the dependency became broken ... Yes, a simple rebase will help here and is IMHO applicable here, since it is the lesser evil. It is not necessarily necessary to rebuild the dependent packages, if libmodplug did not change too much. Therefore in this case, I would consider it pretty irresponsible to just get libmodplug back in the state it is without taking care of the easy to fix vulnerabilities. Regards Till ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
EPEL Fedora 5 updates-testing report
The following Fedora EPEL 5 Security updates need testing: Age URL 849 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5630/bugzilla-3.2.10-5.el5 303 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11893/libguestfs-1.20.12-1.el5 68 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1626/puppet-2.7.26-1.el5 58 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1696/perl-Email-Address-1.905-1.el5 53 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1747/mediawiki119-1.19.17-1.el5 11 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2165/iodine-0.7.0-1.el5 11 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2153/drupal6-6.33-1.el5 11 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2150/drupal7-7.31-1.el5 10 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2155/wordpress-3.9.2-3.el5 6 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2184/389-ds-base-1.2.11.30-1.el5 The following builds have been pushed to Fedora EPEL 5 updates-testing almas-mongolian-title-fonts-1.0-4.el5 bind-to-tinydns-0.4.3-15.20140818gitdf0ddc3.el5 easytag-2.1-4.el5 google-phetsarath-fonts-1.01-2.el5 tharlon-fonts-1.002-3.el5 trabajo-fonts-2.0-2.el5 tuladha-jejeg-fonts-2.01-2.el5 Details about builds: almas-mongolian-title-fonts-1.0-4.el5 (FEDORA-EPEL-2014-2247) Mongolian Title font Update Information: Mongolian Title font References: [ 1 ] Bug #859819 - Review Request: almas-mongolian-title-fonts - Mongolian Title font https://bugzilla.redhat.com/show_bug.cgi?id=859819 bind-to-tinydns-0.4.3-15.20140818gitdf0ddc3.el5 (FEDORA-EPEL-2014-2246) Convert DNS zone files in BIND format to tinydns format Update Information: Updated to latest upstream snapshot; fixes SRV record support ChangeLog: * Mon Aug 18 2014 Tim Jackson 0.4.3-15.20140818gitdf0ddc3 - Updated to latest upstream snapshot; fixes SRV record support easytag-2.1-4.el5 (FEDORA-EPEL-2014-2241) Tag editor for mp3, ogg, flac and other music files Update Information: EasyTAG 2.1 for EPEL 5 google-phetsarath-fonts-1.01-2.el5 (FEDORA-EPEL-2014-2252) The font for the Lao language Update Information: The font for the Lao language References: [ 1 ] Bug #1031588 - Review Request: google-phetsarath-fonts - The font for the Lao language https://bugzilla.redhat.com/show_bug.cgi?id=1031588 tharlon-fonts-1.002-3.el5 (FEDORA-EPEL-2014-2245) The Myanmar font which is designed by Ngwe Tun Update Information: The Myanmar font which is designed by Ngwe Tun References: [ 1 ] Bug #1031587 - Review Request: tharlon-fonts - The Myanmar font which is designed by Ngwe Tun https://bugzilla.redhat.com/show_bug.cgi?id=1031587 trabajo-fonts-2.0-2.el5 (FEDORA-EPEL-2014-2249) Latin Serif font that supports Shavian alphabet Update Information: Latin Serif font that supports Shavian alphabet References: [ 1 ] Bug #991724 - Review Request: trabajo-fonts - Latin Serif font that supports Shavian alphabet https://bugzilla.redhat.com/show_bug.cgi?id=991724 ===
EPEL Fedora 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 849 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6 196 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0440/fwsnort-1.6.4-1.el6 181 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0590/oath-toolkit-2.0.2-4.el6 68 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1616/puppet-2.7.26-1.el6 58 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1693/perl-Email-Address-1.905-1.el6 18 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2088/tor-0.2.4.23-1.el6 17 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2099/v8-3.14.5.10-11.el6 12 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2123/ReviewBoard-1.7.27-1.el6 12 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2117/ansible-1.7-1.el6 12 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2144/mediawiki119-1.19.18-1.el6 11 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2159/iodine-0.7.0-1.el6 11 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2158/drupal7-7.31-1.el6 11 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2148/drupal6-6.33-1.el6 10 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2162/wordpress-3.9.2-3.el6 6 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2185/sks-1.1.5-2.el6 3 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2218/pen-0.25.1-1.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2229/phpMyAdmin-4.0.10.2-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing almas-mongolian-title-fonts-1.0-4.el6 bind-to-tinydns-0.4.3-15.20140818gitdf0ddc3.el6 fts-rest-3.2.26-2.el6 google-phetsarath-fonts-1.01-2.el6 tharlon-fonts-1.002-3.el6 trabajo-fonts-2.0-2.el6 tuladha-jejeg-fonts-2.01-2.el6 Details about builds: almas-mongolian-title-fonts-1.0-4.el6 (FEDORA-EPEL-2014-2244) Mongolian Title font Update Information: Mongolian Title font References: [ 1 ] Bug #859819 - Review Request: almas-mongolian-title-fonts - Mongolian Title font https://bugzilla.redhat.com/show_bug.cgi?id=859819 bind-to-tinydns-0.4.3-15.20140818gitdf0ddc3.el6 (FEDORA-EPEL-2014-2251) Convert DNS zone files in BIND format to tinydns format Update Information: Updated to latest upstream snapshot; fixes SRV record support Updated to latest upstream snapshot; supports records fts-rest-3.2.26-2.el6 (FEDORA-EPEL-2014-2254) FTS3 Rest Interface Update Information: Update for new upstream release ChangeLog: * Fri Aug 15 2014 Michal Simon - 3.2.26-2 - Update for new upstream release google-phetsarath-fonts-1.01-2.el6 (FEDORA-EPEL-2014-2248) The font for the Lao language Update Information: The font for the Lao language References: [ 1 ] Bug #1031588 - Review Request: google-phetsarath-fonts - The font for the Lao language https://bugzilla.redhat.com/show_bug.cgi?id=1031588 tharlon-fonts-1.002-3.el6 (FEDORA-EPEL-2014-2253) The Myanmar font which is designed by Ngwe Tun Update Information: The Myanmar font which is designed by Ngwe Tun References: [ 1 ] Bug #1031587 - Review Request: tharlon-fonts - The Myanmar font which is designed by Ngwe Tun https://bugzilla.redhat.com/show_bug.cgi?id=1031587 ==
Re: EPEL 5 orphaned packages status
On 19/08/14 07:06, Till Maas wrote: Hi, there are a lot of orphaned packages in EPEL 5, that should IMHO either be properly maintained or retired, here is a rough overview: ... I took perl-DateTime-Format-Mail Paul. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Orphaned packages with vulnerabilities
Hi, There is now a security initiative to handle the outstanding security bugs. that's cool that somebody cares however, do you really think that users will appreciate this way of handling the bugs, i.e. removing important libraries instead of patching them? If there is nobody that patches the library, I do not see how this is an option. the key is this "if ..." the person who cares about the security bugs could have been the one to patch - it is not uncommon that things are fixed by other people than the owner (e.g. qmmp, that is owned by me, got recently updated in F20 by Rex Dieter because of some PulseAudio stuff ..) ... I've always thought that it works in the way that if package gets orphaned, it simply won't make it into next version of the distribution, not that it should get removed from the current version, causing regressions for users ...? ... For me it is kind of common sense. Why should it be a good idea to ship packages with known vulnerabilities? as said below - not to cause regressions by removing what users rely upon, because pros may overweight cons ... maybe not always "good" but often "less evil" As you can see from the long list of orphaned packages with known vulnerabilities, just orphaning packages in EPEL creates a dangerous situation where users installing packages from EPEL assume they are well taken care of, but in reality they are not. I thought we've always advertised EPEL as "best effort", so I'd dismiss such assumptions as unfounded ... well, I know this is not nice, but I see it as the best (i.e. least bad) option, as we don't have the capacity to deal with every single problem in the (enterprise linux) world this is the usual conflict between having things perfect but lack of them or having at least something - I often vote for the opposite, better nothing than something that makes the situation worse, but in this concrete case I *think* the better option is to have at least something ... MOD music is a niche market these days, but it used to be one of things I liked about linux that it's not just for the majority So I discussed this with others and retiring orphaned packages after a certain time seemed good to us. okay, I believe you (and "others") know better than me, as I don't have enough insight into various aspects of the distribution (which doesn't mean that I couldn't express my objections :-)) what I'd like to see are clear rules for this, and a bit better process ... However, I did not intentionally retire a package that is depended upon, but since it is really easy to undo retirement in EPEL, I do not see much harm done. so ... suppose someone will follow http://fedoraproject.org/wiki/Package_SCM_admin_requests#Package_Change_Requests_for_existing_packages but it won't fix the cves ... what now, will it get back anyways? So if you would like to have the package in EPEL, you need to find a maintainer or maintain it. sorry, I just don't follow your logic it wasn't me who did the action - why should I undo it? I really do not get what what is your motivation. You are a package maintainer with a package that depends on an orphaned library with security vulnerabilities. Why do you not want to fix this? it's not my package and I don't want it to become mine someone just put that "you want it back so you fix it", creating work for me (or someone else who'd want the same) but I have enough things to do, I don't manage to give enough love to things I do maintain, I really don't want someone to create more work for me - I didn't want the package to be removed in the first place, if it wouldn't be removed, there would be no work to get it back ... First you wanted to get a better heads up, which I agree would have been better, but I do not see how this would have changed anything, because still nobody cares enough about libmodplug to unretire it and fix the security vulnerability. what would have changed is that we wouldn't have broken dependencies and an user filing bug that would need (or "need") to be taken care of the fact that "nobody cares" isn't something that can't be changed - Since you maintain a package that depends on it, you are the first candidate to do this. together with xine maintainers ... I'm not a good candidate, I'm not a programmer ... I understand the things enough to cherry pick a patch that can be applied directly, but I can hardly rewrite the patch for a different code of some old version, especially when I'm completely unfamiliar with the sources; probably I'd be able to handle it somehow in the end, but for a price of a lot of time that I'd need to use for other things (hey, I have a family waiting for me :-)) from what I understand from the bugzilla, everything got fixed upstream so rebase would be the least-effor solution that basically anyone (including me) could handle however, we don't like to do rebases in EPEL ... would it be viable
EPEL epel beta report: 20140819 changes
Compose started at Tue Aug 19 08:15:02 UTC 2014 New package: gkrellm-top-2.2.13-5.el7 GKrellM plugin which shows 3 most CPU intensive processes New package: perl-Crypt-RC4-2.02-6.el7 Perl implementation of the RC4 encryption algorithm New package: perl-Devel-CheckBin-0.02-2.el7 Check that a command is available New package: perl-Spreadsheet-ParseExcel-0.5900-8.el7 Extract information from an Excel file New package: python-flup-1.0.2-9.el7 Random assortment of WSGI servers for python New package: qbittorrent-3.1.9-2.el7 A Bittorrent Client New package: qtlockedfile-2.4-11.el7 QFile extension with advisory locking functions New package: qtsingleapplication-2.6.1-11.el7 Qt library to start applications only once per user New package: rb_libtorrent-0.16.17-2.el7 A C++ BitTorrent library aiming to be the best alternative New package: re2-20131024-1.el7 C++ fast alternative to backtracking RE engines New package: xls2csv-1.07-2.el7 A script that recodes a spreadsheet's charset and saves as CSV Updated Packages: ReviewBoard-2.0.5-1.el7.2 - * Mon Aug 18 2014 Stephen Gallagher 2.0.5-1.2 - Fix runtime dependencies fedora-dockerfiles-0-0.11.git0d2f49b.el7 * Sat Aug 16 2014 Aditya Patawari - 0-0.11.git - we don't want debug package since it is noarch gnuradio-3.7.4-6.el7 * Mon Aug 18 2014 Jaroslav Škarvada - 3.7.4-6 - Removed explicit PyQwt requirement on RHEL-7 * Sat Aug 16 2014 Fedora Release Engineering - 3.7.4-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_22_Mass_Rebuild libspnav-0.2.3-1.el7 * Mon Aug 18 2014 Richard Shaw - 0.2.3-1 - Update to latest upstream release. * Sun Aug 17 2014 Fedora Release Engineering - 0.2.2-8 - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_22_Mass_Rebuild * Sat Jun 07 2014 Fedora Release Engineering - 0.2.2-7 - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild ocsinventory-2.1.2-3.el7 * Mon Aug 18 2014 Remi Collet - 2.1.2-3 - fix SELinux context use httpd_sys_rw_content_t instead of httpd_sys_script_rw_t - requires mariadb-server to avoid pulling mysql-galera (EL-7) perl-Sub-Name-0.09-1.el7 * Mon Aug 18 2014 Paul Howarth - 0.09-1 - Update to 0.09 - Copy the contents of the %DB::sub entry if it exists; fixes Devel::NYTProf's anon sub handling (CPAN RT#50524) - Drop upstreamed debugger patch - Drop EL-5 compatibility since we need Devel::CheckBin, which can't be built for EPEL-5 or EPEL-6 * Sun Aug 17 2014 Fedora Release Engineering - 0.08-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_22_Mass_Rebuild phpMyAdmin-4.2.7.1-1.el7 * Mon Aug 18 2014 Robert Scheck 4.2.7.1-1 - Upgrade to 4.2.7.1 (#1130865, #1130866, #1131104) python-libcloud-0.15.1-1.el7 * Mon Jul 21 2014 Daniel Bruno - 0.6-1 - Update to latest upstream release. * Mon Aug 18 2014 Fedora Release Engineering - 0.5-9 - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_22_Mass_Rebuild * Sun Jun 08 2014 Fedora Release Engineering - 0.5-8 - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild Summary: Added Packages: 11 Removed Packages: 0 Modified Packages: 10 ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
