I've been thinking about Gnome keyring a lot lately, and I have concerns
about security, and I don't know if this is a Gnome keyring problem, or a
problem affecting Fedora specifically.
In short, it doesn't look like Gnome keyring has the ability to notify a
user interactively when a password is read from an unlocked keyring (or to
dynamically unlock it with a master passphrase upon request). Is this
correct? If so, it puts it behind NSS features that Firefox and other apps
use to store passwords and other credentials. However, if it's just
something specific which isn't packaged for Fedora, or isn't installed by
default, that would be very good to know.
In the past, seahorse-plugins provided a gpg-agent with a tool for
configuring cache preferences. It looks like seahorse-plugins is no longer
packaged for Fedora, and gpg2 integrates with seahorse/gnome keyring
differently (I don't know how). At least for GPG passphrases, this provided
some UI to notify the user upon programmatic access to the cached
credentials, and provided an notification icon whenever the cache was
non-empty. It also provided a customizable timer for the cache.
Although they didn't help for non-GPG credentials, these features of
seahorse-plugins provided important (essential, I would say) security for a
GPG credential cache (and, I would argue, essential for any private
credential store). However, these appear to have been lost in Fedora,
making Fedora less secure. Does anybody know about this? Do these features
have replacements which I'm not aware of? If so, why aren't they installed
in Fedora by default?
Is this downgrade in security a Fedora problem, or is it a Gnome problem,
or a seahorse problem? Are there alternatives? NSS seems to be getting some
of this right, but doesn't have good integration with Gnome/Seahorse/GPG.
LLVM upstream is (eventually) dropping their autotools build system in
favor of their cmake buildsystem. This wouldn't normally be something
you'd notice, but the two produce different sets of shared libraries,
autotools gave you one big libLLVM and cmake gives you lots of
This means the llvm consumers need to be relinked against the new set
of libs, and that's grinding its way through koji now. Hopefully those
will all complete before the next rawhide compose, but arm might hold
us back a bit.
On the plus side, this makes it possible to actually build lldb, clang,
and compiler-rt independently of the llvm core. This is a huge win from
my perspective because I absolutely do not care about clang and want
never again to get any bugs about it. If you're someone who does care
about one of those subprojects, they could use maintainers.
I've been around for a while, but as I'm taking on a new role inside
Red Hat, I'll be showing up in different places here and upstream, so
I figured I'd refresh everyone's memory as well as announce the change :-)
For those who don't know me, I'm the creator of the DJGPP project, a
senior engineer at Red Hat for the last 17 years, and a
maintainer/contributor for many upstream projects, including gcc,
binutils, newlib, and gdb. I was also active in the Fedora ARM
bootstrap project, and wrote the initial (stage 1-3) bootstrap scripts
for it. I also do electronics, woodworking, and metalworking as
hobbies, so I tend to show up in lots of forums...
In my new role at Red Hat I'll be focusing more on glibc work, so
expect to see me poking my nose around there too now :-)
The maintainer for python-cairocffi has been non-responsive for some
time. For example, I opened 1249821 in early August; never received a
response; adamw finally did the deed for me. I opened 1273567 in
October, and have still not received a single response. 1288627 was
opened in early December by someone else, and has not received a
In October, I requested commit acls to the package so as to resolve
these outstanding issues and possibly move things forward in the future.
I have not received a response.
I opened 1299042 for unresponsive maintainer, and still have not received
-----BEGIN PGP SIGNED MESSAGE-----
On 01/29/2016 11:41 AM, Antonio Trande wrote:
Latest IceCat-38.6.0 does not compile with GCC-6.0:
> ... In file included from
> ../../dist/include/mozilla/MathAlgorithms.h:15:0, from
> /builddir/build/BUILD/icecat-38.6.0/xpcom/glue/nsTArray.h:14, from
> from ../../dist/include/mozilla/AppData.h:12, from
> /builddir/build/BUILD/icecat-38.6.0/xpcom/glue/AppData.cpp:7, from
> /usr/include/c++/6.0.0/cmath:615:11: error: '::isinf' has not
> been declared using ::isinf; ^~~~~
> /usr/include/c++/6.0.0/cmath:640:11: error: '::isnan' has not been
> declared using ::isnan; ^~~~~
> /builddir/build/BUILD/icecat-38.6.0/config/rules.mk:930: recipe for
> target 'Unified_cpp_xpcom_glue0.o' failed
Do you know how to fix this issue?
Full build log:
mailto: sagitter 'at' fedoraproject 'dot' org
GPG Key: 0x565E653C
Check on https://keys.fedoraproject.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
-----END PGP SIGNATURE-----