what is wrong with this conditional scriplet on rpm.spec
by Sérgio Basto
Hi,
I just notice build in mock or koji this scriptlet [1] on a build for
Fedora gives me "is rhel 8 or 9" , what I'm missing ?
Thank you
[1]
%if ! 0%{?rhel} >= 8
echo "is not rhel >= 8"
%else
echo "is rhel 8 or 9"
%endif
--
Sérgio M. B.
2 years, 2 months
CVE-2021-4034: why is pkexec still a thing?
by Adam Williamson
Hi folks!
For anyone who hasn't seen it yet - there's quite a kerfuffle today
about a major security issue in polkit:
https://arstechnica.com/information-technology/2022/01/a-bug-lurking-for-...
turns out that ever since it was invented, `pkexec` has had a bug
allowing for local root privilege escalation. Which is...bad.
The issue and some of the comments around it prompted me to wonder -
why is `pkexec` still a thing? Particularly, why is it still a thing we
are shipping by default in just about every Fedora install?
My best recollection is that pkexec was kinda a kludge to allow us to
get rid of consolehelper: some apps weren't getting rewritten to the
Right Way of doing things under policykit, they still just wanted to
have the entire app run as root, and pkexec was a way to make that
happen.
But that was then, and this is now. Does anything in Workstation use
pkexec? Does anything in KDE use it? I'm pretty sure (at least I really
hope!) nothing in Server uses it. I don't think any of our
documentation recommends its use for interactive execution of things as
root (these days we tend to just specify `sudo` for that and assume the
install has an admin user).
Should we just split it out of the polkit package into a subpackage and
stop shipping the subpackage on those editions/spins at least? If
there's anything in other desktops still using it, it can grow a
dependency on the subpackage...
Am I forgetting some other reason we still need it?
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
2 years, 2 months
Announcing LLVM Snapshot Packages for Fedora Linux
by Konrad Kleine
Dear Fedora packagers, developers and users,
we have some good news for you:
We are beginning to build nightly snapshot packages of LLVM for the latest
versions of Fedora Linux (currently 34, 35 and rawhide) for a growing list
of
architectures.
You can grab them here:
https://copr.fedorainfracloud.org/coprs/g/fedora-llvm-team/llvm-snapshots/
Feel free to enable the copr repository with
$ dnf copr enable @fedora-llvm-team/llvm-snapshots
and then install the i.e. latest clang with
$ dnf install clang
Beware, that a snapshot release of LLVM is probably more unstable than a
regular release! If you run into a problem, I would kindly ask you to wait
and try it again with the next snapshot.
We hope you enjoy this peek into the next version of LLVM that you can now
try without too much hassle and without compiling it every day on your own.
Regards,
Konrad Kleine
Senior Software Engineer, Platform Tools
Red Hat <https://www.redhat.com>
kkleine(a)redhat.com
M: +49(0)151/21000244
D87A 77F4 2A58 C72D 12A7 203B C0A0 2C32 BCB7 3099
<https://www.redhat.com>
2 years, 2 months
Retire openCOLLADA?
by Richard Shaw
It seems to fail with gcc 12 due to uninitialized variables. That's easy
enough to work around but the last release was in 2018 and the only
consumer in Fedora in Blender.
Maybe it's time to retire it?
I would hate that as it's actually my first package...
Thanks,
Richard
2 years, 2 months
Self Introduction: Stewart Smith
by Stewart Smith
Hi there, I’m Stewart, a Principal Engineer at AWS working on Amazon
Linux, and thanks to our new direction in basing Amazon Linux on Fedora,
also Fedora.
I have a (decently) long time Linux history, remembering Slackware 3.5
on floppies, RedHat (not RHEL) 5 from CD-ROM, MkLinux, and YellowDog
(yay PowerPC). I’ve spent the vast bulk of my carreer around the free
software ecosystem, having spent a long time in the MySQL community, and
more recently OpenPOWER, and now working on Amazon Linux.
I have a few areas of interest that I’d personally love to contribute
around and see progress in the Fedora ecosystem. The idea of atomic
updates and rollback with systems like rpm-ostree is quite fascinating
from an operational point of view (my personal desktop is currently
running Silverblue), and likely fits really well with the versioned (and
version locked) repositories we’re doing with Amazon Linux 2022 and
beyond. I also think there’s a lot of interesting supply chain assurance
we can do to ensure continual and increased confidence in the open source
ecosystem and way of development. Then there’s things like performance,
boot times (including time-to-first-useful-work), image based
deployments (who needs an installer when you can have cloud-init or
similar to init things). So, that's a few areas of interest :)
With my AWS hat on, I’m pretty excited to see what we do over the coming
years with Fedora and Amazon Linux, and growing the number of people who
have working on Fedora as part of their day job (and yes, we're hiring).
2 years, 2 months
Orphaning some packages (w3c-markup-validator fallout)
by Nathanael D. Noblet
Hello,
I recently gave ownership of w3c-markup-validator to Sérgio Basto
which reminded me that there are a handful of perl packages that I
probably created/took a hand in as part of that. I haven't touched them
in as long as w3c-markup-validator so probably should also orphan them
as well. There are also some other packages like dspam that were great
at the time and I used to use them but they don't get much if any
development anymore and I don't run mail servers anymore.
The are as follows:
dspam
html401-dtds
perl-Config-General
perl-HTML-Encoding
perl-HTML-Tidy
perl-Mail-MBox-MessageParser
perl-Mail-MBox-MboxParser
perl-SGML-Parser-OpenSP
php-pecl-cairo
wkhtmltopdf
I will orphan them sometime next week if someone does want them. That
or retire but I don't know/remember what depends on them.
Sincerely,
--
Nathanael
2 years, 2 months
gcc-12.0.1-0.3.fc36 now in rawhide
by Jakub Jelinek
Hi!
A new gcc with most importantly the https://gcc.gnu.org/PR104172
bug (that caused a lot of ppc64le failures) fixed and various other
fixes (e.g. std::basic_string(std::nullptr_t) = deleted only done
for C++23 etc.) is now in rawhide.
Can rel-eng please retry all FTBS builds that failed on ppc64le?
Thanks
Jakub
2 years, 2 months
the meaning of pkgconfig's Libs fields
by Zbigniew Jędrzejewski-Szmek
Hi,
various .pc files that we ship contain a lot of stuff in the Libs and
Libs.private field don't make much sense to me. I started looking at
the documentation, and the documentation is very scarce, and what is
there doesn't seem to have been thought out at all. I'm writing my
observations and questions below.
pc(5) says:
Libs: Required linking flags for this package. Libraries this
package depends on for linking against it, which are not
described as dependencies should be specified here.
Libs.private: Required linking flags for this package that are
only required when linking statically. Libraries this
package depends on for linking against it statically, which
are not described as dependencies should be specified here.
"described as dependencies" here means "not listed in Requires and
Requires.private fields, which are used to specify dependencies on
other pkgconf projects.
On the face, this seems reasonable, but there's other documentation
that has a different spin. E.g.
https://people.freedesktop.org/~dbn/pkg-config-guide.html says:
Libs: The link flags specific to this package and any required
libraries that don't support pkg-config.
Libs.private: The link flags for private libraries required by
this package but not exposed to applications. The same
rule as Cflags applies here.
"required" here refers to using Requires and Requires.private to
list other .pc files.
Neither of the above approaches seems to be consistent with how we
actually use .pc files, and even not much consistent with how they
could be reasonably used:
1. pc(5) talks about "package", as if one would want to link to a
whole "package" instead one of the specific library files provided
by a package. Thankfully most .pc files only list one "-l" in Libs.
(Counterexamples: tbbmalloc_proxy.pc says 'Libs:-ltbbmalloc_proxy -ltbbmalloc',
and mit-krb5.pc says Libs:-lkrb5 -lk5crypto -lcom_err.)
The concept of having multiple libs in Libs in itself is borked:
either the libraries are functional separately, in which case they
would better have separate .pc files, so that the programs using
those libraries can link to the one they need, or if they are not
functional separately, the one that exposes functionality that is
useful externally should be advertised (the others will be pulled
in automatically by the linker).
2. In practice, most .pc files that list multiple things in Libs seem to
be doing exposing their own link dependencies there. For example
mono-2.pc says 'Libs: -L${libdir} -lmono-2.0 -lm -lm -lpthread',
and indeed ldd /usr/lib64/libmono-2.0.so says it is linked to libm.so.6.
Of course this doesn't mean that programs using libmono would need to
be linked to libm themselves.
Items 1 + 2 are promoting overlinking, i.e. adding either unneeded
libraries, or libraries that are used indirectly, to linker flags for
some object being linked.
If we take the pc(5) definition at its word, the Libs.private lines
are even more broken in Fedora, because we almost never provide static
libraries.
Looking at Requires and Requires.private, there is more strangeness.
pc(5):
Requires: Required dependencies that must be met for the package
to be usable. All dependencies must be satisfied or the
pkg-config implementation must not use the package.
Requires.private: Required dependencies that must be met for the
package to be usable for static linking. All dependencies
must be satisfied or the pkg-config implementation must
not use the package for static linking.
To a large extent pkgconfig files are duplicating dependency logic
that is already provided by distro packaging (rpm in our case). This
would seem like an OK idea: upstreams specify which libraries they
need and downstreams use it.
It seems not to work in practice: e.g. atk-bridge-2.0.pc specifies
Requires.private: dbus-1 >= 1.5, atspi-2 >= 2.33.2, atk >= 2.36.0,
glib-2.0 >= 2.32.0, gmodule-2.0 >= 2.0.0, gobject-2.0 >= 2.0.0
which is translated into:
$ rpm -qRf /usr/lib64/pkgconfig/atk-bridge-2.0.pc
/usr/bin/pkg-config
pkgconfig(atk) >= 2.36.0
pkgconfig(atspi-2) >= 2.33.2
pkgconfig(dbus-1) >= 1.5
pkgconfig(glib-2.0) >= 2.32.0
pkgconfig(gmodule-2.0) >= 2.0.0
pkgconfig(gobject-2.0) >= 2.0.0
...
Two problems:
3. We autogenerate a dependency on /usr/bin/pkg-config for -devel.
Logic is reversed here: the -devel package **provides** something
that it consumed by pkg-config. Dependencies are from a consumer to
the providing entity.
4. The -devel subpackage pulls in atk-devel, at-spi2-core-devel,
dbus-devel, glib2-devel, and glib2-devel. Most of those dependencies
are completely pointless. The only reason why one header package
would require another header package is when the headers it provides
#include other headers. at-spi2-atk-devel has a single header file,
with '#include <glib.h>'. It thus should have a dependency on 'pkgconfig(glib-2.0)',
and all the other deps generated from Requires.private just inflate
the build root. (If glib.h or libglib-2.0.so in turn require other
things for themselves, those dependencies will be specified by glib2.rpm.)
And finally, we get to stuff which is included in Libs:
/usr/lib64/pkgconfig/libresample.pc
Libs: -Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -lresample -lm
/usr/lib64/pkgconfig/libpsx.pc
Libs: -L${libdir} -lpsx -lpthread -Wl,-wrap,pthread_create
/usr/lib64/pkgconfig/ruby.pc
DLDFLAGS=-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
Libs: ${DLDFLAGS} ${LIBRUBYARG_SHARED} ${LIBS}
/usr/lib64/pkgconfig/libresample.pc
Libs: -Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -lresample -lm
/usr/lib64/pkgconfig/socket_wrapper.pc
Libs: lib64/libsocket_wrapper.so
/usr/lib/pkgconfig/gmodule-2.0.pc
Libs: -Wl,--export-dynamic
Those seems to be all errors: redhat-hardened-ld is supposed to be
used in package builds, not exposed for user compilations.
lib64/libsocket_wrapper.so cannot be resolved. And other link flags
that change the resulting binary is not the something that libraries
should specify.
To summarize:
- Re 3: drop the generator for the reversed dep?
- Re 2: flat everything that is not -l, -L, in Libs with rpmlint?
Zbyszek
2 years, 2 months
