license of the binary policy
by Jilayne Lovejoy
Hi Fedora legal and packaging,
I'm cross-posting this, as I think it's relevant to both groups.
The current policy for filling out the license field of the spec file
(as described at
https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidel...
) states, "The License: field refers to the licenses of the contents of
the binary rpm. When in doubt, ask."
As we consider how to improve documentation related to Fedora licensing,
it would be helpful to hear people's thoughts on the following:
1) how do you (package maintainers) interpret this policy in practice?
2) what further information/documentation about this policy would be
helpful?
3) should this policy be different, and if so, how?
4) any other related thoughts or observations
Thanks!
Jilayne
2 months, 1 week
Rust crates with optional namespacing and how to map them to package names
by Fabio Valentini
Hi all,
I'm sorry in advance for the wall of text below, but I think it adds
some necessary context to this issue.
The cargo RFC for "Packages as (optional) namespaces" was recently
approved, and will likely be implemented in a future version of cargo,
and on the official package registry, crates.io:
c.f. https://github.com/rust-lang/cargo/issues/12901
c.f. https://github.com/rust-lang/rfcs/pull/3243
With this being an *optional* namespacing, this raises a few problems
for packaging. For example, the 1:1 mapping of crate name <-> package
name is no longer possible, since there will be zero or one namespace
associated with crates. I have found no other language-specific
package registries that use "zero or one" namespaces other than NPM,
so I don't think there's good "prior art" for this problem. Other
language-specific registries I've looked at either use *no*
namespacing at all, or always use *exactly one* level of namespacing -
but not "zero or one", as will likely be implemented in the Rust crate
ecosystem.
After having been made aware of this RFC, I commented on the upstream
tickets, warning them that this is a rather unusual setup, and will
likely cause issues with how Fedora packages Rust crates. One of the
Rust package maintainers from Debian added a similar comment. It looks
like these decisions were made without considering the broader
ecosystem and / or downstream consumers of Rust crates, and I only
became aware of this "pending approval" RFC very late in the process,
since there doesn't seem to have been any outreach to downstream
consumers of Rust crates (neither any Fedora, nor any Debian Rust
packagers were aware).
With the RFC having been approved, it now raises the issue of how to
represent the new optional namespace name in package names in Fedora.
There was some discussion in the upstream ticket(s) about this, and I
don't much like my conclusions - but here's a summary:
- The only characters allowed in names of crates that are published on
crates.io are a-z, A-Z, 0-9, hyphen, and underscore. These are all
acceptable for RPM package names, which has allowed us to map "project
published as $crate" -> "crate packaged as rust-$crate" without
collisions (disregarding any possible collisions due to compat version
suffices, which luckily has not happened yet).
- The proposed separator between crate namespace and crate name is
`::`(two colons, just like the import path separators in "use"
statements in Rust code). This is not a valid character in RPM package
names.
- The intersection of the three sets "ascii characters", "characters
that are valid in RPM package names", and "characters that cannot be
part of a crate name" is vanishingly small. To the best of my
knowledge, the intersection only contains two characters - the plus
sign `+` and the dot `.`.
- Rust crates as they are packaged in Fedora already use the `+`
character as a separator for a different purpose in "feature
subpackages'' (i.e. rust-$crate+$feature-devel), similarly to how
Python packages handle "extras" with additional subpackages.
As best as I can tell, this leaves us with only two options:
The first option would be to adopt the `.` character as the separator
character between crate namespace and crate name, as that appears to
be the only choice that does not lead to any ambiguities (hyphen and
underscore characters can be part of both crate namespace and crate
name, and the plus sign is already used for a different purpose) -
i.e. source packages being named like `rust-$namespace.$crate`, and
subpackages being named like `rust-$namespace.$crate+$feature-devel`.
The second option would be to "overload" the meaning of the `+` sign,
and use it both as a separator between "crate namespace" and "crate
name" *and* as the separator between "crate name" and "feature name".
In this case, both the source package name and the binary package
names will contain the `+` character. Using the `.` as the new
separator, the source package names would not contain any `+`
characters.
However, this would not result in unambiguous package names in all
cases (in particular, for "binary" packages). A `+` sign in the source
package name unambiguously means that the project consists of both
namespace *and* name, but in built "-devel" packages, only the
occurrence of two `+` characters is unambiguous. However, for "-devel"
packages that contain only one `+` character, it is possible for both
`rust-$namespace+$crate-devel` (i.e. the "main" binary package, which
encodes all mandatory dependencies for project "$namespace::$crate")
and `rust-$crate+$feature-devel` (i.e. the binary package that encodes
dependencies for the feature "$feature" for project "$crate") to
coincide, with two source packages for different projects resulting in
binary packages of the same name.
I also don't consider this an "unlikely" thing to happen - rather, I
think it will be *very likely*. For example, a future `serde::derive`
crate and the subpackage for the "derive" feature of `serde` crate
would both result in binary packages named `rust-serde+derive-devel`.
Using the `.` as the separator character, these two cases would result
in unique package names instead (i.e. `rust-serde.derive-devel` and
`rust-serde+derive-devel`, respectively).
So, the only choice that does not lead to ambiguities and name clashes
appears to be to use the `.` character as the new separator between
namespace name and crate name.
The Packaging Guidelines are not really helpful in this case - they
seem to only stipulate that the plus sign `+`, the dot `.`, and the
underscore `_` MUST NOT be used as separators when packaging a
project, but this only seems to apply to the source package name (?)
if the upstream project's name consists of multiple parts, and already
doesn't fit with "extra" feature packages like the ones that are used
in Python or Rust packaging already. If we really need to adopt the
`.` character as a new separator for namespaced Rust crates, I will
ask the FPC to amend this section of the Packaging Guidelines to allow
uses case like this, where there really is no other option:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#_separa...
I'm open to discuss other options, but I don't see any. Please let me
know what you think.
Fabio
6 months, 2 weeks
Do we have a packaging policy for setuid now (was: Re: Documentation for F15's "Remove SETUID" Change?)
by Richard W.M. Jones
Resurrecting this thread ...
On Tuesday, March 1, 2022 6:43:57 PM EST Michel Alexandre Salim wrote:
> The subject of setuid came up in a private conversation recently, and to my
> surprise we don't seem to have it documented in the packaging guidelines:
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/
>
> Per https://fedoraproject.org/wiki/Features/RemoveSETUID#Documentation
>
> "We should change documentation on packaging guidelines to talk about
> using file capabilities."
>
> but the only mention of capabilities seem to be that, if you use it or
> suid, PIE must be enabled:
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_pie
>
> Should this be documented somewhere, or if it's there but it's lost in
> the wiki->docs migration, does anyone know where the documentation is?
Do we have this documented now? I can still only find the two links
you've already identified above. Anyway, xscreensaver in Fedora
suffers from the same problem described in this Debian bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007724
I thought I'd either file a bug or post a merge request to make
%_libexecdir/xscreensaver-auth setuid, but I wanted to check if
there's a policy about this first.
JWZ has of course given a lot of thought to security, but the code is
here in case we'd like to audit it:
https://github.com/Zygo/xscreensaver/blob/master/driver/xscreensaver-auth.c
On Wed, Mar 02, 2022 at 07:11:42PM -0500, Steve Grubb wrote:
> As someone involved in that change, the situation was much worse back in
> 2011. Almost everything was running as root. The inspection tools back then
> were non-existent, which is what I wrote pscap and netcap.
>
> Now, a lot of things use capabilities with a few still running as root when
> they don't need to be. But I have not looked at all daemons. The lesser used
> ones may need checking. But I think maybe some guidance could be good.
> Something like:
Can you comment on whether the code above should or could use
capabilities? It seems to need to do a broad range of things as root,
not just editing /proc/self/oom_score_adj.
> In general, if the package has --with-libcap or --with-libcapng, turn that
> on. If a daemon can run as non-root with capabilities fix the config file to do
> that. If you have to give CAP_DAC_OVERRIDE to a daemon/application, you
> probably have file ownership problems. Depending on the nature of the problem,
> one solution for this is to use group permissions to allow access.
>
> One option for not running as root can be the systemd capabilities options if
> the app does not natively support capabilities. It should be noted that
> systemd does this by using ambient capabilities. Ambient capabilities have
> the property that any children also get the capabilities. And so does their
> children and on and on.This means that if the daemon is exploitable and the
> attacker launches a shell, the shell will also get the capabilities of the
> parent. This makes them a target for attack.
>
> Any app with ambient capabilities should specifically drop them first thing
> after startup. Dropping ambient capabilities does not drop the normal
> capabilities. However, apps that use the systemd capabilities do so because
> they are typically capability unaware. That means they are not likely to be
> able to drop ambient capabilities. One solution is to add LD_PRELOAD=/usr/
> lib64/libdrop_ambient.so.0. It drops ambient capabilities in the library
> constructor so the app is defanged.
>
> I think the PIE thing should not be related to setuid or capabilities. The
> guidance now should be everything should be PIE and full RELRO. That should
> be reflected in the rpm-macros package.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
6 months, 2 weeks
Kde plasma doesn’t start after dnf update
by Francesco Alfano
Hi,
I use Almalinux 9.2, after an update with *dnf update* on 12 - Nov 2023 the
Kde Plasma won’t start.
The log reported: cannot install kf5-akonadi-server-22.12.3-1.el9.x86_64
…
nothing provides qt5_qtbase(x86-64) = 5.15.9
The qt required are available for almalinux beta version 9.3
I tried to downgrade, but apparently, the epel repository doesn’t store
previous versions
When I try I have messages like:
cannot find rpm nevra “PackageKit-Qt5-1.0.2-4.el9.x86_64”
How can I put back the previous epel packages, or allow all packages to be
updated?
Is it possible for you to enable me to access the previous version of the
repository?
Unfortunately, currently, I am unable to provide more information for the
log as I do not have a working graphical environment and I am using a
tablet.
6 months, 3 weeks
Library sonames
by Benson Muite
The packaging guidelines indicate that shared libraries should have
sonames, and if not provided by upstream, packager should use a low
number soname such as 0.x.y to enable easy bumping of the soname should
upstream later add one. This assumes semantic versioning. If upstream
does not use semantic versioning, is it reasonable to use whatever
versioning scheme they use? One alternative is libtool versioning[1,2].
What to do if the versioning scheme is unclear? In particular is
versioning such as:
libSDL-1.2.so.0 -> libSDL-1.2.so.1.2.68
libserf-1.so.0 -> libserf-1.so.1.3.9
libutempter.so.0 -> libutempter.so.1.2.1
reasonable
or should these all be
libSDL-1.2.so.1 -> libSDL-1.2.so.1.2.68
libserf-1.so.1 -> libserf-1.so.1.3.9
libutempter.so.1 -> libutempter.so.1.2.1
These issues have arisen when reviewing [3]
1) https://autotools.info/libtool/version.html
2)
https://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning....
3) https://bugzilla.redhat.com/show_bug.cgi?id=2241062
6 months, 3 weeks
Guidance needed regarding running `ant` in %prep
by Sandro
Hi,
During review of a package I submitted [1], the reviewer asked me to
move running an `ant` script from %prep to %build.
However, I feel that step belongs in %prep for two reasons:
1. It's a preparatory step for the Python build that follows
The `ant` job provides codec mappings (from Java Charsets), which are
subsequently used in the Python package. The process is described in the
CodecMapper README [2].
2. It would be (needlessly?) more complicated to do that in %build
I need to prep the sources and move stuff around for the Python package
to live at the top level, before calling `%pyproject_buildrequires`,
which is done before %build.
The actual Python package, from which the PyPI sdist and wheel are
produced lives in a sub directory of the CodecMapper repository [3].
Unfortunately, the PyPI sdist is incomplete. That's why I'm using the
GitHub sources.
I'd appreciate any guidance with regards to permissibility and/or
alternative approaches.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2244402
[2] https://github.com/roskakori/CodecMapper#codecmapper
[3] https://github.com/roskakori/CodecMapper/tree/master/ebcdic
Cheers,
--
Sandro
FAS: gui1ty
IRC: Penguinpee
Elsewhere: [Pp]enguinpee
6 months, 4 weeks
