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
Note: to count the vulnerabilities, I just manually added up the CVEs
listed at , ignoring the oldest advisory WSA-2015-0001, and
discounting five of the older vulnerabilities in WSA-2015-0002.
My next project for Red Hat is to work on improving Linux laptop battery life.
Part of the (hopefully) low hanging fruit here is using kernel tunables to
enable more runtime powermanagement. My first target here is SATA Link Power
Management (LPM) which, as Matthew Garrett blogged about 2 years ago:
can lead to a significant improvement in battery life.
There is only one small problem, there have been some reports that some
disks/SSDs don't play well with Linux' min_power LPM policy and that this
may lead to system crashes and even data corruption.
As such I've written a new LPM policy, which matches the power-management
defaults from the Intel RST Windows drivers. Since it mimicks Windows,
this new policy will hopefully not hit any SSD firmware bugs like min_power
So now I'm looking for people with a laptop with a SATA SSD or HDD to help
me test this to make sure this won't cause any issues when we enable this
by default for F28, for more details and test instructions see:
= System Wide Change: NSS Default File Format SQL =
* 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
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
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: 
No help should be necessary. No mass rebuild necessary.
* Policies and guidelines: N/A
* Trademark approval: N/A
On Sat, Oct 7, 2017 at 9:34 AM, Jerry James <loganjerry(a)gmail.com> wrote:
> I don't believe that anybody looks at those pull requests on a regular
> basis. Should somebody be doing so? There are 8 pull requests,
> dating back to about the time of the above conversation. Five of
> those don't contain a single comment.
> I opened one for gcl on July 29, and added a comment a month later
> asking if somebody was going to look at it. No response. This is a
> bit annoying, considering that I opened a bugzilla request asking for
> the same thing 4 years ago, and no action has ever been taken on it.
> I thought maybe a PR would finally get something to happen.
Nearly a week has gone by, and no answer. I'm really stumped about
what to do. Let me summarize the whole long saga and solicit help.
GCL is a Common Lisp implementation. It is known for its speed
compared to other CL implementations. It has a long lineage,
summarized here: https://en.wikipedia.org/wiki/GNU_Common_Lisp. I
took over maintenance of the package in late 2008 when the previous
maintainer did not have time to continue. At that point, the package
did not build in Rawhide and was slated to be dropped from Fedora
soon. I got it working with help from upstream and Daniel Walsh, who
provided advice on putting together an SELinux policy to account for
the fact that GCL produces executable code on the fly by calling
mprotect on selected pages.
Fast forward to 2013. By that time, the GCL policy also had to
mention maxima executables, since executables built with GCL also use
the GCL memory allocator. I figured that meant it was time to merge
the GCL policy into the system policy, and consequently opened a
bugzilla ticket. In spite of me trying to reboot the conversation a
couple of times, those involved who held the SELinux reins for Fedora,
Just. Could. Not. Stay. On. Topic. We talked about the execheap
permission in general, and its place in the universe. Some of them
sneeringly, condescendingly wondered why upstream and I were both so
incompetent that we didn't just rewrite the allocator to use mmap.
(Hint: it isn't easy, and upstream isn't interested in the exercise.)
After multiple failures on my part to get something to happen, I gave
up in despair.
Fast forward to 2017. Attempts to build maxima with gcl on aarch64
started hanging at package install time. See
https://bugzilla.redhat.com/show_bug.cgi?id=1435395. This was blamed
on gcl, incorrectly I believe. As I pointed out in the bug, nothing
built from gcl sources runs at package install time, so the hang must
be happening inside one of fixfiles, semodule, or restorecon, which
ARE run from the gcl install scripts because GCL has to install its
own SELinux policy, due to that policy not being merged into the
system policy. So, policycoreutils maintainers! Something Is Afoot
But that's not the end of the fun. GCL failed the mass rebuild this
summer. It built successfully on every architecture but s390x. On
s390x, the build failed due to a failed call to mprotect(), almost
certainly a sign that SELinux was in enforcing mode on the builder.
Was that a known issue with s390x builders? And, if so, has it been
rectified since? If so, I'll try building again.
I still want the system policy to account for GCL, in some way or
another. But, as you can see from the quoted text above, submitting a
pull request to the relevant git repository has resulted in months of
<crickets chirping>. And pointing that out on this list last weekend
has resulted in still more of the crickets.
So ... what is a packager supposed to do???? Why is it so hard to get
any attention for submissions to the system SELinux policy? There
should be a barrier to entry; I understand that. But I can't even get
the gatekeeper to have a conversation with me. Heeeeellllllppppp!!!
let's have some fun with upcoming Firefox 57 a.k.a Firefox Quantum. This
is a major Firefox update with key - pleasant and unpleasant - changes:
- fastest than ever with Rust, CSS Stylo, Sandbox...
- new "Photon" look
- and disabled XUL extensions
according to the disruptive nature of the update which is planned to
land in *all* Fedoras at Nov 14 I decided to put the update to the
testing as soon as possible, which mean we have Firefox 57 Beta packages
at update-testing right now.
If you don't consume update-testing regularly you can install Firefox
# dnf update --enablerepo=updates-testing firefox
and also expect new versions there. Please give it a shot and report any
issue to our  or Mozilla bugzilla .
We're going to build new cryptsetup-2.0.0-rc1 package in rawhide next
week. The major version increase also brings libcryptsetup soname bump.
Among other things new library will drop few functions.
These API functions will be removed:
For further description and explanation why those calls were removed and
what new functions are available, please see:
Following packages are listed as having direct runtime dependency on
cryptsetup-libs (arch x86_64 only) and therefore they may break or fail
to build if they use any function listed above:
The following packages are looking for new maintainers, ping me if
you're able to help out.
1) No co-maintainers at the moment:
2) Needs new main admin, co-maintainers pinged some time ago but no