devel April 2019

devel@lists.fedoraproject.org

195 participants
311 discussions

F31 Self-Contained Change proposal: Include several modules in the EFI build of Grub2 for security use-cases
by Ben Cotton 15 Jul '19

15 Jul '19

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-signa… https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#E… == 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

6 8

rpmlint: library-not-linked-against-libc (parts of Python stdlib, after gcc 9)
by Miro Hrončok 08 Jul '19

08 Jul '19

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

7 19

Orphaning all my packages
by Jens Lody 16 Jun '19

16 Jun '19

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- ) )-,_..;\ ( `'-' '---''(_/--' `-'\_)

2 1

glibc-arm-linux-gnu help
by Tom Callaway 15 Jun '19

15 Jun '19

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 6

Node.js 12.x Plans for F31+
by Stephen Gallagher 14 Jun '19

14 Jun '19

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.

2 6

Octave 4.4 update coming soon to rawhide
by Orion Poplawski 13 Jun '19

13 Jun '19

I've planning on building octave 4.4 soon (next day or two) in rawhide. I've been building dependent packages here: https://copr.fedorainfracloud.org/coprs/g/scitech/octave4.4/packages/ Anyone in the scitech group can submit builds there if needed. Notes on needed changes to packages are here: https://docs.google.com/spreadsheets/d/1bBEe4Ng3TBUh-EWOQTZt_SvbBYoKWgrC-qH… I'm going to start working on PRs for the various changes for maintainers to review. Of note: - swig requires updating to a git snapshot to get octave 4.4 support - pfstools needs an update to 2.1.0 - NLopt updated to 2.5.0 - switches to using cmake Orion -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 https://www.nwra.com/

4 6

I plan to remove python2-pep8
by Miro Hrončok 03 Jun '19

03 Jun '19

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#Pr… -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

2 8

Using SCLs to build a C++ library for EL 7?
by Dan Čermák 02 Jun '19

02 Jun '19

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

6 9

Nonresponsive maintainer: salimma
by Miro Hrončok 27 May '19

27 May '19

https://bugzilla.redhat.com/show_bug.cgi?id=1589077 Does anyone know how to contact the maintainer? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

4 4

Planning on retiring alot and python-urwidtrees
by Tomas Tomecek 27 May '19

27 May '19

Hi! I packaged alot [1] for Fedora a long time ago. Alot is a terminal MUA built on top of notmuch. I stopped using it a year+ ago (OT: now I'm thinking of using neomutt). Given that, I'm planning to retire alot (and also python-urwidtrees which is a direct dep). The main problem here is that alot needs python-urwid [2] which is also retired. If anyone wants to step in, please let me know and I can transfer the ownership to you, otherwise, I'll retire it by the end of this week. Miro, thanks for heads-up. [1] https://github.com/pazz/alot [2] https://src.fedoraproject.org/rpms/python-urwid Tomas

1 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel April 2019