devel January 2022

devel@lists.fedoraproject.org

269 participants
383 discussions

Uninitialized variables and F37
by Steve Grubb 16 May '22

16 May '22

Hello, This is a continuation of the discussion from F36 Change: GNU Toolchain Update. Uninitialized variables are a big problem. They can be sources of information exposure if parts of a buffer are not initialized. They can also cause unexpected execution paths if the attacker can groom the memory to a value of their choosing. If the variable is a pointer to heap, this can cause free to corrupt memory under certain circumstances. If the uninitialized memory is part of user input, this can lead to improper input validation. This is not hypothetical. All of these come from a paper doing an emprical study of android flaws. [1] The data used in the paper is here. [2] Part of the problem is that compilers and static analysis tools can't always find them. I created a test program that has 8 uses of unintialized variables. Gcc 11 misses all of them. Gcc 12 finds 2. Clang 13 finds 1. cppcheck finds 2 or 3 - but does so much complaining you'd think it found all. Valgrind finds 2. Flexelint, a commercial linter, finds 1. Since tools can't always find them, the only option we have right now is force initialization to something the attacker cannot control. Kees Cook started a discussion on the llvm developers mail list a while back. He makes a very clear argument. I would be repeating his points, so please read the original discussion here (also read the replies): https://lists.llvm.org/pipermail/cfe-dev/2020-April/065221.html He talks about -ftrivial-auto-var-init=zero being used for production builds and -ftrivial-auto-var-init=<pattern> being used for debug builds. The use is not just the kernel. Consider a server that returns data across the network to a client. It could possibly leak crypto keys or passwords if the returned data structure has uninitialized memory. For more background, the creator of this technology for LLVM presented a talk about this feature at a past LLVM developer conference: https://www.youtube.com/watch?v=I-XUHPimq3o He said this would have prevented over 900 fixed CVE's in Chrome and 12% of all Android CVE's. From deep inside the LLVM thread above, comes this nugget: --- To add in, we (Microsoft) currently use zero initialization technology in Visual Studio in a large amount of production code we ship to customers (all kernel components, a number of user-mode components). This code is both C and C++. We already have had multiple vulnerabilities killed because we shipped this technology in production. We received bug reports with repros that worked on older versions of Windows without the mitigation and new versions of Windows that do have it. The new versions don't repro, the old ones do. --- Microsoft is also digging in to uninitialized variables. They have a lengthy blog post that talks about extending this to heap memory. [3] I think this would be an important step forward to turn this on across all compilations. We could wipe out an entire class of bugs in one fell swoop. But then, what about heap allocations? Calloc has existed for a long time. It might be worthwhile to have a CFLAG that can tell glibc (or other allocators) to substitute something like calloc for malloc. Cheers, -Steve [1] - https://picture.iczhiku.com/resource/paper/shkeTWJEaFUuWCMc.pdf [2] - http://ml-papers.gitlab.io/android.vulnerabilities-2017/appendix/ MSR2017/vulnerabilitiesList.html [3] - https://msrc-blog.microsoft.com/2020/07/02/solving-uninitialized-kernel-poo…

17 39

Heads-up: grpc 1.41.0 coming to Rawhide with C (core) and C++ soname bumps
by Ben Beasley 09 May '22

09 May '22

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 1

ppc64le build failure on F34 and EPEL8, EPEL8-next only
by Germano Massullo 13 Apr '22

13 Apr '22

Good day. darktable maintainer here. I am experiencing a ppc64le build failure on F34 and EPEL8, EPEL8-next only. https://koji.fedoraproject.org/koji/taskinfo?taskID=81021540 https://koji.fedoraproject.org/koji/taskinfo?taskID=81021476 On F34 the error is /builddir/build/BUILD/darktable-3.8.0/src/iop/channelmixerrgb.c: In function '_convert_GUI_colors.part.0.constprop': /builddir/build/BUILD/darktable-3.8.0/src/iop/channelmixerrgb.c:3085:1: internal compiler error: in patch_jump_insn, at cfgrtl.c:1299 3085 | } | ^ Please submit a full bug report, with preprocessed source if appropriate. Other branches can successfully build on aarch64, x86_64, pcc64le. Do you know what can be the problem? Thank you

2 8

GNOME only: KeepassXC quirks
by Germano Massullo 01 Mar '22

01 Mar '22

KeepassXC comaintainer here. There are many Fedora GNOME Wayland users experiencing quirks in using KeepassXC. Textboxes not showing text that is being written, other quirks with GNOME, etc. Upstream developers said many times that this only happen with Fedora users. Myself I do use KDE Spin and I do not experience these issues (tested on Wayland too) I don't paste bugs titles since they are misleading https://bugzilla.redhat.com/show_bug.cgi?id=1925130 https://bugzilla.redhat.com/show_bug.cgi?id=1941731 (CentOS 8) https://bugzilla.redhat.com/show_bug.cgi?id=1954742 https://github.com/keepassxreboot/keepassxc/issues/5608 plus others that I cannot find again at the moment I would like to ask if you have any idea about why this happens on GNOME only (and not on other distros too) Thank you

10 30

Release criteria proposal: networking requirements
by Adam Williamson 01 Mar '22

01 Mar '22

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

9 22

`BuildRequires: /usr/lib/libc.a` fails on epel8 x86_64
by Christoph Erhardt 01 Mar '22

01 Mar '22

Hi list, I'm trying to build mold for epel8. A bunch of mold's unit tests produce statically linked 32-bit binaries, so on x86_64 we need a build dependency on a static multilib glibc. I have learnt that multilib build dependencies are a tricky thing in Koji, and the only solution I have found to work is to specify a filename-based dependency: `BuildDepends: /usr/lib/libc.a` This works fine for rawhide, f35, f34 and epel9 but fails on epel8: ``` No matching package to install: '/usr/lib/libc.a' ``` Full build log: https://kojipkgs.fedoraproject.org/work/tasks/2503/81962503/mock_output.log Any ideas? Best, Christoph

3 7

sphinx: Intention to orphan package
by Sergio Arroutbi 01 Mar '22

01 Mar '22

Hello. I recently assumed the sphinx package maintenance for Fedora. When I observed the package structure, I realized it is based on source code developed in C, with latest stable version available in next link: http://sphinxsearch.com/downloads/current/ Latest binary versions from previous link (for example, v3.4.1) link to python base source code. Once I have inspected the package structure and the upstream project, I realized Sphinx was migrated to python, and newer versions can be downloaded via the "pip" tool. Apart from that, there is already a "python-sphinx" package to handle sphinx tools. So I guess the correct way to go here is to orphan the C based package (sphinx), unless there is some detail I am missing to keep it maintained. Thanks -- Sergio Arroutbi Braojos Software Engineer at Red Hat - Special Projects (SECENGSP) Red Hat <http://redhat.com>

7 12

New tool - license-validate
by Miroslav Suchý 28 Feb '22

28 Feb '22

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

12 25

F36 Change: DIGLIM (System-Wide Change proposal)
by Ben Cotton 21 Feb '22

21 Feb '22

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@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

24 70

F36 Change: Drop NIS(+) support from PAM (System-Wide Change proposal)
by Ben Cotton 16 Feb '22

16 Feb '22

https://fedoraproject.org/wiki/Changes/drop_NIS_support_from_PAM == Summary == This change is about dropping user-authentication using NIS(+) from PAM. == Owner == * Name: [[User:besser82 | Björn Esser]] * Email: besser82(a)fedoraproject.org * Name: [[User:ipedrosa | Iker Pedrosa]] * Email: ipedrosa(a)redhat.com == Detailed Description == NIS(+) was introduced by Sun/Oracle to easily share files and system users between UNIX-alike systems within the same network, and has been around for some decades. Its simplicity though opens a variety of possible security issues, like not being able the verify whether the shared information is actually correct and/or trustworthy. That said, and with several more secure options (LDAP, Kerberos, Samba, etc.) to achieve the same goal, we should at least remove support for NIS for user authentication. == Feedback == There was some discussion on [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… the fedora-devel mailing-list]. Some people are reluctant about the removal of NIS(+) support from PAM, while most are okay with it as there are more secure alternatives (LDAP, FreeIPA, etc.) available. == Benefit to Fedora == With this change we start directing our users and developers to move away from NIS(+) to secure alternatives like LDAP and/or FreeIPA. == Scope == * Proposal owners: ** Adapt the pam spec file to build without support for NIS(+). ** Communicate the removal of the PAM configuration for user-authentication using NIS with the authselect maintainers; also offer assistance to implement the needed changes. * Other developers: ** Apply the pull-request to the authselect package. ** Test this change. * Release engineering: [https://pagure.io/releng/issue/10351 #10351] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A == Upgrade/compatibility impact == Users that were relying on support for NIS(+) will need to move to secure alternatives like LDAP and/or FreeIPA. == How To Test == There is no need to test, as when configure switch is removed, support is dropped. == User Experience == For some users this change may be a bit disruptive and it may require some learning curve for switching to alternative solutions. == Dependencies == * The authselect package needs to be updated to drop its PAM configuration for user-authentication using NIS. * Apart from that there are actually no rpms, that directly depend on the change of the functionality of the affected PAM module. == Contingency Plan == * Contingency mechanism: Revert the changes made to the affected packages and rebuild them. * Contingency deadline: At beta freeze. * Blocks release? Yes. == Documentation == The documentation about sharing system users and files over NIS should be dropped, if there even is any. == Release Notes == Support for NIS(+) has been dropped from PAM. Users, who are currently using NIS(+) to share UNIX users / groups within a network, should migrate their setups to use LDAP or some other secure service providing comparable functionalities before updating to Fedora 36. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

7 11

← Newer
1
2
3
4
5
6
7
...
39
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel January 2022