[Bug 2224541] Upgrade perl-DBIx-SearchBuilder to 1.78
https://bugzilla.redhat.com/show_bug.cgi?id=2224541 Jitka Plesnikova changed: What|Removed |Added Resolution|--- |RAWHIDE Status|NEW |CLOSED Fixed In Version||perl-DBIx-SearchBuilder-1.7 ||8-1.fc39 Last Closed||2023-07-24 05:57:20 --- Comment #1 from Jitka Plesnikova --- Built by corsepiu -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2224541 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202224541%23c1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2224547] Upgrade perl-Lingua-EN-Sentence to 0.34
https://bugzilla.redhat.com/show_bug.cgi?id=2224547 Jitka Plesnikova changed: What|Removed |Added Resolution|--- |RAWHIDE Fixed In Version||perl-Lingua-EN-Sentence-0.3 ||4-1.fc39 Status|NEW |CLOSED Last Closed||2023-07-24 05:56:22 --- Comment #1 from Jitka Plesnikova --- Built by corsepiu -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2224547 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202224547%23c1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-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/23/23 11:05, Eric Sandeen wrote: > On 7/22/23 7:57 AM, 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. > > mount is a privileged operation in the kernel; when system configuration > works around that to allow non-trusted users to initiate a mount, that > breaks the restrictions that the kernel intentionally put on the ability > to ingest a stream of untrusted data from a block device. > > Filesystems generally *do* care about malformed input, but they do so in > the context of the security model that the kernel defines. > > As an example, XFS goes to great lengths to validate input, and placing > checksums on every piece of metadata is a big part of that. In the real > world, this validation catches and handles the vast majority of > malformed/corrupted input that XFS should expect to see. > > Other filesystems have similar validation, with similar assumptions. > > But when fuzzers intentionally malform metadata and then fix up the > checksum to look valid, this is something that would never happen > organically; it is an intentionally malicious work-around to the > existing mechanism. But again, mount is supposed to be a privileged > operation, so if the system administrator decides to mount the USB drive > they found in the parking lot, that's on them, and not a security issue. > They are root, after all. Unfortunately, this original threat model is out of date. kernel_lockdown(7) explicitly aims to prevent root from compromising the kernel, which means that malformed filesystem images are now in scope, for all filesystems. If a filesystem driver is not secure against malicious filesystem images, then using it should fail if the kernel is locked down, just like loading an unsigned kernel module does. > I wholeheartedly support any effort to restrict (by default) > auto-mounting to a smaller set of filesystems that could reasonably be > expected to be found on removable media (isofs, fat, exfat ...) and shut > off all the rest to limit the attack surface here. Disks used for backups will often be formatted with ext4, XFS, or BTRFS, and it should be possible to safely read the contents of a backup even if the backup source was compromised. > This issue and the > associated CVEs that get raised have been consuming an inordinate amount > of time from a very limited set of filesystem developers. > > -Eric -- 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: Restricting automounting of uncommon filesystems?
On 7/23/23 12:10, Solomon Peachy via devel wrote: > On Sun, Jul 23, 2023 at 11:25:12AM -0400, Neal Gompa wrote: >>> If the system administrator wants to mount $UNCOMMONFS, they should be >>> able to do so without hassle, but that doesn't mean that a normal user >>> who got handed a sketchy USB stick at a conference should be able to do >>> so with no restrictions at all. >>> >> >> So then some kind of configuration to udisks2 to have a similar effect? > > And we're right back at square one, with the *overwhelmingly* common case > of a single-user system whose "admin" is sitting in front of the system. > > Of _course_ they want to mount the disk. It's why they plugged it in, > and they don't give two hoots if it's a "common filesystem" or not. > > (FFS, most of the stuff I personally plug in these days is ext4 or ntfs, > because fat32 sucks and I can't rely on exfat on all systems I need to > interoperate with) > > And let's be realistic here -- the overwhelmingly common threat model > here is that there are untrusted files on a correctly-formed filesystem. > Bad guys rarely need or care to get root on the system; what they're > after requires normal, non-elevated user permissions. > > Prompting users 'are you sure you want to use this device' will turn a > "yes" into an automatic reflex. Not automounting by default will just > add another thing to the "things to change on default fedora > installations" lists out there (ie right after the "enable freshrpms and > install modern video codecs" step), becuase it's a usability nightmare. > > In the "usability vs security" tradeoff, usability/convenience *always* > wins unless you're at a place that has armed guards at the door with > instructions to shoot first. > > - Solomon Then the mount needs to be done in a sandbox, such as a KVM guest or sandboxed userspace process. -- 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
[Bug 2224929] New: perl-Tree-1.16 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2224929 Bug ID: 2224929 Summary: perl-Tree-1.16 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Tree Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Releases retrieved: 1.16 Upstream release that is considered latest: 1.16 Current version/release in rawhide: 1.15-7.fc38 URL: http://search.cpan.org/dist/Tree/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/10580/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Tree -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2224929 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202224929%23c0 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2224800] perl-Moose-2.2205 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2224800 Fedora Update System changed: What|Removed |Added Status|NEW |MODIFIED --- Comment #1 from Fedora Update System --- FEDORA-2023-e6fe7aeced has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-e6fe7aeced -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2224800 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202224800%23c1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2224800] perl-Moose-2.2205 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2224800 Fedora Update System changed: What|Removed |Added Status|MODIFIED|CLOSED Resolution|--- |ERRATA Fixed In Version||perl-Moose-2.2205-1.fc39 Last Closed||2023-07-23 14:12:01 --- Comment #2 from Fedora Update System --- FEDORA-2023-e6fe7aeced has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2224800 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202224800%23c2 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2224866] New: perl-Moose-2.2206 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2224866 Bug ID: 2224866 Summary: perl-Moose-2.2206 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Moose Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, iarn...@gmail.com, lkund...@v3.sk, mspa...@redhat.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Releases retrieved: 2.2206 Upstream release that is considered latest: 2.2206 Current version/release in rawhide: 2.2205-1.fc39 URL: https://metacpan.org/release/Moose/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/6197/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Moose -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2224866 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202224866%23c0 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: proposal to orphan tcpcrypt
On Sun, 2023-07-23 at 13:10 -0400, Paul Wouters wrote: > Hi, > > After talking to the debian maintainer of tcpcrypt, we both decided the > best thing is to remove tcpcrypt from the distributions. > > - The protocol at the IETF seems have stalled for many years > - The main proponent and implementer sadly passed away years ago > - The website tcpcrypt.org has died a while ago > - The package interferes badly with firewalling tools > > If anyone is really objecting, please let me know and be prepared to > become the maintainer in that case. No objection here. I only merged and pushed out the firewalld fix to stable releases because someone mentioned it on Mastodon. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ 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
[Bug 2224800] New: perl-Moose-2.2205 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2224800 Bug ID: 2224800 Summary: perl-Moose-2.2205 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Moose Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, iarn...@gmail.com, lkund...@v3.sk, mspa...@redhat.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Releases retrieved: 2.2205 Upstream release that is considered latest: 2.2205 Current version/release in rawhide: 2.2203-3.fc39 URL: https://metacpan.org/release/Moose/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/6197/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Moose -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2224800 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202224800%23c0 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-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 2:01:34 AM EDT 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.
A while back, I wrote the fsfuzzer specifically to find, in a repeatable way,
filesystem bugs so they can be fixed:
https://github.com/stevegrubb/fsfuzzer
It does not support all filesystems, but it is easy to add support through
adding the correct mounter to the scrips. It has found *so* *many* filesystem
bugs over time.
-Steve
___
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
[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 libopenmpt-0.6.11-1.el7 Details about builds: libopenmpt-0.6.11-1.el7 (FEDORA-EPEL-2023-76532a12e5) C/C++ library to decode tracker music module (MOD) files Update Information: # libopenmpt 0.6.11 (2023-06-18) * [Sec] Possible out-of-bounds read or write when reading malformed MED files. * [Bug] The Opal OPL3 emulator symbols were not namespaced properly. * [Bug] Work-around for MSVC VS2022 17.6.0 ARM64 compiler bug. * [Bug] `Makefile` `CONFIG=emscripten EMSCRIPTEN_PORTS=1` failed to properly use `libogg` and `libvorbis` dependencies. * MO3: Envelope sustain was not imported correctly if the source file was an XM. ChangeLog: * Thu Jul 20 2023 Michael Schwendt - 0.6.11-1 - update to 0.6.11 * Thu Jul 20 2023 Fedora Release Engineering - 0.6.10-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_39_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 7 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 libopenmpt-0.6.11-1.el8 Details about builds: libopenmpt-0.6.11-1.el8 (FEDORA-EPEL-2023-bb7912677a) C/C++ library to decode tracker music module (MOD) files Update Information: # libopenmpt 0.6.11 (2023-06-18) * [Sec] Possible out-of-bounds read or write when reading malformed MED files. * [Bug] The Opal OPL3 emulator symbols were not namespaced properly. * [Bug] Work-around for MSVC VS2022 17.6.0 ARM64 compiler bug. * [Bug] `Makefile` `CONFIG=emscripten EMSCRIPTEN_PORTS=1` failed to properly use `libogg` and `libvorbis` dependencies. * MO3: Envelope sustain was not imported correctly if the source file was an XM. ChangeLog: * Thu Jul 20 2023 Michael Schwendt - 0.6.11-1 - update to 0.6.11 * Thu Jul 20 2023 Fedora Release Engineering - 0.6.10-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_39_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
[Bug 2224450] perl-CPAN-Perl-Releases-5.20230720 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2224450 --- Comment #5 from Fedora Update System --- FEDORA-2023-401ddad84a has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-401ddad84a` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-401ddad84a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2224450 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202224450%23c5 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2222637] F39FailsToInstall: perl-Syntax-Feature-Loop
https://bugzilla.redhat.com/show_bug.cgi?id=637 Fedora Fails To Install changed: What|Removed |Added Flags||needinfo?(jplesnik@redhat.c ||om) --- Comment #1 from Fedora Fails To Install --- Hello, Please note that this comment was generated automatically by https://pagure.io/releng/blob/main/f/scripts/ftbfs-fti/follow-policy.py If you feel that this output has mistakes, please open an issue at https://pagure.io/releng/ This package fails to install and maintainers are advised to take one of the following actions: - Fix this bug and close this bugzilla once the update makes it to the repository. (The same script that posted this comment will eventually close this bugzilla when the fixed package reaches the repository, so you don't have to worry about it.) or - Move this bug to ASSIGNED if you plan on fixing this, but simply haven't done so yet. or - Orphan the package if you no longer plan to maintain it. If you do not take one of these actions, the process at https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/#_package_removal_for_long_standing_ftbfs_and_fti_bugs will continue. This package may be orphaned in 7+ weeks. This is the first reminder (step 3) from the policy. Don't hesitate to ask for help on de...@lists.fedoraproject.org if you are unsure how to fix this bug. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=637 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%20637%23c1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2224699] perl-File-Find-Object-0.3.8 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2224699 --- Comment #1 from Upstream Release Monitoring --- Scratch build failed. Details below: BuilderException: Build failed: Command '['rpmbuild', '-D', '_sourcedir .', '-D', '_topdir .', '-bs', '/var/tmp/thn-uhy_f67x/perl-File-Find-Object.spec']' returned non-zero exit status 1. StdOut: setting SOURCE_DATE_EPOCH=1689984000 error: Bad file: ./File-Find-Object-0.3.8.tar.gz: No such file or directory RPM build errors: Bad file: ./File-Find-Object-0.3.8.tar.gz: No such file or directory Traceback: File "/usr/local/lib/python3.11/site-packages/hotness/use_cases/package_scratch_build_use_case.py", line 56, in build result = self.builder.build(request.package, request.opts) ^ File "/usr/local/lib/python3.11/site-packages/hotness/builders/koji.py", line 229, in build raise BuilderException( If you think this issue is caused by some bug in the-new-hotness, please report it on the-new-hotness issue tracker: https://github.com/fedora-infra/the-new-hotness/issues -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2224699 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202224699%23c1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2222640] F39FailsToInstall: perl-rpm-build-perl
https://bugzilla.redhat.com/show_bug.cgi?id=640 Fedora Fails To Install changed: What|Removed |Added Flags||needinfo?(ppi...@redhat.com ||) --- Comment #1 from Fedora Fails To Install --- Hello, Please note that this comment was generated automatically by https://pagure.io/releng/blob/main/f/scripts/ftbfs-fti/follow-policy.py If you feel that this output has mistakes, please open an issue at https://pagure.io/releng/ This package fails to install and maintainers are advised to take one of the following actions: - Fix this bug and close this bugzilla once the update makes it to the repository. (The same script that posted this comment will eventually close this bugzilla when the fixed package reaches the repository, so you don't have to worry about it.) or - Move this bug to ASSIGNED if you plan on fixing this, but simply haven't done so yet. or - Orphan the package if you no longer plan to maintain it. If you do not take one of these actions, the process at https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/#_package_removal_for_long_standing_ftbfs_and_fti_bugs will continue. This package may be orphaned in 7+ weeks. This is the first reminder (step 3) from the policy. Don't hesitate to ask for help on de...@lists.fedoraproject.org if you are unsure how to fix this bug. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=640 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%20640%23c1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2224451] perl-Module-CoreList-5.20230720 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2224451 --- Comment #5 from Fedora Update System --- FEDORA-2023-652d1c7134 has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-652d1c7134` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-652d1c7134 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2224451 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202224451%23c5 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2224699] New: perl-File-Find-Object-0.3.8 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2224699 Bug ID: 2224699 Summary: perl-File-Find-Object-0.3.8 is available Product: Fedora Version: rawhide Status: NEW Component: perl-File-Find-Object Keywords: FutureFeature, Triaged Assignee: p...@city-fan.org Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: i...@cicku.me, p...@city-fan.org, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Releases retrieved: 0.3.8 Upstream release that is considered latest: 0.3.8 Current version/release in rawhide: 0.3.7-2.fc38 URL: http://search.cpan.org/dist/File-Find-Object/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/2886/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-File-Find-Object -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2224699 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202224699%23c0 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2224699] perl-File-Find-Object-0.3.8 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2224699 --- Comment #2 from Upstream Release Monitoring --- Created attachment 1977015 --> https://bugzilla.redhat.com/attachment.cgi?id=1977015=edit Update to 0.3.8 (#2224699) -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2224699 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202224699%23c2 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2224450] perl-CPAN-Perl-Releases-5.20230720 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2224450 --- Comment #6 from Fedora Update System --- FEDORA-2023-c396b9b911 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-c396b9b911` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-c396b9b911 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2224450 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202224450%23c6 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2220995] perl-HTTP-Date-6.06 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2220995 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-HTTP-Date-6.06-1.fc38 |perl-HTTP-Date-6.06-1.fc38 ||perl-HTTP-Date-6.06-1.fc37 --- Comment #9 from Fedora Update System --- FEDORA-2023-d8c424aa2a has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2220995 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202220995%23c9 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2224451] perl-Module-CoreList-5.20230720 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2224451 --- Comment #6 from Fedora Update System --- FEDORA-2023-65509a2a81 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-65509a2a81` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-65509a2a81 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2224451 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202224451%23c6 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2224699] perl-File-Find-Object-0.3.8 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2224699 Fedora Update System changed: What|Removed |Added Resolution|--- |ERRATA Status|MODIFIED|CLOSED Fixed In Version||perl-File-Find-Object-0.3.8 ||-1.fc39 Last Closed||2023-07-22 18:17:59 --- Comment #4 from Fedora Update System --- FEDORA-2023-eb6800ae58 has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2224699 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202224699%23c4 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2224699] perl-File-Find-Object-0.3.8 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2224699 Fedora Update System changed: What|Removed |Added Status|NEW |MODIFIED --- Comment #3 from Fedora Update System --- FEDORA-2023-eb6800ae58 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-eb6800ae58 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2224699 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202224699%23c3 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] 2023-07-24 @ 15:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2023-07-24 # Time: 15:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.libera.chat Greetings testers! We didn't meet for some time due to travel and holidays and suchlike, apologies for that. Let's get back on track tomorrow! If anyone has any other items for the agenda, please reply to this email and suggest them! Thanks. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 39 status 3. Flock plans 4. Test Day / community event status 5. Open floor -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ 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
proposal to orphan tcpcrypt
Hi, After talking to the debian maintainer of tcpcrypt, we both decided the best thing is to remove tcpcrypt from the distributions. - The protocol at the IETF seems have stalled for many years - The main proponent and implementer sadly passed away years ago - The website tcpcrypt.org has died a while ago - The package interferes badly with firewalling tools If anyone is really objecting, please let me know and be prepared to become the maintainer in that case. Paul ___ 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 Sun, Jul 23, 2023 at 11:25:12AM -0400, Neal Gompa wrote: > > If the system administrator wants to mount $UNCOMMONFS, they should be > > able to do so without hassle, but that doesn't mean that a normal user > > who got handed a sketchy USB stick at a conference should be able to do > > so with no restrictions at all. > > > > So then some kind of configuration to udisks2 to have a similar effect? And we're right back at square one, with the *overwhelmingly* common case of a single-user system whose "admin" is sitting in front of the system. Of _course_ they want to mount the disk. It's why they plugged it in, and they don't give two hoots if it's a "common filesystem" or not. (FFS, most of the stuff I personally plug in these days is ext4 or ntfs, because fat32 sucks and I can't rely on exfat on all systems I need to interoperate with) And let's be realistic here -- the overwhelmingly common threat model here is that there are untrusted files on a correctly-formed filesystem. Bad guys rarely need or care to get root on the system; what they're after requires normal, non-elevated user permissions. Prompting users 'are you sure you want to use this device' will turn a "yes" into an automatic reflex. Not automounting by default will just add another thing to the "things to change on default fedora installations" lists out there (ie right after the "enable freshrpms and install modern video codecs" step), becuase it's a usability nightmare. In the "usability vs security" tradeoff, usability/convenience *always* wins unless you're at a place that has armed guards at the door with instructions to shoot first. - Solomon -- Solomon Peachypizza at shaftnet dot org (email) @pizza:shaftnet dot org (matrix) Dowling Park, FL speachy (libra.chat) 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 Sun, Jul 23, 2023 at 11:08 AM Eric Sandeen wrote: > > On 7/22/23 9:12 AM, Neal Gompa wrote: > > 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 > > That's approaching it from the wrong angle, IMHO. It's not that you > don't want to be able to mount these filesytems at all, it's that you > don't want let any random unprivileged user do so. > > If the system administrator wants to mount $UNCOMMONFS, they should be > able to do so without hassle, but that doesn't mean that a normal user > who got handed a sketchy USB stick at a conference should be able to do > so with no restrictions at all. > So then some kind of configuration to udisks2 to have a similar effect? -- 真実はいつも一つ！/ 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 9:12 AM, Neal Gompa wrote: 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 That's approaching it from the wrong angle, IMHO. It's not that you don't want to be able to mount these filesytems at all, it's that you don't want let any random unprivileged user do so. If the system administrator wants to mount $UNCOMMONFS, they should be able to do so without hassle, but that doesn't mean that a normal user who got handed a sketchy USB stick at a conference should be able to do so with no restrictions at all. -Eric We could take a similar approach, maybe...? ___ 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 7:57 AM, 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. mount is a privileged operation in the kernel; when system configuration works around that to allow non-trusted users to initiate a mount, that breaks the restrictions that the kernel intentionally put on the ability to ingest a stream of untrusted data from a block device. Filesystems generally *do* care about malformed input, but they do so in the context of the security model that the kernel defines. As an example, XFS goes to great lengths to validate input, and placing checksums on every piece of metadata is a big part of that. In the real world, this validation catches and handles the vast majority of malformed/corrupted input that XFS should expect to see. Other filesystems have similar validation, with similar assumptions. But when fuzzers intentionally malform metadata and then fix up the checksum to look valid, this is something that would never happen organically; it is an intentionally malicious work-around to the existing mechanism. But again, mount is supposed to be a privileged operation, so if the system administrator decides to mount the USB drive they found in the parking lot, that's on them, and not a security issue. They are root, after all. Once you let any random user do this, working around the kernel's privilege checks, it's a different scenario, and it exposes the system to risks that were not part of the original threat model. I wholeheartedly support any effort to restrict (by default) auto-mounting to a smaller set of filesystems that could reasonably be expected to be found on removable media (isofs, fat, exfat ...) and shut off all the rest to limit the attack surface here. This issue and the associated CVEs that get raised have been consuming an inordinate amount of time from a very limited set of filesystem developers. -Eric ___ 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
Fedora rawhide compose report: 20230723.n.0 changes
OLD: Fedora-Rawhide-20230722.n.1 NEW: Fedora-Rawhide-20230723.n.0 = SUMMARY = Added images:2 Dropped images: 4 Added packages: 11 Dropped packages:0 Upgraded packages: 9 Downgraded packages: 0 Size of added packages: 311.83 KiB Size of dropped packages:0 B Size of upgraded packages: 1.20 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 1.39 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: i3 live aarch64 Path: Spins/aarch64/iso/Fedora-i3-Live-aarch64-Rawhide-20230723.n.0.iso Image: Workstation live aarch64 Path: Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-Rawhide-20230723.n.0.iso = DROPPED IMAGES = Image: Silverblue dvd-ostree aarch64 Path: Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-Rawhide-20230722.n.1.iso Image: Silverblue dvd-ostree x86_64 Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20230722.n.1.iso Image: Kinoite dvd-ostree x86_64 Path: Kinoite/x86_64/iso/Fedora-Kinoite-ostree-x86_64-Rawhide-20230722.n.1.iso Image: Onyx dvd-ostree x86_64 Path: Onyx/x86_64/iso/Fedora-Onyx-ostree-x86_64-Rawhide-20230722.n.1.iso = ADDED PACKAGES = Package: rust-biquad-0.4.2-1.fc39 Summary: Library for digital second order IIR filtrers, also known as biquads RPMs:rust-biquad+default-devel rust-biquad-devel Size:25.59 KiB Package: rust-lv2-core-3.0.0-1.fc39 Summary: Rust-lv2's core library RPMs:rust-lv2-core+default-devel rust-lv2-core-devel Size:35.07 KiB Package: rust-lv2-core-derive-2.1.1-1.fc39 Summary: Procedural macros for lv2-core RPMs:rust-lv2-core-derive+default-devel rust-lv2-core-derive-devel Size:24.38 KiB Package: rust-lv2-sys-2.0.0-1.fc39 Summary: Rust-lv2's C header bindings RPMs:rust-lv2-sys+default-devel rust-lv2-sys-devel Size:46.04 KiB Package: rust-lv2-time-0.1.3-1.fc39 Summary: Rust-lv2's wrapper of LV2's time types RPMs:rust-lv2-time+default-devel rust-lv2-time-devel Size:21.96 KiB Package: rust-lv2-units-0.1.3-1.fc39 Summary: Rust-lv2's wrapper of LV2's unit types RPMs:rust-lv2-units+default-devel rust-lv2-units-devel Size:21.81 KiB Package: rust-lv2-urid-2.1.0-1.fc39 Summary: Rust-lv2's URID handling library RPMs:rust-lv2-urid+default-devel rust-lv2-urid-devel Size:23.29 KiB Package: rust-lv2-worker-0.1.1-1.fc39 Summary: Rust-lv2's work offloading library RPMs:rust-lv2-worker+default-devel rust-lv2-worker-devel Size:25.58 KiB Package: rust-urid-0.1.0-1.fc39 Summary: Library for idiomatic URID support RPMs:rust-urid+default-devel rust-urid-devel Size:26.00 KiB Package: rust-urid-derive-0.1.1-1.fc39 Summary: Procedural macros for urid RPMs:rust-urid-derive+default-devel rust-urid-derive-devel Size:22.26 KiB Package: rust-wmidi-4.0.6-1.fc39 Summary: Midi parsing library RPMs:rust-wmidi+default-devel rust-wmidi+std-devel rust-wmidi-devel Size:39.85 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: CTML-2.0.0-6.fc39 Old package: CTML-2.0.0-4.fc38 Summary: C++ HTML document constructor only depending on the standard library RPMs: CTML-devel Size: 99.17 KiB Size change: 1.23 KiB Changelog: * Wed Jul 19 2023 Fedora Release Engineering - 2.0.0-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild * Sun Jul 23 2023 Davide Cavalca - 2.0.0-6 - Update BR to catch2-devel Package: corsix-th-0.67~rc1-1.fc39 Old package: corsix-th-0.67~beta1-1.fc39 Summary: Open source clone of Theme Hospital RPMs: corsix-th corsix-th-data Size: 2.75 MiB Size change: 778 B Changelog: * Wed Jul 19 2023 Fedora Release Engineering - 0.67~beta1-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild * Sat Jul 22 2023 Artem Polishchuk - 0.67~rc1-1 - chore: Update to 0.67-rc1 Package: ghc9.6-9.6.2-9.fc39 Old package: ghc9.6-9.6.2-8.fc39 Summary: Glasgow Haskell Compiler RPMs: ghc9.6 ghc9.6-Cabal ghc9.6-Cabal-devel ghc9.6-Cabal-doc ghc9.6-Cabal-prof ghc9.6-Cabal-syntax ghc9.6-Cabal-syntax-devel ghc9.6-Cabal-syntax-doc ghc9.6-Cabal-syntax-prof ghc9.6-array ghc9.6-array-devel ghc9.6-array-doc ghc9.6-array-prof ghc9.6-base ghc9.6-base-devel ghc9.6-base-doc ghc9.6-base-prof ghc9.6-binary ghc9.6-binary-devel ghc9.6-binary-doc ghc9.6-binary-prof ghc9.6-bytestring ghc9.6-bytestring-devel ghc9.6-bytestring-doc ghc9.6-bytestring-prof ghc9.6-compiler ghc9.6-compiler-default ghc9.6-containers ghc9.6-containers-devel ghc9.6-containers-doc ghc9.6-containers-prof ghc9.6-deepseq ghc9.6-deepseq-devel ghc9.6-deepseq-doc ghc9.6-deepseq-prof ghc9.6-devel ghc9.6-directory ghc9.6-directory-devel ghc9.6-directory-doc ghc9.6-directory-prof ghc9.6-doc ghc9.6-doc-index ghc9.6-exceptions ghc9.6-exceptions-devel ghc9.6-exceptions-doc ghc9.6-exceptions-prof ghc9.6-filepath ghc9.6-filepath-devel ghc9.6-filepath-doc ghc9.6-filepath-prof
Re: Restricting automounting of uncommon filesystems?
On 22/07/2023 08:01, Matthew Garrett wrote: 1) Automounting of removable media exposes the kernel to a lot of untrusted input Disable automatic mount by default. Problem solved. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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)
Il 22/07/23 22:31, Kevin Fenzi ha scritto: > 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? > > LO 7.6 will be branched upstream the next week (week 30) and the final release is scheduled by week 33 (Aug 14, 2023 - Aug 20, 2023). F39 Beta freeze is scheduled on Aug 22. An effort building LO 7.6 in Fedora is ongoing in https://copr.fedorainfracloud.org/coprs/mattia/Libreoffice7.6testing/ We are hitting some test failures that need investigation. To upgrade LO to 7.6 some components will need to be updated (mdds, libixion, liborcus). CCing the package maintainer (dtardon) here. Mattia ___ 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
