Fedora rawhide compose report: 20230722.n.1 changes
OLD: Fedora-Rawhide-20230721.n.0 NEW: Fedora-Rawhide-20230722.n.1 = SUMMARY = Added images:0 Dropped images: 2 Added packages: 4 Dropped packages:2 Upgraded packages: 174 Downgraded packages: 0 Size of added packages: 120.49 KiB Size of dropped packages:25.32 MiB Size of upgraded packages: 13.34 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -67.96 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: i3 live aarch64 Path: Spins/aarch64/iso/Fedora-i3-Live-aarch64-Rawhide-20230721.n.0.iso Image: Workstation live aarch64 Path: Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-Rawhide-20230721.n.0.iso = ADDED PACKAGES = Package: frozen-1.1.1-3.fc39 Summary: A header-only, constexpr alternative to gperf for C++14 users RPMs:frozen-devel Size:52.68 KiB Package: rust-human_format-1.0.3-1.fc39 Summary: Converts a number to/from a human readable string RPMs:rust-human_format+default-devel rust-human_format-devel Size:21.04 KiB Package: rust-md5-asm-0.5.0-1.fc39 Summary: Assembly implementation of MD5 compression function RPMs:rust-md5-asm+default-devel rust-md5-asm-devel Size:19.96 KiB Package: rust-sha2-asm-0.6.2-1.fc39 Summary: Assembly implementation of SHA-2 compression functions RPMs:rust-sha2-asm+default-devel rust-sha2-asm-devel Size:26.81 KiB = DROPPED PACKAGES = Package: libgweather-40.0-5.fc38 Summary: A library for weather information RPMs:libgweather libgweather-devel Size:15.23 MiB Package: python-django3-3.2.19-1.fc39 Summary: A high-level Python Web framework RPMs:python-django3-bash-completion python3-django3 python3-django3-doc Size:10.09 MiB = UPGRADED PACKAGES = Package: MUSIC-1.1.16-13.20201002git8c6b77a.fc39 Old package: MUSIC-1.1.16-11.20201002git8c6b77a.fc39 Summary: The MUltiSimulation Coordinator RPMs: MUSIC-common MUSIC-mpich MUSIC-mpich-devel MUSIC-openmpi MUSIC-openmpi-devel python3-MUSIC-mpich python3-MUSIC-openmpi Size: 7.51 MiB Size change: 2.79 KiB Changelog: * Wed Jul 19 2023 Fedora Release Engineering - 1.1.16-12.20201002git8c6b77a - Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild * Thu Jul 20 2023 Benjamin A. Beasley - 1.1.16-13.20201002git8c6b77a - Use the Cython compat package for now Package: PackageKit-Qt-1.1.1-1.fc39 Old package: PackageKit-Qt-1.0.2-6.fc38 Summary: Qt support library for PackageKit RPMs: PackageKit-Qt5 PackageKit-Qt5-devel Size: 652.79 KiB Size change: 40.93 KiB Changelog: * Wed Jul 19 2023 Fedora Release Engineering - 1.0.2-7 - Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild * Sat Jul 22 2023 Alessandro Astone - 1.1.1-1 - Update to 1.1.1 Package: abootimg-0.6-29.20230721git7e127fe.fc39 Old package: abootimg-0.6-26.20110830gitff8e759.fc38 Summary: Tool for manipulating Android boot images RPMs: abootimg Size: 116.50 KiB Size change: 1.31 KiB Changelog: * Wed Jan 18 2023 Fedora Release Engineering - 0.6-27 - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild * Wed Jul 19 2023 Fedora Release Engineering - 0.6-28 - Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild * Fri Jul 21 2023 Yanko Kaneti - 0.6-29.20230721git7e127fe - New upstream location. SPDX migration. Modernize. Drop upstreamed patch. Package: arbor-0.7-9.fc39 Old package: arbor-0.7-4.fc38 Summary: Multi-compartment neural network simulation library RPMs: arbor arbor-devel arbor-doc arbor-mpich arbor-mpich-devel arbor-openmpi arbor-openmpi-devel Size: 207.28 MiB Size change: -67.43 MiB Changelog: * Wed Jun 28 2023 Vitaly Zaitsev - 0.7-5 - Rebuilt due to fmt 10 update. * Wed Jun 28 2023 Python Maint - 0.7-6 - Rebuilt for Python 3.12 * Wed Jul 19 2023 Fedora Release Engineering - 0.7-7 - Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild * Thu Jul 20 2023 Sandro - 0.7-8 - Fix use of distutils (RHBZ#2219935) * Fri Jul 21 2023 Sandro - 0.7-9 - Fix ExcludeArch - s/s390/s390x/ Package: azote-1.12.3-1.fc39 Old package: azote-1.11.0-2.fc39 Summary: Wallpaper and color manager for Sway, i3 and some other WMs RPMs: azote Size: 7.65 MiB Size change: 2.71 KiB Changelog: * Wed Jul 19 2023 Fedora Release Engineering - 1.11.0-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild * Fri Jul 21 2023 Bob Hepple - 1.12.3-1 - new version - migrated to SPDX license Package: byteman-4.0.16-10.fc39 Old package: byteman-4.0.16-8.fc38 Summary: Java agent-based bytecode injection tool RPMs: byteman byteman-bmunit byteman-dtest byteman-javadoc byteman-rulecheck-maven-plugin Size: 1.59 MiB Size change: -194.25 KiB Changelog: * Wed Jul 19 2023 Fedora
[EPEL-devel] Fedora EPEL 9 updates-testing report
The following Fedora EPEL 9 Security updates need testing: Age URL 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-eaff7ffae1 kitty-0.26.5-6.el9 The following builds have been pushed to Fedora EPEL 9 updates-testing netdata-1.41.0-1.el9 partclone-0.3.24-1.el9 python-openslide-1.3.0-2.el9 Details about builds: netdata-1.41.0-1.el9 (FEDORA-EPEL-2023-a2685c4126) Real-time performance monitoring Update Information: Update from upstream ChangeLog: * Sat Jul 22 2023 Didier Fabert 1.41.0-1 - Update from upstream * Thu Jul 20 2023 Fedora Release Engineering - 1.40.1-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild References: [ 1 ] Bug #2224157 - netdata-1.41.0 is available https://bugzilla.redhat.com/show_bug.cgi?id=2224157 partclone-0.3.24-1.el9 (FEDORA-EPEL-2023-d2c177fc26) Utility to clone and restore a partition Update Information: # partclone v0.3.24 - IO stream support for torrent info file - Handle absence of `mtrace.h` (e.g. uClibc) gracefully - Link with `-lm` for `isnormal()`/`__fpclassifyf()` as needed - Add Russian language file - Add missing space before opening parenthesis - Add German language ChangeLog: * Sat Jul 22 2023 Robert Scheck 0.3.24-1 - Upgrade to 0.3.24 (#2224618) * Thu Jul 20 2023 Fedora Release Engineering - 0.3.23-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild References: [ 1 ] Bug #2224618 - partclone-0.3.24 is available https://bugzilla.redhat.com/show_bug.cgi?id=2224618 python-openslide-1.3.0-2.el9 (FEDORA-EPEL-2023-67d27307dd) Python bindings for the OpenSlide library Update Information: OpenSlide Python 1.3.0 exposes color management profiles where available and adds support for the upcoming OpenSlide 4.0.0. ChangeLog: * Sat Jul 22 2023 Benjamin Gilbert - 1.3.0-2 - Fix tests on EPEL 9 * Sat Jul 22 2023 Benjamin Gilbert - 1.3.0-1 - New release * Fri Jul 21 2023 Fedora Release Engineering - 1.2.0-7 - Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild * Tue Jul 11 2023 Benjamin Gilbert - 1.2.0-6 - Avoid invoking setup.py subcommands directly * Fri Jun 16 2023 Python Maint - 1.2.0-5 - Rebuilt for Python 3.12 * Fri Jan 20 2023 Fedora Release Engineering - 1.2.0-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-226639904e netcdf-4.7.0-3.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing netdata-1.41.0-1.el8 partclone-0.3.24-1.el8 tsung-1.8.0-1.el8 Details about builds: netdata-1.41.0-1.el8 (FEDORA-EPEL-2023-00af2c5783) Real-time performance monitoring Update Information: Update from upstream ChangeLog: * Sat Jul 22 2023 Didier Fabert 1.41.0-1 - Update from upstream * Thu Jul 20 2023 Fedora Release Engineering - 1.40.1-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild References: [ 1 ] Bug #2224157 - netdata-1.41.0 is available https://bugzilla.redhat.com/show_bug.cgi?id=2224157 partclone-0.3.24-1.el8 (FEDORA-EPEL-2023-6f8fa58c2a) Utility to clone and restore a partition Update Information: # partclone v0.3.24 - IO stream support for torrent info file - Handle absence of `mtrace.h` (e.g. uClibc) gracefully - Link with `-lm` for `isnormal()`/`__fpclassifyf()` as needed - Add Russian language file - Add missing space before opening parenthesis - Add German language ChangeLog: * Sat Jul 22 2023 Robert Scheck 0.3.24-1 - Upgrade to 0.3.24 (#2224618) * Thu Jul 20 2023 Fedora Release Engineering - 0.3.23-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild References: [ 1 ] Bug #2224618 - partclone-0.3.24 is available https://bugzilla.redhat.com/show_bug.cgi?id=2224618 tsung-1.8.0-1.el8 (FEDORA-EPEL-2023-9578f4aff7) A distributed multi-protocol load testing tool Update Information: Update from upstream ChangeLog: * Sat Jul 22 2023 Didier Fabert - 1.8.0-1 - Update to 1.8.0 (#2174608) * Sat Jan 21 2023 Fedora Release Engineering - 1.7.0-21 - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild * Sat Jul 23 2022 Fedora Release Engineering - 1.7.0-20 - Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild * Wed Jun 1 2022 Jitka Plesnikova - 1.7.0-19 - Perl 5.36 rebuild * Sat Jan 22 2022 Fedora Release Engineering - 1.7.0-18 - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild * Fri Jul 23 2021 Fedora Release Engineering - 1.7.0-17 - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild * Sat May 22 2021 Jitka Plesnikova - 1.7.0-16 - Perl 5.34 rebuild * Wed Jan 27 2021 Fedora Release Engineering - 1.7.0-15 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild * Wed Jul 29 2020 Fedora Release Engineering - 1.7.0-14 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild * Thu Jun 25 2020 Jitka Plesnikova - 1.7.0-13 - Perl 5.32 rebuild * Fri Jan 31 2020 Fedora Release Engineering - 1.7.0-12 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild * Sat Jul 27 2019 Fedora Release Engineering - 1.7.0-11 - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild * Thu Jun 6 2019 Didier Fabert - 1.7.0-10 - Conditionnal patch (not for el7) * Mon Jun 3 2019 Jitka Plesnikova - 1.7.0-9 - Perl 5.30 re-rebuild updated packages * Sun Jun 2 2019 Didier Fabert - 1.7.0-8 - Patch to support python3 (submit to upstream) - Create doc subpackage * Thu May 30 2019 Jitka Plesnikova - 1.7.0-7 - Perl 5.30 rebuild * Sun Feb 3 2019 Fedora Release Engineering - 1.7.0-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild * Sat Jul 14 2018 Fedora Release Engineering - 1.7.0-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild * Fri Jun 29 2018 Jitka Plesnikova - 1.7.0-4 - Perl 5.28 rebuild * Fri Feb 9 2018 Iryna Shcherbina - 1.7.0-3 - Update Python 2 dependency declarations to new packaging standards (See https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3) * Fri Feb 9 2018 Fedora Release Engineering - 1.7.0-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild * Fri Sep
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-62c97d6572 zabbix50-5.0.36-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing netdata-1.41.0-1.el7 partclone-0.3.24-1.el7 tsung-1.8.0-1.el7 xxhash-0.8.2-1.el7 Details about builds: netdata-1.41.0-1.el7 (FEDORA-EPEL-2023-60f026ee37) Real-time performance monitoring Update Information: Update from upstream ChangeLog: * Sat Jul 22 2023 Didier Fabert 1.41.0-1 - Update from upstream * Thu Jul 20 2023 Fedora Release Engineering - 1.40.1-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild References: [ 1 ] Bug #2224157 - netdata-1.41.0 is available https://bugzilla.redhat.com/show_bug.cgi?id=2224157 partclone-0.3.24-1.el7 (FEDORA-EPEL-2023-f5fa1d2bba) Utility to clone and restore a partition Update Information: # partclone v0.3.24 - IO stream support for torrent info file - Handle absence of `mtrace.h` (e.g. uClibc) gracefully - Link with `-lm` for `isnormal()`/`__fpclassifyf()` as needed - Add Russian language file - Add missing space before opening parenthesis - Add German language ChangeLog: * Sat Jul 22 2023 Robert Scheck 0.3.24-1 - Upgrade to 0.3.24 (#2224618) * Thu Jul 20 2023 Fedora Release Engineering - 0.3.23-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild References: [ 1 ] Bug #2224618 - partclone-0.3.24 is available https://bugzilla.redhat.com/show_bug.cgi?id=2224618 tsung-1.8.0-1.el7 (FEDORA-EPEL-2023-19f73a17ad) A distributed multi-protocol load testing tool Update Information: Update from upstream ChangeLog: * Sat Jul 22 2023 Didier Fabert - 1.8.0-1 - Update to 1.8.0 (#2174608) * Sat Jan 21 2023 Fedora Release Engineering - 1.7.0-21 - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild * Sat Jul 23 2022 Fedora Release Engineering - 1.7.0-20 - Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild * Wed Jun 1 2022 Jitka Plesnikova - 1.7.0-19 - Perl 5.36 rebuild * Sat Jan 22 2022 Fedora Release Engineering - 1.7.0-18 - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild * Fri Jul 23 2021 Fedora Release Engineering - 1.7.0-17 - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild * Sat May 22 2021 Jitka Plesnikova - 1.7.0-16 - Perl 5.34 rebuild * Wed Jan 27 2021 Fedora Release Engineering - 1.7.0-15 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild * Wed Jul 29 2020 Fedora Release Engineering - 1.7.0-14 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild * Thu Jun 25 2020 Jitka Plesnikova - 1.7.0-13 - Perl 5.32 rebuild * Fri Jan 31 2020 Fedora Release Engineering - 1.7.0-12 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild * Sat Jul 27 2019 Fedora Release Engineering - 1.7.0-11 - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild References: [ 1 ] Bug #2174608 - tsung-1.8.0 is available https://bugzilla.redhat.com/show_bug.cgi?id=2174608 xxhash-0.8.2-1.el7 (FEDORA-EPEL-2023-6a9bf6b5e2) Extremely fast hash algorithm Update Information: xxhash 0.8.2 ChangeLog: * Sat Jul 22 2023 Mattias Ellert - 0.8.2-1 - Update to version 0.8.2 - Drop patch xxhash-epel7-ppc64le.patch - Use SPDX license identifiers * Sat Jul 22 2023 Fedora Release Engineering - 0.8.1-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild * Mon Jun 19 2023 Florian Weimer -
[Test-Announce] Fedora 39 Rawhide 20230722.n.1 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 39 Rawhide 20230722.n.1. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: pungi - 20230719.n.0: pungi-4.4.0-2.fc39.src, 20230722.n.1: pungi-4.4.0-3.fc39.src Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/39 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230722.n.1_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230722.n.1_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230722.n.1_Base https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230722.n.1_Server https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230722.n.1_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230722.n.1_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230722.n.1_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Restricting automounting of uncommon filesystems?
On Sat, Jul 22, 2023 at 10:32:01AM +0200, drago01 wrote: > Which file systems are considered uncommon in that context? And aren't most > attacks based on file systems used by windows, which makes them "common" ? > (Extfat, NTFS, VFAT) Any attack here is going to be OS-specific - a vulnerability in a filesystem used by Windows is massively unlikely to be present in Linux. If your goal is to compromise a Linux device then the attack surface available to you (right now) is everything that's present in Linux. For removable devices I'd argue that anything other than exfat and vfat are probably uncommon, but could be convinced that ext4 and xfs made sense as well (and maybe ntfs since I assume some people do want to transfer data on USB hard drives) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: Enable fwupd-refresh.timer by default on IoT, CoreOS & Server Editions (Self-Contained)
On Sat, Jul 22, 2023 at 3:32 PM Dan Čermák wrote: > > Hi, > > Aoife Moloney writes: > > > https://fedoraproject.org/wiki/Changes/EnableFwupdRefreshByDefault > > > *snip* > > > > == Detailed Description == > > > > Firmware for hardware devices can have bugs and firmware updates > > generally help address those. Firmware updates might however need > > manual interaction, a reboot or device unplug/re-plug so we can not > > enable firmware update by default. > > > > This change thus only enable notifying about new firmware updates, not > > installing them. > > > > With this change, Fedora installations will contact the Linux Vendor > > Firmware Service CDN (LVFS, https://cdn.fwupd.org/) to get the updated > > metadata but will not send any information about the hardware without > > user interaction. > > > > See the LVFS privacy policy at > > https://lvfs.readthedocs.io/en/latest/privacy.html. > > > > I like this, it's a very unobtrusive change and will point some admins > to apply firmware updates. Thanks for this idea! > Actually, why wouldn't this be used everywhere? I could see this be useful when people remote into workstations and apply updates. I know of plenty of people that split their desktops between local and remote access/administration. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Restricting automounting of uncommon filesystems?
On 7/22/23 08:57, Michael Catanzaro wrote: > I've been thinking about this for a while. The status quo is really > awful. > > On Sat, Jul 22 2023 at 11:31:22 AM +, Zbigniew Jędrzejewski-Szmek > wrote: >> A bigger problem I see, is that if a user plugins in a usb stick, >> expecting to make use of it, and it's not automounted without any >> explanation, they are most likely to just click for it to be mounted, >> or to even issue an explicit 'mount', defeating the whole protection. > > Yup, there's the problem. The user will almost always mount it > manually, so disabling automount seems pointless. > >> A more reasonable UI would be to display a pop-up that says "Device >> ASDF uses file system AmigaFS 1982 which is not well supported. See >> https://some.link/ for details. Do you want to a) mount once, b) not >> mount, c) mount this fs type always?". This would require some work >> in DE. > > The UI would have to not mention technical details like the name of the > filesystem. Also, warning a user that the filesystem is not > "well-supported" is also not likely to accomplish much. The user > plugged in the USB stick in order to look at files, and will almost > always choose to do so if presented with the option. Even if we warn > that the device may be malicious (which we don't actually know), users > will still just think about it and decide "probably not, I want to see > my files." > > The desktop security model assumes the kernel is robust to malformed > filesystems and removing that assumption is just not workable. This > development mindset might be prevalent among kernel developers, but > it's not acceptable for desktop users. Filesystems that are not > designed to be robust to untrusted input should be disabled outright > and not supported at all. I'm not sure how practical this actually is, > though, because I think it would probably entail disabling common > filesystems (ext4? xfs? btrfs?) in addition to uncommon filesystems. > Starting with disabling uncommon filesystems is better than nothing, > though. > > Michael A much better solution is: 1. Do not mount automatically. The user might have intended to operate on the drive at the block level, such as to create or validate boot media. Instead, defer mounting until the user looks at the contents of the filesystem. 2. Perform the mount in a **sandboxed** userspace process or even a virtual machine. This is what Chromium OS does and is the only solution that is decently secure. There are all sorts of other problems that need to be addressed as well, such as ensuring that only fuzzed and hardened USB drivers are used. But the mounting restrictions are the first step. -- Sincerely, Demi Marie Obenour (she/her/hers) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Java-devel list?
On Fri, Jul 21, 2023 at 01:59:47AM +0200, Peter Boy wrote: > Is there something wrong with the Java-Devel list? > > I can send a message to the list and get no reject or error, but is never > shows up, at least it looks like that. > > Or did I miss something? If you are subscribed it should go through. Can you file a infra ticket and include the messageid of the message(s) you sent? we can then look at logs and see where it went... kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: LibreOffice 7.6 (Self-Contained)
On Fri, Jul 21, 2023 at 04:31:01PM +0100, Aoife Moloney wrote: > https://fedoraproject.org/wiki/Changes/LibreOffice_7.6 > > This document represents a proposed Change. As part of the Changes > process, proposals are publicly announced in order to receive > community feedback. This proposal will only be implemented if approved > by the Fedora Engineering Steering Committee. > > == Summary == > Update LibreOffice suite to 7.6 > > > == Owner == > * Name: [[User:mattia| Mattia Verga]] > * Name: [[User:limb| Gwyn Ciesla ]] > * libreoffice-SIG > * Email: mattia.ve...@protonmail.com, gw...@protonmail.com > > > > > == Detailed Description == > LibreOffice 7.6 is currently in Beta and the first stable release is > currently scheduled during F39 development. We aim to bring the latest > LibreOffice stable release in F39. When is the stable release scheduled for? ie, how does it align with fedora release milestones ? Perhaps add that here? > At the same time we plan to stop building LibreOffice for i686 architecture. Good plan. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Restricting automounting of uncommon filesystems?
On Sat, Jul 22, 2023 at 10:12:33AM -0400, Neal Gompa wrote: > Several years ago, SUSE distributions moved to disabling the modules > by default for a number of filesystems, but making it pretty easy to > turn them back on: > https://github.com/openSUSE/suse-module-tools/pull/5 The problem there is that if you install a module you need for a static mount, you open yourself up to attack via automounts. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: Enable fwupd-refresh.timer by default on IoT, CoreOS & Server Editions (Self-Contained)
Hi, Aoife Moloney writes: > https://fedoraproject.org/wiki/Changes/EnableFwupdRefreshByDefault > *snip* > > == Detailed Description == > > Firmware for hardware devices can have bugs and firmware updates > generally help address those. Firmware updates might however need > manual interaction, a reboot or device unplug/re-plug so we can not > enable firmware update by default. > > This change thus only enable notifying about new firmware updates, not > installing them. > > With this change, Fedora installations will contact the Linux Vendor > Firmware Service CDN (LVFS, https://cdn.fwupd.org/) to get the updated > metadata but will not send any information about the hardware without > user interaction. > > See the LVFS privacy policy at > https://lvfs.readthedocs.io/en/latest/privacy.html. > I like this, it's a very unobtrusive change and will point some admins to apply firmware updates. Thanks for this idea! Cheers, Dan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora 39 Mass Rebuild started
On Sat, Jul 22, 2023 09:35:26 -0700, Kevin Fenzi wrote: > On Sat, Jul 22, 2023 at 11:04:19AM +0100, Ankur Sinha wrote: > > > The wiki page also looks out of date (still refers f38): > > https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild > > > > I had the usual question---should I be making new builds for updates and > > fixes into the mass rebuild side tag, or is rawhide OK? > > Rawhide as normal is fine. > > When the tag is merged it will look and see if there is a newer build in > rawhide already. If so, it won't take the mass rebuild one in. Cool! Thanks very much. -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora 39 Mass Rebuild started
On Sat, Jul 22, 2023 at 11:04:19AM +0100, Ankur Sinha wrote: > On Wed, Jul 19, 2023 13:31:57 +0200, Tomas Hrcka wrote: > > Oh, that thing again. > > Let me update the template so sed works correctly. > > > > The wiki page also looks out of date (still refers f38): > https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild > > I had the usual question---should I be making new builds for updates and > fixes into the mass rebuild side tag, or is rawhide OK? Rawhide as normal is fine. When the tag is merged it will look and see if there is a newer build in rawhide already. If so, it won't take the mass rebuild one in. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Restricting automounting of uncommon filesystems?
On Sat, Jul 22, 2023 at 9:53 AM Florian Weimer wrote: > > * Matthew Garrett: > > > a) Does this seem like a good idea? > > b) If so, is dealing with it via udev rules the right approach? This way > > seems desktop-agnostic > > c) Where should it ship, and what should the process be for disabling it > > for people who need this functionality? > > Maybe a first step would be to disable automounting while the screen is > locked. > > > Long-term I'd love to see more work put into having FUSE support for > > these and leaving the in-kernel fs to stuff we know is trustworthy, but > > that's rather more work. > > Fedora moved in the opposite direction (from gvfs to unprivileged > mounting via udisks2 IIRC). > Several years ago, SUSE distributions moved to disabling the modules by default for a number of filesystems, but making it pretty easy to turn them back on: https://github.com/openSUSE/suse-module-tools/pull/5 We could take a similar approach, maybe...? openSUSE discussed this back in 2019: https://lists.opensuse.org/archives/list/fact...@lists.opensuse.org/thread/NCNVFI53B4OSD3E2BVW5QY5MYKMYLH7G/#NCNVFI53B4OSD3E2BVW5QY5MYKMYLH7G -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Restricting automounting of uncommon filesystems?
* Matthew Garrett: > a) Does this seem like a good idea? > b) If so, is dealing with it via udev rules the right approach? This way > seems desktop-agnostic > c) Where should it ship, and what should the process be for disabling it > for people who need this functionality? Maybe a first step would be to disable automounting while the screen is locked. > Long-term I'd love to see more work put into having FUSE support for > these and leaving the in-kernel fs to stuff we know is trustworthy, but > that's rather more work. Fedora moved in the opposite direction (from gvfs to unprivileged mounting via udisks2 IIRC). Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Restricting automounting of uncommon filesystems?
I've been thinking about this for a while. The status quo is really awful. On Sat, Jul 22 2023 at 11:31:22 AM +, Zbigniew Jędrzejewski-Szmek wrote: A bigger problem I see, is that if a user plugins in a usb stick, expecting to make use of it, and it's not automounted without any explanation, they are most likely to just click for it to be mounted, or to even issue an explicit 'mount', defeating the whole protection. Yup, there's the problem. The user will almost always mount it manually, so disabling automount seems pointless. A more reasonable UI would be to display a pop-up that says "Device ASDF uses file system AmigaFS 1982 which is not well supported. See https://some.link/ for details. Do you want to a) mount once, b) not mount, c) mount this fs type always?". This would require some work in DE. The UI would have to not mention technical details like the name of the filesystem. Also, warning a user that the filesystem is not "well-supported" is also not likely to accomplish much. The user plugged in the USB stick in order to look at files, and will almost always choose to do so if presented with the option. Even if we warn that the device may be malicious (which we don't actually know), users will still just think about it and decide "probably not, I want to see my files." The desktop security model assumes the kernel is robust to malformed filesystems and removing that assumption is just not workable. This development mindset might be prevalent among kernel developers, but it's not acceptable for desktop users. Filesystems that are not designed to be robust to untrusted input should be disabled outright and not supported at all. I'm not sure how practical this actually is, though, because I think it would probably entail disabling common filesystems (ext4? xfs? btrfs?) in addition to uncommon filesystems. Starting with disabling uncommon filesystems is better than nothing, though. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)
On Sat, Jul 22 2023 at 02:44:30 AM +, "Smith, Stewart via devel" wrote: I’d almost prefer we work out a policy where anything of the sort is disabled by default, and with a distro-wide standard bcond to not even compile it in as an option. (No, I don’t quite know how that could be worded sensibly as a policy…. but it’s where I think I’d prefer to start from). You can just not package the eos- packages (eos-metrics, eos-event-recorder-daemon, eos-metrics-instrumentation). eos-event-recorder-daemon is the package that actually sends metrics. Without that, no metrics. And nothing should have a hard dependency on it, so no bconds should be needed. If you have some denylist somewhere that throws an error if an unwanted package exists, that should robustly ensure it's never enabled. For everything else, the test for whether to send metrics is "is the event recorder bus name owned?" so no conditional compilation or bconds is needed. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Restricting automounting of uncommon filesystems?
On Sat, Jul 22, 2023 at 07:01:34AM +0100, Matthew Garrett wrote:
> A discussion within Debian again brought up the problem that:
>
> 1) Automounting of removable media exposes the kernel to a lot of
> untrusted input
> 2) Kernel upstream are not terribly concerned with ensuring that kernel
> filesystems are resilient against deliberately malformed filesystems so
> are mostly not proactively looking for bugs there
> 3) Uncommonly used filesystems are less likely to be tested against
> adverse input in the real world and so are more likely to contain
> exploitable bugs
>
> There are various cases where people do need to make use of uncommon
> filesystems, but the majority of them aren't related to removable media.
> udisks2 supports setting the UDISKS_AUTO variable to 0 on devices that
> shouldn't be automounted, which means something like:
>
> SUBSYSTEM!="block", GOTO="udisks_insecure_fs_end"
> ENV{ID_FS_TYPE}=="hfs", ENV{UDISKS_AUTO}="0"
> # repeat as necessary for anything else that shouldn't be automounted
> LABEL="udisks_insecure_fs_end"
>
> ought to be enough. So:
>
> a) Does this seem like a good idea?
In general, yes. I think the issue can be summed up as:
if you allow an attacker to plug in and automount a USB with an
arbitrary file system, it's almost certain that they will be able to
make the kernel to undefined behaviour. If the list of filesystem
types is limited to the best-supported file system types, there is a
reasonable chance that the attack will fail. By limiting the list
of fs types, we pragmatically make the attack much harder.
FWIW, systemd merged a patch to do something similar in a different
context: https://github.com/systemd/systemd/commit/80ce8580f5.
> b) If so, is dealing with it via udev rules the right approach? This way
> seems desktop-agnostic
The udev-based approach would work, and is something that could be
used right now. Nevertheless, it's not very user friendly. Some users
will want to override the list, and with the udev-rule-based approach
this is doable but not very convenient.
A bigger problem I see, is that if a user plugins in a usb stick,
expecting to make use of it, and it's not automounted without any
explanation, they are most likely to just click for it to be mounted,
or to even issue an explicit 'mount', defeating the whole protection.
A more reasonable UI would be to display a pop-up that says "Device
ASDF uses file system AmigaFS 1982 which is not well supported. See
https://some.link/ for details. Do you want to a) mount once, b) not
mount, c) mount this fs type always?". This would require some work
in DE.
> c) Where should it ship, and what should the process be for disabling it
> for people who need this functionality?
> SUBSYSTEM!="block", GOTO="udisks_insecure_fs_end"
> ENV{ID_FS_TYPE}=="hfs", ENV{UDISKS_AUTO}="0"
> # repeat as necessary for anything else that shouldn't be automounted
> LABEL="udisks_insecure_fs_end"
Since those rules are for udisks, I think they should be part of the
udisks package.
If this is done, it'd be much better to make the rule configurable.
So maybe something like this:
SUBSYSTEM=="block", ACTION!="remove",
PROGRAM="/usr/libexec/fstype-automount-policy", RESULT=="?*",
ENV{UDISKS_AUTO}="$result"
And the program /usr/libexec/fstype-automount-handline would
have a built-in list, but also look for /etc/kernel/fstype-automount.conf
that would include lists like AUTOMOUNT_FSTYPE_ALLOW=
and AUTOMOUNT_FSTYPE_DISALLOW=.
We could then reuse this machinery in other places, not just udisks.
Obiously this is a very rought draft, but I think it should be extensible
and configurable.
> Long-term I'd love to see more work put into having FUSE support for
> these and leaving the in-kernel fs to stuff we know is trustworthy, but
> that's rather more work.
Yep.
Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Restricting automounting of uncommon filesystems?
On Sat, Jul 22, 2023 at 07:01:34AM +0100, Matthew Garrett wrote:
> A discussion within Debian again brought up the problem that:
>
> 1) Automounting of removable media exposes the kernel to a lot of
> untrusted input
> 2) Kernel upstream are not terribly concerned with ensuring that kernel
> filesystems are resilient against deliberately malformed filesystems so
> are mostly not proactively looking for bugs there
> 3) Uncommonly used filesystems are less likely to be tested against
> adverse input in the real world and so are more likely to contain
> exploitable bugs
>
> There are various cases where people do need to make use of uncommon
> filesystems, but the majority of them aren't related to removable media.
> udisks2 supports setting the UDISKS_AUTO variable to 0 on devices that
> shouldn't be automounted, which means something like:
>
> SUBSYSTEM!="block", GOTO="udisks_insecure_fs_end"
> ENV{ID_FS_TYPE}=="hfs", ENV{UDISKS_AUTO}="0"
> # repeat as necessary for anything else that shouldn't be automounted
> LABEL="udisks_insecure_fs_end"
>
> ought to be enough. So:
>
> a) Does this seem like a good idea?
> b) If so, is dealing with it via udev rules the right approach? This way
> seems desktop-agnostic
> c) Where should it ship, and what should the process be for disabling it
> for people who need this functionality?
>
> Long-term I'd love to see more work put into having FUSE support for
> these and leaving the in-kernel fs to stuff we know is trustworthy, but
> that's rather more work.
Well, libguestfs is a thing.
Are any filesystems really trusted?
I do take your point though that some kernel-supported filesystems are
hardly ever used and you should probably need to take special steps to
expose them to your kernel. At least Fedora no longer enables the BBC
Micro filesystem, last widely used in the 1980s.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: dist-git: Diverging branches can't be fast-forwarded
On Sat, Jul 22, 2023 at 09:08:37AM +0200, Miroslav Suchý wrote: > Dne 21. 07. 23 v 10:50 Zbigniew Jędrzejewski-Szmek napsal(a): > > > Is this expected? Or is this sign of something malicious happenening? > > Dunno. Generally the most likely explanation would be that you have local > > commits. But if that is impossible, then something strange is going on. > > Can you identify the repos in question? > > It took some time... I found one: > > It is a package xorg-x11-xdm > > Now I see: > > * 1ee5a42 (HEAD -> rawhide, origin/rawhide, origin/main, origin/f38, > origin/f37, origin/HEAD)Remove duplicated patch > * d97e4c6Unretire xorg-x11-xdm package > * a9058e1Unretirement request: https://pagure.io/releng/issue/11456 > * e776f0fOrphaned for 6+ weeks > * 6f197fa (origin/f36)- Rebuilt for > https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild > > > > But the checkout from past I have is: > > * 8a9aff8 (HEAD -> rawhide)Unretirement request: > https://pagure.io/releng/issue/11456 > * e776f0fOrphaned for 6+ weeks > * 6f197fa (origin/f36)- Rebuilt for > https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild > > So the commit where it diverge is commit: > > commit 8a9aff84896f28b93851579600afdc59b75b7710 (HEAD -> rawhide) > Author: Tomas Hrcka > Date: Thu Jun 8 15:06:43 2023 +0200 > > Unretirement request: https://pagure.io/releng/issue/11456 > > That has been replaced by: > > commit a9058e1cce504e6b354b59d6711d76aeb0a8418c > Author: Tomas Hrcka > Date: Wed Jun 14 14:35:41 2023 +0200 > > Unretirement request: https://pagure.io/releng/issue/11456 > > I repeat myself: this my local checkout that was done by "fedpkg clone" and > I never changed anything in this git repo. I have never made a commit there. > I just read the data. And every two weeks I am doing git-pull there. Tomáš, do you know what's going on here? Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora 39 Mass Rebuild started
On Wed, Jul 19, 2023 13:31:57 +0200, Tomas Hrcka wrote: > Oh, that thing again. > Let me update the template so sed works correctly. > The wiki page also looks out of date (still refers f38): https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild I had the usual question---should I be making new builds for updates and fixes into the mass rebuild side tag, or is rawhide OK? -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Restricting automounting of uncommon filesystems?
On Saturday, July 22, 2023, Matthew Garrett wrote:
> A discussion within Debian again brought up the problem that:
>
> 1) Automounting of removable media exposes the kernel to a lot of
> untrusted input
> 2) Kernel upstream are not terribly concerned with ensuring that kernel
> filesystems are resilient against deliberately malformed filesystems so
> are mostly not proactively looking for bugs there
> 3) Uncommonly used filesystems are less likely to be tested against
> adverse input in the real world and so are more likely to contain
> exploitable bugs
>
> There are various cases where people do need to make use of uncommon
> filesystems, but the majority of them aren't related to removable media.
> udisks2 supports setting the UDISKS_AUTO variable to 0 on devices that
> shouldn't be automounted, which means something like:
>
> SUBSYSTEM!="block", GOTO="udisks_insecure_fs_end"
> ENV{ID_FS_TYPE}=="hfs", ENV{UDISKS_AUTO}="0"
> # repeat as necessary for anything else that shouldn't be automounted
> LABEL="udisks_insecure_fs_end"
>
> ought to be enough. So:
>
> a) Does this seem like a good idea?
> b) If so, is dealing with it via udev rules the right approach? This way
> seems desktop-agnostic
> c) Where should it ship, and what should the process be for disabling it
> for people who need this functionality?
>
> Long-term I'd love to see more work put into having FUSE support for
> these and leaving the in-kernel fs to stuff we know is trustworthy, but
> that's rather more work.
Which file systems are considered uncommon in that context? And aren't most
attacks based on file systems used by windows, which makes them "common" ?
(Extfat, NTFS, VFAT)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://docs.fedoraproject.
> org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.
> fedoraproject.org
> Do not reply to spam, report it: https://pagure.io/fedora-
> infrastructure/new_issue
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: dist-git: Diverging branches can't be fast-forwarded
Dne 21. 07. 23 v 10:50 Zbigniew Jędrzejewski-Szmek napsal(a): Is this expected? Or is this sign of something malicious happenening? Dunno. Generally the most likely explanation would be that you have local commits. But if that is impossible, then something strange is going on. Can you identify the repos in question? It took some time... I found one: It is a package xorg-x11-xdm Now I see: * 1ee5a42 (HEAD -> rawhide, origin/rawhide, origin/main, origin/f38, origin/f37, origin/HEAD)Remove duplicated patch * d97e4c6Unretire xorg-x11-xdm package * a9058e1Unretirement request: https://pagure.io/releng/issue/11456 * e776f0fOrphaned for 6+ weeks * 6f197fa (origin/f36)- Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild But the checkout from past I have is: * 8a9aff8 (HEAD -> rawhide)Unretirement request: https://pagure.io/releng/issue/11456 * e776f0fOrphaned for 6+ weeks * 6f197fa (origin/f36)- Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild So the commit where it diverge is commit: commit 8a9aff84896f28b93851579600afdc59b75b7710 (HEAD -> rawhide) Author: Tomas Hrcka Date: Thu Jun 8 15:06:43 2023 +0200 Unretirement request: https://pagure.io/releng/issue/11456 That has been replaced by: commit a9058e1cce504e6b354b59d6711d76aeb0a8418c Author: Tomas Hrcka Date: Wed Jun 14 14:35:41 2023 +0200 Unretirement request: https://pagure.io/releng/issue/11456 I repeat myself: this my local checkout that was done by "fedpkg clone" and I never changed anything in this git repo. I have never made a commit there. I just read the data. And every two weeks I am doing git-pull there. -- Miroslav Suchy, RHCA Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Restricting automounting of uncommon filesystems?
A discussion within Debian again brought up the problem that:
1) Automounting of removable media exposes the kernel to a lot of
untrusted input
2) Kernel upstream are not terribly concerned with ensuring that kernel
filesystems are resilient against deliberately malformed filesystems so
are mostly not proactively looking for bugs there
3) Uncommonly used filesystems are less likely to be tested against
adverse input in the real world and so are more likely to contain
exploitable bugs
There are various cases where people do need to make use of uncommon
filesystems, but the majority of them aren't related to removable media.
udisks2 supports setting the UDISKS_AUTO variable to 0 on devices that
shouldn't be automounted, which means something like:
SUBSYSTEM!="block", GOTO="udisks_insecure_fs_end"
ENV{ID_FS_TYPE}=="hfs", ENV{UDISKS_AUTO}="0"
# repeat as necessary for anything else that shouldn't be automounted
LABEL="udisks_insecure_fs_end"
ought to be enough. So:
a) Does this seem like a good idea?
b) If so, is dealing with it via udev rules the right approach? This way
seems desktop-agnostic
c) Where should it ship, and what should the process be for disabling it
for people who need this functionality?
Long-term I'd love to see more work put into having FUSE support for
these and leaving the in-kernel fs to stuff we know is trustworthy, but
that's rather more work.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
