Re: Restricting automounting of uncommon filesystems?
On 7/24/23 15:11, Eric Sandeen wrote:
> On 7/23/23 7:22 PM, Steve Grubb wrote:
>> 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.
>
> If "a malicious input can't cause problems" is the threshold for
> trustworthy, I'm not sure we have any trustworthy filesystems as this point.
>
> https://syzkaller.appspot.com/upstream/s/ext4
> https://syzkaller.appspot.com/upstream/s/xfs
> https://syzkaller.appspot.com/upstream/s/btrfs
> https://syzkaller.appspot.com/upstream/s/fat
>
>> 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.
>
> That was awesome, back in the day! syzbot/syzcaller is the new shiny
> here though, finding filesystem flaws day after day that (with all due
> respect) fsfuzzer could never have reached (think: fuzzing metadata and
> then fixing up the checksum so it passes initial validation on read.)
>
> And frankly that is some of my motivation to find an improvement here. A
> small cadre of filesystem developers are near the breaking point trying
> to keep up with an army of machines running syzkaller.
>
> -Eric
How much of the problem is the C programming language itself? I’m NOT
suggesting that you rewrite your filesystem in Rust; that would be an
extremely unreasonable request. I’m merely trying to figure out how
much of this is a case of “filesystems are hard” and how much of this
is C providing essentially no help.
--
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/24/23 08:47, Richard W.M. Jones wrote: > On Sun, Jul 23, 2023 at 11:18:45PM -0400, Demi Marie Obenour wrote: >> 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. > > This is what libguestfs does (KVM guest). > > Rich. I saw that libguestfs has a guestmount(1) tool, and I think this could be a potential solution. An exploit against the kernel FS driver would only grant access to a KVM guest, and the QEMU process can be tightly sandboxed by means such as seccomp and SELinux. I still believe that mounting should _not_ be automatic, though, because it could have side-effects (such as replaying the FS journal) that might not be wanted. To prevent prompt fatigue, Fedora could offer to remember the user’s choice. -- 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 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
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: btrfs loses 32-bit application compatibility after a while
On 7/20/23 11:06, Florian Weimer wrote: > * Demi Marie Obenour: > >> On 7/17/23 09:51, Florian Weimer wrote: >>> * Daniel P. Berrangé: >>> >>>>> But that still raises the question - why does it look like this >>>>> started to happen pretty suddenly around June 30? >>>>> The list of updates that were applied to builders in that timeframe >>>>> doesn't raise any alarm bells (except maybe the 6.3 kernel): >>>>> (see https://pagure.io/releng/issue/11531#comment-864471) >>>>> I read the release notes for the 6.3 kernel but didn't see any >>>>> mentions of BTRFS changes that could explain this. :( >>>> >>>> Or what 32-bit code is being run in the context of koji that is >>>> NOT compiled with LFS ? Is this something silly like configure >>>> script tests not enabling LFS, but the resulting applications >>>> correctly using LFS ? >>> >>> A dependency used during RPM file creation, libcap, is not fully built >>> in LFS mode. Once we fix that, we know that we'll run into issues with >>> chkconfig and update-alternatives. It's a never-ending source of bugs. >>> It's not a good use of maintainer time. >>> >>> We can't change the overall distribution flags with CFLAGS injection >>> because doing so has ABI implications. >> >> Can they be changed at the next mass rebuild? > > Not if we want to maintain compatibility with non-Fedora software. It > probably doesn't matter for most packages, but doing a per-package > analysis is a lot of work. From this thread, it appears that non-LFS 32-bit software is fundamentally unsupportable in the long run, just like software with 32-bit time_t is unsupportable. That leaves two options: 1. Break the ABI, preferably in such a way that causes non-LFS code to fail at load time rather than crashing. 2. Drop 32-bit support from the distribution altogether. It looks like trying to keep 32-bit non-LFS software working will be an endless time sink and is not sustainable in the long term. -- 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: btrfs loses 32-bit application compatibility after a while
On 7/17/23 09:51, Florian Weimer wrote: > * Daniel P. Berrangé: > >>> But that still raises the question - why does it look like this >>> started to happen pretty suddenly around June 30? >>> The list of updates that were applied to builders in that timeframe >>> doesn't raise any alarm bells (except maybe the 6.3 kernel): >>> (see https://pagure.io/releng/issue/11531#comment-864471) >>> I read the release notes for the 6.3 kernel but didn't see any >>> mentions of BTRFS changes that could explain this. :( >> >> Or what 32-bit code is being run in the context of koji that is >> NOT compiled with LFS ? Is this something silly like configure >> script tests not enabling LFS, but the resulting applications >> correctly using LFS ? > > A dependency used during RPM file creation, libcap, is not fully built > in LFS mode. Once we fix that, we know that we'll run into issues with > chkconfig and update-alternatives. It's a never-ending source of bugs. > It's not a good use of maintainer time. > > We can't change the overall distribution flags with CFLAGS injection > because doing so has ABI implications. Can they be changed at the next mass rebuild? -- 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: btrfs loses 32-bit application compatibility after a while
On 7/14/23 17:32, Chris Adams wrote: > Once upon a time, Eric Sandeen said: >> XFS does have a hack^Wmount option to force inodes into the 32-bit >> range, but just FWIW we almost never see users running into problems >> with 32-bit applications (but maybe because they know about the >> mount option...) > > Aren't even most 32-bit applications compiled with LFS? It looks like > anything with _GNU_SOURCE will get it, and IIRC that's not uncommon. > I'm curious how many 32-bit binaries are looking at inode numbers and > are NOT already LFS compatible. I recommending that the entire distro be compiled with LFS. The non-LFS ABI is obsolete for exactly this reason. -- 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: Flock CFP: Language SIGs discussion
On 7/13/23 11:52, Demi Marie Obenour wrote: > On 7/13/23 11:32, Fabio Valentini wrote: >> On Thu, Jul 13, 2023 at 5:25 PM Demi Marie Obenour >> wrote: >>> >>> On 7/5/23 02:22, Jens-Ulrik Petersen wrote: >>>> I have submitted a Flock proposal to have a common discussion session for >>>> (modern) Language SIGs. I think for this to be successful we need >>>> representatives from various Language SIGs to be there (Rust, Haskell, >>>> OCaml, Golang and of course Python and older ecosystems like Perl, R, TeX >>>> come to mind immediately - surely there are more). Language packaging >>>> experts are also welcome of course independently or affiliated to one or >>>> more language SIGs. Of course I also hope there will be broad attendance by >>>> interested contributors. >>>> >>>> The idea is to talk about common and distinct problems faced, both to learn >>>> from each other and to come up with practical ideas and plans for generally >>>> easing Fedora's mass packaging efforts. >>>> >>>> If you plan to be at Flock and are willing and able to represent your >>>> Language SIG at this Flock session do please reply or reach out to me. I >>>> think each SIG could do a brief presentation there to kick off the >>>> dialogue. >>>> >>>> Thanks, Jens >>> >>> This could be made much easier if Fedora’s build system supported automated >>> cascading rebuilds of transitive dependencies. Haskell and OCaml are >>> currently >>> linked statically in Fedora, but could be linked dynamically if cascading >>> rebuilds were supported. Rust is likely, IMO, gain improved support for >>> dynamic >>> linking in the future. >>> >>> I am _not_ going to start a debate as to whether requiring cascading >>> rebuilds >>> is a good idea. That requirement comes from Haskell, OCaml, and Rust, not >>> me, >>> and so any complaints should be directed there. This subthread is strictly >>> about changes to Fedora’s build system that make it easier to implement >>> cascading rebuilds. >> >> I'm not sure how often I have to repeat myself, but dynamic linking >> for Rust crates is NOT GOING TO HAPPEN. Even if the build system >> supported doing this, the average number of updates for Rust crates I >> push every week would keep the build system busy for a month, not even >> mentioning the fact that it would blow up package sizes exponentially >> (yes, *exponentially*, by about a factor of 2^n, with the number n of >> optional features they support). Please stop mentioning Rust in this >> context, it is misleading. >> >> Fabio > > Why is static linking any better? I’m not suggesting building the > Cartesian product of all possible build configurations. That would be > absurd. From my perspective it looks like static linking actually > requires _more_ effort from the builders: they must build everything > for each application that uses it instead of just building it once. > Also if Rust winds up being a significant fraction of the overall system, > the storage requirements of statically linking everything that uses Rust > will be a serious problem. Is what I am missing that the builders cannot handle rebuilding all of the transitive dependencies whenever a new version of a Rust crate comes out? If so, that means that Fedora is shipping binaries built from old versions of Rust crates. -- 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: Flock CFP: Language SIGs discussion
On 7/13/23 11:32, Fabio Valentini wrote: > On Thu, Jul 13, 2023 at 5:25 PM Demi Marie Obenour > wrote: >> >> On 7/5/23 02:22, Jens-Ulrik Petersen wrote: >>> I have submitted a Flock proposal to have a common discussion session for >>> (modern) Language SIGs. I think for this to be successful we need >>> representatives from various Language SIGs to be there (Rust, Haskell, >>> OCaml, Golang and of course Python and older ecosystems like Perl, R, TeX >>> come to mind immediately - surely there are more). Language packaging >>> experts are also welcome of course independently or affiliated to one or >>> more language SIGs. Of course I also hope there will be broad attendance by >>> interested contributors. >>> >>> The idea is to talk about common and distinct problems faced, both to learn >>> from each other and to come up with practical ideas and plans for generally >>> easing Fedora's mass packaging efforts. >>> >>> If you plan to be at Flock and are willing and able to represent your >>> Language SIG at this Flock session do please reply or reach out to me. I >>> think each SIG could do a brief presentation there to kick off the dialogue. >>> >>> Thanks, Jens >> >> This could be made much easier if Fedora’s build system supported automated >> cascading rebuilds of transitive dependencies. Haskell and OCaml are >> currently >> linked statically in Fedora, but could be linked dynamically if cascading >> rebuilds were supported. Rust is likely, IMO, gain improved support for >> dynamic >> linking in the future. >> >> I am _not_ going to start a debate as to whether requiring cascading rebuilds >> is a good idea. That requirement comes from Haskell, OCaml, and Rust, not >> me, >> and so any complaints should be directed there. This subthread is strictly >> about changes to Fedora’s build system that make it easier to implement >> cascading rebuilds. > > I'm not sure how often I have to repeat myself, but dynamic linking > for Rust crates is NOT GOING TO HAPPEN. Even if the build system > supported doing this, the average number of updates for Rust crates I > push every week would keep the build system busy for a month, not even > mentioning the fact that it would blow up package sizes exponentially > (yes, *exponentially*, by about a factor of 2^n, with the number n of > optional features they support). Please stop mentioning Rust in this > context, it is misleading. > > Fabio Why is static linking any better? I’m not suggesting building the Cartesian product of all possible build configurations. That would be absurd. From my perspective it looks like static linking actually requires _more_ effort from the builders: they must build everything for each application that uses it instead of just building it once. Also if Rust winds up being a significant fraction of the overall system, the storage requirements of statically linking everything that uses Rust will be a serious problem. -- 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: Flock CFP: Language SIGs discussion
On 7/5/23 02:22, Jens-Ulrik Petersen wrote: > I have submitted a Flock proposal to have a common discussion session for > (modern) Language SIGs. I think for this to be successful we need > representatives from various Language SIGs to be there (Rust, Haskell, > OCaml, Golang and of course Python and older ecosystems like Perl, R, TeX > come to mind immediately - surely there are more). Language packaging > experts are also welcome of course independently or affiliated to one or > more language SIGs. Of course I also hope there will be broad attendance by > interested contributors. > > The idea is to talk about common and distinct problems faced, both to learn > from each other and to come up with practical ideas and plans for generally > easing Fedora's mass packaging efforts. > > If you plan to be at Flock and are willing and able to represent your > Language SIG at this Flock session do please reply or reach out to me. I > think each SIG could do a brief presentation there to kick off the dialogue. > > Thanks, Jens This could be made much easier if Fedora’s build system supported automated cascading rebuilds of transitive dependencies. Haskell and OCaml are currently linked statically in Fedora, but could be linked dynamically if cascading rebuilds were supported. Rust is likely, IMO, gain improved support for dynamic linking in the future. I am _not_ going to start a debate as to whether requiring cascading rebuilds is a good idea. That requirement comes from Haskell, OCaml, and Rust, not me, and so any complaints should be directed there. This subthread is strictly about changes to Fedora’s build system that make it easier to implement cascading rebuilds. -- 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: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)
On 7/6/23 12:10, Aoife Moloney wrote: > Important process note: we are experimenting with using Fedora > Discussion as part of the Changes process. Change announcements (like > the one you are reading right now) will still be sent to the > devel-announce mailing list, but the conversation about each change > will take place on Fedora Discussion at > https://discussion.fedoraproject.org/t/f40-change-request-privacy-preserving-telemetry-for-fedora-workstation-system-wide/85320 > > > This will follow the same process as before, just with discussion in a > different format > https://docs.fedoraproject.org/en-US/program_management/changes_policy/ > > > You can subscribe to and interact with these conversations by email. > See > https://discussion.fedoraproject.org/t/guide-to-interacting-with-this-site-by-email/ > for detailed instructions. To make sure you do not miss anything, make > sure that you have the Change Proposal category set to “Watching” — > or, if you just want to get notified about new changes but not every > reply in the conversation, to “Watching First Post”. (Click on the > little bell icon at the top right of the category page.) > > > > > The below 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 == > > The Red Hat Display Systems Team (which develops the desktop) proposes > to enable limited data collection of anonymous Fedora Workstation > usage metrics. There are two problems here: 1. The GDPR and similar regulations are 100% clear that consent must be opt-*in*. Opt-*out*, as is proposed here, is not consent. Therefore, this change is proposing collecting telemetry *without user’s consent*. 2. Irrespective of whether or not the metrics are personally identifiable for the purposes of GDPR and other regulations, I highly doubt you will be able to convince people that they are in fact not personally identifiable. Techniques for correlating metrics can only get better, never worse, and this means that what information may become personally identifiable in the future even if it was not in the past. Even Differential Privacy cannot solve this problem because it works on aggregate statistics, not on the raw data collected. The only way I could be convinced that the raw data is in fact not personally identifiable is if there was a mathematical proof to that effect. Such a proof would probably be worthy of publication in a peer-reviewed research paper. Since this Change proposal comes from Red Hat, I have an alternative to propose: Red Hat can ask its paying corporate customers for this information, perhaps in exchange for a discount on their RHEL subscriptions. This should be much less controversial. -- 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: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)
On 7/6/23 21:17, Michael Catanzaro wrote: > On Thu, Jul 6 2023 at 07:42:47 PM -0400, Demi Marie Obenour > wrote: >> Then make the metrics be neither opt-in nor opt-out. Have >> “Enable telemetry (y/n)?” be a mandatory question in the >> installer, >> which the user must answer. > > The problem is if users are expected to answer, they are going to > probably answer No and it's effectively the same as an opt-in. But if > we have a default value, users will be inclined to leave the default > value. > > My plan is to put this switch in gnome-initial-setup, not the > installer. But it will have a default value. > > Remember, for avoidance of doubt, we will NEVER enable telemetry upload > without the user's consent The GDPR is clear that failure to opt-out does not represent consent. -- 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: OT: Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)
On 7/11/23 15:45, Jeremy Linton wrote: > On 7/10/23 13:16, Demi Marie Obenour wrote: >> On 7/10/23 02:30, Vitaly Zaitsev via devel wrote: >>> On 10/07/2023 02:49, Demi Marie Obenour wrote: >>>> QtWebEngine (used by Falkon) was a >>>> month or more behind upstream Chromium last I checked. >>> >>> Qt5QtWebEngine is an extremely vulnerable thing. It still uses Chromium >>> 87.0[1]. >>> >>> Current Chromium version: 105.0. >>> >>> [1]: https://wiki.qt.io/QtWebEngine/ChromiumVersions >> >> In that case it should be removed from the distribution. Can KDE >> mail clients be built without QtWebEngine? This would disable >> HTML email support, but plain text mail might still work. > > The problem isn't QtWebEngine, the latest Qt 6.X is using 108 according > to the link above. > > The problem seems to be that not everything has moved to the 6.x branch yet. > > https://iskdeusingqt6.org/ It’s a mixture. The best possible outcome would be for QtWebEngine to be part of upstream Chromium and use Chromium’s release schedule. Not sure if that is possible/practical. -- 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: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)
On 7/10/23 02:30, Vitaly Zaitsev via devel wrote: > On 10/07/2023 02:49, Demi Marie Obenour wrote: >> QtWebEngine (used by Falkon) was a >> month or more behind upstream Chromium last I checked. > > Qt5QtWebEngine is an extremely vulnerable thing. It still uses Chromium > 87.0[1]. > > Current Chromium version: 105.0. > > [1]: https://wiki.qt.io/QtWebEngine/ChromiumVersions In that case it should be removed from the distribution. Can KDE mail clients be built without QtWebEngine? This would disable HTML email support, but plain text mail might still work. More generally, WebKit is the only major browser engine with upstream support for being embedded, so it is the only embedded browser engine that is supportable security-wise. Unfortunately, it is also the least secure of the major browser engines on Linux last I checked, and in particular is far behind Chromium. -- 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: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)
On 7/9/23 19:08, Allan via devel wrote: > On Sun, 9 Jul 2023 18:54:18 -0400 > Demi Marie Obenour wrote: > >> On 7/9/23 18:53, Allan via devel wrote: >>> On Sun, 09 Jul 2023 06:59:11 + >>> Mattia Verga via devel wrote: >>> >>>> Il 08/07/23 13:06, Vitaly Zaitsev via devel ha scritto: >>>>> On 06/07/2023 18:10, Aoife Moloney wrote: >>>>>> but the conversation about each change >>>>>> will take place on Fedora Discussion at >>>>>> https://discussion.fedoraproject.org/t/f40-change-request-privacy-preserving-telemetry-for-fedora-workstation-system-wide/85320 >>>>> It looks like they've started moving replies they don't like to >>>>> other threads to cover up the flow of resentment that comes >>>>> naturally to them. >>>>> >>>>> That's why switching to Fedora Discussion from the mailing lists >>>>> is a very bad idea: admins or RH staff can easily delete your >>>>> comments or bury them in another threads. >>>>> >>>> Can we please stop implying malevolence every time we don't agree >>>> with something? >>>> >>>> BTW in the spirit of openness, I've set up a poll (UNOFFICIAL) to >>>> clearly state community sentiment about enabling OPT-OUT metrics to >>>> FESCO: >>>> https://discussion.fedoraproject.org/t/unofficial-poll-about-opt-out-metrics-proposal/85494 >>> >>> How is that going to help anything, when some of us are using >>> browsers from Fedora repos, that just gets this answer: >> >> Which browser? > . > Seamonkey, Falkon maybe more... SeaMonkey and Falkon are based on outdated versions of Firefox and Chromium respectively. Mozilla stopped issuing security advisories for SeaMonkey back in 2015, and QtWebEngine (used by Falkon) was a month or more behind upstream Chromium last I checked. -- 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: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)
On 7/9/23 18:53, Allan via devel wrote: > On Sun, 09 Jul 2023 06:59:11 + > Mattia Verga via devel wrote: > >> Il 08/07/23 13:06, Vitaly Zaitsev via devel ha scritto: >>> On 06/07/2023 18:10, Aoife Moloney wrote: >>>> but the conversation about each change >>>> will take place on Fedora Discussion at >>>> https://discussion.fedoraproject.org/t/f40-change-request-privacy-preserving-telemetry-for-fedora-workstation-system-wide/85320 >>> It looks like they've started moving replies they don't like to >>> other threads to cover up the flow of resentment that comes >>> naturally to them. >>> >>> That's why switching to Fedora Discussion from the mailing lists is >>> a very bad idea: admins or RH staff can easily delete your comments >>> or bury them in another threads. >>> >> Can we please stop implying malevolence every time we don't agree >> with something? >> >> BTW in the spirit of openness, I've set up a poll (UNOFFICIAL) to >> clearly state community sentiment about enabling OPT-OUT metrics to >> FESCO: >> https://discussion.fedoraproject.org/t/unofficial-poll-about-opt-out-metrics-proposal/85494 > > How is that going to help anything, when some of us are using browsers > from Fedora repos, that just gets this answer: Which browser? -- 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: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)
On 7/8/23 06:19, Michal Domonkos wrote: > On Thu, Jul 06, 2023 at 05:10:24PM +0100, Aoife Moloney wrote: >> == Summary == >> >> The Red Hat Display Systems Team (which develops the desktop) proposes >> to enable limited data collection of anonymous Fedora Workstation >> usage metrics. > > One thing to realize here is that, no matter what collection method will be > used and how well it will be secured against potential malicious actors, the > reputation of Fedora *will* be harmed or at least tainted. And it won't be > easy to undo that. > > Even if we end up using mathematically sound techniques as per Differential > Privacy (as I suggested in my other reply), most user won't know/realize that > and will only see the words "telemetry" and "Fedora" alongside each other in > all those discussions and articles that will inevitably pop up as a result of > this change. > > I think the reputation of Fedora as a project shouldn't be taken lightly, > regardless of the actual implementation, and should be weighted against the > benefits that it would bring to the project. I'd say a huge portion of the > user base in Fedora consists of technical people who actively despise the > notion of any kind of "phone home" mechanism on their system (me included), > and > for good reason. It's also evidenced by this thread so far. > > The problem, as noted in this thread multiple times, is that if we make this > opt-in, the usefulness would decrease to almost it being irrelevant. If we > make it opt-out, all the above applies (IMHO). > > Consider that even those big software companies couldn't prevent their > products > from getting the bad reputation, despite some of them reportedly using > Differential Privacy (!). I 100% agree with this. Even if it can be done in a way that preserves user privacy, the risk to Fedora’s reputation is simply not worth it. -- 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: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)
On 7/6/23 12:10, Aoife Moloney wrote: > That said, Fedora Legal has determined that if we collect any > personally-identifiable data, the entire metrics system must be > opt-in. Since we are only interested in opt-out metrics due to the low > value of opt-in metrics, we must accordingly never collect any > personally-identifiable data. I oppose any telemetry that is not opt-in, but I also do not think that what this proposal is suggesting is possible to implement. For metrics to not be personally identifiable, it is necessary that the set of metrics collected have sufficiently low entropy that on average, _many_ users will send _the exact same metrics_. It is very hard for me to see any useful set of metrics having such low entropy. If Fedora has 2 million users (possibly an overestimate) then the metrics would need to have entropy much less than 2^21, which means that the entire metrics set would need to be able to be represented as a 20-bit integer. In practice, I suspect one would need to fit the entire set in a 16-bit integer or less, and possibly _significantly_ less. -- 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: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)
On 7/7/23 21:14, Naheem Zaffar wrote: > On Sat, 8 Jul 2023, 01:08 Randy Barlow via devel, < > devel@lists.fedoraproject.org> wrote: > >> On 7/7/23 19:59, Demi Marie Obenour wrote: >>> That is not consent. The GDPR explicitly states that consent must >>> be opt-IN. >> >> I agree. >> >> I think it is important to make it possible for a user to ask for the >> data collected from their machine to be deleted in the event they >> mistakenly submitted data, or changed their mind. >> > > Wouldnt that require the data to be individually identifiable? Yup! The set of all Fedora users is small enough that trying to use cryptographic approaches to mask it won’t work, as a brute-force attack is feasible. -- 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: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)
On 7/6/23 21:17, Michael Catanzaro wrote: > On Thu, Jul 6 2023 at 07:42:47 PM -0400, Demi Marie Obenour > wrote: >> Then make the metrics be neither opt-in nor opt-out. Have >> “Enable telemetry (y/n)?” be a mandatory question in the >> installer, >> which the user must answer. > > The problem is if users are expected to answer, they are going to > probably answer No and it's effectively the same as an opt-in. But if > we have a default value, users will be inclined to leave the default > value. > > My plan is to put this switch in gnome-initial-setup, not the > installer. But it will have a default value. > > Remember, for avoidance of doubt, we will NEVER enable telemetry upload > without the user's consent, which is indicated by either (a) not > flipping the telemetry switch in gnome-initial-setup to the off > position, or (b) flipping the telemetry switch in gnome-control-center > to the on position. That is not consent. The GDPR explicitly states that consent must be opt-IN. The way to get more data is not to trick users, but to explain _exactly_ what that data is in a way that non-technical people can actually understand. -- 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: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)
On 7/6/23 21:17, Michael Catanzaro wrote: > On Thu, Jul 6 2023 at 07:42:47 PM -0400, Demi Marie Obenour > wrote: >> Then make the metrics be neither opt-in nor opt-out. Have >> “Enable telemetry (y/n)?” be a mandatory question in the >> installer, >> which the user must answer. > > The problem is if users are expected to answer, they are going to > probably answer No and it's effectively the same as an opt-in. But if > we have a default value, users will be inclined to leave the default > value. > > My plan is to put this switch in gnome-initial-setup, not the > installer. But it will have a default value. It needs to be off by default. See KDE’s telemetry policy. -- 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: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)
On 7/6/23 15:32, Michael Catanzaro wrote: > > On Thu, Jul 6 2023 at 08:19:07 PM +0200, Vitaly Zaitsev via devel > wrote: >> All telemetry collection MUST be an opt-in feature (disabled by >> default). I'm strongly against enabling it by default. > > As explained in the proposal document, we know that opt-in metrics are > not very useful because few users would opt in, and these users would > not be representative of Fedora users as a whole. We are not interested > in opt-in metrics. Then make the metrics be neither opt-in nor opt-out. Have “Enable telemetry (y/n)?” be a mandatory question in the installer, which the user must answer. -- 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: Proposal: drop delta rpms (for real this time)
On 7/4/23 11:49, Fabio Valentini wrote: > On Thu, Jun 22, 2023 at 10:32 AM Matthew Miller > wrote: >> >> On Mon, Jun 12, 2023 at 09:46:26AM -0700, Kevin Fenzi wrote: >>> I don't think there's a formal change filed yet. >>> >>> Matthew: Did you want to do that? Or would you like me or someone else >>> to do so? >> >> I would love someone else to do so, but if no one else wants to, I can. :) > > Well ... has anybody filed a change proposal yet, or should I do that? > > Fabio Do it! Also include deltarpm=False by default for attack surface reduction. -- 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: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)
On 7/3/23 12:30, Michael Catanzaro wrote: > On Mon, Jul 3 2023 at 06:15:43 PM +0200, Simon de Vlieger > wrote: >> Funnily enough it was switched explicitly from webkitgtk to Firefox >> for >> a reason I forget; I think it was related to disk size. Perhaps Martin >> or Jiri has more details to share on that. > > It's because we're going to remove WebKitGTK from ELN. > > Michael Why is that? WebKitGTK+ is one of those packages that one should only ship if one is willing to take every update from upstream, but my understanding is that WebKitGTK+ tries quite hard to make this easy. -- 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: Minified JS and CSS in Node packages
On 7/3/23 11:59, Tom Hughes wrote: > On 03/07/2023 16:41, Demi Marie Obenour wrote: > >> Would it be possible to ensure that Node packages contain only actual source >> code, as in “the preferred form for making modifications” (quote from GNU >> GPL, >> I forget which version)? > > The simple answer is maybe in principle but in practice it's > very hard as numerous previous threads will tell you. > > The tar balls from the npmjs registry which constitute the > released versions of node packages frequently contain such > things often without the original source or any of the tooling > to build from it. > > The alternative is packaging from the upstream git but even > then, and even if it is well maintained with version tags, there > are often huge dependency chains to get all the tools needed to > actually do the builds. I thought Fedora policy required shipping actual source code, in which case this alternative is the only option allowed. -- 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
Minified JS and CSS in Node packages
Looking at the source to llparse reveals that it contains minified versions of lodash, source-map, js-yaml, diff, and snprintf-js. The corresponding source code also appears to be present, but my understanding of Fedora policy is that the minified versions should not be in a Fedora source package. I suspect other packages in the Node ecosystem have the same problem. Would it be possible to ensure that Node packages contain only actual source code, as in “the preferred form for making modifications” (quote from GNU GPL, I forget which version)? -- 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: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)
On 7/3/23 03:18, Simon de Vlieger wrote: > On 7/2/23 23:56, Demi Marie Obenour wrote: > >> Remote installation is not a solution to the memory bloat. It only >> pushes the problem to whatever machine the browser runs on, and it >> has significant and negative security implications. A solution >> here would be ensuring that the web UI uses no more RAM than the >> GTK UI that preceded it. > > Hi Demi Marie, > > From what I can see by using `smem` the RSS/PSS for the Anaconda GTK > installer in Fedora 38 is 62 MiB RSS and 22 MiB PSS. The Anaconda WebUI > installer (Firefox) in Fedora 39 is 170 MiB RSS and 115 MiB PSS. > > Note that Hans mentioned removing/disabling sssd_kcm and gnome-calendar > in his thread about minimizing memory usage which is a much larger dent > in total memory usage in the scheme of things. > > Personally I'd also like to point out that I an using a 2 GiB memory > single core VM to test these images to see if the live installer > performs on the lower memory devices (yes, I think we can call 2 GiB low > memory nowadays...). > > Regards, > > Simon Fair. I wonder how much of that memory use would go away if instead of using Firefox, the web content ran in an embedded WebKitGTK+ webview. Browser security is not a concern here because in this case the web content is trusted, and this would also allow using WebKitGTK+’s URL redirection features instead of HTTP over localhost. That said, I do want to check that the new Anaconda installer and all of its transitive dependencies will be built from source on Fedora infrastructure. That means _actual_ sources as found in the SCM repository, not the minified blobs one finds on NPM. Web stuff has historically been extremely packaging-unfriendly for this reason, and the Node ecosystem has a long history of supply-chain attacks. Using a React-based UI should mean finding the original source code to all of the transitive NPM dependencies, then rebuilding all of them on Fedora infrastructure. -- 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: LibreOffice packages
On 7/2/23 19:28, Michael Catanzaro wrote: > On Sun, Jul 2 2023 at 04:59:39 PM -0400, Demi Marie Obenour > wrote: >>> >> Fedora Flatpaks are also a security disaster: they are shipped in OCI >> format instead of OSTree format, but they aren’t signed by anyone. >> I’ve disabled the Fedora remote and recommend that others do the >> same. > > I didn't know about this problem. I agree that sounds pretty bad. I'm > going to ask some colleagues to comment on this. Thank you. As an aside, Fedora container images are also unsigned, and inasmuch as they are both shipped in OCI format, it might be possible to fix both at once. > There are, frankly, many other serious problems with Fedora Flatpaks, > most notably lack of regular updates when the app or bundled > dependencies are updated in Fedora. I think of them as a tech preview > that we shipped too early. That sounds accurate. I recommend turning them off by default _for now_, but hopefully they can be turned back on again in the future. > But these problems are not insurmountable, > and if we can get it right, building Flatpaks from RPMs will allow > Fedora to deliver applications packaged at Fedora's high level of > quality in a modern and safer format. I 100% support this. >>> My $0.02: maintaining complex desktop applications as part of the >>> operating system requires significant effort and produces low value >>> for >>> users when you can easily install that app from Flathub instead. (It >>> *especially* doesn't make sense to do in RHEL, but let's focus on >>> Fedora here.) >> >> What is your reasoning here? I’m not saying I disagree with you, >> but >> I want to know *why* you believe this, especially since flatpaks >> consume >> additional memory and disk space compared to RPMs. > > I do not believe that Flatpaks consume significant additional memory. > OK, host shared libraries and flatpaked libraries will be loaded at the > same time, but I really doubt that's going to be at all significant. > They do consume significant disk space if your disk is really small. > ostree deduplication is pretty good, though (and OCI images are > deduplicated too): > > https://blogs.gnome.org/wjjt/2021/11/24/on-flatpak-disk-usage-and-deduplication/ > > So I don't think many users will seriously care about additional memory > use or disk space. > > As a matter of strategy, packaging applications is fine, but nowadays > it is *optional*. 15 years ago, if Fedora did not ship an application, > you had to compile it yourself or, more likely, switch to Ubuntu or > Debian because they have more applications available. That is not the > case today. Our most popular applications are nowadays available from > Flathub or other third-party sources, and users are going to install > them regardless of whether we package them. Having Fedora packages > provides users with another way to use applications they would use on > Fedora anyway. So for the most complex applications, where packaging is > difficult or time-consuming, Fedora packagers will have to decide for > themselves whether it still makes sense to do that work as opposed to > other possible Fedora work. That makes total sense. If there are N distributions and M applications, traditional packaging takes O(N * M) time, whereas Flatpaks take O(N + M) time. Needless to say, the latter is a lot more sustainable as N and M get bigger. > (Flatpaks without sandbox holes are also dramatically more secure than > Fedora RPMs, which is why I'm *really* interested in Flatpaks. But > currently application declare too many holes: > https://theevilskeleton.gitlab.io/2023/05/11/overview-of-flatpaks-permission-models.html > > ) Sandboxing is also my main interest in Flatpaks. The current state of non-macOS desktop security is honestly rather embarrassing and sandboxing applications is a necessary first step in fixing that. Furthermore, sandboxed applications have well-defined interfaces with the rest of the system, which makes isolation techniques like SELinux, Landlock, or even virtualization much easier to apply. > Anyway, I don't mean to suggest we should stop packaging applications > or that the work to keep the LibreOffice packages maintained is not > valuable (thank you to everyone working on that). Being able to > continue shipping LibreOffice by default is especially important for > users who do not already know about LibreOffice and would otherwise not > realize that Linux has an office suite available. What I really meant > there was that packaging applications is not the most valuable way for > Red Hat to contribute to Fedora. That makes total sense, thanks! > Contrast the LibreOffic
Re: CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]
On 6/24/23 11:05, Michael Catanzaro wrote: > > On Sat, Jun 24 2023 at 08:53:32 AM -0500, Chris Adams > wrote: >>> Is it? At one point, there were considerable gaps in security >>> updates; >> RHEL 9.x would get an update while CentOS Stream 9 (as the target for >> RHEL 9.[x+1]) didn't get a corresponding update for quite a while. If >> Stream doesn't get security updates in a timely fashion, it is not at >> all suitable for production use. > > So here is the reality with security updates. The vast majority of > security updates are shipped in RHEL 3-9 months after we fix them, > because minimizing the quantity of updates is an important goal in RHEL > to reduce update churn for customers, so we only want to release quick > fixes for issues that pose serious risk. (Most security issues are just > not very urgent.) This means you get most security fixes drastically > sooner in CentOS Stream than you would in RHEL. However, > higher-severity security updates do get fixed in RHEL first. Developers > are not permitted to fix higher-severity security issues in CentOS > Stream until after the fix is shipped in at least one RHEL update. > We're encouraged to do so immediately after the fix ships in RHEL, so > there *should* only be a minor delay of, say, one or two business days > for the developer to notice the update has shipped. So in general, > CentOS Stream *should* generally be ahead of RHEL and ideally only > slightly behind for the more serious CVEs. What about stuff that is too urgent to wait on Red Hat QA? There have been vulnerabilities (such as CVE-2013-0156 and Log4Shell) for which unauthenticated, fully automated, remote code execution exploits have been found very, _very_ quickly. There may well be times when attackers can write and use an exploit faster than Red Hat QA can process an update. For these vulnerabilities waiting on Red Hat QA is not an option. -- 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: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)
On 6/27/23 05:00, Simon de Vlieger wrote: > On 6/27/23 10:40, Hans de Goede wrote: > > > Ok, so can you provide some instructions for how to make this work ? > I guess it would be something like add the cmdline option + then start > some systemd unit ? Can you please put some instructions for this in > the testing section of: > https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation > (with a note that this is currently not supported / recommended). > > > >> About the improvements on the Live ISO, that should be a question on > Fedora Workstation SIG. Anaconda team is not in charge of the > environment on the Live ISO. > > > > Well you are suggesting a change that is likely going to > significantly increase the amount of memory needed to do a livecd > workstation install and as mentioned above pushing the requirements > above 2G would basically block this change since 2G RAM is currently the > advertised minimum RAM requirement for Fedora workstation installs. > > > > So although I realize this is not entirely fair IMHO if you want to > push forward with this feature then you may also be on the hook to look > into reducing the memory footprint elsewhere so that the end result > still fits in 2G RAM. I have some experience with tweaking the livecd to > work with less RAM and I'm happy to share my experience in this, but I > do not have time to actually implement needed changes for this. > Hi Hans, > > it would indeed involve adding the `inst.webui` and `inst.webui.remote` > kernel command line options and a systemd unit to start the relevant > services (I *think* that'd only be `cockpit.service`). Remote installation is not a solution to the memory bloat. It only pushes the problem to whatever machine the browser runs on, and it has significant and negative security implications. A solution here would be ensuring that the web UI uses no more RAM than the GTK UI that preceded it. -- 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: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)
On 6/26/23 12:00, Aoife Moloney wrote: > https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation > > 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 == > The new PatternFly-based UI has been developed by the Anaconda team > for some time now and we would like to make it available for users of > Fedora to enhance and modernize installation experience. As the first > step in this user adoption process, we are targeting Fedora > Workstation only. > > == Owner == > > * Name: Anaconda team ([[User:jkonecny| Jiří Konečný]]) > > * Email: jkone...@redhat.com > * Name: Fedora Workstation SIG > * Email: desk...@lists.fedoraproject.org > > > == Detailed Description == > The Anaconda team has been working on a new web-based UI for the OS > installer for some time. We would like to give users the fruits of our > work and get feedback so that we know what we need to improve or where > we should focus. > To make the adoption as painless as possible, the Fedora Workstation > was chosen as the first target so we have better control over the > environment and can have a focus. Also, Fedora Workstation has a > smaller featureset than other installation media. The adoption for the > other media later is planned too, but the exact date will be based on > feedback and our capacity allowance. What is the reason for using a web-based UI instead of continuing to use GTK? -- 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: LibreOffice packages
On 6/3/23 08:42, Michael Catanzaro wrote: > On Sat, Jun 3 2023 at 10:26:07 AM -, John Iliopoulos > wrote: >> Hello, >> >> While i completely understand why you do this i do think that it is >> important for desktop/workstation oriented devices to have some >> optional access to Office directly from the image file. Have you >> considered shipping the LibreOffice flatpak via the ISO much like >> Fedora Silverblue does with various other applications? >> >> This is the first time i reply to a mailing list so i hope i have not >> done anything wrong. > > Hi. Welcome to the list. You haven't done anything wrong. > > For Fedora Workstation, the mid-term plan is to ship all preinstalled > apps as Fedora Flatpaks. We cannot ship anything from Flathub because > FESCo will not allow it. I don't *like* this FESCo requirement, but I > also don't expect that to change. Accordingly, since Fedora Flatpaks > are built from Fedora RPMs, maintaining the LibreOffice RPMs is > essential to keep LibreOffice preinstalled. (I think that applies to > Silverblue as well?) Fedora Flatpaks are also a security disaster: they are shipped in OCI format instead of OSTree format, but they aren’t signed by anyone. I’ve disabled the Fedora remote and recommend that others do the same. > My $0.02: maintaining complex desktop applications as part of the > operating system requires significant effort and produces low value for > users when you can easily install that app from Flathub instead. (It > *especially* doesn't make sense to do in RHEL, but let's focus on > Fedora here.) What is your reasoning here? I’m not saying I disagree with you, but I want to know *why* you believe this, especially since flatpaks consume additional memory and disk space compared to RPMs. -- 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: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide) - Proposal Addendum
ically ok, but is heavily discouraged in > principle. > b) build portable for all OSes, but do not ship them (don't do bodhi update) >- this would probably work for all frontiers, only the real > repacked JDK will be different >- pros is, that we will be sure that portables builds on live fedoras >- cons is, that the portable JDK will not be available by dnf install > anyway > c) build portable for all OSes, including bodhi update >- pros is, that we will be sure that portables builds on live fedoras >- another pros is that the portable JDK will be available by dnf > install anyway >- there may be clash during the build which will cause to repack > wrong (newer, non certified) portables > d) include SRPM_REBUILD.readme in srpm and generated > PORTABLES_INSTALL.readme in RPMs, which will ideally at least contain: >- instruction why you need portables >- instruction how to find the portables >- from SRPM_REBUILD.readme pointing to PORTABLES_INSTALL.readme >- generated link to the koji, allowing to download the SRPM >- generated link to the koji, allowing to download the binaries >- generated instruction how to dnf install used portables > > I would currently vote for d). If there will be complains about broken > SRPM rebuild, or need to install portables without hacking, then > fall-back a, b or c via Change Proposal. > Once Bodhi allows single build to be tagged to several release, I will > move to that. > > == Feedback == > > > == Benefit to Fedora == > > Java maintainers will finally have some free time... No kidding - > maintenance and *certification* of so much supported JDKs on so much > Fedora versions is brutal. By building once, and repack, we will > regain cycles to continue support Fedora with all LTS and one STS JDK. What is the reason certification is so hard in terms of human (as opposed to machine) time? If the TCK fails intermittently then that needs to be fixed in the TCK or OpenJDK. It seems to me that an upstream OpenJDK release should not happen unless the TCK passes, and if it passes once it should pass everywhere. Otherwise, there is a bug somewhere, most likely upstream. -- 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: What is Fedora?
On 6/23/23 15:20, Michael Catanzaro wrote: > On Fri, Jun 23 2023 at 01:27:24 PM -0400, Josh Boyer > wrote: >> Which means equivalent fixes are in CentOS Stream and anyone wanting >> to recreate exactly what is in RHEL is welcome to backport that code >> from CentOS Stream or upstream. > > Yes, but that's going to be pretty hard to do if you cannot see what > needs to be backported because you don't have a Customer Portal > subscription. :) > > In this particular case, there are two CVEs fixed somewhere in the > middle of maybe 100 other upstream changes, and the correspondence > between CVE vs. upstream commit is intentionally not public to > discourage distros from backporting individual security fixes. (It's > not a smart idea. Only 5% of WebKit security bugs get CVEs. I sometimes > do security backports for RHEL anyway for regulatory rather than > security reasons.) Anyway, to figure out what to backport in order to > match what's in RHEL, you'd have to either somehow get access to the > RHEL SRPM, or else email me and ask what to do. > > I don't really have any strong opinion about this change. Just pointing > out that it's going to be effectively impossible to reverse-engineer > RHEL from CentOS Stream. Let's not pretend that's realistic. Rebuilders > are going to need to get copies of the RHEL SRPMs somehow if they want > to match RHEL, and they do. For WebKit specifically, my recommendation is to just take the latest version from upstream, since anything else will be missing critical security patches. I would be highly surprised if Red Hat has patches that add any significant value there. This is even more true for Firefox, since Firefox is a leaf package. For upstreams as complex, fast-moving, and exposed as browser engines, trying to backport fixes is a fool’s errand. Just take what upstream provides and ship it. If one needs patches for legal reasons, upstream those and ship the result. And yes, in the case of Chromium that does mean using a clang binary built from the same sources as the one Google provides. Every hour needed to ship a patch is one hour the attackers have to write and deploy an exploit. -- 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: U-Boot for x86 BIOS systems
On 6/15/23 15:00, Jeremy Linton wrote: > Hi, > > On 5/22/23 06:01, Neal Gompa wrote: >> On Mon, May 22, 2023 at 6:57 AM Gerd Hoffmann wrote: >>> >>>Hi, >>> >>>> But could we use U-Boot to fill in this gap so these systems still >>>> work? We'd then treat x86 like ARM (if no UEFI, use U-Boot UEFI). >>> >>> How does u-boot handle EFI variables in that case? >>> >> >> Unless the variable store is disabled, I believe it's written to a >> file? That seems to be how it works on ARM. > > Usually with u-boot the runtime service is simply unavailable, which > tends to break all kinds of things in subtle ways. > > More recently though there have been patches merged to support runtime > services in the uboot/uefi shim by trapping to lower level firmware > which has always had runtime components available (unlike uboot), ex > PSCI. So, if you have runtime variable storage with uboot its most > likely being handled by Trusted Firmware A > (https://www.trustedfirmware.org/). > > That said TFA has all the same problems as EDK2 on some of these > platforms WRT variable storage because its not generally possible to > share something like an emmc/etc device between the Linux kernel and the > firmware. Meaning the firmware needs to have a dedicated device, used to > store the variables. Usually some SPI flash, but not always. I don't > think anyone has managed to get a workable runtime service that writes > the variable store to a file on a shared FS outside of maybe some tech > demos. The problem is that the low level firmware need to understand and > be able to read/write something like the ESP + USB/SD/MMC and then > release it while keeping a volatile copy around long enough for a OS > specific service to then take over persistence of the data. Its brittle > and OS dependent as every single OS in existence then needs to have the > service ported and active. The closest solutions I'm aware of are things > like the older rpi3 EDK2 ports which wrote the variable store back to > the firmware image itself on the ESP. But this doesn't really provide > non-volatile runtime storage either because power loss/whatever causes > updates done while the OS is running to be lost. It also technically > violates the relevant specs as well since it fails to be "tamperproof" . My understanding is that _reading_ variables can be made to work, but SetVariable() will invariably return EFI_UNSUPPORTED. On some WoA systems the solution is a special driver that communicates with the trusted execution environment (TEE). This meets the “tamperproof” requirement (quotes because unless it is in a proper secure element it isn’t really tamperproof), but it means that the OS must use nonstandard methods to access these variables. For WoA this is not a problem because the vendor can just provide a driver for Windows to use, but for Linux it means that the kernel will need a whole bunch of drivers. -- 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: LibreOffice packages
On 6/5/23 15:01, Adam Williamson wrote: > On Mon, 2023-06-05 at 19:51 +0200, Roberto Ragusa wrote: >> On 6/5/23 19:13, Demi Marie Obenour wrote: >> >>> Are you willing to do the packaging work? Asking upstream to create >>> packages for every distribution is not reasonable. >> >> I would never want upstream to do packaging, as experience teaches, >> they would certainly do it wrong. >> Packaging and integration is a job for the distribution; it is their >> added value. Otherwise, what's the meaning of a distribution, if >> the system is composed by a minimal booting image on which you >> add upstream generated blobs? > > This is really the heart of the question, and it's an interesting one. > > The idea that the distribution's job is to package up everything you > might possibly want to use on your system is a very old one that goes > back to the days before having an internet connection was the norm, let > alone having several hundred megabits a second on tap at all times. “several hundred megabits a second on tap at all times” is completely out of the question for the majority of the world’s population. I’m not sure what the median bandwidth in the developing world is, but it is far FAR less than that, not to mention often being metered. -- 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: LibreOffice packages
On 6/5/23 16:35, Michael Catanzaro wrote: > On Mon, Jun 5 2023 at 02:09:58 PM -0400, Steve Grubb > wrote: >> Yes. And how does it's security model work? > > The security model is that the application is assumed to be compromised > by malicious input and is trying to do evil things to the host system, > like read your home directory and send copies of your files to a > ransomware operator or nation state. Linux namespaces plus seccomp > filters are used to confine applications to prevent them from messing > with the host system, or reading your personal files, etc. > > It's great in theory. Problem is, as a transition measure to encourage > developers to adopt Flatpak, you can give your application extra > permissions that totally break the security model, and this is > extremely common in practice. You should only trust applications that > don't do this, but most apps do. See [1] for a discussion of this. > > [1] > https://theevilskeleton.gitlab.io/2023/05/11/overview-of-flatpaks-permission-models.html > > There are different degrees of badness. E.g. Epiphany, which I > maintain, has a sandbox hole that allows it to read and write your > Downloads directory, and another hole that allows it to talk to > Geoclue. These are both unacceptable, but certainly not as bad as > allowing read/write access to the user's home directory or root > filesystem, which many apps actually do. > > Flatpak could be pretty darn secure, but only if we stop allowing this, > and I fear that would likely result in applications abandoning the > platform. This is a major threat IMO. I'd love to see more effort > towards improving our portals so that applications don't need to use > static permissions anymore. We need to really clamp down on this so > that users can trust the Flatpak ecosystem. > >> What is the root of trust? > > I think there is no root. A GPG key is provided when installing a > runtime or application. > >> Are they signed by a Fedora key that I already >> have? > > Nope (except presumably for Fedora Flatpaks). > >> How can we verify it's integrity? > > I think the GPG keys are trust-on-first-use. > >> Once installed, how do I verify it's >> integrity? How do I check if anything has been modified? > > I don't know. Non-Fedora Flatpaks are stored using ostree, so people > familiar with ostree would be able to answer this question. Fedora > Flatpaks are OCI containers, so people familiar with OCI containers > would know about that. > > ostree is a "git for binaries" and you can detect normal non-malicious > modification by looking at the history, e.g. `flatpak remote-info --log > flathub org.gnome.Platform//44`; however, this only tells you when > something changed, not what actually changed. > >> Does it integrate >> well with SE Linux, > > No. selinux is entirely outside the Flatpak security model because > Flatpak is a cross-distro tool and selinux is not used outside Fedora > and Red Hat distros. Fedora could, of course ship its own SELinux policy for Flatpak (and I recommend this), but Flatpak will not (and cannot reasonably be expected to) integrate with SELinux natively. >> IMA, fapolicyd, or openscap? > > I'm not familiar with these technologies, but I think the answer is: no. > >> On a locked down system, are >> there sysctls that I have undo such as user namespaces? > > Technically, Flatpak can work without user namespaces, but this is a > legacy configuration and it only works if bubblewrap (/usr/bin/bwrap) > is built to use suid root instead of user namespaces, which is not > recommend and which we do not do in Fedora. (I think Debian maybe still > does this?) So it will surely break if you disable user namespaces, but > you might be able to make it work by rebuilding your own bubblewrap > instead of using Fedora's. > > The Flatpak sandbox does not attempt to guard against kernel bugs -- it > can't, because it has to allow access to all syscalls that applications > might reasonably want to use -- so if you don't trust the kernel to be > secure (including user namespaces), Flatpak is not the tool for you. Could Flatpak be changed to use e.g. KVM + crosvm for isolation? Flatpak does (via seccomp) prevent applications from creating _new_ user namespaces. -- 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: LibreOffice packages
On 6/5/23 12:13, Roberto Ragusa wrote: > On 6/5/23 09:35, Dominik 'Rathann' Mierzejewski wrote: > >> "easily install from Flathub" brings us closer to Windows where you >> "easily" install software from random places on the Internet and they >> bring their own bundled outdated versions of libraries. Flatpaks have >> the added downside of not integrating well with the OS on top of the >> bloat they bring. No, thank you. I'd rather have proper well-integrated >> RPMs installed from official distro repos. > > Unfortunately very few people still understand the value of using > system libraries instead of bundling one hundred of them in each package. > The day a zlib vulnerability is discovered, instead of just updating > a 50k lib rpm (and restart apps, or maybe reboot), you have to update > 30 apps, each of them sized at 50MB, and including possibly badly patched > versions of the lib etc. (good luck knowing which app is affected, > when the fix will be available, ...). zlib should be added to the standard freedesktop.org runtime if it is not already included. > There is a disturbing trend to bundling everything, which comes from > environments with no shared libraries (Android) or from languages > that do not do dynamic linking (golang). Bundling is the norm on Windows and macOS, and is required on Android and iOS. Cross-platform projects like LibreOffice, Firefox, and OBS already have to deal with updating bundled dependencies. > Whatever is not in a rule-conforming rpm, is not correctly packaged, > in my opinion. Are you willing to do the packaging work? Asking upstream to create packages for every distribution is not reasonable. -- 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: LibreOffice packages
On 6/1/23 15:59, Christian Schaller wrote: > On Thu, Jun 1, 2023 at 2:36 PM Demi Marie Obenour > wrote: >> Why is a Flatpak a better choice for LibreOffice? > > There are a lot of ways to answer this, but from any upstream the advantage > of Flatpak is that it means package once and then deploy everywhere. So it > saves them work. > > From a Fedora perspective there is of course nobody telling anyone to not > maintain LibreOffice as RPMS or as a Fedora flatpak going forward, but even > if nobody does we have a good option available in the Flathub package, > especially with the Flathub package not being verified as the official > package of upstream LibreOffice. Did you mean “now”? “not” seems like the opposite of your intended meaning. > Having things as Flatpaks is also of value for us to enable long term > efforts such as Fedora Silverblue. > > Hope this answers your question. > > Christian-- 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: LibreOffice packages
On 6/1/23 14:30, Matthias Clasen wrote: > Hey, > > as you've probably seen, the LibreOffice RPMS have recently been orphaned, > and I thought it would be good to explain the reasons > behind this. > > The Red Hat Display Systems team (the team behind most of Red Hat’s desktop > efforts) has maintained the LibreOffice packages in Fedora for years as part > of our work to support LibreOffice for Red Hat Enterprise Linux. We are > adjusting our engineering priorities for RHEL for Workstations and focusing > on gaps in Wayland, building out HDR support, building out what’s needed for > color-sensitive work, and a host of other refinements required by Workstation > users. This is work that will improve the workstation experience for Fedora > as well as RHEL users, and which, we hope, will be positively received by the > entire Linux community. > > The tradeoff is that we are pivoting away from work we had been doing on > desktop applications and will cease shipping LibreOffice as part of RHEL > starting in a future RHEL version. This also limits our ability to maintain > it in future versions of Fedora. > > We will continue to maintain LibreOffice in currently supported versions of > RHEL (RHEL 7, 8 and 9) with needed CVEs and similar for the lifetime of those > releases (as published on the Red Hat website). As part of that, the > engineers doing that work will contribute some fixes upstream to ensure > LibreOffice works better as a Flatpak, which we expect to be the way that > most people consume LibreOffice in the long term. > > Any community member is of course free to take over maintenance, both for the > RPMS in Fedora and the Fedora LibreOffice Flatpak, but be aware that this is > a sizable block of packages and dependencies and a significant amount of work > to keep up with. > > Matthias Why is a Flatpak a better choice for LibreOffice? -- 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: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)
On 6/1/23 07:33, Kevin Kofler via devel wrote:
> Jiri Vanek wrote:
>> At elast providing ofjava/openjdk is definitley out of scope.
>
> I do not think a Provides would be a trademark violation. It is a part of
> the standard procedure for renaming a package. But you would have to ask Red
> Hat Legal for a definite answer. I am not a lawyer.
>
> That said, there might not even be a trademark issue at all, at least for
> "OpenJDK" ("Java" might be different), see Florian Weimer's reply, pointing
> to:
> https://openjdk.org/legal/openjdk-trademark-notice.html
>
>> As you wrote about the liberty of choice between temurins and fdeoara ona
>> - can you be a bit more specific? Afaik if the builds are similar, we have
>> mcuh less possibility of some fedora-specific bug.
>
> But it also means that I no longer have the option to use a Java that does
> not bundle several libraries, possibly including security vulnerabilities,
> bloating its size, and likely reducing system integration (there have been
> concerns about, e.g., worse fontconfig integration in the discussion of your
> previous Change proposal). There is now just the "choice" between a Fedora
> package with everything bundled and third-party packages with also
> everything bundled.
>
>> I once wrote,m that wworked 10years to enable dynamic linking, and yes,
>> all is upstream, but there are limitations which can not be overtaken -
>> major is ahead of tie comilation. If you can do it right, you cnanot have
>> dyanmic linking.
>
> Wait, Java does real AOT compilation now? Or are we talking about that
> strange "feature" you already brought up in the old discussion, where you
> basically just prepend a JRE to a JAR and ship that as a "compiled"
> executable? That "feature", to be honest, I had never heard of before you
> folks brought it up.
>
> As far as I can tell, nobody in the Java world uses it. It breaks the "write
> once, run anywhere" promise and brings us no real advantage over having the
> JRE and the JAR separate.
>
> It is definitely not useful for me because our customers all run Windows,
> not Fedora or any other GNU/Linux. So really it makes no difference for me
> whether my "AOT-compiled" binaries run only on Fedora ≥ n (dynamic linking)
> or on all GNU/Linux (static linking), they will not run on our customers'
> computers anyway, making that "feature" entirely useless either way.
>
> We have a few ways to deploy our JARs to our customers, but none of them
> involves turning them into native executables through (either real or fake
> as described above) AOT compilation.
I haven’t written Java in years, but my understanding is
that AOT compilation has three major advantages:
1. It reduces the size of total deliverables because the
final executable only includes the libraries it needs.
2. It is the _only_ way to have decent performance on
platforms where JIT compilation is forbidden.
3. AOT-compiled apps start up faster and use less memory.
In short, an AOT-compiled application behaves much more
like one that is written in a native language like C++,
Rust, or Swift. Additionally, AOT-compiled applications
are likely significantly harder to reverse engineer. That
is a bad thing from my perspective, but in the corporate
world it might be desirable.
--
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: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)
On 5/31/23 13:08, Peter Boy wrote: > > >> Am 31.05.2023 um 18:52 schrieb Vitaly Zaitsev via devel >> : >> >> On 31/05/2023 17:02, David Schwörer wrote: >>> Could you explain what certification means? >>> It sounds like you run some very expensive tests, and building is actually >>> fast. >> >> You can't distribute any package named Java or OpenJDK unless it passes the >> Oracle test suite. >> >> I think Fedora should drop openjdk package and introduce a new one - >> coffee-named-language. Then we can get rid of any Oracle tests. > > Did you ever develop in Java? It doesn't sound like you are even minimally > familiar with Java. A little expertise would really be beneficial for devel > mailing list. Can you explain please? -- 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: Should Fedora switch to full kernel preemption (CONFIG_PREEMPT=y)?
On 5/24/23 08:44, Zdenek Kabelac wrote: > Dne 20. 05. 23 v 22:43 Demi Marie Obenour napsal(a): >> I noticed that by default, Qubes OS has voluntary kernel preemption >> as opposed to full preemption. I found that enabling full preemption >> (preempt=full on kernel command line) makes the system significantly >> more responsive under heavy I/O load. In particular, if I build a >> kernel in a Qubes OS VM, it significantly degrades responsiveness >> without preempt=full. With preempt=full, the system remains >> responsive. The storage stack used is LVM thin provisioning on LUKS, >> and I have observed significant CPU usage in dom0 kernel threads with >> names that indicate they are related to dm-thin and dm-crypt. >> >> The kernel config used by the Qubes kernel package I use (6.1.28) is >> based on Fedora 37’s config, and Marek Marczykowski-Górecki (CCd) >> indicated that the same arguments apply to Fedora. Therefore, I am >> asking if Fedora should use full kernel preemption by default. > > > Hi Demi > > > Could you please provide 'dmsetup table' - so we could see how doe your > device stack looks like ? The output of 'dmsetup table' contains all qube names so I would prefer to not post it publicly. The device stack is NVMe -> crypt -> linear -> thin pool -> thin. > Aren't you disabling work-queues on the table line for crypt targets ? The only optional parameter passed to dm_crypt is allow_discards, so presumably no. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital 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: Salt is broken in Fedora 38 - asking a python-savvy provenpackager to help
On 5/22/23 19:17, Christopher wrote: > Hi, > > Is anybody able to help fix salt-minion in F38? It's been broken > because of a newer version of python setuptools in F38. There's a > patch upstream, and the newer version also includes that patch. It > just needs to be incorporated into Fedora. > > https://bugzilla.redhat.com/show_bug.cgi?id=2189782 > > The maintainer does not seem to have responded in at least several > months on bugzilla. I'm not really a python person, and don't know > much about salt, and am not a provenpackager. But my $dayjob uses Salt > for some things, and if it doesn't start working again soon, I'm > afraid they'll revoke my permission to use Fedora at work. So, any > help to get this fixed would be greatly appreciated. Qubes OS also uses Salt. CCing Marek Marczycowski-Górecki and Frédéric Pierret of Invisible Things Lab. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital 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
Should Fedora switch to full kernel preemption (CONFIG_PREEMPT=y)?
I noticed that by default, Qubes OS has voluntary kernel preemption as opposed to full preemption. I found that enabling full preemption (preempt=full on kernel command line) makes the system significantly more responsive under heavy I/O load. In particular, if I build a kernel in a Qubes OS VM, it significantly degrades responsiveness without preempt=full. With preempt=full, the system remains responsive. The storage stack used is LVM thin provisioning on LUKS, and I have observed significant CPU usage in dom0 kernel threads with names that indicate they are related to dm-thin and dm-crypt. The kernel config used by the Qubes kernel package I use (6.1.28) is based on Fedora 37’s config, and Marek Marczykowski-Górecki (CCd) indicated that the same arguments apply to Fedora. Therefore, I am asking if Fedora should use full kernel preemption by default. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital 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 proposal: BiggerESP (Self-Contained Change proposal)
On 5/9/23 14:47, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, May 09, 2023 at 01:31:01PM -0500, Chris Adams wrote: >> Once upon a time, Chris Murphy said: >>> What about the increasing growth in linux-firmware and in particular the >>> NVIDIA firmware requirements? My reading suggests it's significant and the >>> future growth also significant. >> >> Could we use a dumb framebuffer in initrd and get rid of all the GPU >> firmware from the image? > > Maybe, probably, who knows… But it's not just the video. The pressure > to add more stuff and more drivers will only grow: bluetooth for keyboards > and FIDO2, sound support for voice assistance, network for remote attestation > or clevis, etc. We can push this can down the road, but it seems we need > to be ready to add move stuff before root is available anyway. > > Zbyszek I don’t think putting more and more in the initramfs is a good idea. I would much rather have a dm-verity protected partition for early boot stuff, which then uses pivot_root() to switch to the main system. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital 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 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)
On 5/9/23 07:53, Stephen Smoogen wrote: > On Mon, 8 May 2023 at 19:35, Demi Marie Obenour > wrote: > >> On 5/8/23 19:09, Neal Gompa wrote: >>> On Mon, May 8, 2023 at 7:05 PM Demi Marie Obenour >> wrote: >>>> >>>> On 5/8/23 18:49, Kevin Fenzi wrote: >>>>> On Mon, May 08, 2023 at 09:29:02PM +0100, Sebastian Crane wrote: >>>>>> Dear Kevin, >>>>>> >>>>>>>> Hmm, quoting from https://pagure.io/releng/issue/11092: >>>>>>>>>> Also the aarch64 cluster is running on Fedora 33 boxes, so we >>>>>>>>>> should probably try to do a full redeploy :-( >>>>>>>>> We can't upgrade it from f33 because docker is no longer in f34+ >> and >>>>>>>>> openshift origin / 3.11 doesn't support any newer either. >>>>>>>> >>>>>>>> Is this still true? I don't think we want to make the Fedora release >>>>>>>> process contingent on something that requires F33. >>>>>>> >>>>>>> yes, it's still true. Note thats the aarch64 osbs cluster. >>>>>>> The x86_64 one is rhel7. >>>>>> >>>>>> Might it be possible to replace Docker with CRI-O on the OpenShift >>>>>> cluster? >>>>> >>>>> Nope. openshift 3 / osbs1 uses docker. :( >>>>> >>>>> kevin >>>> >>>> alias docker=podman >>> >>> Using Podman with it through Podman's implementation of the Docker >>> Host protocol *may* work, but a version of Podman that has it is not >>> currently available for RHEL 7 (which is what OpenShift 3.11 runs on). >> >> Time for an OpenShift upgrade? >> >> > I realize people are trying to help with suggestions, but the problem is > that this is not a simple solution or it would have been done years ago. > > The Fedora Build System is a very complicated set of applications all tied > together with custom scripting, schema, and various updates over time. > There are somewhere around 40 core services and 30 more subsidiary ones > which need to be continually working to allow for the daily builds for > multiple releases. Many of those services have been added in at different > times with different operating systems and rules. In order to work with > each other a lot of 'glue' scripting, libraries and such are needed. > > You upgrade podman/docker in one section and you find that the message bus > isn't sending in another because an API call isn't there anymore. You try > putting in something which says it has a koji plugin and you find it > doesn't work with our koji and then you need to extend the plugin 40 ways > to work with bodhi, pdc, fedmsg and fedora-messaging, and a dozen other > things which all are the actual build system. Once those get fixed, you > find that it is now causing other glue parts to fail in odd ways no one > remembers why without some archaeological coding. Having ancient versions of OpenShift is almost certainly a security problem. If there is stuff that cannot be kept on a supported version it should be removed. > When dealing with the Build system side of things there is currently 1 > senior system administrator and 1 senior release engineer. There are some > volunteers who can work on subparts but mainly have day jobs doing other > things. Looking at IRC, most of the 10-12 hour work day is dealing with > compose problems, build issues, hardware failures, and similar things. Most > of the 40 component subsystems like the Open Shift Build System (OSBS) are > brought in by a dedicated team who have a budget time to get it working and > into place. Once that time is done, any fixes are on the Fedora staff or > working with available time from whatever team. This is the actual problem IMO. What will it take to fix it? > tl;dr: The Fedora Build System is in total a very complicated set of tools > where changing or upgrading any one part tends to cascade to fixing lots of > glue throughout the system. Instead of looking to upgrade things to add > more deliverables, it may be better to look at other ways to get those > deliverables built. Do you mean outside of the Fedora Build System? -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital 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 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)
On 5/8/23 19:09, Neal Gompa wrote: > On Mon, May 8, 2023 at 7:05 PM Demi Marie Obenour > wrote: >> >> On 5/8/23 18:49, Kevin Fenzi wrote: >>> On Mon, May 08, 2023 at 09:29:02PM +0100, Sebastian Crane wrote: >>>> Dear Kevin, >>>> >>>>>> Hmm, quoting from https://pagure.io/releng/issue/11092: >>>>>>>> Also the aarch64 cluster is running on Fedora 33 boxes, so we >>>>>>>> should probably try to do a full redeploy :-( >>>>>>> We can't upgrade it from f33 because docker is no longer in f34+ and >>>>>>> openshift origin / 3.11 doesn't support any newer either. >>>>>> >>>>>> Is this still true? I don't think we want to make the Fedora release >>>>>> process contingent on something that requires F33. >>>>> >>>>> yes, it's still true. Note thats the aarch64 osbs cluster. >>>>> The x86_64 one is rhel7. >>>> >>>> Might it be possible to replace Docker with CRI-O on the OpenShift >>>> cluster? >>> >>> Nope. openshift 3 / osbs1 uses docker. :( >>> >>> kevin >> >> alias docker=podman > > Using Podman with it through Podman's implementation of the Docker > Host protocol *may* work, but a version of Podman that has it is not > currently available for RHEL 7 (which is what OpenShift 3.11 runs on). Time for an OpenShift upgrade? -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital 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 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)
On 5/8/23 18:49, Kevin Fenzi wrote: > On Mon, May 08, 2023 at 09:29:02PM +0100, Sebastian Crane wrote: >> Dear Kevin, >> >>>> Hmm, quoting from https://pagure.io/releng/issue/11092: >>>>>> Also the aarch64 cluster is running on Fedora 33 boxes, so we >>>>>> should probably try to do a full redeploy :-( >>>>> We can't upgrade it from f33 because docker is no longer in f34+ and >>>>> openshift origin / 3.11 doesn't support any newer either. >>>> >>>> Is this still true? I don't think we want to make the Fedora release >>>> process contingent on something that requires F33. >>> >>> yes, it's still true. Note thats the aarch64 osbs cluster. >>> The x86_64 one is rhel7. >> >> Might it be possible to replace Docker with CRI-O on the OpenShift >> cluster? > > Nope. openshift 3 / osbs1 uses docker. :( > > kevin alias docker=podman -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital 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 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)
On 5/8/23 16:10, Stephen Smoogen wrote: > On Mon, 8 May 2023 at 15:58, Zbigniew Jędrzejewski-Szmek > wrote: > >> On Mon, May 08, 2023 at 09:24:08AM -0700, Kevin Fenzi wrote: >> >>> I'd like to note that making this blocking doesn't waive any kind of >>> magic wand that makes our infrastructure more reliable. ;) >>> The container build pipeline is a long collection of fragile things. >>> It may well result in us slipping more based on things not working. ;( >> >> Hmm, quoting from https://pagure.io/releng/issue/11092: >>>> Also the aarch64 cluster is running on Fedora 33 boxes, so we >>>> should probably try to do a full redeploy :-( >>> We can't upgrade it from f33 because docker is no longer in f34+ and >>> openshift origin / 3.11 doesn't support any newer either. >> >> Is this still true? I don't think we want to make the Fedora release >> process contingent on something that requires F33. >> >> ``` > $ sudo -i ssh osbs-aarch64-node01.iad2.fedoraproject.org cat > /etc/system-release > Fedora release 33 (Thirty Three) > ``` > > My memory of this is that this is not an easy thing to 'fix'. Podman instead of Docker? -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital 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: Firefox builds broken on F38/39
On 4/30/23 06:41, Fabio Valentini wrote: > On Sun, Apr 30, 2023 at 8:00 AM Bojan Smojver via devel > wrote: >> >> Thank you for the pointer Kevin! Trying to build with older rust in >> corp now: >> https://copr.fedorainfracloud.org/coprs/bojan/FF/build/5862010/ > > Note that there's apparently a few known issues with Rust + LLVM 16 > (look at the "Fedora Rust" matrix room's history from a few days ago, > if you can). > Long story short, at least llvm < 16.0.2 seems to have had code > generation problems with Rust, but at least *some* of those should be > fixed by the llvm 16.0.2 update ... but it looks like not all of them, > since firefox still fails to build with 16.0.2 :( > > If you haven't already, please file a bug against the "rust" package > ... jistone is the expert for this kind of thing, but we can't all > follow the devil list :). If this turns out to be an issue in LLVM > itself, the bug can always be reassigned to the llvm package if > necessary. > > Fabio Why does the Rust package not use Rust’s own fork of LLVM? -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital 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: Firecracker microVM manager
On 4/24/23 08:33, Neal Gompa wrote: > On Mon, Apr 24, 2023 at 4:19 AM Peter Robinson wrote: >> >>>> There is no problem technically; the Copr repo[2] is building >>>> Firecracker RPMs with musl. Maintainers of both Rust and musl seemed >>>> to be against it in Fedora. From this thread: >>> Why does Fedora not want to ship Firecracker statically linked to musl? >>> That is the supported and tested configuration upstream. Using glibc >>> or dynamic linking is not supported for production use. >> >> Because glibc is Fedora's supported libc implementation and supporting >> two different implementations at the same time is complex > > And importantly, as the musl maintainer, I recommended against it. We > should take the opportunity to engage with upstream to fully support > glibc instead. Can they support glibc without either taking on a huge maintenance burden or weakening the sandbox? -- 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: Firecracker microVM manager
On 4/22/23 10:13, David Michael wrote: > On Fri, Apr 21, 2023 at 10:02 PM Demi Marie Obenour > wrote: >> On 4/21/23 11:13, David Michael wrote: >>> Hi, >>> >>> Following up on this, Firecracker has been accepted and submitted to >>> Fedora. Thanks to Fabio for all of the Rust reviews. >>> >>> F37 https://bodhi.fedoraproject.org/updates/FEDORA-2023-dca8124d3b >>> F38 https://bodhi.fedoraproject.org/updates/FEDORA-2023-edcbcf18e0 >>> >>> Some quick comments on the TODO from the original e-mail: >>> >>> On Sat, Mar 4, 2023 at 12:40 PM David Michael wrote: >>>> - The musl package adds /usr paths for compatibility with the compiler >>>> --sysroot option. >>>> - The rust compiler adds musl target subpackages. >>> >>> Targeting musl was dropped after the initial discussion, so there is >>> no sandbox or seccomp filter in Fedora until that can be implemented >>> with dynamic linking glibc upstream. I'll keep the Copr repo[0] >>> active for a while to provide musl builds. >> >> Would it be possible to add a warning to this effect? Without any form >> of sandboxing Firecracker is not suitable for production use. > > Where would such a warning be placed? The sandboxing is done by a > standalone program[0] which is not built in the package, so it should > be clear that it isn't available. Package description perhaps? >> Does the >> sandboxed portion of Firecracker do anything that would require an NSS >> (name service switch) lookup, such as DNS or username resolution? > > I don't think NSS lookups are an issue since the program takes > numerical UID/GID values as command-line arguments. The main breaking > issue with the jailer is that it requires Firecracker to be a single > static binary[1] (which is the musl target's default output upstream). > Their documentation also says glibc isn't supported, but I haven't > tried making a static glibc binary to see what fails. The seccomp > filter being unimplemented for glibc is a separate issue from the > jailer. glibc does not support static linking well. >> If >> not, then I don’t see why musl (which Fedora already ships!) would be a >> problem. > > There is no problem technically; the Copr repo[2] is building > Firecracker RPMs with musl. Maintainers of both Rust and musl seemed > to be against it in Fedora. From this thread: Why does Fedora not want to ship Firecracker statically linked to musl? That is the supported and tested configuration upstream. Using glibc or dynamic linking is not supported for production use. -- 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: Firecracker microVM manager
On 4/21/23 11:13, David Michael wrote: > Hi, > > Following up on this, Firecracker has been accepted and submitted to > Fedora. Thanks to Fabio for all of the Rust reviews. > > F37 https://bodhi.fedoraproject.org/updates/FEDORA-2023-dca8124d3b > F38 https://bodhi.fedoraproject.org/updates/FEDORA-2023-edcbcf18e0 > > Some quick comments on the TODO from the original e-mail: > > On Sat, Mar 4, 2023 at 12:40 PM David Michael wrote: >> - The musl package adds /usr paths for compatibility with the compiler >> --sysroot option. >> - The rust compiler adds musl target subpackages. > > Targeting musl was dropped after the initial discussion, so there is > no sandbox or seccomp filter in Fedora until that can be implemented > with dynamic linking glibc upstream. I'll keep the Copr repo[0] > active for a while to provide musl builds. Would it be possible to add a warning to this effect? Without any form of sandboxing Firecracker is not suitable for production use. Does the sandboxed portion of Firecracker do anything that would require an NSS (name service switch) lookup, such as DNS or username resolution? If not, then I don’t see why musl (which Fedora already ships!) would be a problem. If it does, could the lookups be moved to a separate process? -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital 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: Firecracker microVM manager
On 3/6/23 13:38, Richard W.M. Jones wrote: > On Sun, Mar 05, 2023 at 12:18:18AM +0100, Kevin Kofler via devel wrote: >> David Michael wrote: >>> - Firecracker can be built with Fedora's libc (glibc), but it is >>> officially unsupported upstream[3]. Functionality would be harmed by >>> not using musl, e.g. seccomp filters are not used. >> >> Upstream's refusal to write seccomp filters that work with glibc should be a >> red flag. It is definitely possible to sandbox glibc applications with >> seccomp, e.g., Chromium does it. It does need updates/fixes to the seccomp >> rules with almost every new version of glibc, but it is possible. > > And since we're talking hypervisors, qemu also manages to use glibc & > implement a seccomp filter. Is it an allowlist or a blocklist? Allowlists are much more secure, but require knowing about *everything* that a program will ever execute. Static linking makes this much easier to ensure. IIUC the main problem with musl is the lack of NSS support, which means that name lookups won’t work. One option would be to split Firecracker into two processes: a launcher that does all name lookups, and a sandboxed process that does everything else. -- 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: Proposal: drop delta rpms (for real this time)
On 2/28/23 05:06, Petr Pisar wrote: > V Tue, Feb 28, 2023 at 02:47:03AM -, Daniel Alley napsal(a): >> I am not sure whether by "all historical updates" you are only referring to >> all updates being listed in updateinfo.xml, or all history generally >> (including old packages). > > The latter. > >> But in the latter case, note that keeping all >> updates massively inflates the storage requirements for maintaining a copy >> of the repo, which many (or even most) corporate users do. This is not >> a huge problem, generally, but it's also not ideal, and probably isn't the >> right tradeoff for Fedora. >> > I know. I only replied the question. > >> Here[0] for example is RHEL 8 baseos and appstream, for which the difference >> between storing "only the latest package" and "all the packages listed" is >> 20x and 10x, respectively. Metadata size would likewise be larger, meaning >> DNF clients have more to download. >> > I don't say Fedora needs to do it the same way. Fedora could only accumulate > updateinfos while only retaining the latest package. Would it inflate > metadata? Definitely. But if you want to deliver the data to the clients, you > have to store them somewhere. Would that affect all clients? No. > updateinfo.xml can only be downloaded by clients requesting that data. People > doing "dnf upgrade" can safely skip it. > > Or Fedora could reverse it: Fedora would run a network service which clients > would send a list of installed packages and the service would return a list of > affected packages. At the end, ostree od debuginfod services work like that. debuginfod clients should be checking the downloaded data against a hash included in the binary being debugged. -- 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: Proposal: drop delta rpms (for real this time)
On 2/23/23 18:00, Björn Persson wrote: > Gordon Messmer wrote: >> Contrary-wise: Because Fedora updates only contains the latest built, >> once a build marked as a security fix is obsoleted by another build, >> there is no longer any indication that a security issue existed in any >> version, at which point "dnf update --security" no longer works. > > There are also other dangers with installing only security fixes. If a > bugfix is released and packaged, and later it's discovered that the bug > had security implications, then no security update will be made because > the fix is already packaged. It might be possible to set a security > flag on the update after the fact, but nobody will bother with that. > > I would therefore advise against using --security. If one can't install > all the updates continuously, then one should use a more stable > distribution than Fedora. > > Björn Persson I actually use --security for the *opposite* purpose: to get security updates from updates-testing. Only problem I can remember having is broken syntax highlighting from a somewhat recent vim update. -- 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: Proposal: drop delta rpms (for real this time)
On 2/23/23 12:52, Matthew Miller wrote: > On Wed, Feb 22, 2023 at 10:33:27AM -0800, Kevin Fenzi wrote: >> Just FYI, we do not produce drpms for rawhide/branched at all (since >> 2017 ish). > [...] >> Its one line in bodhi pungi config: >> createrepo_deltas = False >>> If shut off, can it be turned back on again (in case of Regrets)? >> Just change the one line back to True (well, it's more complex because >> we only actually do drpms for the 'Everything' repo, not others, but >> it's one line). > > > So, it sounds like "remove the step in the release SOP to turn them _on_ for > the branch at release time" would be the easiest way to go. And the default > config could be changed in DNF at any time for F38+. I would like to see the DNF config changed in F38, for attack surface reduction reasons. -- 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: Proposal: drop delta rpms (for real this time)
On 2/22/23 10:39, Ben Cotton wrote: > On Tue, Feb 21, 2023 at 3:48 PM Matthew Miller > wrote: >> >> What we're doing now — as has been the case for several years, already noted >> in the previous discussion — has very little end-user value. Also as noted >> in that thread (as in the ticket)... that's unfortunate, because it did >> bring some real benefits (and could possibly do even more.) > > The fact that the value of deltas requires frequent updates means that > most people don't get the benefit. And since delta RPMs trade > bandwidth for CPU, it probably makes things worse for folks in > developing countries. So I agree, it's probably not worth keeping > deltas as the default. > >> But, I think it's time to move on. We have ostree and various >> container-delta approaches. We should focus on those — and give DeltaRPMs a >> sad, fond farewell. > > Could we do this as a two-step approach? First change the default to > not use deltas but still allow people to opt-in to it. Then (assuming > we can track this, which maybe we can't) see how much they're used > before we decide to pull the plug on producing them. That would be absolutely awesome. -- 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: Proposal: drop delta rpms (for real this time)
On 2/21/23 17:13, Matthew Miller wrote: > On Tue, Feb 21, 2023 at 04:44:31PM -0500, Stephen Smoogen wrote: >> So do we kill it for: >> >> F39/F40 and beyond? >> F38 and beyond? >> X-date and all releases? > > My normal response would be... well, I missed the F38 change deadline by a > wide margin, so F39+. > > But, I think we could stop producing deltarpms for current releases without > really affecting those releases (there would just not be more created, which > as previously explored, would not really have a strong effect). So... I > wouldn't leave the other options out of the question. Can we also disable deltarpms in the F38 repo files? It’s a 1-line change, trivially revertable, and it measurably reduces the attack surface of DNF. If no deltarpms are being generated, there is no point in DNF looking for them. -- 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: Proposal: drop delta rpms (for real this time)
On 2/21/23 16:44, Stephen Smoogen wrote: > On Tue, 21 Feb 2023 at 15:48, Matthew Miller > wrote: > >> I was asked to weigh in on https://pagure.io/releng/issue/7215 as a >> priority. Last time we talked about this we didn't really get anywhere... >> >> >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/JYKVELSBJQMEK6KEFXG354ZDZDDX4C5G/#RLEUYSWOUVUS53YAP7WQQNN7HNEBIC4E >> >> ... and that ticket hasn't moved, because fixing it isn't trivial. >> >> > So do we kill it for: > > F39/F40 and beyond? > F38 and beyond? > X-date and all releases? F38+? Also maybe disable deltarpms in dnf.conf, to reduce attack surface. -- 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: Fedora Linux 38 blocker status summary
On 2/13/23 16:10, Neal Gompa wrote: > On Mon, Feb 13, 2023 at 4:00 PM Kevin Kofler via devel > wrote: >> >> Neal Gompa wrote: >>> FYI, if the GTK-based Anaconda UI goes away, the KDE variants probably >>> ship a thin QtWebEngine wrapper or use Firefox instead for the >>> web-based UI. No reason to depend on WebKitGTK for this. >> >> Well, the way the Anaconda web UI is currently packaged, it hardcodes a >> requirement on a specific browser or engine. >> >> As for Firefox, it should be gone from the Spin to begin with. It is >> consistently one of the largest packages on the entire Spin and it is >> entirely redundant. QtWebEngine cannot go away (since even Plasma itself >> depends on it, but also, e.g., KMail/Kontact), so what needs to go to remove >> the duplication is clearly Firefox. >> > > We're not getting rid of Firefox. It's the premier open source > browser, well-supported and well-liked by the community, and most > things on the Internet will at least accept Firefox as a browser. It > also works on all Fedora architectures, unlike anything Chromium-based. And is kept up to date, unlike QtWebEngine. QtWebEngine is invariably behind on security patches. I blame Google for not making embedded Chromium a first-class citizen. -- 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: [reviewing akmod] request for reviewing intel-ipu6 akmod package
On 2/12/23 22:06, Kate Hsuan wrote: > Hi, > > On Sat, Feb 11, 2023 at 4:54 AM Demi Marie Obenour > wrote: >> >> On 2/10/23 04:24, Kate Hsuan wrote: >>> Hi, >>> >>> Recently, we are working on getting IPU6 MIPI camera to work for the >>> laptops. We also made a akmod package for Intel opensource drivers and >>> the package will live in RPM fusion. The details can be found here. >>> https://bugzilla.rpmfusion.org/show_bug.cgi?id=6469 >>> >>> Could a reviewer who is familiar with akmod package take a look into it? >>> >>> Thank you >> >> This is great! That said, are you working on getting this driver >> upstreamed, with corresponding working, open userspace? > > Hans already got the important part (INT3472 LED) of IPU6 controls > upstream. However, Intel IPU6 and IVSC drivers had already opensource. How is the LED driver the important part? Are the IPU6 and IVSC drivers being upstreamed? Also, the software-controlled LED was a bad design for obvious security reasons. The hardware should have been designed such that there is no way to power on the image sensor without turning on the LED. This would have been very easy to implement. > The entire solution is based on the Intel proprietary application > libraries to make the MIPI camera work. Simply speaking, For now, we > need Hans' upstream work, Intel driver, and Intel binary library files > to make it work. Now, we are working on packaging the v4l2loopback > solution for the users. :) Are there plans to replace the proprietary userspace with open source code? I don’t care if the open source userspace is less optimized than the proprietary binary. I do care that distributions can ship with IPU6 support out of the box, and that requires open source userspace and drivers that are either upstream or themselves running in userspace via VFIO. -- 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: [reviewing akmod] request for reviewing intel-ipu6 akmod package
On 2/10/23 04:24, Kate Hsuan wrote: > Hi, > > Recently, we are working on getting IPU6 MIPI camera to work for the > laptops. We also made a akmod package for Intel opensource drivers and > the package will live in RPM fusion. The details can be found here. > https://bugzilla.rpmfusion.org/show_bug.cgi?id=6469 > > Could a reviewer who is familiar with akmod package take a look into it? > > Thank you This is great! That said, are you working on getting this driver upstreamed, with corresponding working, open userspace? -- 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: Hoping to disable i686 and 32-bit arm for Podman and related tools for existing Fedora releases
On 2/7/23 07:52, Peter Robinson wrote: > On Tue, Feb 7, 2023 at 12:36 PM Lokesh Mandvekar > wrote: >> >> On Tue, Feb 7, 2023 at 5:56 PM Peter Robinson wrote: >> >>> There are still active users of Fedora IoT 36 on armhfp using >>> containers so I suspect they may be unhappy of they go away before the >>> F-36 EOL in the late May/early June timeframe. >> >> I see. I guess we could leave armhfp be until then. Btw, just curious >> what happens to IoT on armhfp once f36 goes EOL. >> Would users have to pick something else? > > Basically yes. Not sure if Debian supports armhfp, but in the long term the answer is going to be to find a distro that cross-compiles everything. -- 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: Retiring Bottles in favor of Flatpak provided by upstream
On 2/8/23 08:41, Kevin Kofler via devel wrote:
> (*) I know this term ("lowest common denominator") is mathematically
> nonsense. There is only a least/lowest common multiple and a greatest common
> denominator in mathematics. :-)
I mean there *is* a lowest common denominator: 1 :)
--
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: -fno-omit-frame-pointer does not work as advertised
On 1/30/23 02:17, Florian Weimer wrote: > * Demi Marie Obenour: > >> What about the new SFrame unwind info? > > It has the same limitation as DWARF: there's no mainline kernel > implementation for profiling or bpftrace. > > Thanks, > Florian Have you considered writing such an implementation, or finding someone who can? -- 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
When is it better to just use containers?
On 1/28/23 18:43, Demi Marie Obenour wrote: > On 1/28/23 18:06, Nico Kadel-Garcia wrote: >> On Thu, Jan 26, 2023 at 8:31 PM Reon Beon via devel >> wrote: >>> >>> Are there still some outstanding bugs preventing this from happening? >> >> Is there any one critical feature that justifies the update? Avoiding >> the requirement of python is... OK, maybe understandable, but I don't >> see it as a "must-have" improvement. And better modularity support >> My observation so far is that modularity simply destabilizes systems, >> because the authors of the "modularized" tools do not build up the >> full suites of likely necessary components. I'm running into that >> right now with python310 back in RHEL 8 for ansible, the results are >> not pretty. > > At this point it might be better to just containerize Ansible. > Containers may waste resources and require extra effort to keep > up-to-date, but they *work*, and that is important. They also > *massively* reduce the test burden. To elaborate: if I am an upstream developer for something like Ansible, my options are either: 1. Ship a whole bunch of packages for a whole bunch of distributions and make sure everything works across all of the various dependency versions. This also means that I have to restrict myself to the packages that e.g. RHEL 8 has, which might be quite old. 2. Ship a single container that only needs to be QA’d once, works everywhere, and has no dependencies except for the Linux kernel. I get to update dependencies when *I* want to, and don’t have to worry about breaking user’s systems. I can even ship a shell script wrapper so that the container can be invoked as a binary. 3. Something that I am not aware of (suggestions welcome). It’s pretty easy to see why someone would go with option 2. -- 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: When is dnf5 going to replace dnf4?
On 1/28/23 18:06, Nico Kadel-Garcia wrote: > On Thu, Jan 26, 2023 at 8:31 PM Reon Beon via devel > wrote: >> >> Are there still some outstanding bugs preventing this from happening? > > Is there any one critical feature that justifies the update? Avoiding > the requirement of python is... OK, maybe understandable, but I don't > see it as a "must-have" improvement. And better modularity support > My observation so far is that modularity simply destabilizes systems, > because the authors of the "modularized" tools do not build up the > full suites of likely necessary components. I'm running into that > right now with python310 back in RHEL 8 for ansible, the results are > not pretty. At this point it might be better to just containerize Ansible. Containers may waste resources and require extra effort to keep up-to-date, but they *work*, and that is important. They also *massively* reduce the test burden. -- 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: When to close CVE's
On 1/20/23 10:48, Richard Shaw wrote: > On Fri, Jan 20, 2023 at 9:22 AM Gary Buhrmaster > wrote: > >> On Fri, Jan 20, 2023 at 1:54 PM Richard Shaw wrote: >>> >>> So is it when a build is complete in Rawhide? Or must *ALL* active >> releases get the "fix"? >>> >> >> I am not sure it is official policy/practice, but in >> theory I would think that the CVE is technically >> closed when all impacted Fedora releases get >> the fix, but if you use various "Resolves rhbz#1234567" >> syntax in the change log (and I generally try to >> do so in addition to referencing the CVE by it's >> identifier) I seem to recall that as soon as the >> package hits rawhide the issue gets closed. It >> is therefore up to the packager to make sure they >> have actually done the necessary builds/backports >> to previous releases as appropriate (not all CVEs >> may apply to previous Fedora releases as they >> may have different package versions, of course). >> I have mostly decided that in practice, as long as >> I have done any appropriate builds/backports, and >> one is just waiting for the usual distribution delays, >> that it is good enough (although high severity >> CVEs may need special handling). >> >> Or are you asking something different? >> > > I think in practical terms that makes sense but our tools don't really > help. > > Let's take the case of OpenImageIO[1][2], which is why I'm asking this > question, I only update Rawhide when SONAME is bumped, so if a CVE is only > fixed in the latest release, then only Rawhide, or Rawhide-1 (depending on > when we branch) gets the fix. My general rule is that a security fix is worth backporting a SONAME change for, if there is no way to backport the patch. -- 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: Yet another unwinding approach
lua interpreter). And then you can start generating a backtrace using > the dedicated unwinder for that memory region. That original unwinder > can start with the full ucontext_t. But what is the contract between > unwinders? If we start with e.g. a frame-pointer unwinder then when we > get to a part that needs to use the python unwinder we only have a pc, > sp and fp left. Is that enough context for the python unwinder to > continue? > > What would we need to prototype this idea and show that we can produce > quick backtraces using fast eh_frame unwinding before we convinced the > kernel to provide this interface and have it in glibc (or the vdso, > without any fancy caching, it might fit the vdso)? > > We could use LD_PRELOAD or some ptrace parasite code like criu uses to > insert the unwinder code and trigger registration, use an itimer and > SIGPROF as signal and shared memory to use as ringbuffer to provide > the backtrace addresses (and possible other context - build-id > mappings?) for a profiling app/library to read events from. Without > explicit kernel support that might not feel like system wide > profiling, but should give us a feel of how well it would work. Or are > there other holes/missing functionality? > > Cheers, > > Mark > >> [1] >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/646XXHGEGOKO465LQKWCPPPAZBSW5NWO/ >> > > _______ > 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 -- 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: Yet another unwinding approach
On 1/16/23 16:32, Daniel Colascione wrote: >> Could the vDSO do the unwinding? > > The vDSO is just userspace code that happens to be provided by the kernel, > so, sure, a function in vDSO *could* unwind. But why would it? What would be > the advantage of doing that over putting the unwinding in libc? To change the > vDSO, you have to change the kernel, so the vDSO is more suited for things > coupled to the kernel, like a fast clock_gettime implementation. Having the vDSO do the unwinding allows the unwinding to be entirely transparent to userspace programs and libraries, and therefore provides complete compatibility with the in-kernel unwinder. It also allows supporting programs in languages such as Go that do not use any libc.-- 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: Yet another unwinding approach
On 1/16/23 15:54, Daniel Colascione wrote: >> On Mon, Jan 16, 2023 at 3:30 PM Daniel Colascione > wrote: >> >> This sounds great, but how is it going to get made? > Someone has to do it. I've been thinking about adding this mechanism for a > few years, but haven't had time so far. I suppose the first step would be > raising the subject on libc-alpha and LKML. Both places (especially the > former) tend to be conservative, so it'd be prudent to settle in for a long > debate. > >> And is the kernel amenable to this in the first place? > I don't think anyone's asked. I don't see a reason (at least a reason based > on the technical merits) for the kernel to be opposed, but the Linux world > isn't known for the tight coordination between the kernel, libc, and managed > runtimes that this mechanism would require. > > I'm more worried about libc, to be honest. The last time [1] I proposed > improvements involving signal handling, libc-alpha's response was essentially > "No, absolutely not, we're not going to touch a thing related to signals > because nobody should be using signals for any purpose whatsoever". I don't > think this is a terribly realistic perspective on the part of libc-alpha, > especially given how often signals are, in fact, used productively in the > real world. I hope that they might be a little more moderate when it came to > unwinding. Could the vDSO do the unwinding? > [1] https://sourceware.org/legacy-ml/libc-alpha/2018-03/msg00214.html -- 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: -fno-omit-frame-pointer does not work as advertised
On 1/16/23 08:40, Florian Weimer wrote: > * Daniel Alley: > >> What has happened is that because -O2 optimized away all of the stack >> access for the function, so it uses no space on the stack, so there is >> no stack frame separate from the caller's. >> >> It is unlikely that the critical bottleneck of any applications will >> be on such a function. > > Is it? Plenty of math functions and cryptographic primitives are like > that. Anything that makes an inline system call, too. Maybe you can > infer from the caller's caller where the time is spent in these cases. > People certainly seem to be concerned about this gap because they > included -mno-omit-leaf-frame-pointer in the build flags. > > This is something that an upstream/ABI discussion could cover, with some > sort of protocol that ensures the toolchain produces something the > intended tools can consume. For example, there could be a rule that > only frames up to a certain size may lack a frame pointer, so that a > fixed-size copy from the top of the stack can recover the caller address > by looking at the DWARF unwinding data (out of context, for that frame > alone). Or it could be spelt out that LBR has to be used to recover the > calling frame. This isn't really something that Fedora can implement in > a downstream change, though. What about the new SFrame unwind info? -- 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: -fno-omit-frame-pointer does not work as advertised
On 1/15/23 12:58, Kevin Kofler via devel wrote: > Daniel Alley wrote: >> The quotation says the opposite of what you are saying. "leaves the frame >> pointer pointing to the caller's frame" => the caller set the frame >> pointer, the leaf did not, therefore the leaf function will not show up >> but the caller still will. > > No, that is not what it says. You are missing an important point there. To > understand that point, you need to look more closely at how unwinding works, > so let me (as a cross-toolchain developer) explain it to you: > > The first thing the sampling profiler will see is the current instruction > pointer / program counter. That is the very instruction the CPU is currently > executing (or, depending on the CPU, it may actually be the next instruction > that will be executed). So it always points to the function currently being > executed. I.e., that function will ALWAYS show up in the backtrace, even if > unwinding is completely broken. > > But then you want to locate the caller. To locate the caller, you need to > find the return address of the current function (i.e., where the `ret` > instruction terminating the function will return to) on the stack. For that, > the frame-pointer-based unwinder will use the frame pointer. But the frame > pointer still points to the caller's stack. So what it will see is the > CALLER's return address, i.e., the caller's caller! The caller itself, on > the other hand, will be missing. > >> You seem to be arguing that because the solution is not 100% perfect (and >> it was already acknowledged that it is not), it is useless. > > It is at least not as useful as the change proponents claim and clearly not > worth the performance loss that will be imposed on all users. > >> Is shipping debug symbols for an optimized binary completely useless just >> because there are situations where optimizations like inlining and TCO >> make the executed code radically different from the source code, and >> therefore make it impossible to trace the execution line by line? > > Debugging information has improved over the years so that optimized > executables can actually be debugged in a better and better way over time. > E.g., GDB can actually synthesize the value of some variables that have been > optimized out, but can be computed from values actually present in registers > or stack variables. Of course, if the variable was optimized out completely, > it is impossible to view its value, but within this kind of limitations, > debugging optimized executables actually works pretty well these days. > > Part of that work was on unwinding, which is why frame pointers are actually > unnecessary to perform unwinding if the unwinder works properly, making them > an obsolete pessimization. The only reason we are having this discussion is > because there are some broken tools that still do not understand unwinding > information in 2023, putting them one or two decades behind the state of the > art (and the Linux kernel developers' stubborn refusal to allow a DWARF > unwinder into the kernel is one of the reasons for that and should be > addressed by a downstream kernel patch, not by pessimizing the entire > distribution). Would you be willing to write such a patch and send a PR to include it in Fedora’s kernel packages? -- 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: Schedule for Tuesday's FESCo Meeting (2023-01-03)
On 1/10/23 18:13, Kevin Kofler via devel wrote: > Michael Catanzaro wrote: >> You've previously indicated that developers should just 'dnf >> distro-sync' to an alternative Fedora that has frame pointers, as if >> building two alternate versions of Fedora, one for developers and one >> for users, is a reasonable thing to do. The cost of this is just too >> high. We'd need double build infrastructure. > > +100% CPU power for the Koji build farm is still a lot less overall cost > than +2.5% CPU power for *all* Fedora users in the entire world. > > Kevin Kofler Absolutely correct. -- 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: Schedule for Tuesday's FESCo Meeting (2023-01-03)
On 1/6/23 20:35, Frank Ch. Eigler wrote: > > Hi - > >> The thing is that perf + flamegraphs makes your whole system much more >> visible and so it's much easier to find these kind of gains in >> specific scenarios. > > (There are exist other profiling tools and techniques that do not > require frame pointer recompilation, but whatever.) Which ones? I would love for them to exist, and I believe there is work being done in that direction, but I am not aware of any yet. -- 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: Schedule for Tuesday's FESCo Meeting (2023-01-03)
On 1/5/23 11:08, Frank Ch. Eigler wrote: > >> Of course, but the benefit is to fix performance bugs in applications >> or maybe the desktop itself. [...] > >>> Let's be firm in testing this empirically rather than aspirationally. >> I really don't know how. Suggestions welcome. > > I'd put the onus on the proponents of the Change, who made predictions > like "I'm confident that over the course of the next year, we'll recover > performance that was lost by FORTIFY_SOURCE=3 and frame pointers" and > "The optimizations enabled by profiling can be much larger than 3-10%." As the one who made this statement: Profiling can result in very large gains. I cannot predict what the actual gains will be. > There needs to be substance behind such predictions if they are going > to be used as justification for slowing things down in the mean time. I agree. -- 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: Schedule for Tuesday's FESCo Meeting (2023-01-03)
On 1/4/23 10:05, Vitaly Zaitsev via devel wrote: > On 04/01/2023 15:25, Michael Catanzaro wrote: >> All Fedora users will benefit from the performance improvements that >> we're able to make using sysprof. > > Maybe. Or maybe not. And the performance penalty is here and now. The optimizations enabled by profiling can be much larger than 3-10%. To be clear, I would prefer a means of profiling that does not cause a performance penalty for everyone else, but that will take much longer to create. -- 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: F38 proposal: GNU Toolchain Update (gcc 13.0, binutils 2.39, glibc 2.37, gdb 12.1) (System-Wide Change proposal)
On 1/2/23 22:30, Kevin Kofler via devel wrote: > Fabio Valentini wrote: >> - incompatible compile-time options (i.e. resulting in conditional >> compilation): different packages depend on crates with different sets >> of features enabled, sometimes with conflicting options. Even with a >> stable ABI, you'd need to build crates for all necessary combinations >> of configurations, and that matrix quickly explodes (i.e. usually >> exponentially - 2^n builds for for n independent flags). This is a >> deal-breaker for shared libraries in most cases, and also can't be >> solved by using a different compiler. (Unless you want to figure out >> *which* combinations to build, and *only* build these.) > > Let me try formulating my criticism more constructively (since my previous > reply failed both at being polite and at getting my point through, sorry > again for that): > > I am really surprised to read above that Rust apparently allows applications > to pick the flag with which the libraries they depend on are compiled. I > really have to wonder why anyone would think that allowing that would be a > good idea, but then again I guess I know the answer: Whoever added this > feature was so set in a mindset where everything is compiled on demand and > statically linked that they figured: why not? One of the major uses is to allow code that requires a particular dependency to be disabled when that dependency is not available. In particular, Rust targets platforms (such as OS kernels and embedded systems) where the standard library is not available. This would be extremely difficult without Cargo features. > And if you are in that mindset, that actually sounds like a reasonable call > to make. Source-based software distributions do have the advantage of > offering this kind of flexibility on demand, see also the USE flags in > Gentoo. Those are in fact one of the main reasons some people decide to > compile an entire GNU/Linux distribution from source (and hence pick a > distribution such as Gentoo) to begin with. Likewise, the Rust way of > compiling dependencies on demand allows applications to make this kind of > settings for them. > > Still, I can see several issues with that approach, e.g., what if an > application depends on two libraries A and B that both depend on library C, > but with conflicting flags? Last I checked, Cargo features are additive, so the answer is that C will be compiled with the union of all flags used by A and B. > But the main issue is that, as you point out, it > makes binary distribution of shared libraries highly impractical. That is > why I think this was a short-sighted design decision. Cargo features are supposed to be additive, so one can sometimes ship a single package with the union of all features used by its reverse dependencies. This must be handled on a case-by-case basis, though. -- 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: F38 proposal: GNU Toolchain Update (gcc 13.0, binutils 2.39, glibc 2.37, gdb 12.1) (System-Wide Change proposal)
GNU Compiler Collection has its own testsuite which is run during >> the package build and examined by the gcc developers before being >> uploaded. >> >> The GNU C Library has its own testsuite which is run during the >> package build and examined by the glibc developers before being >> uploaded. This test suite has over 6200 tests that run to verify the >> correct operation of the library. In the future we may also run the >> microbenchmark to look for performance regressions. >> >> The GNU Binutils has its own testsuite which is run during the package >> build and examined by binutils developers before being uploaded. The >> regression testsuite is run to verify the correct operation of the >> static linker and attendant utilities. >> >> The GNU Debugger has its own testsuite which is run during the package >> build and examined by gdb developers before being uploaded. The >> regression testsuite is run to verify the correct operation of the >> debugger. >> >> == User Experience == >> Fedora developers as well as developers using the distribution will be >> able to use and develop using the new features offered by the updated >> components. Developers will need to enable specific compiler features >> as required e.g. '-mcpu=neoverse-v2'. >> >> == Dependencies == >> All packages do not need to be rebuilt due to backwards compatibility. >> However, it is advantageous if a mass rebuild is performed during the >> Fedora 38 cycle. The mass rebuild would ensure all packages can be >> built with the newer compiler and core runtime. >> >> == Contingency Plan == >> >> * Contingency mechanism glibc: If glibc 2.37 proves too disruptive to >> compiling the distribution we could revert to 2.36, but given that >> Rawhide has started tracking glibc 2.37, no show-stopper problems are >> expected. At this point we can still revert to upstream version 2.36 >> if insurmountable problems appear, but to do so may require a mass >> rebuild to remove new symbols from the ABI/API. >> >> * Contingency mechanism binutils: If binutils 2.39 proves too >> distruptive to assembling and linking the distribution we could revert >> to 2.38, but given that Rawhide is using 2.39, no show-stopper >> problems are expected. At this point we can still revert if >> insurmountable problems appear, but to do so may require a mass >> rebuild if the defects involve generated binaries. >> >> * Contingency mechanism for gcc: If gcc 13 proves too disruptive to >> compiling the distribution we could revert to gcc 12. >> >> * Contingency mechanism for gdb: The gdb 12.1 release is already in >> all the Fedora releases and it would not be reverted. If any gcc, >> glibc or binutils changes cause gdb to fail then that would need to be >> reviewed on a case-by-case basis. >> >> >> * Contingency deadline: Fedora mass rebuild on 2023-01-18. >> * Blocks release? >> ** Yes, upgrading to gcc 13.0 does block the release. >> ** Yes, upgrading to binutils 2.39 does block the release. >> ** Yes, upgrading to glibc 2.37 does block the release. >> ** No, upgrading to gdb 12.1 does block the release (already released). >> >> >> == Documentation == >> The gcc manual contains the documentation for the release and doesn't >> need any more additional work. >> >> The binutils manual contains the documentation for the release and >> doesn't need any more additional work. >> >> The glibc manual contains the documentation for the release and >> doesn't need any more additional work. >> >> The gdb manual contains the documentation for the release and doesn't >> need any more additional work. >> >> >> == Release Notes == >> >> >> See https://gcc.gnu.org/gcc-13/changes.html for the GNU Compiler >> Collection version 13 release notes. >> >> >> The GNU C Library version 2.37 will be released at the beginning of >> February 2023. The current NEWS notes can be seen here as they are >> added: https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;hb=HEAD >> >> The GNU Binary Utilities version 2.39 was released August 2022. The >> current release notes will be sent to the developer mailing list: >> https://sourceware.org/pipermail/binutils/2022-August/122246.html. >> > > Can we please have gcc-rs also built (even though it's experimental)? gcc-rs is not capable of even compiling hello world, so it would be rather pointless to package it. Even once gcc-rs is finished, I suspect rustc-codegen-gcc will be a better long-term solution for architectures LLVM does not support, as it reuses the existing rustc frontend. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital 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: F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)
On 12/29/22 08:06, Neal Gompa wrote: > On Thu, Dec 29, 2022 at 1:10 AM Peter Hutterer > wrote: >> >> On Wed, Dec 28, 2022 at 10:16:45PM -0500, Neal Gompa wrote: >>> On Wed, Dec 28, 2022 at 10:13 PM Peter Hutterer >>> wrote: >>>> >>>> On Thu, Dec 22, 2022 at 05:41:06AM -0500, Neal Gompa wrote: >>>>> On Thu, Dec 22, 2022 at 5:30 AM Niklas Schnelle >>>>> wrote: >>>>>> >>>>>> Hi All, >>>>>> >>>>>> This might not be as niche as you might think. I'm one of the >>>>>> Linux kernel maintainers for s390. Many of us do the vast majority of >>>>>> their development work natively on s390 systems via SSH from Fedora >>>>>> laptops. After all mainframes are pretty damn fast at compiling with >>>>>> plenty of memory and dog fooding is part of quality control. And I'm >>>>>> sure it's not just the teams working on the Linux kernel but also >>>>>> plenty of other people working with s390 Linux machines. These s390 >>>>>> machines mostly only host X servers via VNC and usually just for the >>>>>> installation but they do that too. There is also a hand full of X >>>>>> clients I run on s390 which are essential for my and many of my >>>>>> colleagues daily workflows. The most important one is defintely >>>>>> xsel/xclip to copy from the (neo-)vim/tmux I use for coding to my local >>>>>> system. Some people also use x3270 via SSH X forwarding from jumphosts, >>>>>> others use XEmacs. I also know essential internal tools that are run on >>>>>> s390 hosts via X forwarding. Sure people using X forwarding are capable >>>>>> of changing configuration defaults but if at all possible I would >>>>>> suggest to rethink this, as it will create significant hassle for >>>>>> anyone using their Fedora systems to SSH + X forward to s390 Linux >>>>>> hosts and it definitely sees more use and thus testing than the >>>>>> proposal makes it sound. >>>>>> >>>>> >>>>> How bad would it be to force little-endian for the X protocol >>>>> regardless of architecture? >>>> >>>> simply said - not realistic. It's a lot of effort, with zero visible >>>> benefit beyond the *potential* that we're slightly safer now. Which you >>>> won't know until you tested it all. >>>> >>>> The code works, at least for the bits that are executed. Swapped clients >>>> run on different hosts by definition so there are probably whole >>>> extensions that are never used at all and likely completely untested. >>>> And it's not a matter of "working" but "safe against a malicious client >>>> sending bad messages". That's a completely different ballpark. >>>> e.g. the code for CVE-2022-46340 has been there since ~2008 but no-one >>>> ever noticed the issue - because it works as long as the client is nice. >>>> >>>> Forcing the server to little endian only means you'd need to do the >>>> swapping client-side. There is nothing in place right now to do this and >>>> while it's probably possible to automate this somewhat with xcb, you're >>>> still looking at a huge project. And once it all works, you need to >>>> ensure it works against malicious input data. You could *possibly* MITM >>>> the whole protocol-swapping into a separate process but, well, goto 10 >>>> :) >>>> >>> >>> Please tell me the Wayland protocol doesn't do this? >> >> the wayland protocol doesn't to this :) >> >> Wayland integers must be encoded in the host's (read: compositor) byte >> order. Somewhat of an exception are the wl_shm image formats which >> are (apparently) always in little-endian [1]. > > So in effect we do this, because things like waypipe won't function > properly when transmitting across systems of differing endianness? Waypipe would need to translate the endianness of messages as needed. -- 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: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
On 12/22/22 14:55, Chris Murphy wrote: > > > On Thu, Dec 22, 2022, at 1:29 PM, Adam Williamson wrote: >> On Thu, 2022-12-22 at 18:44 +0100, Tomasz Torcz wrote: >>> On Thu, Dec 22, 2022 at 12:35:54PM -0500, Ben Cotton wrote: >>>> https://fedoraproject.org/wiki/Changes/Shorter_Shutdown_Timer >>>> >>>> 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 == >>>> A downstream configuration change to reduce the systemd unit timeout >>>> from 2 minutes to 15 seconds. >>> >>> Great change, please do it! >>> Also, sometimes after reaching the timeout, systemd extends wait by >>> another 2 minutes (or 1m30). I wasn't able to find in the sources or >>> documentation why this happens, but this behaviour should be blocked. >>> Otherwise some services after 15s will get another 15, and then another… >> >> 15 seconds feels very aggressive to me. I can think of some cases, like >> libvirtd automatically suspending or cleanly shutting down running VMs, >> that might well take longer than that. Could we not go for 30 seconds? >> Going all the way from 90/120 down to 15 seems pretty radical. > > Yeah. I'm not opposed to the change, and I understand the main impetus behind > it (PackageKitd), but it's the consequences of unknowns that I'm still left > scratching my head trying to imagine worse case before we actually subject > users to it. > > There really isn't a good kernel facility for something in between SIGTERM > which is ignorable, and SIGKILL which isn't. And I'm not familiar with > systemd's facilities for tracking service shutdown progress. i.e. I'm OK with > SIGKILL for a process that isn't responding. But I'm also not sure if there's > a facility for a process indicating either "I'm working on it" or "don't > force kill me or it'll be bad". > > I also don't know if privileged services doing writes to the file system can > inhibit either remount read-only or umount? And if so, do we just wait for > all of that to complete? I think we'd have to. I'm pretty leery of rebooting > forcibly even if we can't remount ro because some process is holding things > up, doing the best it can to flush. Databases and VM's do come to mind, in > particular because I routinely run VMs on my laptop with cache mode unsafe. > If the VM is forcibly quit, it's fine. But if the host is forcibly rebooted > before the VM's pending writes are completed by the host, that'd be bad > (regardless of the file system choice). Why cache mode unsafe? How big a performance win is it? -- 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: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On 12/22/22 12:00, Luca Boccassi wrote: >> On Thu, Dec 22, 2022 at 10:51 AM Lennart Poettering >> > >> Basically, I'm saying that the model of trust is flawed because users >> are unable to work with it. >> >> And besides, each level up is a smaller scope from the previous. A >> cert trusted by shim can execute anything the firmware trusts, a cert >> trusted by grub can only execute things it trusts, and finally a cert >> trusted by the OS can only execute things in its context. Once we >> reach the OS-level, we don't need pre-boot trust anymore. So enrolling >> certificates to trust kernel modules/sysexts/etc. should not require >> going down the trust levels. The OS should be able to establish its >> own trust to those pieces or reject them independently. It should >> certainly trust everything the lower levels trust, but there's no >> reason to not allow the higher levels to establish their own scoped >> trust. >> >> This is the flaw we have right now: we can't do that. > > Of course there's a reason to only allow a fully validated trust chain - not > only that, but it's the very basic of the entire model, and without it the > entire premise falls flat on its face. > The way to enroll your own certs is via firmware-mediated mechanisms such as > shim+mok, and via built-in trusted keyring. Adding arbitrary trust anchors at > the OS level completely ignores the foundational principle of the whole thing. As Neal mentioned earlier, these mechanisms are often broken. Not only does some firmware wind up bricking the machine when they are used, they also may not support removing the key used to sign Windows. If the attacker can boot Windows and measured boot is not in use, they have won. A much better approach is to install a TPM-generated key in the TPM’s NVRAM, with a policy that only allows the key to be used once a trusted operating system has booted. That can be used as a trust anchor even without support from buggy UEFI firmware. Furthermore, measured boot allows tying e.g. LUKS keys to a combination of the actual OS booted and a passphrase needed to unlock the TPM. This allows the TPM’s protection against brute-force attacks to be used. -- 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: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On 12/22/22 12:33, Neal Gompa wrote: > On Thu, Dec 22, 2022 at 12:00 PM Luca Boccassi wrote: >> >>> On Thu, Dec 22, 2022 at 10:51 AM Lennart Poettering >>> >> >>> Basically, I'm saying that the model of trust is flawed because users >>> are unable to work with it. >>> >>> And besides, each level up is a smaller scope from the previous. A >>> cert trusted by shim can execute anything the firmware trusts, a cert >>> trusted by grub can only execute things it trusts, and finally a cert >>> trusted by the OS can only execute things in its context. Once we >>> reach the OS-level, we don't need pre-boot trust anymore. So enrolling >>> certificates to trust kernel modules/sysexts/etc. should not require >>> going down the trust levels. The OS should be able to establish its >>> own trust to those pieces or reject them independently. It should >>> certainly trust everything the lower levels trust, but there's no >>> reason to not allow the higher levels to establish their own scoped >>> trust. >>> >>> This is the flaw we have right now: we can't do that. >> >> Of course there's a reason to only allow a fully validated trust chain - >> not only that, but it's the very basic of the entire model, and without >> it the entire premise falls flat on its face. The way to enroll your own >> certs is via firmware-mediated mechanisms such as shim+mok, and via >> built-in trusted keyring. Adding arbitrary trust anchors at the OS level >> completely ignores the foundational principle of the whole thing. > > Your concept only works in *some* enterprise hardware where it's even > possible to have full control without breaking something. Even in my > server gear, I can't do that without breaking the network firmware. What??? That is strange. > If I can't safely distrust Microsoft reliably, then it's already broken. Absolutely. Otherwise, an attacker can just boot into Windows and use any of the numerous bring-your-own-vulnerable-driver exploits to get code execution in the kernel. To stop this, one needs to remove the Microsoft signing key from the root store. > Firmware trust has been broken since the very beginning, and it was > broken by design in the PC world. > > Consumer PC equipment is even worse off because of how Microsoft's > Windows requirements influence how UEFI implementations work. IMO a much more realistic approach for bare hardware is measured boot, using Dynamic Root of Trust for Measurement (DRTM) where available. The latter is the basis of Qubes OS’s Anti Evil Maid. -- 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: F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)
On 12/22/22 10:24, Elizabeth K. Joseph wrote: >> This might not be as niche as you might think. I'm one of the >> Linux kernel maintainers for s390. Many of us do the vast majority of >> their development work natively on s390 systems via SSH from Fedora >> laptops. > > I first wanted to echo and confirm what Niklas says here. > > The crux of this issue seems to be "the code in the X server that > does this is virtually untested" so would more attention being paid > to this code help? It certainly would, but there is another factor: Input validation bugs that would only be out-of-bounds reads with swapping disabled can easily turn into out-of-bounds writes with swapping enabled. The former is an information leak, but the latter can be exploited for code execution. > I can't make any promises, but it would be > valuable to know if this, or something else, is needed. I will also > bring this to the attention of the Open Mainframe Project Linux > Distributions Working Group, since all of the distros use this > byte-swapped code. Fuzzing the X server’s byte-swapping and input validation routines would be a good place to start. -- 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: F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)
> Alternatively, a test client is available in >> [https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1029 the >> upstream PR]. This test client pretends to be BigEndian and will fail >> to connect when run against a little endian X server. >> >> >> == User Experience == >> For virtually all users, there is no change in behavior. >> >> Users with X server and client on two different machines must add the >> `xorg.conf.d` snippet shown above on affected systems. >> >> == Dependencies == >> No other RPMs depend on this change. >> >> >> == Contingency Plan == >> >> This change depends on whether upstream merges this new default >> behavior. If upstream does not merged the feature in time, this Change >> will be postponed until the next Fedora version to avoid potential >> incompatibilities between configurations or commandline options. >> >> * Contingency mechanism: keep current behavior, try again with next >> Fedora version >> * Contingency deadline: beta freeze >> * Blocks release? No >> >> >> == Documentation == >> >> == Release Notes == >> > > So I guess this means no remoting into ppc64 or s390x machines from > x86_64 or ppc64le machines without a configuration tweak? No X11 forwarding, correct. Other protocols like VNC will continue to work. I am honestly surprised that this is a use-case that arises frequently in practice; I would expect ppc64 and especially s390x machines to be managed via SSH or dedicated configuration management software such as Ansible or Salt. > Or do modern versions of X use consistent endianness regardless of > architecture? Sadly no. -- 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: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On 12/21/22 12:17, Lennart Poettering wrote: > On Mi, 21.12.22 12:12, Demi Marie Obenour (demioben...@gmail.com) wrote: > >>> At least for the systemd stuff, we carefully made sure that our access >>> patterns to the ESP both from sd-boot/sd-stub and from userspace are >>> by default as minimal and robust as we can make them, to minimize >>> chance of corruption, given that vfat is not particularly good with >>> that. (i.e. we sync a lot, and the whole ESP mount is by default an >>> autofs instance with an extremely short idle timeout so that it >>> basically remains unmounted — and thus — clean during almost all >>> times). >>> >>> Anyway, if you want to know more about choice of the fs for /boot/, >>> see my ideas here: >>> >>> https://0pointer.net/blog/linux-boot-partitions.html >>> >>> Lennart >> >> Does vfat support atomic rename? Is it possible to atomically upgrade >> a bootloader/UKI/etc? > > Depends on the fs driver. But yeah, the filename is stored at exactly > one place, and hence typically a single-sector update is > possible. (well, within bounds: for example if you rename a file from > a short filename to a long one, fs driver might need to allocate a > bunch of separate long file name dir entries, which might then span > multiple sectors) > > Lennart Under what circumstances do the Linux kernel driver and the firmware driver actually make such guarantees? For instance, is renaming a file with a longer name to a shorter name (and replacing the old one) atomic? -- 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: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On 12/21/22 12:00, Lennart Poettering wrote: > On Mi, 21.12.22 10:03, Gerd Hoffmann (kra...@redhat.com) wrote: > >> For the general case we need some other option. Could be just stick to >> grub2 for those cases (we'll continue to need grub2 anyway for bios boot >> and ppc64le). Or drop an ext4 driver to /boot/efi/EFI/systemd/drivers, >> for example this one: >> https://github.com/tianocore/edk2-platforms/tree/master/Features/Ext4Pkg > > I am pretty strongly against the idea of ext4 for /boot/. > > First of all, the firmware can't read it natively, but what's worse, > uefi cannot even make sense of any of the features it provides above > vfat. i.e. file ownership, access modes, ACLs, selinux labels, xattrs, > symlinks, … are all complete nonsense to the UEFI fs layer (and to > boot loaders that natively implement the fs drivers, the same). The > UEFI fs API has no concepts for *any* of these features. Hence, if > this is supposed to carry data intended for consumption by the boot > loader, why the f**k would you use a file system it cannot even > remotely take benefit of? > > Also, I am pretty sure boot loaders should have the ability to make > changes to the file systems they read UKIs from, to implement boot > counting and random seed management. grub fs drivers and the stuff > derived thereof (i.e. efifs stuff) typically is read-only though. > > At least for the systemd stuff, we carefully made sure that our access > patterns to the ESP both from sd-boot/sd-stub and from userspace are > by default as minimal and robust as we can make them, to minimize > chance of corruption, given that vfat is not particularly good with > that. (i.e. we sync a lot, and the whole ESP mount is by default an > autofs instance with an extremely short idle timeout so that it > basically remains unmounted — and thus — clean during almost all > times). > > Anyway, if you want to know more about choice of the fs for /boot/, > see my ideas here: > > https://0pointer.net/blog/linux-boot-partitions.html > > Lennart Does vfat support atomic rename? Is it possible to atomically upgrade a bootloader/UKI/etc? -- 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: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On 12/20/22 16:34, Simo Sorce wrote: > On Tue, 2022-12-20 at 14:56 -0500, Demi Marie Obenour wrote: >> How do you plan to handle system recovery? For VMs this is much >> less of a concern, but on bare metal there needs to be a way for >> a local, authenticated administrator to obtain a root shell on >> the system console even if the root filesystem cannot be mounted. >> This has saved my system more than once. >> >> Also, how will Xen be supported in this model? Will the hypervisor >> be part of an alternate UKI? CCing Marek Marczykowski-Gorécki of >> Qubes OS. > > It is all answered in the large amount of text you quoted, if you read > it carefully. > The old kernel+inird does not go away, so you disable secure boot and > just use the good old methods, or worst case you use a recovery disk > (or USB drive, or whatever you use to install) if you damaged the boot > partition. > > Anything that is not explicitly supported likewise will use the old > kernel + custom initrd, you just disable secure boot. If rescuing a system means disabling secure boot, then there is no point in having secure boot in the first place, because malware can reliably cause the user to disable it. There needs to be a way to rescue the system *without* disabling secure boot, at least as long as the UKI can itself be loaded. Furthermore, this must not require the user to enter secrets until they have (via TPM PCR-based attestation) verified that the system is booting trusted code. This means that the initramfs must be able to authenticate the user. And having Xen be incompatible with secure boot is not something Xen users are going to be happy with, especially because Xen fully supports UKIs that include the hypervisor. Having this be out of scope for phase 1 is fine, but it should be supported eventually. -- 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: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
the installed
> system is fragile, root cause for kernel bugs reported is simply a
> broken initrd sometimes).
>
> == Scope ==
> * Proposal owners:
> ** Update kernel build to create unified kernel sub-package.
> *** part one: [https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2179
> PR#2179]
> *** part two: (wip)
> [https://gitlab.com/kraxel/kernel-ark/-/commits/unified/
> https://gitlab.com/kraxel/kernel-ark/-/commits/unified/]
>
> * Other developers:
> ** grub2: add unified kernel support
> *** wip code at [https://github.com/osteffenrh/grub2/
> https://github.com/osteffenrh/grub2/]
> ** installer(s): add support for discoverable partitions.
> *** [https://bugzilla.redhat.com/show_bug.cgi?id=1075288 Bug#1075288]
>
> * Release engineering: [https://pagure.io/releng/issues #Releng issue number]
> * Policies and guidelines: N/A (not needed for this Change)
> * Trademark approval: N/A (not needed for this Change)
> * Alignment with Objectives:
>
>
> == Upgrade/compatibility impact ==
>
> None (using unified kernel is opt-in for Phase 1).
>
> == How To Test ==
> Try on a existing (uefi) system:
> * make sure you are running fedora 37 or rawhide.
> * make sure your root filesystem has type "Linux root (x86-64)" (use
> `fdisk -l` to check).
> ** should that not be the case use the fdisk tag command ('t') to
> change the partition type.
> * when using btrfs: make sure the 'root' subvolume is set as default volume.
> * `dnf copr enable kraxel/unified.kernel`
> * `dnf update "grub2*"`
> * `dnf install kernel-unified-virt`
> * `reboot`
> You should find two entries in the grub2 boot menu, one for classing
> kernel with separate initrd and one for the unified kernel image.
> Both should boot fine.
>
> The https://gitlab.com/kraxel/fedora-uki project has kickstart files
> and helper scripts for generating virtual machine images.
> * image using grub2-efi:
> https://gitlab.com/kraxel/fedora-uki/-/raw/master/kickstart/fedora-uki-grub2.ks
> * image using systemd-boot:
> https://gitlab.com/kraxel/fedora-uki/-/raw/master/kickstart/fedora-uki-sdboot.ks
>
> Prebuilt virtual machine images are available from
> https://www.kraxel.org/fedora-uki/.
>
> == User Experience ==
>
>
> == Dependencies ==
>
>
> == Contingency Plan ==
> * Contingency mechanism:
> ** Probably none (unified kernel images are opt-in for Phase 1).
> ** In case we tried switching the cloud images to unified kernels:
> revert the kickstart config changes.
> * Contingency deadline:
> * Blocks release? No
>
> == Documentation ==
>
>
> == Release Notes ==
How do you plan to handle system recovery? For VMs this is much
less of a concern, but on bare metal there needs to be a way for
a local, authenticated administrator to obtain a root shell on
the system console even if the root filesystem cannot be mounted.
This has saved my system more than once.
Also, how will Xen be supported in this model? Will the hypervisor
be part of an alternate UKI? CCing Marek Marczykowski-Gorécki of
Qubes OS.
--
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: Looking for advice - ffmpeg-free and wf-recorder
On 12/18/22 00:24, Neal Gompa wrote: > On Sun, Dec 18, 2022 at 12:21 AM Demi Marie Obenour > wrote: >> >> On 12/18/22 00:19, Neal Gompa wrote: >>> On Sun, Dec 18, 2022 at 12:18 AM Demi Marie Obenour >>> wrote: >>>> >>>> On 12/17/22 05:31, Vitaly Zaitsev via devel wrote: >>>>> On 17/12/2022 06:29, Bob Hepple wrote: >>>>>> Now that we have ffmpeg-free we have an opportunity to move wf-recorder >>>>>> to the mainstream and change the default codec to the non-proprietary >>>>>> libopenh264. >>>>> >>>>> You still can't link against openh264 because Fedora can't ship it an >>>>> even have in Koji's buildroot, you can only use dlopen(). >>>> >>>> Could Fedora ship a shim library that exposed the same API and used >>>> dlopen() internally? >>> >>> In that case, why wouldn't we just adjust the program to dlopen() the >>> library itself? We already did it for ffmpeg and webrtc, after all. >> >> Because that requires per-program patches, whereas this approach does >> not. > > And that approach means applications will crash instead of being > modified to gracefully handle the library missing. If the libopenh264 API allows returning errors, then the shim could just return an error from all API functions. Otherwise, that is what Requires: is for. (Build stuff can use a stub package that never gets shipped.) For the specific case of ffmpeg, another option would be to pretend that the non-libopenh264 codecs exist, but have them just wrap libopenh264 internally. -- 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: Looking for advice - ffmpeg-free and wf-recorder
On 12/18/22 00:19, Neal Gompa wrote: > On Sun, Dec 18, 2022 at 12:18 AM Demi Marie Obenour > wrote: >> >> On 12/17/22 05:31, Vitaly Zaitsev via devel wrote: >>> On 17/12/2022 06:29, Bob Hepple wrote: >>>> Now that we have ffmpeg-free we have an opportunity to move wf-recorder >>>> to the mainstream and change the default codec to the non-proprietary >>>> libopenh264. >>> >>> You still can't link against openh264 because Fedora can't ship it an >>> even have in Koji's buildroot, you can only use dlopen(). >> >> Could Fedora ship a shim library that exposed the same API and used >> dlopen() internally? > > In that case, why wouldn't we just adjust the program to dlopen() the > library itself? We already did it for ffmpeg and webrtc, after all. Because that requires per-program patches, whereas this approach does not. -- 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: Looking for advice - ffmpeg-free and wf-recorder
On 12/17/22 05:31, Vitaly Zaitsev via devel wrote: > On 17/12/2022 06:29, Bob Hepple wrote: >> Now that we have ffmpeg-free we have an opportunity to move wf-recorder >> to the mainstream and change the default codec to the non-proprietary >> libopenh264. > > You still can't link against openh264 because Fedora can't ship it an > even have in Koji's buildroot, you can only use dlopen(). Could Fedora ship a shim library that exposed the same API and used dlopen() internally? -- 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: Small rant: installer environment size
On 12/8/22 07:31, Kevin Kofler via devel wrote: > Tomáš Popela wrote: >> firefox, because that's what the web based installer should/will use in >> the end > > 臘 A full-blown, 71 MB compressed (!) web browser just to show the UI for the > installer! > > IMHO, the web-based UI is a major mistake and should never be shipped in > Fedora. It is good as a prototype, but way too resource-heavy to be shipped > in production. We need a rewrite of the UI design in a desktop toolkit. (If > GTK is not suitable, how about Qt? ☺) I wholeheartedly agree. Not only because of resource consumption, but also because of the total disaster that is the NPM ecosystem. Do they really plan on building each and every Node module from the ACTUAL source code? What ‘npm install’ puts in node_modules is often NOT actual source code, but rather minified or transpiled in some way. Using a desktop toolkit would be far FAR better. -- 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: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)
On 12/6/22 14:02, Richard W.M. Jones wrote: > On Tue, Dec 06, 2022 at 05:52:16PM -, Andrii Nakryiko wrote: >>> On Tue, Dec 06, 2022 at 03:12:19AM +, Gary Buhrmaster wrote: >>> >>> Note that is not a fully equivalent scenario. The no-omit-frame-pointer >>> proposal was only offering a functional debugging benefit to a fairly >>> small number of users who are also developers, while adding a likely >>> performance hit to all users. There needs to be a high bar to justify >>> the performance hit when the benefit offered is narrow. >> >> First, frame pointers are not just for debugging benefit. It's not even it's >> main benefit from POV of https://pagure.io/fesco/issue/2817. Frame pointers >> are for performance profiling and observability first and foremost, and >> that's most useful under real-world conditions of production workloads. Not >> some custom re-built debug versions of applications. >> >> Second, it might benefit a relatively small (but not tiny, it's at least >> thousands of people doing performance profiling) fraction of users, but >> those users (developers that care about performance) are the ones bringing >> benefits to very wide user base. > > Yes! I spent a frustrating time getting perf to record stack traces > properly until I recompiled the program with frame pointers. (I know > about --call-graph=dwarf but it doesn't seem to work most of the time.) That is due to known limitations in perf, IIUC. Hence why at least I was pushing so heavily to improve perf to not require frame pointers. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital 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: Some reasons I really dislike buildroot overrides and would like us to get rid of them soon
On 12/4/22 16:29, Kevin Kofler via devel wrote: > Neal Gompa wrote: >> I would prefer that *every* build would automatically generate a side >> tag, even if it's a side-tag of one package. Or at least provide an >> option to do that. That would provide opportunities for server-side >> automation for populating side-tags with updated builds against a >> package. > > But it is not practical given the performance concerns around side tags. Can those be fixed? -- 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: FF 107.0 scratch builds - just for fun
On 12/3/22 22:41, Bojan Smojver via devel wrote: > 107.0.1 build for > F37/x86_64: https://copr.fedorainfracloud.org/coprs/bojan/FF/ > > If you want/need or are obsessive about version numbers, like yours > truly. ;-) When will FF107 actually ship in Fedora? -- 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: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)
On 11/22/22 10:19, Florian Weimer wrote: > * Neal Gompa: > >> On Tue, Nov 22, 2022 at 6:54 AM Florian Weimer wrote: >>> >>> Why isn't this something that is up to the toolchain team to decide? >>> >> >> The toolchain team doesn't work with the full corpus of packages, >> doesn't really interface with most of the packagers, and doesn't work >> with most of the upstreams that make up Fedora. So by that definition, >> the toolchain team can't decide either. > > Still I think this interferes *a lot* in an area that should the package > maintainer's prerogative. > > As of today, we do not have patches to build glibc with frame pointers > on most architectures. Someone said on the ticket that they have done > it, but they haven't upstreamed their patches. The individual changes > may be tiny, but just for x86-64, roughly 500 assembler files need > patching. I just don't see us maintaining this as a downstream-only > patch. And without these patches, the most widely used glibc functions > (by executed instructions) won't have frame pointers. IIRC the initial motivation for this was profiling requirements at Meta. Could they pay one or two people to actually make profiling work on Linux *without* frame pointers, instead of slowing everyone’s system down by requiring them? I have already proposed a solution (do the stack unwinding in the vDSO) which makes this possible *without* having to parse untrusted DWARF in kernel mode. This does mean moving the unwinding out of NMI context, but that is highly desirable *anyway*, as it means being able to page in memory as needed. If unwinding *really* needs to be done in kernel mode, this would be a good use of the recently-added Rust support. At this point, it is a matter of paying someone to actually do the work, not of whether the work is possible. -- 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
