Note that this change was submitted after the deadline, but since it can be
shipped in an complete state, I am still processing it for Fedora 34.
== Summary ==
We want to add signatures to individual files that are part of shipped RPMs.
These signatures will use the Linux IMA (Integrity Measurement
Architecture) scheme, which means they can be used to enforce runtime
policies to ensure execution of only trusted files.
== Owner ==
* Name: [[User:Puiterwijk| Patrick Uiterwijk]]
* Email: puiterwijk(a)redhat.com
* Name: [[User:Pbrobinson| Peter Robinson]]
* Email: pbrobinson(a)gmail.com
== Detailed Description ==
During signing builds, the files in it will be signed with IMA signatures..
These signatures will be made with a key that’s kept by the Fedora
Infrastructure team, and installed on the sign vaults.
== Benefit to Fedora ==
Having all files signed with a verifiable key means that system owners can
use the kernel Integrity and Measurement Architecture (IMA) to enforce only
verified files can be executed, or define other policies.
== Scope ==
* Proposal owners:
The proposal owners will write the code for sigul to pass the required
arguments, generate the keys in Infrastructure and get them deployed to the
* Other developers:
Nothing needed from other developers
* Release engineering:
A mass rebuild would be nice (as it ensures all packages are signed), but
is not required to implement the change itself.
* Policies and guidelines:
* Trademark approval:
* Alignment with Objectives:
This aligns with the Internet of Things objective.
== Upgrade/compatibility impact ==
For standard Fedora users there will be no impact. If an advanced user was
already signing their own files (for the Fedora shipped RPMs) for IMA
functionality, they will just overwrite the existing signature.
== How To Test ==
The signatures can be tested “in vitro” by running `evmctl ima_verify
--sigfile --key publiccert.der -v myfile.txt`.
This should result in the system reporting “<filename>: verification is OK”.
The full system could be tested by enrolling the Fedora IMA key to the
kernel `_ima` keyring, and adding a policy that verifies (some) files to be
verified against the key. (instructions to follow).
== User Experience ==
If the user deploys an IMA policy to verify all or some files, they should
be able to trust the signatures made by the Fedora build system.
== Dependencies ==
No external package dependencies.
== Contingency Plan ==
* Contingency mechanism: If the change is not finished in time, we have
probably not yet started signing new files. Signing can easily be disabled
by updating the config file should issues arise.
If we did start signing, but haven’t signed everything, that is okay, since
then packages will get signed as they’re bumped by developers, and they’ll
be all signed in the next major release.
* Contingency deadline: We could ship with this feature in an unfinished
* Blocks release? No
* Blocks product? N/A
== Documentation ==
Documentation to follow.
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
lua-filesystem has not been properly updated since 2015; we missed the
1.7.0 release in 2017 and the 1.8.0 release in April last year.
The changelogs seem to indicate this should be backward-compatible, but
if your package depends on the `lfs` module please test:
This package is already in RHEL so there's no EPEL updates, but the
updated spec has been tested on EPEL8 as well.
❯ sudo dnf repoquery --whatrequires lua-filesystem
I've kept the stable autokarma to +3 and disabled the auto-promoting by
time to make sure this does not get accidentally promoted.
Thanks to Robert Scheck for helping modernize the spec (and is now co-
maintaining the package). I've further cleaned it up to match what will
be in the upcoming Lua packaging guidelines.
Michel Alexandre Salim
When we work on rebuilding Python packages with new Python version and when
other provenpackagers rebuild multiple packages at once, I've seen several
problems with packages failing to build from source and/or creating unexpected
breakage in rawhide when built. Usually, some of the following happens:
1. Untested changes
Packager pushes a "simple update" to dist git without checking if it even
builds. It doesn't. Packager has no time to fix this, so they move on for now.
Or they submit a build but never check if it actually built. Provenpackagers who
need to rebuild the package need to figure this out and fix the problem if it is
trivial, or revert the recent commit, when the failure blocks them.
IMHO Provenpackagers should not need to worry about this. Changes should be at
least smoke tested by a mock/scratch build and installation check before
2. Changes that work but are waiting on external factors
Packager pushes a breaking change to dist git (such as a soname bump) before
coordinating the change with the dependent packages, not intending to
immediately build it. A provenpackager rebuilds the package for a different
reason (such as a different soname bump), accidentally shipping the
not-yet-wanted upgrade to rawhide.
IMHO Provenpackagers should not need to worry about this. Commits should land in
dist git only when they are intended to be built (close to) immediately. The
only reasonable exception is when building the pushed changes in a side tag and
even then, packagers should communicate their intentions.
3. Work-in-progress changes
Packager works on a package. They have a work in progress solution to their
problem, but no time to finish. They push a "WIP" commit that either breaks the
build or produces a broken package. The symptoms are similar to (1) or (2). I've
heard packagers saying "but this is rawhide, this is where development happens,
so this is expected" - I disagree.
I'd like to explicitly say that neither of this is considered a good behavior.
I'd like to have a policy that more or less says:
1. Packagers MUST NOT push changes that are not considered ready to be built and
shipped at the time of the push. Using Pull Requests (clearly marked as not
ready to be merged) is a better place to present/save changes that are not ready
2. Packagers SHOULD preemptively check if the changes they intend to push work.
At least checking if the intended change builds and the package installs with it
is strongly recommended. In cases where the check is skipped for time reasons
(e.g. when a testing build takes several hours and the changes are urgent),
packagers SHOULD be ready to fix the build/installation failure in timely manner
after it is discovered by the actual build.
Before I try to word it more carefully I'd like to hear some feedback on this.
What do you think?
I've not been using Ocaml recently, and have not been able to give
these packages the attention they deserve.
I'll be orphaning them; in all cases there's only exactly one
comaintainer (Ding-Yi Chen) so they'll be the primary maintainer going
Michel Alexandre Salim
chat via email: https://delta.chat/
GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2
George Bastin writes:
> Sorry Marius, it is not a violation of any law.
Right. By the way, banning everyone from an organization from using a
mailing list: that's not a violation of any law, either. It would also not
be a violation of any law to notify administrators of other mailing lists
what a certain organization tends to use mailing lists for. This will also
be perfectly legal.
> You address is on a public mailing list, which anyone in the world can
A "public mailing list" is not a synonym for being open to "anyone in the
world can" to send any message, on any topic, to the mailing list. I'm
wondering what you would think about me sending a picture of my cute kitty-
cat to this mailing list. Would that be appropriate? How come? After all,
this is a public mailing list, and that's the only justification you offered
for your action, quote: this is a "public mailing list". There were no
further constraints. So, if this is good enough for your email, it should be
good enough for my email too, with a picture of my kitty-cat.
I wonder, what would be the sentiment if I proposed to deprecated the
`fedpkg local` command. I don't think it should be used. Mock should be
the preferred way. Would there be anybody really missing this functionality?
On Mon, Jan 25, 2021 at 11:17 AM Graham White <graham_alton(a)hotmail.com>
> I'm trying to get to the bottom of bug #1901065 -
> Anyone know why PackageKit-gtk3-module.i686 has been removed from the
> Fedora 33 repositories? This package was there for Fedora 32 and checking
> Koji it looks like the 32-bit version is still being built. However, for
> some reason it's not appearing in the F33 repositories for the x86_64
> architecture. We have some packages that rely on the 32-bit version so it
> would be good to have it re-included in the repo.
Multilib detection (which i686 packages should end up in x86_64 repos) is
done in Pungi. There is some heuristics which I haven't found documented
anywhere (one would think it should be in the packaging docs). A
whitelisting of some package can be requested here:
However, as you can see, the maintainers don't respond much to such
requests :-( Perhaps Mohan, Kevin or others could shed a light here how to
best make sure those requests are noticed? Thanks.