fedpkg clone fails with Permission denied (publickey).
by Richard Shaw
Long story short I lost my home directory where I do all of my packager
activities (separate from my main user) so I'm setting things up from
scratch.
I created new ssh keys and uploaded the public key to
admin.fedoraproject.org and pasted into pagure.io. It's been over an hour
and I'm still getting:
$ fedpkg clone hamlib
Cloning into 'hamlib'...
hobbes1069(a)pkgs.fedoraproject.org: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Could not execute clone: Failed to execute command.
I've also updated my API tokens, which is STILL not well documented. I
pasted them in the appropriate spot in "/etc/rpkg/fedpkg.conf" which isn't
real intuitive.
Thanks,
Richard
1 year, 4 months
[HEADS UP] -Wl,--as-needed is added in rawhide
by Igor Gnatenko
It's in redhat-rpm-config-118-1.fc30.
If it causes any problems for you - let me know. In the meantime, you can
use `%undefine _ld_as_needed` to disable it.
Thanks for attention!
--
-Igor Gnatenko
1 year, 9 months
Wine MinGW system libraries
by Zebediah Figura
Hello all,
I'm a contributor to the Wine project. To summarize the following mail,
Wine needs special versions of some of its normal dependencies, such as
libfreetype and libgnutls, built using the MinGW cross-compiler, and I'm
sending out a mail to major distributions in order to get some feedback
from our packagers on how these should be built and packaged.
For a long time Wine has built all of its Win32 libraries (DLLs and
EXEs) as ELF binaries. For various reasons related to application
compatibility, we have started building our binaries as PE instead,
using the MinGW cross-compiler. It is our intent to expand this to some
of our dependencies as well. The list of dependencies that we intend to
build using MinGW is not quite fixed yet, but we expect it to include
and be mostly limited to the following:
* libvkd3d
* libFAudio
* libgnutls
* zlib (currently included via manual source import)
* libmpg123
* libgsm
* libpng
* libjpeg-turbo
* libtiff
* libfreetype
* liblcms2
* jxrlib
and dependencies of the above packages (not including CRT dependencies,
which Wine provides).
There is currently some internal discussion about how these dependencies
should be built and linked. There are essentially three questions I see
that need to be resolved, and while these resolutions have a significant
impact on the Wine building and development process, they also have an
impact on distributions, and accordingly I'd like to get input from our
packagers to ensure that their considerations are accurately taken into
account.
(1) Should we build via source import, or link statically, or dynamically?
Static linking and source imports are dispreferred by Fedora [1] [2], as
by many distributions, on the grounds that they cause duplication of
libraries on disk and in memory, and make it harder to update the
libraries in question (see also question 2). They also make building and
bisecting harder.
Note however that if they are linked dynamically, we need to make sure
that we load our packages instead of MinGW builds of open-source
libraries with applications ship with. Accordingly we need each library
to be renamed, and to link to renamed dependencies. For example, if
application X ships with its own copy of libfreetype-6.dll, we need to
make sure that our gdi32.dll links to libwinefreetype-6.dll instead, and
that libwinefreetype-6.dll links to libwineharfbuzz-0.dll and
winezlib.dll. I think, although I haven't completely verified yet, that
this can be done just with build scripts (i.e. no source patches), by
using e.g. --with-zlib=/path/to/winezlib.dll.
Accordingly, although static linking and source imports are generally
disprefered, it may quite likely be preferable in our case. We don't get
the benefits of on-disk deduplication, since Wine is essentially the
only piece of software which needs these libraries.
(2) If we use dynamic libraries, should dependencies be included in the
main wine package, or packaged separately?
This is mostly a question for packagers, although it also relates to (3).
I expect that Fedora (and most distributions) want to answer "packaged
separately" here, on the grounds that this lets them update (say) Wine's
libgnutls separately, and in sync with ELF libgnutls, if some security
fix is needed. There is a snag, though: we need libraries to be copied
into the prefix (there's some internal effort to allow using something
like symlinks instead, but this hard and not done yet). Normally we
perform this copy every time Wine is updated, but if Wine and its
dependencies aren't updated on the same schedule, we may end up loading
an old version of a dependency in the prefix, thus missing the point of
the update.
(3) If dependencies are packaged separately, should Wine build them as
part of its build tree (e.g. using submodules), or find and link
(statically or dynamically) to existing binaries?
Linking to existing binaries is generally preferable: it avoids
duplication on disk; it reduces compile times when compiling a single
package from source (especially the first time). However, we aren't
going to benefit from on-disk duplication. And, most importantly, unlike
with ELF dependencies, there is no standardized way to locate MinGW
libraries—especially if it comes to Wine-specific libraries. We would
need a way for Wine's configure script to find these packages—and
ideally find them automatically, or else fall back to a submodule-based
approach.
If we rely on distributions to provide our dependencies, the best idea I
have here would be something like a x86_64-w64-mingw32-pkg-config. And
if we use shared libraries rather than static, things get worse: we need
to know the exact path of each library and its dependencies so that we
can copy (or symlink) them into a user's WINEPREFIX.
For what it's worth, the current proposed solution (which has the
support of the Wine maintainer) involves source imports and submodules.
There's probably room for changing our approach even after things are
committed, but I'd still like to get early feedback from distributions,
and make sure that their interests are accurately represented, before we
commit. In short, it's not clear whether distributions want their
no-static-library policies to apply to us as well, or whether we're
enough of a special case and would be enough of a pain to package that
they'd rather we deal with the hard parts, and I don't want us to make
any assumptions.
ἔρρωσθε,
Zebediah
[1]
https://docs.fedoraproject.org/en-US/packaging-guidelines/#packaging-stat...
[2] https://fedoraproject.org/wiki/Bundled_Libraries
1 year, 10 months
OpenJDK and unremoved directories
by Vitaly Zaitsev
Hello.
I have a lot of unremoved directories and files in /usr/lib/jvm/:
$ ls -l /usr/lib/jvm/
total 140
drwxr-xr-x. 5 root root 4096 Sep 10 14:32
java-11-openjdk-11.0.12.0.7-4.fc34.x86_64
drwxr-xr-x. 3 root root 4096 Mar 14 2017
java-1.8.0-openjdk-1.8.0.121-10.b14.fc25.x86_64
drwxr-xr-x. 3 root root 4096 Apr 21 2017
java-1.8.0-openjdk-1.8.0.131-1.b12.fc25.x86_64
drwxr-xr-x. 3 root root 4096 Oct 25 2017
java-1.8.0-openjdk-1.8.0.151-1.b12.fc26.x86_64
drwxr-xr-x. 3 root root 4096 Oct 25 2017
java-1.8.0-openjdk-1.8.0.151-1.b12.fc27.x86_64
drwxr-xr-x. 3 root root 4096 Jan 24 2018
java-1.8.0-openjdk-1.8.0.161-0.b14.fc27.x86_64
drwxr-xr-x. 3 root root 4096 Feb 6 2018
java-1.8.0-openjdk-1.8.0.161-5.b14.fc27.x86_64
drwxr-xr-x. 3 root root 4096 Mar 29 2018
java-1.8.0-openjdk-1.8.0.162-3.b12.fc27.x86_64
drwxr-xr-x. 3 root root 4096 Apr 18 2018
java-1.8.0-openjdk-1.8.0.171-1.b10.fc27.x86_64
drwxr-xr-x. 3 root root 4096 Apr 25 2018
java-1.8.0-openjdk-1.8.0.171-4.b10.fc27.x86_64
drwxr-xr-x. 3 root root 4096 Apr 25 2018
java-1.8.0-openjdk-1.8.0.171-4.b10.fc28.x86_64
drwxr-xr-x. 3 root root 4096 Jul 3 2018
java-1.8.0-openjdk-1.8.0.172-12.b11.fc28.x86_64
drwxr-xr-x. 3 root root 4096 Jun 18 2018
java-1.8.0-openjdk-1.8.0.172-9.b11.fc28.x86_64
drwxr-xr-x. 3 root root 4096 Jul 23 2018
java-1.8.0-openjdk-1.8.0.181-7.b13.fc28.x86_64
drwxr-xr-x. 3 root root 4096 Sep 5 2018
java-1.8.0-openjdk-1.8.0.181.b15-0.fc28.x86_64
drwxr-xr-x. 3 root root 4096 Oct 4 2018
java-1.8.0-openjdk-1.8.0.181.b15-5.fc28.x86_64
drwxr-xr-x. 3 root root 4096 Oct 11 2018
java-1.8.0-openjdk-1.8.0.181.b15-6.fc28.x86_64
drwxr-xr-x. 3 root root 4096 Oct 11 2018
java-1.8.0-openjdk-1.8.0.181.b15-6.fc29.x86_64
drwxr-xr-x. 3 root root 4096 Nov 29 2018
java-1.8.0-openjdk-1.8.0.191.b12-11.fc29.x86_64
drwxr-xr-x. 3 root root 4096 Nov 1 2018
java-1.8.0-openjdk-1.8.0.191.b12-8.fc29.x86_64
drwxr-xr-x. 3 root root 4096 Jan 14 2019
java-1.8.0-openjdk-1.8.0.191.b13-0.fc29.x86_64
drwxr-xr-x. 3 root root 4096 Feb 6 2019
java-1.8.0-openjdk-1.8.0.201.b09-2.fc29.x86_64
drwxr-xr-x. 3 root root 4096 Mar 26 2019
java-1.8.0-openjdk-1.8.0.201.b09-6.fc29.x86_64
drwxr-xr-x. 3 root root 4096 Apr 23 2019
java-1.8.0-openjdk-1.8.0.212.b04-0.fc29.x86_64
drwxr-xr-x. 3 root root 4096 Apr 23 2019
java-1.8.0-openjdk-1.8.0.212.b04-0.fc30.x86_64
drwxr-xr-x. 3 root root 4096 Jul 31 2019
java-1.8.0-openjdk-1.8.0.222.b10-0.fc30.x86_64
drwxr-xr-x. 3 root root 4096 Oct 16 2019
java-1.8.0-openjdk-1.8.0.232.b09-0.fc30.x86_64
drwxr-xr-x. 3 root root 4096 Oct 16 2019
java-1.8.0-openjdk-1.8.0.232.b09-0.fc31.x86_64
drwxr-xr-x. 3 root root 4096 Jan 28 2020
java-1.8.0-openjdk-1.8.0.242.b08-0.fc31.x86_64
drwxr-xr-x. 3 root root 4096 Mar 23 2020
java-1.8.0-openjdk-1.8.0.242.b08-1.fc32.x86_64
drwxr-xr-x. 3 root root 4096 May 4 2020
java-1.8.0-openjdk-1.8.0.252.b09-0.fc32.x86_64
drwxr-xr-x. 3 root root 4096 May 22 2020
java-1.8.0-openjdk-1.8.0.252.b09-1.fc32.x86_64
drwxr-xr-x. 3 root root 4096 Jul 17 2020
java-1.8.0-openjdk-1.8.0.262.b10-1.fc32.x86_64
drwxr-xr-x. 3 root root 4096 Jul 28 2020
java-1.8.0-openjdk-1.8.0.265.b01-1.fc32.x86_64
drwxr-xr-x. 3 root root 4096 Oct 21 2020
java-1.8.0-openjdk-1.8.0.272.b10-0.fc32.x86_64
lrwxrwxrwx. 1 root root 21 Sep 10 14:32 jre -> /etc/alternatives/jre
lrwxrwxrwx. 1 root root 24 Sep 10 14:32 jre-11 -> /etc/alternatives/jre_11
lrwxrwxrwx. 1 root root 32 Sep 10 14:32 jre-11-openjdk ->
/etc/alternatives/jre_11_openjdk
lrwxrwxrwx. 1 root root 41 Aug 31 18:50
jre-11-openjdk-11.0.12.0.7-4.fc34.x86_64 ->
java-11-openjdk-11.0.12.0.7-4.fc34.x86_64
lrwxrwxrwx. 1 root root 29 Sep 10 14:32 jre-openjdk ->
/etc/alternatives/jre_openjdk
I think the OpenJDK's scriplets need to be adjusted to remove everything.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
1 year, 10 months
Heads-up: grpc 1.41.0 coming to Rawhide with C (core) and C++ soname
bumps
by Ben Beasley
In one week (October 6), or slightly later, I will build grpc 1.41.0 for
Rawhide (F36). Fedora 35 will remain on 1.39.1.
As is traditional for minor releases of grpc, the C++ ABI was broken
(soversion bumped from 1.40 to 1.41). This time, the C (core) ABI was
also broken (soversion bumped from 18 to 19).
I will coordinate builds in a side tag of packages that use the C (core)
and/or C++ libraries. Maintainers of the following packages should have
received this email directly:
• bear
• frr
• perl-grpc-xs
Packages that use the Python bindings should be unaffected, as there
should be no incompatible API changes:
• buildstream
• python-chirpstack-api
• python-etcd3
• python-google-api-core
• python-google-cloud-core
• python-grpc-google-iam
• python-opencensus (orphaned)
• python-opencensus-proto
• python-opentelemetry
• python-pytest-grpc
• python-xds-protos
1 year, 11 months
Release criteria proposal: networking requirements
by Adam Williamson
Hi folks!
So at this week's blocker review meeting, the fact that we don't have
explicit networking requirements in the release criteria really started
to bite us. In the past we have squeezed networking-related issues in
under other criteria, but for some issues that's really difficult,
notably VPN issues. So, we agreed we should draft some explicit
networking criteria.
This turns out to be a big area and quite hard to cover (who'd've
thought!), but here is at least a first draft for us to start from. My
proposal would be to add this to the Basic criteria. I have left out
some wikitext stuff from the proposal for clarity; I'd add it back in
on actually applying the proposed changes. It's just formatting stuff,
nothing that'd change the meaning. Anyone have thoughts, complaints,
alternative approaches, supplements? Thanks!
=== Network requirements ===
Each of these requirements apply to both installer and installed system
environments. For any given installer environment, the 'default network
configuration tools' are considered to be those the installer documents
as supported ways to configure networking (e.g. for anaconda-based
environments, configuration via kernel command line options, a
kickstart, or interactively in anaconda itself are included).
==== Basic networking ====
It must be possible to establish both IPv4 and IPv6 network connections
using DHCP and static addressing. The default network configuration
tools for the console and for release-blocking desktops must work well
enough to allow typical network connection configuration operations
without major workarounds. Standard network functions such as address
resolution and connections with common protocols such as ping, HTTP and
ssh must work as expected.
Footnote titled "Supported hardware": Supported network hardware is
hardware for which the Fedora kernel includes drivers and, where
necessary, for which a firmware package is available. If support for a
commonly-used piece or type of network hardware that would usually be
present is omitted, that may constitute a violation of this criterion,
after consideration of the [[Blocker_Bug_FAQ|hardware-dependent-
issues|normal factors for hardware-dependent issues]]. Similarly,
violations of this criteria that are hardware or configuration
dependent are, as usual, subject to consideration of those factors when
determining whether they are release-blocking
==== VPN connections ====
Using the default network configuration tools for the console and for
release-blocking desktops, it must be possible to establish a working
connection to common OpenVPN, openconnect-supported and vpnc-supported
VNC servers with typical configurations.
Footnote title "Supported servers and configurations": As there are
many different VPN server applications and configurations, blocker
reviewers must use their best judgment in determining whether
violations of this criterion are likely to be encountered commonly
enough to block a release, and if so, at which milestone. As a general
principle, the more people are likely to use affected servers and the
less complicated the configuration required to hit the bug, the more
likely it is to be a blocker.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
2 years, 1 month
New tool - license-validate
by Miroslav Suchý
Hi.
I have created new tool license-validate
https://pagure.io/copr/license-validate/
And I packaged it for Fedora. Here is the review request:
https://bugzilla.redhat.com/show_bug.cgi?id=2035680
The goal of this tool is to validate the string in the License tag in the spec file. I.e.
LIcense: GPLv2
---------------^^^^ this part only
It doe **not** check if it actually agree with the actual code or even %license file. We have `licensecheck` for that.
The Fedora's package already contains list of license from Licensing:Main and you can run it as
$ license-validate-v'GPLv1 or (MIT and BSD)'
Approved license
or
$ license-validate-v'GPL or (MIT and BSD)'
No terminal defined for 'G' at line 1 col 1
GPL or (MIT and BSD)
...
Not a valid license string
which fails because GPL is not valid short name.
My next goal will be to download all Fedora's spec files, extract the license line and run it through this script. But I
am going to be few days offline, so anyone who want step in QE shoes can do that - I will not be mad :)
Comments are welcomed.
Miroslav
2 years, 1 month
F36 Change: DIGLIM (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/DIGLIM
== Summary ==
Digest Lists Integrity Module (DIGLIM) provides a repository of file
digests from authenticated sources, such as RPM headers, to be used by
kernel services for remote attestation and/or secure boot at
application level.
== Owner ==
* Name: [[User:robertosassu| Roberto Sassu]]
* Email: roberto.sassu(a)huawei.com
== Detailed Description ==
Integrity Measurement Architecture (IMA), a kernel service for remote
attestation and secure boot at application level, has been integrated
in the kernel since a long time. However, two main barriers limited
its wide adoption. First, it extends a Platform Control Register (PCR)
of the Trusted Platform Module (TPM) in an unpredictable way (due to
parallel execution of software), making it impossible to use that PCR
for sealing policies of TPM keys. Second, it requires that a file
signature is added to the package header for each file to be
appraised.
Digest Lists Integrity Module (DIGLIM) takes a different approach. It
allows IMA to extend a PCR in a predictable way or to verify the
authenticity of files by querying an in-kernel repository of
authenticated reference values, built from information already
available in existing packages (FILEDIGESTS section of the RPM header,
with signature in the RSAHEADER section). Data source authentication
does not require additional key management. With support for PGP keys
in the kernel, the official Fedora PGP keys can be imported to the
builtin keyring of the kernel and used to verify the PGP signature of
the RPM headers.
DIGLIM is not specifically tied to IMA. Since it is based on the hash
table implementation of the kernel, it can store data of different
types or be used by other kernel subsystems. It might for example
store fsverity digests, to achieve the goal of another proposed
[//fedoraproject.org/wiki/Changes/FsVerityRPM change] with less
overhead (by adding to the RPM header digests instead of signatures).
It might also be used by other kernel services, such as
[//lore.kernel.org/linux-security-module/1634151995-16266-1-git-send-email-deven.desai(a)linux.microsoft.com/
Integrity Policy Enforcement (IPE)], a new LSM being proposed for
inclusion in the upstream kernel.
A preliminary performance evaluation showed that DIGLIM does not
introduce a significant overhead. A repository of executables and
shared libraries digests, of a Fedora 33 minimal installation,
occupies less than 800k of memory.
The new feature behaves as follows. A modified kernel with the DIGLIM
patches will expose to user space an interface to add/remove file
digests from the kernel hash table. A user space parser, executed by
the kernel during early boot, parses RPM headers found in /etc/diglim
in the initial ram disk (included with a custom dracut script) and
uploads them to the kernel. When a file is accessed, IMA calculates
the file digest and queries it with DIGLIM. If the digest is found,
measurement is skipped and appraisal is successful. If the digest is
not found, a measurement of the file is performed and appraisal fails.
When packages are installed or removed, the kernel hash table is kept
synchronized with a new rpm plugin.
== Feedback ==
DIGLIM has been proposed some time ago, and was previously known as
IMA Digest Lists.
The original implementation was found to be too invasive, as both the
management of the repository of reference values and the new
measurement and appraisal mechanisms based on the query of the
repository needed to coexist with the existing code. DIGLIM is now
implemented as a standalone module, which includes the repository
management part, and exposes a simple API so that IMA and other kernel
services can use it to implement the query part (much simpler).
At the time IMA Digest Lists was published, the proposal of adding
file signatures to the package header was deemed to be more mature and
suitable for adoption. From [//pagure.io/fesco/issue/2547 previous]
and [//lists.fedoraproject.org/archives/list/devel(a)lists.fedoraproject.org/thread/JE2HGLJMLEKUJW3YBP6MQJWP43CSTC57/
current] discussions, it seems that Linux distribution vendors are a
bit reluctant to make such change, especially due to the increased
size of the packages. DIGLIM just requires a modification of the
kernel, rpm and dracut, and could work on old distribution versions
once the modified packages are installed.
Another remote attestation-specific issue is that the approach of
measuring only unknown software reduces the amount of information
available to remote verifiers for the integrity evaluation of the
system being attested. In particular, a measurement list made with the
DIGLIM approach does not show which file have been actually accessed
and when. This tradeoff was chosen to make the PCR value extended with
software measurements predictable and to allow the usage of sealing
policies based on that PCR.
== Benefit to Fedora ==
The main benefits of DIGLIM have been elaborated
[//lore.kernel.org/linux-integrity/20210914163401.864635-1-roberto.sassu(a)huawei.com/
here].
Briefly summarizing: DIGLIM brings the benefits of kernel services for
integrity detection (measurement) and protection (appraisal) to Linux
distributions, and relieves the distributions from the burden of
managing the integrity functionality.
More specifically, it will make a system running Fedora attestable
without the need of using dedicated remote attestation protocols. In
fact, the assertion that a system is running a specific set of
software will be implicitly implied by the ability of that system to
correctly respond to the other peer in the TLS handshake protocol.
This could be achieved with widely available software such as the
Apache web server, the tpm2 openssl engine and a browser. Also
[//keylime.dev/ Keylime], a Red Hat-based solution for remote
attestation, could make use of the proposed scheme.
It will also make Fedora able to detect tampering of its components at
a more privileged level, the kernel, without the interference of user
space programs. Once tampering has been detected, the actions of the
altered component are prevented before that component gets the chance
to perform any action. Fedora could be configured to also allow the
usage of components provided by the user, if he wishes to do so
(DIGLIM has a tool to build custom digest lists).
== Scope ==
* Proposal owners:
** Maintain the following patch sets for the Linux kernel, and
possibly have them accepted in the upstream kernel:
*** [//lore.kernel.org/linux-integrity/20210409114313.4073-1-roberto.sassu(a)huawei.com/
IMA execution policies]
*** [//lore.kernel.org/linux-integrity/20210914163401.864635-1-roberto.sassu(a)huawei.com/
DIGLIM basic features]
*** [//lore.kernel.org/linux-integrity/20210915163145.1046505-1-roberto.sassu(a)huawei.com/
DIGLIM advanced features]
*** [//lore.kernel.org/linux-integrity/20210930115533.878169-1-roberto.sassu(a)huawei.com/
DIGLIM integration with IMA]
*** [//lore.kernel.org/linux-integrity/20181112102423.30415-1-roberto.sassu(a)huawei.com/
PGP keys and signatures]
*** Support for PGP appended signatures
** Port the [//gitee.com/src-openeuler/rpm/blob/master/Add-digest-list-plugin.patch
digest_list rpm plugin] from openEuler to Fedora:
** Create dracut configuration file/module for copying RPM headers to
the initial ram disk (optimization: copy only RPM headers related to
files in the initial ram disk)
** Introduce [//gitee.com/openeuler/digest-list-tools/blob/master/scripts/setup_grub2
script]to enable IMA measurement/appraisal execution policies in the
boot loader configuration:
* Other developers:
** Review the changes proposed above
* Release engineering: https://pagure.io/releng/issue/10473
** Discuss with Release engineering team about the possibility of
enabling IMA measurement and/or appraisal policies since first boot (a
checkbox in Anaconda would cause the boot loader configuration to be
updated to enable such policies)
** The feature might be enabled later by the user without any change
required for the image generation
* Policies and guidelines: N/A
* Trademark approval: N/A
* Alignment with Objectives: Yes
== Upgrade/compatibility impact ==
The user should ensure that software (not updated) from the old
distribution is packaged and the package header is signed, or he
should create and sign a custom digest list for the software he wishes
to use after the upgrade.
== How To Test ==
DIGLIM is already available for testing. A Fedora 34 kernel package
with DIGLIM is available in this
[//copr.fedorainfracloud.org/coprs/robertosassu/DIGLIM/ copr project].
The installation instructions have been published to the
linux-integrity kernel mailing list
[//lore.kernel.org/linux-integrity/48cd737c504d45208377daa27d625531(a)huawei.com/
here].
== User Experience ==
Both integrity detection and protection will be transparent for the
user. For protection, the user will notice a change only if his
actions (or of a malicious software on his behalf) are not in
accordance with the integrity policy being enforced (e.g. the user
executes an unknown binary).
== Dependencies ==
* kernel
* rpm
* dracut
The feature owner will be responsible to submit all the changes
necessary and will not depend on other developers' work.
== Contingency Plan ==
* Contingency mechanism: remove provided patches from the packages
* Contingency deadline: rebuilding the packages without the new
patches can be done at any time
* Blocks release? No
== Documentation ==
A comprehensive documentation can be found
[//lore.kernel.org/linux-integrity/20210914163401.864635-1-roberto.sassu(a)huawei.com/
here].
== Release Notes ==
Release notes will be derived from the documentation.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 1 month
