I just had to setup a new machine, and new ssh keys.
I chose my new id_rsa.pub to upload.
But I get:
git push --verbose
Pushing to ssh://firstname.lastname@example.org/mercurial
Permission denied (publickey).
fatal: The remote end hung up unexpectedly
This proposal was originally at https://fedorahosted.org/fesco/ticket/1104
(mitr asked me to move the discussion to fedora-devel to get more
attention and feedback)
http://fedoraproject.org/wiki/Hardened_Packages page mentions
that "FESCo requires some packages to use PIE and relro hardening by
It would be great if this list could be expanded to include even more
packages which are at comparatively more risk of being exploited (locally
Such packages will typically include various system daemons, network
daemons and network enabled applications.
Lot of network daemons are already using PIE and RELRO (e.g. httpd,
MariaDB). So a natural question is why packages in same "network
daemons" class like PostgreSQL, Dovecot and MongoDB aren't being
Some of the ways to implement this proposal are,
1. Hardening flags should be turned on (by default) for all packages
which are at comparatively more risk of being exploited or which meet
some well-defined criteria (suggestions welcome).
"Packaging Guidelines" say that "Other packages may enable the flags at
the maintainer's discretion."
Thinking from a security perspective, I find "Hardening flags can only
be disabled for other packages at the maintainer's discretion provided
enough justification is given to FESCo" to be more appropriate.
2. An alternate approach is to come up with an expanded list of packages
which should be hardened.
Any feedback is welcome!
I'm not sure whether or not this is a bug, but it sure looks strange.
$ rpm -qf /usr/bin/ssh
$ ldd /usr/bin/ssh|grep ldap
libldap-2.4.so.2 => /lib64/libldap-2.4.so.2 (0x00007fad274fc000)
/usr/lib64/libldap-2.4.so.2 is a symbolic link to a symbolic link
which passes through a -devel package.
/usr/lib64/libldap-2.4.so.2 -> libldap.so # openldap-2.4.34-1.fc18
/usr/lib64/libldap.so -> libldap-2.4.so.2.9.0 # openldap-devel-2.4.34-1.fc18
/usr/lib64/libldap-2.4.so.2.9.0 is a real file # openldap-2.4.34-1.fc18
To cut a long story short, I fixed this by uninstalling openldap-devel
and reinstalling it. Now there is no -devel package in the chain:
$ ldd /usr/bin/ssh | grep ldap
libldap-2.4.so.2 => /lib64/libldap-2.4.so.2 (0x00007fe8caf69000)
/lib64/libldap-2.4.so.2 -> libldap-2.4.so.2.9.0
I'd like to understand how the original situation happened, because it
broke a supermin-built appliance (RHBZ#954185). I assume ldconfig
must have something to do with it. There is nothing unusual in the
%scripts of openldap (it just runs ldconfig as you'd expect), nor is
there any special openssh/openldap config file in /etc/ld.so.conf.d.
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
I'm trying to package a web application with bundled fonts. These fonts
are used by the web clients (browsers), and just served from the Fedora
Trying to package the webfonts as dependencies I have run into problem
together with my reviewer. Basically, we don't know what to do. Some
- Where should webfonts be stored? A specific dir would be good, since
some fonts exists in both a webfont and desktop variant with the same
- How shoulld webapps get access to the system webfont? Is the apache
config file approach used for ..js files, where the webapp gets access
to specific system paths, usable also here?
- Given that the primary concern about fonts seems to be licensing, is
it really meaningful to unbundle them?
This is the short story. The somewhat longer:
Any help, out there?
the current xine-lib maintainer speaking. :-)
The Xine project:
has recently released a new major version, version 1.2.0.
Unfortunately, among the list of changes:
there are these new "features":
* Use libavutil-provided implementations for CRC, SHA1 and BASE64 algorithms,
this makes use of libavutil even outside the FFmpeg decoding plugin,
but avoid duplication of algorithms between different plugins.
* Use av_mallocz() when xine_xmalloc_aligned() wouldn't be needed.
* FFmpeg is now required as an external dependency; if you want to build
xine-lib from source, please download a copy of FFmpeg from their SVN
which basically mean that xine-lib now has a global, non-optional dependency
on FFmpeg's libavutil library.
So there are 4 possible ways forward:
(a) Stick with 1.1.x forever. I don't think that's a good idea in the long
run, upstream won't be providing security fixes for the old branch forever.
(b) Package libavutil (and only libavutil) from FFmpeg in Fedora. (I don't
think libavutil, as opposed to libavcodec, is actually patent-encumbered,
though that'd also have to be checked.) The issue there is that FFmpeg
upstream obviously doesn't support this. It would need some more black
packaging magic of the kind already done in xine-lib, and more legal
auditing. I don't think I want to investigate going down that road.
(c) Bundle parts or all of libavutil with xine-lib. Yuck!!!
(d) Move the whole thing (back) to RPM Fusion (where it originally was, before
we started needing xine-lib for Amarok and Phonon, which both no longer
use it). It would go to the Free section, of course.
My proposal is to go with (d).
The following packages currently depend on xine-lib:
* (k9copy – already in RPM Fusion, not affected)
* kaffeine (my package, the reason why I maintain xine-lib in the first place)
These packages would have to move to RPM Fusion along with xine-lib.
In Kaffeine's case, upstream is switching from xine-lib to MPlayer in their git
repository, so it will likely have to move to RPM Fusion sooner or later
anyway. This means the affected packages are basically *xine*.
So my plan is to retire (for my packages, resp. have the respective maintainer
retire) the listed packages in Fedora for Fedora ≥ 17 and get (or have the
respective maintainer get) them into RPM Fusion Free instead. (I'd take care
of xine-lib and kaffeine myself, I hope the maintainers of the other packages
will take care of them.)
So I'm writing a blog post on this topic ATM, and that really kinda
brought home how messy this design is at present.
Quick refresher for anyone who hasn't looked at it much yet: in F19,
anaconda can create user accounts, and 'firstboot' has been replaced
with two alternative tools, 'initial-setup' which is used in any
graphical install other than a GNOME install and just replicates
anaconda's 'root password', 'user creation' and 'date/time' spokes, and
gnome-initial-setup, which is used in GNOME installs and is its own
whole thing that can also do user creation.
I mapped out all the potential paths through this maze, and got this -
anaconda: root pw, no user - g-i-s: admin user
i-s: admin user
i-s: regular user
anaconda: root pw, regular user - g-i-s: user mode
i-s: edit root pw or user
i-s: leave intact
console: regular user + root
anaconda: root pw, admin user - g-i-s: user mode
i-s: edit root pw or user
i-s: leave intact
console: admin user + root
anaconda: no root pw, admin user - g-i-s: user mode
i-s: edit root pw or user
i-s: leave intact
console: admin user + root
Note the paths marked "i-s: edit root pw or user" are pretty messy and
open ended in themselves - initial-setup always runs if installed, no
matter what you set in anaconda, and at least theoretically lets you
change the settings you picked in anaconda.
This is...kinda nuts, and a QA nightmare. Can we maybe take a step back
and look if there's a more sensible way to design this, ideally with the
GNOME and anaconda teams working together?
If we imagined initial-setup didn't exist and we only had the
anaconda/g-i-s case, the proliferation of trees at least looks rather
better, because g-i-s can't set the root password or change what
anaconda did; if you create a user account during anaconda, g-i-s runs
only after you log in with that user account and just lets you configure
various settings for that user account, it doesn't let you create other
user accounts (this is what I've labelled as 'g-i-s: user mode' in the
tree). So the anaconda/g-i-s paths are broadly sane already. It's the
anaconda/i-s paths that are really complicating things. Still, it might
help to just take a step back and decide if we really need all this
flexibility. We could, for instance, simply force user creation during
anaconda, dump initial-setup entirely, and use only
gnome-initial-setup's "user mode" (desktops other than GNOME could
implement something like this "user mode" if they wanted to, or not).
That would be a hell of a lot simpler to code, test, support and
explain, with the minor(?) drawback that you couldn't install without a
user account and then create it on first boot any more. Xkcd Law tells
us that someone will not be happy about this:
but still, it seems to be worth considering. Alternatively, we could
make i-s behave a lot more like g-i-s: it could dump its 'root password'
and 'date/time' spokes, and only run at all, and only to allow user
creation, if you didn't create a user during anaconda.
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
I've been asked by Luya Tshimbalanga <luya(a)fedoraproject.org> to
maintain the gimp-separate+ package for official Fedora project so that
it can be included in Design Suite Livemedia.
Having read some introductory information, I would now like to introduce
myself with few short facts:
- I'm using Linux (at start Red Hat, later Fedora) since roughly 1997.
- To ease the maintenance of my systems, I'm creating RPM packages "just
for myself" since 1998 - this one seems to be the oldest one:
- I'm supporter of Free and Open Source Software and small-scale
contributor, more recently broadening it with participation in Open Data
- Now, Luya's invite finally pushed me to come closer to the Fedora project.
- I'm earning a living by doing software development and related
- I'm married with two children.
I'm looking forward for future cooperation. And I would also like to
thank in advance to all which will help me to get through initial stages
of first package submission
Peter Hanecak <hany(a)hany.sk>
In Fedora 20, we'll be using BlueZ 5.x to manage Bluetooth devices.
Bluez5 uses a D-Bus API that's not compatible with Bluez4 and as
such, management applications and a number of libraries and daemons will
need to be ported.
For GNOME 3.10 (due September 2013), Gustavo Padovan and I are going to
be porting gnome-bluetooth, NetworkManager and PulseAudio to BlueZ5.
Packages for BlueZ5 will be available as soon as we figure out how to
integrate a few downstream features that were in the Fedora packages.
Bluez4 and Bluez5 are not parallel-installable, and incompatible, so
other applications relying on Bluez4 will need to be ported by their
I'm the current Fedora maintainer of the twinkle package.
Sadly, it's in poor shape:
- Segfaults on start in recent fedora versions (depending on config).
- Has not had an upstream release in 4+ years.
- Has not had any response from upstream maintainer in at least that
- Uses Qt3 and a complex stack of c++ libraries.
- 8 open bugs:
Debian removed it last year, Arch moved it to a user repo instead of
the main repo last year.
So, I am going to retire this package in rawhide soon unless there's
folks with a very strong C++ background wishing to fix issues and
basically become the new upstream.
although package Docky was lot of work for me (licensing patching etc) I
am no longer using it and last two releases were very unstable. There
are couple of bugzillas reported mainly because of gconf migration.
Docky is an advanced shortcut bar that sits at the edges of your screen.
It provides easy access to some of the files, folders and applications
on your computer, displays which applications are currently running,
holds windows in their minimized state and more.
Docky is written in mono.
Please ping me if you are interested to maintain the package.
Lukas "lzap" Zapletal