devel July 2017

devel@lists.fedoraproject.org

213 participants
270 discussions

apitrace, bundled libbacktrace
by Sandro Mani 17 Dec '17

17 Dec '17

Hi, apitrace 5.0 bundles libbacktrace, which looks like is living within the gcc sources. libbacktrace is not build as a shared library from the gcc sources, and not packaged. Is it feasible to build libbacktrace as a shared library and ship it in a corresponding package? Or should I rather go for a bundling exception request? Thanks, Sandro

8 9

Reminder: upcoming retirement of webkitgtk and webkitgtk3 packages
by Michael Catanzaro 13 Dec '17

13 Dec '17

Hi, This is a reminder that the webkitgtk and webkitgtk3 packages will be retired from rawhide shortly after F26 is branched from rawhide. This is due to numerous security issues affecting those packages (I just counted 204 CVEs), many of which could allow remote code execution. Bugs have already been filed against all directly-affected packages [1]. Note: to count the vulnerabilities, I just manually added up the CVEs listed at [2], ignoring the oldest advisory WSA-2015-0001, and discounting five of the older vulnerabilities in WSA-2015-0002. Michael [1] https://bugzilla.redhat.com/show_bug.cgi?id=1375784 [2] https://webkitgtk.org/security.html

10 26

F27 System Wide Change: NSS Default File Format SQL
by Jaroslav Reznik 23 Nov '17

23 Nov '17

= System Wide Change: NSS Default File Format SQL = https://fedoraproject.org/wiki/Changes/NSSDefaultFileFormatSql Change owner(s): * Kai Engert <kaie(a)redhat.com> Change the NSS library default to use the sqlite based data storage, when applications don't specify their preferred storage file format. == Detailed Description == Applications that use the NSS library often use a database for storage of keys, certificates and trust. NSS supports two different file formats, one called DBM (based on berkeley DB files) and another one called SQL (based on sqlite DB files). Today's default file format used by NSS, used when applications omit the type parameter, is the older DBM file format, which forbids parallel access to the storage. The suggestion is to change the default file format to SQL, which allows parallel access to the storage. Applications, or users using the NSS command line utilities, often provide the database storage location using a simple directory path parameter. Some might not be aware, or forget, that the parameter can be prefixed with a type modifier, either "dbm:" or "sql:". As a result, when not providing this parameter, the file format used will be the fragile DBM file format. This is particuarly problematic, if a user attempts to modify the NSS storage using command line tools, while another process, such as a daemon, is running concurrently, which also accesses the same database in the DBM file format. This often results in corrupted database storage, which cannot be recovered. By changing the default, all applications that currently use the DBM file format, will automatically be migrated to the SQL file format. NSS has the ability to discover if a storage location (a directory) contains the DBM file format. If configured to use the modern SQL format, NSS will automatically perform a one-time conversion from the DBM to the SQL format. The same applies to the NSS command line utilities. If the NSS library default is changed to SQL, the NSS tools will also trigger the one-time conversion, or access the already converted files. == Scope == * Proposal owners: A small downstream patch needs to be applied to the NSS library package, which changes the library default. * Other developers: It's up to developers of NSS applications, if they accept the new default and an automatic conversion, or if they prefer to continue to use the classic DBM storage format. Although not recommended, developers can easily do so, by adding a "dbm:" prefix to the storage parameter they provide to NSS at NSS library initialization time. * Release engineering: [1] No help should be necessary. No mass rebuild necessary. * Policies and guidelines: N/A * Trademark approval: N/A [1] https://pagure.io/releng/issue/6883 Thanks, Jaroslav

3 5

RFC: Always sourcing /etc/bashrc for interactive mode in bash
by Siteshwar Vashisht 10 Oct '17

10 Oct '17

We are discussing about always sourcing /etc/bashrc for interactive mode in bug 1193590 [1]. Currently /etc/bashrc is sourced by user's bashrc script and if a user forgets to source it, some of the default configurations will not be set (for e.g. see bug 1390780 [2]). I am pondering over the idea to source /etc/bashrc by default (see commmit at [3]) and fix current /etc/bashrc script to avoid double sourcing [4]. This change may cause undesirable effects if a custom /etc/bashrc is prone to double sourcing and might break some systems. Any comments about this change are welcome. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1193590 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1390780 [3] https://github.com/fedora-testing/bash/commit/87ac935a6643a9afee44a95757714… [4] https://bugzilla.redhat.com/show_bug.cgi?id=1193590#c20 -- -- Siteshwar Vashisht

2 2

SELinux policy contibutions
by Robert Marcano 07 Oct '17

07 Oct '17

Greetings. Is https://github.com/fedora-selinux/selinux-policy-contrib the right place to contribute to the Fedora SELinux policy? I added a pull request for a small update needed for a new release of cups-pdf, but I am not sure someone is monitoring that. There is another one from rhatdan there so I presume is the right place.

5 5

Nonresponsive maintainer: attempting to contact kanarip
by James Hogarth 05 Sep '17

05 Sep '17

Hi, Has anyone heard from kanarip or able to contact him? I've been attempting to contact for this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1223593 If there's no response in one week an issue will be filed with FESCo following the nonrepsonsive maintainer policy to review the ownership status of the packages. For ruby maintainers please note that this has a significant impact on you, if you want to keep track of this, as he owns puppet, rubygems and ruby ... https://admin.fedoraproject.org/pkgdb/packager/kanarip/ Regards, James

4 8

Non-responsive maintainer process for caillon, and retiring xchat
by Debarshi Ray 04 Sep '17

04 Sep '17

Hello everybody, I would like to initiate the non-responsive maintainer process [1] for Christopher Aillon [2]. A long time ago, he used to be part of the Fedora and Red Hat desktop teams. He is no longer around. He left software development and was last seen living off the grid in Hawaii [3]. Therefore I have jumped straight to the fourth step in the aforementioned process. Here is a list of his packages: https://admin.fedoraproject.org/pkgdb/packager/caillon/ I am particularly interested in xchat, which I want to retire right after removing Chris as the point of contact for his packages. HexChat [5] is the natural replacement of XChat these days. XChat is dead [6] - the last upstream release was seven years ago [7]. On the other hand, HexChat has been a part of Fedora for the last four years, upstream [4] is involved in both the Fedora [8] and GNOME communities, and I learnt that the MATE spin already ships it by default. For what it is worth, this was already discussed and approved on desktop(a)lists.fedoraproject.org [9]. Cheers, Rishi [1] https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers [2] https://admin.fedoraproject.org/accounts/user/view/caillon [3] https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.o… [4] https://admin.fedoraproject.org/pkgdb/package/rpms/xchat/ [5] https://hexchat.github.io/ [6] https://en.wikipedia.org/wiki/XChat [7] http://xchat.org/ [8] https://fedoraproject.org/wiki/User:Tingping [9] https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.o…

3 6

No i686 kernel: Can we require SSE2 for i686?
by Florian Weimer 28 Aug '17

28 Aug '17

I ran into this unannounced change: https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels If this is accepted, all x86 hardware on which Fedora can run will support SSE2, and we should reflect that in the i686 build flags. How likely is it that this proposal is accepted? Ideally, we would know this before the mass rebuild so that we can change the compiler flags in redhat-rpm-config. Thanks, Florian

37 96

ImageMagick Unresponsive Maintainer process - hubbitus (Pavel Alexeev)
by Moez Roy 24 Aug '17

24 Aug '17

ImageMagick Unresponsive Maintainer process - hubbitus (Pavel Alexeev) Sources were last updated 2016-01-06 13:43:26 - https://koji.fedoraproject.org/koji/packageinfo?packageID=425 Since then there have been numerous security vulnerabilities including ImageTragick. I commented here: https://bugzilla.redhat.com/show_bug.cgi?id=1299275#c153 that "Many security bugs were closed automatically when F23 went EOL. Those are the only 2 versions supported upstream @ https://www.imagemagick.org/download/linux/CentOS/x86_64/ "

12 23

Removal of code signing trust bits from ca-certificates
by Kai Engert 23 Aug '17

23 Aug '17

Until recently, Mozilla maintained three individual trust bits for each root CA certificate: - trust for TLS servers - trust for email security - trust for code signing The next CA update from Mozilla will switch the code signing trust bit OFF for all CAs. Mozilla will no longer maintain this trust bit. See https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/004uvRR… for background. I'm not aware of anyone using this trust bit. The removal might have no effect. This update of the CA list is supposed to get published with Firefox 56 on September 26. In order to allow the Fedora community to test potential effects of this change, I intend to publish an update to the ca-certificates packages early, and keep it in updates-testing for a few weeks. Tracking bug: https://bugzilla.redhat.com/show_bug.cgi?id=1472468 Thanks Kai

2 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel July 2017