F31 Self-Contained Change proposal: Include several modules in the
EFI build of Grub2 for security use-cases
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Include_security_modules_in_efi_Grub2
== Summary ==
Include Grub's "verify," "cryptodisk" and "luks" modules (and if
necessary, relevant "gcry" modules) in grubx64.efi of the
'grub2-efi-x64' package.
== Owner ==
* Name: [[User:pjones| Peter Jones]]
* Email: pjones(a)redhat.com
* Name: [[User:javierm| Javier Martinez Canillas]]
* Email: fmartine(a)redhat.com
== Detailed Description ==
Users utilising secure boot functionality on the UEFI platform cannot
insert modules that aren't in grubx64.efi. Paradoxically, this means
that security-conscious users cannot use grub's verify module, or
employ (near) full disk encryption using cryptodisk and luks.
The security benefits of signature verification would reach more users
if Fedora automated it by incorporating the process into
grub2-mkconfig.
For the long-term, to grant flexibility with grub2 modules on secure
boot instances, it may be advisable to sign the .mod files in the
'grub2-efi-x64-modules' package, modify grub2-mkconfig (or -install)
to copy the necessary modules into the EFI partition when required by
the user's configuration and then allow inserting of signed modules in
secure boot instances.
== Benefit to Fedora ==
This change will allow users to gain trust in the integrity of
early-launch code either through verification of signatures
(particularly useful for initramfs, which is particularly vulnerable
to possible offline modification) or encryption of the boot partition.
== Scope ==
* Proposal owners: Modify grub.macros file to include the
above-mentioned modules in the GRUB_MODULES variable.
* Other developers: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Change only adds modules, so existing users should have no problems.
== How To Test ==
<b>For "verify":</b>
1. Generate a signing key with "gpg --gen-key" and copy it to the EFI partition
2. Add "trust <gpg key>" (but grub may inherit this from shim's MOK)
and "set check_signatures=enforce" to /etc/default/40_custom
3. Run grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
4. Create a file, /tmp/pass, with the key's passphrase, then execute:
for x in $(find /boot -name "*.cfg" -or -name "*.mod" -or -name
"vmlinuz*" -or -name "initramfs*" -or -name "grubenv"); do gpg --batch
--detach-sign --passphrase-fd 0 $x < /tmp/pass; done. Then, shred
/tmp/pass
5. Reboot. If system starts, change is successful
<b>For cryptography modules:</b>
1. Backup boot partition
2. Run cryptsetup luksFormat <boot partition's block device, for
example, /dev/sda2> --type luks1
3. Open luks container and restore backup
4. Add GRUB_ENABLE_CRYPTODISK=y to /etc/default/grub
5. Confirm that /etc/fstab has the correct UUID for /boot
6. Run grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
7. Reboot. Grub should ask for the password created in step 2. If
system then starts, change is successful
(If filesystem root is also encrypted, user may be asked for a
password twice. This can be mitigated with a keyfile for filesystem
root, or use of the clevis package, and likely, a tpm.)
== User Experience ==
Users may optionally elect to verify the integrity of boot code either
through verification of digital signatures or encryption of the boot
partition.
== Dependencies ==
Grub2-efi-x64-modules and grub2-tools-* depend on this package, but
require no change.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Revert the
shipped configuration
* Contingency deadline: Beta freeze
* Blocks release? N/A (not a System Wide Change)
* Blocks product? No
== Documentation ==
https://www.gnu.org/software/grub/manual/grub/html_node/Using-digital-sig...
https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system...
== Release Notes ==
Fedora now supports Grub's detached verify and cryptodisk
functionality natively, even on secure boot systems.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
Pronouns: he/him
4 years, 8 months
rpmlint: library-not-linked-against-libc (parts of Python stdlib,
after gcc 9)
by Miro Hrončok
I've just spotted these when working on Python 3.8.0a1. This happens on 3.7 as
well since GCC 9:
python3-debug.x86_64: E: library-not-linked-against-libc
/usr/lib64/python3.7/lib-dynload/_contextvars.cpython-37dm-x86_64-linux-gnu.so
python3-debug.x86_64: E: library-not-linked-against-libc
/usr/lib64/python3.7/lib-dynload/_testimportmultiple.cpython-37dm-x86_64-linux-gnu.so
python3-libs.x86_64: E: library-not-linked-against-libc
/usr/lib64/python3.7/lib-dynload/_contextvars.cpython-37m-x86_64-linux-gnu.so
python3-test.x86_64: E: library-not-linked-against-libc
/usr/lib64/python3.7/lib-dynload/_testimportmultiple.cpython-37m-x86_64-linux-gnu.so
(Note that there are plenty of other extension modules that do not raise this
error.)
This doesn't happen with latest python3 built prior to the gcc update to 9.
$ rpmlint -I library-not-linked-against-libc
library-not-linked-against-libc:
That isn't helpful either.
I found a similar Debian thing [1] that says:
> It is theoretically possible to have a library which doesn't use any symbols
> from libc...
Do I care? Should I fix something? I honestly have no idea.
[1] https://lintian.debian.org/tags/library-not-linked-against-libc.html
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4 years, 8 months
Orphaning all my packages
by Jens Lody
Dear fellow developers,
I'm no longer able to maintain my packages on Fedora, due to lack of
time and power.
I am maintainer of:
aeskulap,
astyle,
codeblocks,
dvdbackup,
gnome-dvb-daemon,
gnome-shell-extension-openweather,
gnome-shell-extension-panel-osd
All packages build (as far as I know) except for gnome-dvb-daemon which
failed to build on fc30 mass-rebuild.
The two gnome-shell-extensions should be retired in my opinion, because
they are available via extensions.gnome.org (at the moment), but as I
am also upstream maintainer, the will not be continued (at least not by
me).
I'm also upstream maintainer for aeskulap
(https://github.com/jenslody/aeskulap) but will archive the github-repo
sooner or later.
So if somebody is interested in keeping it, she/he should know this and
probably think about becoming upstream.
If anybody is interested in taking one of the projects, please let me
know and send your fas-name, so I can give it to you.
Jens (jenslody)
--
Jens Lody
|\ _,,,---,,_
/,`.-'`' -. ;-;;,_
<|,4- ) )-,_..;\ ( `'-'
'---''(_/--' `-'\_)
4 years, 9 months
glibc-arm-linux-gnu help
by Tom Callaway
A few years ago, I packaged up glibc-arm-linux-gnu, so that Fedora could
have a packaged arm cross-toolchain that was useful (with glibc, it
cannot build anything in userspace). It worked for a while, but lately,
all builds have been failing with this error:
/usr/bin/arm-linux-gnu-ld: skipping incompatible
/usr/lib/gcc/arm-linux-gnueabi/8/libgcc_eh.a when searching for -lgcc_eh
I've looked at it and poked it quite a bit locally, but I can't seem to
get around that. I could really use some help to get this building
again, ideally, updated to 2.28.
All my work is committed to git, no help will be refused.
Thanks in advance,
~tom
4 years, 9 months
Node.js 12.x Plans for F31+
by Stephen Gallagher
Today, the Node.js upstream released 12.0.0, the next in its line of
long-term support releases. I plan to make this the default version of
Node.js in Fedora 31+, but not immediately. I'm currently working on
getting a modular version of 12.x built for F29, F30 and Rawhide. I'll
get that out to updates-testing this week. I'll send out an update
once it's pushed to updates-testing.
Once that's available, I encourage all NPM packagers in Fedora to
start testing their build and runtime with the 12.x module. I will be
filing a Change Proposal and plan to switch the system interpreter for
Rawhide over to 12.x around the end of May or beginning of June.
The exact timing may depend on the current status of the
modules-in-the-non-modular-buildroot work in Fedora. If that's
available by this time, I will retire the non-modular Node.js
interpreter package and make the 12.x module the default stream for
F31+. If it's not available, I'll continue to do what I've been doing
in F29 and F30; building both the modular and non-modular packages.
If you discover that you own NPM packages that are critical and do not
work with Node.js 12.x, please inform me immediately. We'll talk with
upstream and see what we can do about it.
4 years, 9 months
I plan to remove python2-pep8
by Miro Hrončok
Hey. pep8 is no longer released upstream and its successor is called pycodestyle.
I plan to retire python-pep8, as tracked in [1], however there are still too
many consumers of python3-pep8. On the other hand, python2-pep8 is only
buildrequired by:
cachedir - already FTBFS, not dependent upon
genbackupdata - already FTBFS, fails to install, not dependent upon
ovirt-guest-agent - already FTBFS, not dependent upon outside of subpackages
pylast - python2-pylast is not dependent upon
python-cliapp - python2-cliapp is required by:
cachedir
cmdtest - FTBFS, fails to install, required by:
cachedir
genbackupdata
python-larch - FTBFS, not dependent upon outside of subpackages
genbackupdata
python-larch
Maintainers by package:
cachedir mathstuf
cmdtest salimma
genbackupdata salimma
ovirt-guest-agent evilissimo nyoxi
pylast peter
python-cliapp salimma
python-larch salimma
Packages by maintainer:
evilissimo ovirt-guest-agent
mathstuf cachedir
nyoxi ovirt-guest-agent
peter pylast
salimma cmdtest genbackupdata python-cliapp python-larch
Would you like to take python2-pep8? I'd advice against, please update to Python
3 and/or pycodestyle instead.
This is my attempt to follow [2].
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1667200
[2]
https://fedoraproject.org/wiki/Changes/F31_Mass_Python_2_Package_Removal#...
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4 years, 10 months
Using SCLs to build a C++ library for EL 7?
by Dan Čermák
Hi list,
I'm co-maintaining a C++ library that has been continuously updated in
CentOS 7 but a recent change made it incompatible with the default GCC
version available in el7. I.e. the next release (scheduled for the end
of 2019) will FTBFS in CentOS/RHEL 7.
Would it be fine to require a gcc version from a SCL to build this
library? I'm afraid that due to the nature of C++'s non-standardized ABI
it would require all dependent packages to be rebuild with gcc from the
SCL too.
Cheers,
Dan
4 years, 10 months