Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

[Vitaly Zaitsev via devel]

On 22/12/2022 21:29, Chris Murphy wrote:

This is a rare but real problem.


I don't think so. Power outage is a very common problem in some countries.

I still remember how unreliable FAT32 was in the Windows 9x era. You 
needed to run a scandisk check after every power failure or pressing the 
reset button. And sometimes your documents or other files disappeared. I 
really don't want a repeat of this.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)

[Tomasz Torcz]

On Thu, Dec 22, 2022 at 05:22:09PM -0500, Steve Grubb wrote:
> On Thursday, December 22, 2022 1:29:29 PM EST Adam Williamson wrote:
> > 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.
> 
> I run across this with some regularity. PackageKit is not installed on my 
> system. What I wished was that when there is a stall shutting down, a message 
> to the console or a dialog box explains who is holding up shutdown. If we 
> knew who was holding things up, bugs might get filed.

  But there already is such message! First "waiting for shutdown" with
unit name and a timer. Then, in the last phase there's also "wating for 
process:"
message.
  The problem is: at this points it is hardly debuggable. One cannot
start a new shell, sshd is off already, journalctl too. No way to gather
any information what's wrong with the process holding up shutdown. We
only get a name.  And usually you cannot reproduce the problem easy on
next shutdown.
  Maybe netconsole is still functioning at this point, but I doubt it.

-- 
Tomasz TorczTo co nierealne – tutaj jest normalne.
to...@pipebreaker.pl  Ziomale na życie mają tu patenty specjalne.
___
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)

[Demi Marie Obenour]

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)

[Demi Marie Obenour]

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)

[Demi Marie Obenour]

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)

[Demi Marie Obenour]

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

[Bug 2155345] perl-CPAN-Perl-Releases-5.20221220 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2155345



--- Comment #4 from Fedora Update System  ---
FEDORA-2022-441c08c2e6 has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh
--advisory=FEDORA-2022-441c08c2e6`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-441c08c2e6

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2155345
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2155351] perl-Module-CoreList-5.20221220 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2155351



--- Comment #4 from Fedora Update System  ---
FEDORA-2022-d837237b50 has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh
--advisory=FEDORA-2022-d837237b50`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-d837237b50

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2155351
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2155956] New: perl-JSON-Path-1.0.3 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2155956

Bug ID: 2155956
   Summary: perl-JSON-Path-1.0.3 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-JSON-Path
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 1.0.3
Upstream release that is considered latest: 1.0.3
Current version/release in rawhide: 1.0.2-1.fc38
URL: https://metacpan.org/release/JSON-Path/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/15651/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-JSON-Path


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2155956
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Fedora EPEL 8 updates-testing report

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-5d08436b7d   
davix-0.8.3-1.el8
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-49c3f833e1   
libptytty-2.0-2.el8 rxvt-unicode-9.30-3.el8
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-47a8accb45   
trafficserver-9.1.4-1.el8


The following builds have been pushed to Fedora EPEL 8 updates-testing

apptainer-1.1.4-2.el8
colordiff-1.0.21-1.el8
python-colcon-defaults-0.2.7-1.el8
python-colcon-notification-0.2.15-1.el8
python-pylero-0.0.5-1.el8
rpki-client-8.2-2.el8

Details about builds:



 apptainer-1.1.4-2.el8 (FEDORA-EPEL-2022-f43b053bd8)
 Application and environment virtualization formerly known as Singularity

Update Information:

Move Obsoletes: singularity to apptainer-suid, remove Provides: singularity, and
add Provides/Conflicts sif-runtime

ChangeLog:

* Wed Dec 14 2022 Carl George  - 1.1.4-2
- Add pivot provides/conflict of sif-runtime
- Reduce singularity obsoletes upper bound
- Remove singularity provides due to incompatibilities introduced in apptainer
- Add the word singularity to the summary so it shows up in dnf search results
- Move obsoletes to suid subpackage




 colordiff-1.0.21-1.el8 (FEDORA-EPEL-2022-29cd179e32)
 Color terminal highlighter for diff files

Update Information:

Update to new version 1.0.21. Improved documentation for command-line options.

ChangeLog:

* Thu Dec 22 2022 Richard Fearn  - 1.0.21-1
- Update to 1.0.21 (#2155860)




 python-colcon-defaults-0.2.7-1.el8 (FEDORA-EPEL-2022-fa898cfe07)
 Extension for colcon to read defaults from a config file

Update Information:

Update to the latest `colcon-defaults` release.

ChangeLog:

* Wed Dec 21 2022 Scott K Logan  - 0.2.7-1
- Update to 0.2.7 (rhbz#2155374)

References:

  [ 1 ] Bug #2155374 - python-colcon-defaults-0.2.7 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2155374




 python-colcon-notification-0.2.15-1.el8 (FEDORA-EPEL-2022-032de7e3e6)
 Extension for colcon to provide status notifications

Update Information:

Update to the latest `colcon-notification` release.

ChangeLog:

* Wed Dec 21 2022 Scott K Logan  - 0.2.15-1
- Update to 0.2.15 (rhbz#2155375)

References:

  [ 1 ] Bug #2155375 - python-colcon-notification-0.2.15 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2155375




 python-pylero-0.0.5-1.el8 (FEDORA-EPEL-2022-1eeb389f7a)
 Python SDK for Polarion

Update Information:

python-pylero-0.0.5-1

ChangeLog:

* Wed Dec 21 2022 Wayne Sun  0.0.5-1
- Update to 0.0.5




 rpki-client-8.2-2.el8 (FEDORA-EPEL-2022-d76b361a0f)
 OpenBSD RPKI validator to support BGP Origin Validation

Update Information:

- Added upstream patch for `AF_INET6` support in `inet_net_pton()`

ChangeLog:

* Thu Dec 22 2022 Robert Scheck  8.2-2
- Added upstream patch for AF_INET6 support in inet_net_pton()

[EPEL-devel] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-2b4c6176d0   
davix-0.8.3-1.el7
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-c57a51c195   
rxvt-unicode-9.30-2.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-8362ddfe7c   
trafficserver-9.1.4-1.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

apptainer-1.1.4-2.el7
colordiff-1.0.21-1.el7
python-colcon-defaults-0.2.7-1.el7
python-colcon-notification-0.2.15-1.el7
rpki-client-8.2-2.el7

Details about builds:



 apptainer-1.1.4-2.el7 (FEDORA-EPEL-2022-0b3eb6cf72)
 Application and environment virtualization formerly known as Singularity

Update Information:

Move Obsoletes: singularity to apptainer-suid, remove Provides: singularity, and
add Provides/Conflicts sif-runtime

ChangeLog:

* Wed Dec 14 2022 Carl George  - 1.1.4-2
- Add pivot provides/conflict of sif-runtime
- Reduce singularity obsoletes upper bound
- Remove singularity provides due to incompatibilities introduced in apptainer
- Add the word singularity to the summary so it shows up in dnf search results
- Move obsoletes to suid subpackage




 colordiff-1.0.21-1.el7 (FEDORA-EPEL-2022-8d922d2095)
 Color terminal highlighter for diff files

Update Information:

Update to new version 1.0.21. Improved documentation for command-line options.

ChangeLog:

* Thu Dec 22 2022 Richard Fearn  - 1.0.21-1
- Update to 1.0.21 (#2155860)




 python-colcon-defaults-0.2.7-1.el7 (FEDORA-EPEL-2022-e91681b03a)
 Extension for colcon to read defaults from a config file

Update Information:

Update to the latest `colcon-defaults` release.

ChangeLog:

* Wed Dec 21 2022 Scott K Logan  - 0.2.7-1
- Update to 0.2.7 (rhbz#2155374)

References:

  [ 1 ] Bug #2155374 - python-colcon-defaults-0.2.7 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2155374




 python-colcon-notification-0.2.15-1.el7 (FEDORA-EPEL-2022-50b87db438)
 Extension for colcon to provide status notifications

Update Information:

Update to the latest `colcon-notification` release.

ChangeLog:

* Wed Dec 21 2022 Scott K Logan  - 0.2.15-1
- Update to 0.2.15 (rhbz#2155375)

References:

  [ 1 ] Bug #2155375 - python-colcon-notification-0.2.15 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2155375




 rpki-client-8.2-2.el7 (FEDORA-EPEL-2022-41aa2296fd)
 OpenBSD RPKI validator to support BGP Origin Validation

Update Information:

- Added upstream patch for `AF_INET6` support in `inet_net_pton()`

ChangeLog:

* Thu Dec 22 2022 Robert Scheck  8.2-2
- Added upstream patch for AF_INET6 support in inet_net_pton()


___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Fedora EPEL 9 updates-testing report

[updates]

The following Fedora EPEL 9 Security updates need testing:
 Age  URL
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-53c9c8c84a   
trafficserver-9.1.4-1.el9


The following builds have been pushed to Fedora EPEL 9 updates-testing

apptainer-1.1.4-2.el9
colordiff-1.0.21-1.el9
composer-2.5.1-1.el9
python-colcon-defaults-0.2.7-1.el9
python-colcon-notification-0.2.15-1.el9
python-pylero-0.0.5-1.el9
python-sushy-4.3.3-2.el9
rpki-client-8.2-2.el9

Details about builds:



 apptainer-1.1.4-2.el9 (FEDORA-EPEL-2022-dab8553a71)
 Application and environment virtualization formerly known as Singularity

Update Information:

Move Obsoletes: singularity to apptainer-suid, remove Provides: singularity, and
add Provides/Conflicts sif-runtime

ChangeLog:

* Wed Dec 14 2022 Carl George  - 1.1.4-2
- Add pivot provides/conflict of sif-runtime
- Reduce singularity obsoletes upper bound
- Remove singularity provides due to incompatibilities introduced in apptainer
- Add the word singularity to the summary so it shows up in dnf search results
- Move obsoletes to suid subpackage




 colordiff-1.0.21-1.el9 (FEDORA-EPEL-2022-5511dfdbc6)
 Color terminal highlighter for diff files

Update Information:

Update to new version 1.0.21. Improved documentation for command-line options.

ChangeLog:

* Thu Dec 22 2022 Richard Fearn  - 1.0.21-1
- Update to 1.0.21 (#2155860)
* Wed Jul 20 2022 Fedora Release Engineering  - 
1.0.20-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild




 composer-2.5.1-1.el9 (FEDORA-EPEL-2022-aeb9f62dd9)
 Dependency Manager for PHP

Update Information:

**Version 2.5.1** - 2022-12-22  * Fixed ClassLoader regression which made it
fail if serialized (e.g. within PHPUnit process isolation) (#11237) * Fixed preg
type error in svn version guessing (#11231)     **Version 2.5.0** -
2022-12-20* BC Warning: To prevent abuse of our includeFile() function it is
now gone, it was not part of the official API but may still cause issues if some
code incorrectly relied on it (#11015)   * Improved version guessing of
`require` command to use the dependency resolution result instead of using the
latest available version (except if you run with --no-update) (#11160)   *
Improved version selection in `archive` command (#11230)   * Added
autocompletion of config option names in the `config` command (#11130)   * Added
support for writing [custom commands as Command
classes](https://getcomposer.org/doc/articles/scripts.md#writing-custom-
commands) (#11151)   * Added hard failure when installing from a lock file which
does not satisfy the composer.json requirements (#11195)   * Added warning when
the outdated command rejects a new package due to unmet platform requirements
(#3)   * Added support for `bump` command to bump `>=x` to `>=installed-
version` (#11179)   * Added `--download-only` flag to `install` command to only
download and prime the cache with the package archives (#11041)   * Added
autoconfiguration of `github-domains`/`gitlab-domains` when GitHub/GitLab
credentials are configured for a custom domain (#11062)   * Added hard failure
(throw) if COMPOSER_AUTH is present and malformed JSON (#11085)   * Added
interactive prompt to `run-script` and `exec` commands if run without any
argument (#11157)   * Added interactive prompt where to store credentials when a
project-local auth.json exists (#11188)   * Fixed full disk warning to be shown
when less than 100MiB is available (#11190)   * Fixed cache keys to allow `_` to
avoid conflicts between package names like `a-b` and `a_b` (#11229)   * Fixed
docker compatibility by making paths more portable even if the project is
installed at `/` (#11169)

ChangeLog:

* Thu Dec 22 2022 Remi Collet  - 2.5.1-1
- update to 2.5.1
* Tue Dec 20 2022 Remi Collet  - 2.5.0-1
- update to 2.5.0




 python-colcon-defaults-0.2.7-1.el9 (FEDORA-EPEL-2022-3271edcfda)
 Extension for colcon to read defaults 

[Bug 2155345] perl-CPAN-Perl-Releases-5.20221220 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2155345

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-2022-bfd926fc14 has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh
--advisory=FEDORA-2022-bfd926fc14`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-bfd926fc14

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2155345
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2155351] perl-Module-CoreList-5.20221220 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2155351

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-2022-3c99427018 has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh
--advisory=FEDORA-2022-3c99427018`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-3c99427018

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2155351
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

F37 election results

[Ben Cotton]

Greetings, all!

The elections for the Fedora Linux 37 cycle have completed.

## Fedora Council

Aleksandra Fedorova is elected to the Fedora Council

## Fedora Engineering Steering Committee (FESCo)

The following candidates are elected to FESCo:

* Kevin Fenzi
* Miro Hrončok
* Zbigniew Jędrzejewski-Szmek
* David Cantrell
* Fabio Valentini

## Fedora Mindshare Committee

Fernando F. Mancera is elected to the Fedora Mindshare Committee.

Congratulations to all those elected and thank you to the candidates and voters.

For more details, see the Community Blog post:
https://communityblog.fedoraproject.org/fedora-linux-37-election-results/

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

F37 election results

[Ben Cotton]

Greetings, all!

The elections for the Fedora Linux 37 cycle have completed.

## Fedora Council

Aleksandra Fedorova is elected to the Fedora Council

## Fedora Engineering Steering Committee (FESCo)

The following candidates are elected to FESCo:

* Kevin Fenzi
* Miro Hrončok
* Zbigniew Jędrzejewski-Szmek
* David Cantrell
* Fabio Valentini

## Fedora Mindshare Committee

Fernando F. Mancera is elected to the Fedora Mindshare Committee.

Congratulations to all those elected and thank you to the candidates and voters.

For more details, see the Community Blog post:
https://communityblog.fedoraproject.org/fedora-linux-37-election-results/

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@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)

[Chris Murphy]

On Thu, Dec 22, 2022, at 5:22 PM, Steve Grubb wrote:
> On Thursday, December 22, 2022 1:29:29 PM EST 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.
>
> I run across this with some regularity. PackageKit is not installed on my 
> system. What I wished was that when there is a stall shutting down, a message 
> to the console or a dialog box explains who is holding up shutdown. If we 
> knew who was holding things up, bugs might get filed.

I wonder if systemctl list-jobs would be too much? 

This information needs to be logged too because 15 seconds won't be enough to 
see much. And for it to be logged, sysroot needs to be rw.


>
> In some cases I know that the system is rebuilding the nvidia drivers so that 
> graphics work on boot up. I'd like to let that finish and it certainly takes 
> more than 15 seconds. But without a blame message, how do we know what needs 
> looking into?

I expect there is (or will be) a way of tagging service units with indefinite 
wait. Reboot can't happen in the middle of kmod updates.


-- 
Chris Murphy
___
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)

[Steve Grubb]

On Thursday, December 22, 2022 1:29:29 PM EST 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.

I run across this with some regularity. PackageKit is not installed on my 
system. What I wished was that when there is a stall shutting down, a message 
to the console or a dialog box explains who is holding up shutdown. If we 
knew who was holding things up, bugs might get filed.

In some cases I know that the system is rebuilding the nvidia drivers so that 
graphics work on boot up. I'd like to let that finish and it certainly takes 
more than 15 seconds. But without a blame message, how do we know what needs 
looking into?

-Steve

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Golang bundled() Provides generator

[Maxwell G via devel]

Hi Fedorians,

A recent PR reminded me that I never properly announced the new (well,
four months old) bundled() Provides generator for Golang projects[1].
This can be used to simplify generating these Provides when bundling is
justified in Fedora[2] or for (EP)EL. Simply mark the vendor/modules.txt
file generated by `go mod vendor` with `%license` and the generator will
take care of the rest.

This removes the need for long lists of Provides that clutter specfiles
and have to be updated after each upstream release. It's up to package
maintainers to inspect the Provides for correctness when opting in to
this generator. Please let us know if you find any bugs.

The generator is available in all Fedora branches and on EPEL 9 (part of
go-rpm-macros-epel that shadows RHEL's go-rpm-macros). go-rpm-macros has
been updated in c9s, so I'll remove the generator from
go-rpm-macros-epel when the next RHEL 9 minor release comes out.

[1]:
https://pagure.io/go-rpm-macros/c/226596177c63c3dc180b5aeda45fe3b18706e877?branch=master
and
https://pagure.io/go-rpm-macros/c/c32fbbd25bbcedee8c0b898d3653255b18a0d30e?branch=master

[2]: 
https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/#_bundled_or_unbundled

--
Maxwell G (@gotmax23)
Pronouns: He/Him/His
___
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: Orphaned packages looking for new maintainers

[Sérgio Basto]

On Wed, 2022-12-21 at 12:08 +, Sérgio Basto wrote:
> On Mon, 2022-12-19 at 19:45 +, Smith, Stewart via devel wrote:
> > 
> > > On Dec 19, 2022, at 7:43 AM, Miro Hrončok 
> > > wrote:
> > > 
> > > The following packages are orphaned and will be retired when they
> > > are orphaned for six weeks, unless someone adopts them. If you
> > > know
> > > for sure
> > > that the package should be retired, please do so now with a
> > > proper
> > > reason:
> > > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
> > > 
> > > Note: If you received this mail directly you (co)maintain one of
> > > the affected
> > > packages or a package that depends on one. Please adopt the
> > > affected package or
> > > retire your depending package to avoid broken dependencies,
> > > otherwise your
> > > package will fail to install and/or build when the affected
> > > package
> > > gets retired.
> > > 
> > > Request package ownership via the *Take* button in he left column
> > > on
> > > https://src.fedoraproject.org/rpms/
> > 
> > I took a bunch that we still ship in some Amazon Linux version, and
> > may end up going through the package retirement process for some of
> > them in Fedora, as some of these are probably a few years beyond
> > any
> > upstream activity.
> > 
> > biosdevname
> > fros
> > gconf-editor
> > gtkhtml3
> > libbonobo
> > libbonoboui
> > libcmpiutil
> > libgnome
> > libmodman
> > liboil
> > libvirt-cim
> > libvirt-java
> > maven-scm
> > openjpeg
> 
> Note that we are not orphan all openjpeg , because we have openjpeg2
> . 
> we are orphan only openjpeg1 .
> 
> Looking for dependencies on openjepg1, now we only have one
> dependency
> [1] but only on BuildRequires which may mean that BuildRequires can
> be
> unneeded and dropped.

Confirmed megaglest does not need  openjepg1 , and no dependencies on
openjepg1 left . 

> In resume, two thoughts , one, is maybe we should move openjpeg2 to
> openjpeg , is more than time and avoid confusions .

I think we should rename openjpeg2 with openjpeg


> Other though is, I realize that we can use find_unblocked_orphans.py
> [2] to detect unneeded BuildRequires and start dropping it,
> particularly on old software . 
> 
> Best regards,
> 
> [2] 
> https://pagure.io/releng/blob/main/f/scripts/find_unblocked_orphans.py
> 
> 
> [1] 
> Depending on: openjpeg (1), status change: 2022-11-28 (3 weeks ago)
> megaglest (maintained by: andymenderunix)
> megaglest-3.13.0-14.fc38.src requires openjpeg-devel = 1.5.1-33.fc37
> 
> > python-cov-core
> > system-storage-manager
> > tboot

-- 
Sérgio M. B.
___
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)

[allan2016--- via devel]

På Thu, 22 Dec 2022 10:29:29 -0800
Adam Williamson  skrev:
> 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.

15 seconds will for sure kill the modem on the Pinephones for good.
When the shutdown command are sent to the modem, it takes 20-30 seconds
for the modem to shut down completely. Powering off the phone before the
modem has completely shut down is more or less a sure way to kill the
modem for good, as it can destroy the user space data in the modem.
You will get a lot of angry Pinephone users - if introducing this
"feature" in rawhide !


___
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)

[Chris Murphy]

On Wed, Dec 21, 2022, at 12:00 PM, 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?

And for btrfs, the GRUB btrfs.mod doesn't do any checksum checking at all, so 
there's not even an incremental improvement to integrity, let alone any support 
for fs-verity. So while I like btrfs for /boot due to the space efficiency 
advantage (I don't have to ask how big boot should be, no space is wasted and I 
don't run out either), I'm willing to give it up for practical matters like 
simplicity and reduced attack and maintenance surface area.



-- 
Chris Murphy
___
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)

[Chris Murphy]

On Wed, Dec 21, 2022, at 6:53 AM, Vitaly Zaitsev via devel wrote:
> On 21/12/2022 12:38, Daniel P. Berrangé wrote:
>> Why shouldn't FAT be used for /boot.  In an EFI world, /boot
>> is used for the same functional pupose as the ESP, which is
>> already going to use FAT.
>
> Doesn't support links, lournaling and ACLs.

What's the use case? Is it a nice to have or is it a hard requirement and why?

The Linux FAT driver does support SELinux context with a mount option. We 
aren't using that right now but we can have a suitable SELinux label enforced 
file system wide on ESP and XBOOTLDR.


> Everyone can do whatever they want with the files, and a trivial power 
> outage can easily wipe out all of its contents.

This is a rare but real problem. I think we should be looking at ESP and 
XBOOTLDR updates doing A/B updates, i.e. write the updates to temporary files 
or directories and then use renameat(2) which is atomic at the VFS layer, and 
should get pretty close to atomic at the FAT layer to the degree that worse 
case scenario we have either the old *and* new files following a crash. Ideally 
we'd get old *or* new. But that's probably not possible with FAT. But we can 
still boot. 


>> Such drivers would need to be signed to be used
>> under SecureBoot, thus expanding the set of components you
>> need to audit & trust for security purposes.
>
> These drivers are backports from the grub2 code. If we trust GRUB, we 
> can trust them too.
>
> Fedora Infra can be configured to sign the contents of the efifs package 
> with a Fedora SB key.

Yeah but then try getting all the distros to agree on signing efifs. How many 
distros are there? It's not unfair to say  all distros should be able to put 
their signed efifs drivers on the ESP because that's the only way their 
bootloader can read loader/entries to properly draw a boot menu.


-- 
Chris Murphy
___
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)

[Alexander Ploumistos]

On Thu, Dec 22, 2022 at 8:55 PM Chris Murphy  wrote:
>
> Also I wonder if  there's a way for desktops to opt into this behavior? Or a 
> way for servers, iot, cloud, and rpm-ostree based systems to opt out?

Do you mean like setting the "DefaultTimeoutStopSec" variable in
/etc/systemd/system.conf?
(at least that's the one I *think* is responsible)
___
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)

[Chris Murphy]

On Wed, Dec 21, 2022, at 6:22 AM, Vitaly Zaitsev via devel wrote:
> On 20/12/2022 19:56, Chris Murphy wrote:
>> Great. The gotcha though is this in effect requires a change in the file 
>> system currently mounted at /boot, which is ext4. And ext4 isn't supported 
>> by sd-boot or UEFI firmware. So if you're going to support sd-boot, the 
>> installer needs to be aware that either the ESP is big enough to be used as 
>> /boot, or if it's not big enough then it will be mounted on /efi*and*  a new 
>> partition XBOOTLDR formatted as FAT will be used as /boot.
>
> Nobody should use FAT for /boot. efifs[1] should be used instead.
>
> systemd-boot can load these drivers from ESP out of the box[2].

The founding principle in Boot Loader Spec is that multiboot between Linux 
distros sucks. The cooperation between distros, is shit. And BLS strives to 
present an opportunity to compromise and fix that problem.

It's harder to fix this problem if XBOOTLDR is not FAT. efifs drivers need to 
be Secure Boot signed just like the bootloader. The firmware already trusts its 
built-in FAT driver, for better or worse, so what is the exact problem with 
just using that so we don't have to deal with UEFI SB signing efifs drivers, 
and the much harder job of expecting every distro to include signed efifs 
drivers *on the ESP* for multiboot to work? 

If /boot is ext4, then every Linux distro must include a signed ext4 efifs 
driver in order to properly render the boot menu. But what if (open)SUSE 
doesn't want to use ext4, they want Btrfs? Compromise dictates that every 
distro now needs to provide a signed btrfs efifs driver too. OK Red Hat uses 
XFS for boot, so now every distro needs to include ext4, btrfs, and XFS signed 
efifs drivers with every installation. It's explosively more complicated to 
implement let alone to agree upon than just use the one driver we know everyone 
has and can use.

XBOOTLDR in practice needs to be FAT. I don't like it. But I like it better 
than choosing batshit as the alternative, and having a bunch of signed efifs 
drivers on the ESP per distro sounds like batshit to me. And not in the good 
way.


-- 
Chris Murphy
___
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)

[Björn Persson]

Vít Ondruch wrote:
> Dne 22. 12. 22 v 9:56 Olivier Fourdan napsal(a):
> > When the connection fails, the Xserver returns a reason in plain text.
> > In that case, the reason for the connection being rejected would be
> > „Swapped clients prohibited“.  
> 
> Appreciate that there is at least some explanation, but if I saw this 
> error, I would not be much smarter what is going on and how should I 
> proceed 

Yes, that's a really bad error message. My reaction would be "What
nonsense is that? I haven't swapped any clients." If it had at least
said "byte-swapped" it would probably have gotten me searching in the
right direction, but if the X server wants to be helpful it should say
"big/little-endian mismatch; the option AllowSwappedClients is off".

Björn Persson


pgptXffOuQJrN.pgp
Description: OpenPGP digital signatur
___
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)

[Chris Murphy]

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).

Also I wonder if  there's a way for desktops to opt into this behavior? Or a 
way for servers, iot, cloud, and rpm-ostree based systems to opt out? They very 
well might have legitimate reasons for very long service shutdowns: they're 
really super busy, and forward progress is being made but it'll take a *lot* 
longer than 15 minutes to get to a safe shutdown point.



-- 
Chris Murphy
___
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)

[Tom Hughes via devel]

On 22/12/2022 19:18, Michael Catanzaro wrote:
On Thu, Dec 22 2022 at 10:29:29 AM -0800, Adam Williamson 
 wrote:

Could we not go for 30 seconds?


Personally I think 30 seconds is way too long for desktop users. But 
it's a lot better than 2 minutes, so if that's what we settle on, I 
won't complain.


The thing is that it's not really two minutes anyway, it's more
like eight minutes because each time the timer expires systemd
sends a stronger signal and restarts the timer until it eventually
gets to SIGKILL.

So in the worst case where a process is stuck in D wait then
you get all the way to the SIGKILL phase and then wait two minutes
for that before it eventually gives up and continues.

At least that is what usually seems to happen when I run into
this problem.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
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)

[Michael Catanzaro]

On Thu, Dec 22 2022 at 10:29:29 AM -0800, Adam Williamson 
 wrote:

Could we not go for 30 seconds?


Personally I think 30 seconds is way too long for desktop users. But 
it's a lot better than 2 minutes, so if that's what we settle on, I 
won't complain.


libvirtd should probably take an inhibitor to inform the user to close 
things cleanly before starting to shut down the host.


___
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)

[Dennis Gilmore via devel]

On Thu, Dec 22, 2022 at 5:25 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Wed, Dec 21, 2022 at 11:56:32AM -0600, Dennis Gilmore via devel wrote:
> > In my case, I have Network Manager config files included in my initrd
> > and bootargs to bring up the network so that I get automatic disk
> > decryption while on my home network, and prompted for a password when
> > I am not at home. I think this a reasonable enough use case it should
> > be considered in the long term plan. There was an effort many years
> > ago that built the initramfs with the kernel, it was abandoned due to
> > not being able to guarantee sources for the binaries in the initramfs,
>
> If a UKI is built in koji, the initrd it embeds must also be built in koji. 
> And
> when the initrd is built in koji, it is just taking some binaries from rpms 
> and
> repacking them. We ensure that we have an srpm for any official srpm. Thus, 
> going
> back from the UKI, you look up the initrd, and the logs for the initrd build,
> and get a list of rpms, and then look the appropriate srpms from that, and 
> from
> the srpms you get the sources. There's a few more steps, but the availability 
> of
> sources is guaranteed using the mechanism existing for normal rpms.

In the past that was deemed to not be good enough. by legal as it is
too hard for the average user to do.

> > trying to dig up the details I am having trouble finding it, but legal
> > blocked it there is a reference to it in an old FESCo meeting
> > https://lists.fedoraproject.org/pipermail/devel/2013-February/178220.html.
> > Additionally, we should also consider
> > https://fedoraproject.org/wiki/Features/DracutHostOnly and the size
> > implications and why we moved to have kernel-core, kernel-modules, and
> > kernel-modules-extra for cloud and different use cases.
>
> Yes. That's why this proposal explicitly targets a narrow use case which 
> doesn't
> need many drivers and will support many different machines with the same
> (relatively small) initrd.

I think the proposal needs to be explicit in how other use cases and
all architectures will be handled. I think if we do not have a path
for all architectures to be supported we should spend more time
working out how to cover them all.

> Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

[Luca Boccassi]

> On Thu, Dec 22, 2022 at 12:00 PM Luca Boccassi  
> 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. If
> I can't safely distrust Microsoft reliably, then it's already broken.
> 
> Firmware trust has been broken since the very beginning, and it was
> broken by design in the PC world.

"My" (not really mine, but whatever) concept works on pretty much every single 
x86 consumer device sold in the past ~12 years, in every public cloud provider, 
a gazillion arm64 use cases, and more. It's only "broken" if by that you mean 
that an entire class of very real and very much alive in the wild malware 
infections are no longer possible.
Of course if you do things like deleting the 3rd party UEFI CA on machines that 
require option roms to work without allow-listing or re-signing, then things 
break, but that has absolutely nothing to do with the "concept" - if you delete 
a trust anchor, objects trusted by it are no longer trusted in the absence of 
an alternative chain, that's pretty much expected behaviour.
Obviously things can always be improved, and we are working on that, SBAT is 
the first step in that direction. But saying that the trust chain model is 
broken is simply untrue.

> Consumer PC equipment is even worse off because of how Microsoft's
> Windows requirements influence how UEFI implementations work.

You meant to say "light years ahead" here - it is not even funny anymore how 
far behind Linux is to Windows w.r.t. security, especially in the boot process. 
We have been playing catch-up for 10 years and are nowhere near done. It is 
very fortunate for the ecosystem at large that there are people who actually 
understand the threat models pushing the industry forward, because if it was up 
to the hardware vendors computer security would still be where it was in the 
mid 90s.

But we are working on it, and making progress - in some technical concepts we 
are even ahead of them right now (eg: signed TPM policies, FIDO2 for luks, 
Windows doesn't have anything like that), but only in PoCs. Now we need the 
wide adoption, and this proposal is one timid step forward in that direction. 
The fact that in 2022 there is still no mainstream distro that has closed the 
glaring security gaping hole of writable, untrusted initrd (yes some distros 
have non-default specialized flavours for this, but it's niche) should be a 
source of embarrassment for anybody who works on OS development. It is a 
difficult problem, but by no means impossible, and it really ought to have been 
fixed at least for the generic use case by now. We need to get this sorted at 
long last.
___
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)

[Adam Williamson]

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.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)

[Ben Cotton]

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.

== Owner ==
* Name: catanzaro
* Email: mcatanzaro at redhat dot com
* Name: aday
* Email: aday at redhat dot com


== Detailed Description ==
Currently, a service that fails to stop at shutdown time can block
shutdown for up to 2 minutes. This is extremely frustrating for our
users - someone goes to shutdown or reboot their system, and then
unexpectedly has to wait for a long time before they can do anything
else.

The most common service to cause this issue is PackageKit, but there are others.

When a service fails to shutdown when it is instructed to do so, it is
not behaving properly, and it is preventing the system from behaving
in an orderly and predictable manner. Desktop APIs exist for cases
when services or apps legitimately need to prevent shutdown, and these
allow the shutdown inhibit to be communicated to admins and users, so
they understand what is happening. When the user decides to shut down
anyway, services must terminate in a timely manner. The Workstation
Working Group feels that 15 seconds is the maximum appropriate time
for both system and user services, and that Fedora should be robust to
buggy and misbehaving services that do not shut down in an appropriate
manner.

=== History ===

The Workstation Working Group has been
[https://pagure.io/fedora-workstation/issue/163 working on this issue
for several years]. Investigations have revealed that it's not
possible to fix every misbehaving service: in some cases the
misbehaviour comes from design flaws that are difficult to resolve.

An attempt has also been
[https://github.com/systemd/systemd/pull/18386 made to have the unit
timeout changed in upstream systemd]. That attempt did not go
anywhere, despite various efforts to move it along. We are no longer
comfortable waiting for upstream changes to land.

To our knowledge, there are no issues that will result from forcing
services to stop after 15 seconds on typical systems. However, system
administrators may need to configure a higher timeout if waiting
longer for a particular service, which may be true for database
services, for example.

== Feedback ==
The relevant [https://pagure.io/fedora-workstation/issue/163
Workstation Working Group ticket] includes some discussion. This
change [https://pagure.io/fesco/issue/2853 was also previously
proposed to FESCo].

== Benefit to Fedora ==
The primary benefit of the change will be to mitigate a very annoying
and - frankly - embarrassing bug. Our users shouldn't have to randomly
sit waiting for their machine to shutdown. It will also encourage the
correct use of shutdown inhibit APIs.

Although this change will "paper over" bugs in services without fixing
them, we emphasize that reducing the timeout is not merely a
workaround for buggy services, but also the desired permanent design.
Of course it is desirable to fix the underlying bugs as well, but it
doesn't make sense to require this before fixing the service timeout
to match our needs.

== Scope ==
* Proposal owners:
** Merge [https://src.fedoraproject.org/rpms/systemd/pull-request/85
the downstream change] to {{package|systemd}}.
* Other developers:
** Test their packages with the new behavior and report issues as necessary.
* Release engineering: [https://pagure.io/releng/issue/11193 #11193]
* Policies and guidelines: No policy or guideline changes required
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:

== Upgrade/compatibility impact ==
System and user services will be killed with SIGKILL 15 seconds after
receiving SIGTERM, from previously 1 minute 30 seconds for most system
and user services, or 2 minutes for user manager system services (the
system service that runs all user services for a user), so services
will have less time to shut down gracefully by default. These defaults
are configurable and system administrators who require longer timeouts
would need to adjust them before or after upgrade. You may edit the
DefaultTimeoutStopSec= setting in /etc/systemd/user.conf and
/etc/systemd/system.conf. You may also create a drop-in to change the
TimeoutStopSec= setting for user@service.

== How To Test ==
Given the intermittent and unpredictable nature of the bug that is
being targeted, the best way to test is by using the upcoming Fedora
release. Are shutdown delays eliminated as intended? Do system
services experience issues as a result of the change?

== User Experience ==
This change will make the Fedora user experience less annoying. It
will also encourage the use of the existing inhibit APIs, which
provide better feedback for users 

Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)

[Tomasz Torcz]

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…


-- 
Tomasz TorczTo co nierealne – tutaj jest normalne.
to...@pipebreaker.pl  Ziomale na życie mają tu patenty specjalne.
___
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

F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)

[Ben Cotton]

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.

== Owner ==
* Name: catanzaro
* Email: mcatanzaro at redhat dot com
* Name: aday
* Email: aday at redhat dot com


== Detailed Description ==
Currently, a service that fails to stop at shutdown time can block
shutdown for up to 2 minutes. This is extremely frustrating for our
users - someone goes to shutdown or reboot their system, and then
unexpectedly has to wait for a long time before they can do anything
else.

The most common service to cause this issue is PackageKit, but there are others.

When a service fails to shutdown when it is instructed to do so, it is
not behaving properly, and it is preventing the system from behaving
in an orderly and predictable manner. Desktop APIs exist for cases
when services or apps legitimately need to prevent shutdown, and these
allow the shutdown inhibit to be communicated to admins and users, so
they understand what is happening. When the user decides to shut down
anyway, services must terminate in a timely manner. The Workstation
Working Group feels that 15 seconds is the maximum appropriate time
for both system and user services, and that Fedora should be robust to
buggy and misbehaving services that do not shut down in an appropriate
manner.

=== History ===

The Workstation Working Group has been
[https://pagure.io/fedora-workstation/issue/163 working on this issue
for several years]. Investigations have revealed that it's not
possible to fix every misbehaving service: in some cases the
misbehaviour comes from design flaws that are difficult to resolve.

An attempt has also been
[https://github.com/systemd/systemd/pull/18386 made to have the unit
timeout changed in upstream systemd]. That attempt did not go
anywhere, despite various efforts to move it along. We are no longer
comfortable waiting for upstream changes to land.

To our knowledge, there are no issues that will result from forcing
services to stop after 15 seconds on typical systems. However, system
administrators may need to configure a higher timeout if waiting
longer for a particular service, which may be true for database
services, for example.

== Feedback ==
The relevant [https://pagure.io/fedora-workstation/issue/163
Workstation Working Group ticket] includes some discussion. This
change [https://pagure.io/fesco/issue/2853 was also previously
proposed to FESCo].

== Benefit to Fedora ==
The primary benefit of the change will be to mitigate a very annoying
and - frankly - embarrassing bug. Our users shouldn't have to randomly
sit waiting for their machine to shutdown. It will also encourage the
correct use of shutdown inhibit APIs.

Although this change will "paper over" bugs in services without fixing
them, we emphasize that reducing the timeout is not merely a
workaround for buggy services, but also the desired permanent design.
Of course it is desirable to fix the underlying bugs as well, but it
doesn't make sense to require this before fixing the service timeout
to match our needs.

== Scope ==
* Proposal owners:
** Merge [https://src.fedoraproject.org/rpms/systemd/pull-request/85
the downstream change] to {{package|systemd}}.
* Other developers:
** Test their packages with the new behavior and report issues as necessary.
* Release engineering: [https://pagure.io/releng/issue/11193 #11193]
* Policies and guidelines: No policy or guideline changes required
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:

== Upgrade/compatibility impact ==
System and user services will be killed with SIGKILL 15 seconds after
receiving SIGTERM, from previously 1 minute 30 seconds for most system
and user services, or 2 minutes for user manager system services (the
system service that runs all user services for a user), so services
will have less time to shut down gracefully by default. These defaults
are configurable and system administrators who require longer timeouts
would need to adjust them before or after upgrade. You may edit the
DefaultTimeoutStopSec= setting in /etc/systemd/user.conf and
/etc/systemd/system.conf. You may also create a drop-in to change the
TimeoutStopSec= setting for user@service.

== How To Test ==
Given the intermittent and unpredictable nature of the bug that is
being targeted, the best way to test is by using the upcoming Fedora
release. Are shutdown delays eliminated as intended? Do system
services experience issues as a result of the change?

== User Experience ==
This change will make the Fedora user experience less annoying. It
will also encourage the use of the existing inhibit APIs, which
provide better feedback for users 

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

[Neal Gompa]

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. If
I can't safely distrust Microsoft reliably, then it's already broken.

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.



--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

[Gerd Hoffmann]

On Thu, Dec 22, 2022 at 02:49:37PM +, Daniel P. Berrangé wrote:
> > There are at three ways that are used: 'dracut --uefi', systemd's ukify, 
> > and a
> > manual objcopy invocation. The first two are wrappers around objcopy. I'm 
> > biased
> > because I wrote 'ukify', but I think that's the way to go. What dracut does 
> > is
> > somewhat primitive and doesn't get the offsets right. Obviously it could be
> > improved, but putting the code to generate UKIs inside of an initrd 
> > generator is
> > a historical accident, and bash is not the nicest language to do offset
> > calculations. Thus I hope we can standarize on ukify instead.
> 
> When you say it dooesn't get the offsets right, can you elaborate ?
> We've been using dracut --uefi to build the UKIs in koji and they
> appear to work as expected. Are the offsets only incorrect in
> certain circumstances.

When the kernel binary happens to be too big things break because the
end of the kernel will overlap with the start of the initrd due to the
fixed offsets used and thus the fixes space being available for the
kernel binary (and the other things being added to the uki, except
initrd which comes last).

Which is not the case right now with fedora kernels, so everything works
fine.

take care,
  Gerd
___
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: Can't pull fedora rawhide container image

[Jun Aruga (he / him)]

Thanks! I confirmed it works now.

On Thu, Dec 8, 2022 at 9:58 PM Clement Verna  wrote:
>
> This is fixed now, happy containering :-D

-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See  for
the timezone.
___
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: Replace DNF with DNF5 (System-Wide Change proposal)

[Jaroslav Mracek]

Because the naming of the tool is upstream decision I opened a discussion 
https://github.com/rpm-software-management/dnf5/discussions/210. DNF and the 
new tool is shipped into multiple upstream therefore we have to collect 
feedback from multiple distribution and upstream discussion channel is the bet 
place for that. I asked there several question and I provided 3 basic scenarios.

```
What name (**dnf**, yum, **dnf5**, or microdnf ) we should use for package 
providing binary (currently DNF5)?
What binary name or symlink we should use in man pages (currently DNF5) for 
examples?
What binary name or symlink we should use in Fedora guidelines?
What binary name or symlink we should use in RHEL guidelines?
How we should name packages containing plugins (additional command)?
```

Best regards

Jaroslav
___
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)

[Gerd Hoffmann]

On Thu, Dec 22, 2022 at 10:52:05AM -0500, Neal Gompa wrote:
> On Thu, Dec 22, 2022 at 10:46 AM Lennart Poettering
>  wrote:
> >
> > BTW, you keep talking of "these" problems, and are extremely vague
> > about those. I think I understood that you hit the NVRAM size limits
> > before, by enrolling private certs?
> 
> Yes.

Physical hardware or virtual machines?

For virtual machines:  Fedora uses for historical reasons 2M builds of
OVMF, which have not much NVRAM space.  Alternative 4M builds which have
much more space are available in /usr/share/edk2/ovmf-4m.  Using these
needs manual work right now, hashing out a plan to use these by default
for new VMs without changing/breaking existing VMs is not (yet) done.

take care,
  Gerd
___
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)

[Luca Boccassi]

> 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.
___
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)

[Zbigniew Jędrzejewski-Szmek]

On Thu, Dec 22, 2022 at 04:24:11PM +0100, Lennart Poettering wrote:
> On Do, 22.12.22 14:49, Daniel P. Berrangé (berra...@redhat.com) wrote:
>
> > When you say it dooesn't get the offsets right, can you elaborate ?
>
> dracut uses fixed offsets for the sections to be placed in memory
> in. The values are simply hardcoded, literally specified address
> offsets, that worked for the original authors. This typically works –
> as long as your sections are not much larger than they were for the
> people wo came up with these offsets initially. But as it turns out
> this doesn't work for some cases. In such cases the sections will be
> loaded into memory overlapped and bad things happen.
>
> ukify hence calculates the offsets manually (by adding up the section
> sizes so that this cannot happen.

The issue was detected in CI [1]. Some code changes made the .text
section bigger, causing other sections to overlap, causing an actual
failure during boot. But it seems that the problem is more widespread and
we were just being lucky ;(  We're figuring out the details,

See the attached program:
$ dracut --uefi /tmp/initrd 6.0.13-300.fc37.x86_64
$ python info.py /tmp/initrd
...
#   4 .rela 10c8  0001f000  0001f000  00017f40  2**2
  start=126976 end=131272
#   5 .osrel02df  0002  0002  00019140  2**2
  start=131072 end=131807
  vma overlap with previous section: 200 bytes
...

I plan to return to this after the holidays.

Zbyszek

[1] https://github.com/systemd/systemd/pull/23706#issuecomment-1354729112
'''\
Idx Name  Size  VMA   LMA   File off  Algn
  0 .text 00013aa0  5000  5000  0370  2**4
  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .reloc000a  00019000  00019000  00013f70  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .data 51a8  0001a000  0001a000  00014170  2**4
  CONTENTS, ALLOC, LOAD, DATA
  3 .dynamic  0100  0002  0002  00019370  2**2
  CONTENTS, ALLOC, LOAD, DATA
  4 .osrel029c  0002  0002  00019570  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .rela 14e8  00021000  00021000  00019970  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .dynsym   0018  00023000  00023000  0001af70  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  7 .sbat 00d5  00025980  00025980  0001b170  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  8 .sdmagic  0027  00025a60  00025a60  0001b370  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  9 .cmdline  0032  0003  0003  0001b570  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
 10 .linux00c285e8  0200  0200  0001b770  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
 11 .initrd   038a76ee  0300  0300  00c43d70  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
'''

import subprocess
import sys
dump = subprocess.check_output(['objdump', '-h', sys.argv[1]], text=True)

prev = None

print(dump)

for line in dump.splitlines()[5::2]:
print(f'# {line}')
idx, name, size, vma, lma, file_off, align = line.split()

idx = int(idx)
size = int(size, 16)
vma = int(vma, 16)
lma = int(lma, 16)
file_off = int(file_off, 16)
align = eval(align)

print(f'  start={vma} end={vma + size}')

if prev:
gap = file_off - prev[5] - prev[2]
if gap < 0:
print(f'  file offset overlap with previous section: {-gap} bytes')

gap = vma - prev[3] - prev[2]
if gap < 0:
print(f'  vma overlap with previous section: {-gap} bytes')

prev = (idx, name, size, vma, lma, file_off, align)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2155727] perl-Perl-Critic-1.146 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2155727

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version||perl-Perl-Critic-1.146-1.fc
   ||38
 Status|MODIFIED|CLOSED
 Resolution|--- |ERRATA
Last Closed||2022-12-22 16:23:36



--- Comment #4 from Fedora Update System  ---
FEDORA-2022-93bceed586 has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2155727
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2155727] perl-Perl-Critic-1.146 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2155727

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #3 from Fedora Update System  ---
FEDORA-2022-93bceed586 has been submitted as an update to Fedora 38.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-93bceed586


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2155727
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

[Neal Gompa]

On Thu, Dec 22, 2022 at 10:56 AM Lennart Poettering
 wrote:
>
> On Do, 22.12.22 10:52, Neal Gompa (ngomp...@gmail.com) wrote:
> 65;6800;1c
> > > BTW, you keep talking of "these" problems, and are extremely vague
> > > about those. I think I understood that you hit the NVRAM size limits
> > > before, by enrolling private certs?
> >
> > Yes. Specifically for dealing with the NVIDIA driver, backports of
> > Intel network card drivers, OpenZFS, ELRepo modules, etc.
> >
> > > What are those issues precisely? Did you file bugs? How many certs did
> > > you try to enroll? Or did you try to enroll hashes? Were was this
> > > dicussed?
> >
> > Anywhere between 1 to 3 UEFI certs, representing different vendors
> > (machine-local, ELRepo, and OpenZFS).
>
> OK, so what's left is exactly one issue you had: you tried to enroll 3
> UEFI certs via mokutil and what exactly happened then? machine
> bricked how precisely?
>

The UEFI environment failed to import without reporting failure and
the system failed to boot, showing garbage instead.

> link for a bug report?
>

Sorry, I can't.

> Please be specific, otherwise noone will be able to help you!
>

No one helped anyway, even back when I could provide more information.
They're even less likely now that I can't provide that information.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

[Neal Gompa]

On Thu, Dec 22, 2022 at 10:51 AM Lennart Poettering
 wrote:
>
> On Do, 22.12.22 10:43, Neal Gompa (ngomp...@gmail.com) wrote:
>
> > On Thu, Dec 22, 2022 at 10:39 AM Lennart Poettering
> >  wrote:
> > >
> > > On Do, 22.12.22 05:38, Neal Gompa (ngomp...@gmail.com) wrote:
> > >
> > > > > I understand the big issue you have is that the certificate store for
> > > > > Linux (i.e. the mokutil db) is limited in size because EFI variable
> > > > > NVRAM is limited in size? If that's the big issue you are having then
> > > > > that's absolutely something the Linux community can fix, and can
> > > > > address. Specifically, shim could allow storing the cert store on
> > > > > disk, and authenticate it at boot via the TPM. Not trivial, but
> > > > > doable. And certainly not the firmware's fault...
> > > > >
> > > > > I mean, UEFI has its warts, but I don't see that it's UEFI's fault if
> > > > > the way Linux/shim/mokutil implement the cert db is done the way it is
> > > > > currently done.
> > > >
> > > > Frankly, I'm aggravated by the increased reliance on UEFI features
> > > > without fixing Linux's problems with UEFI features. If we stopped
> > > > relying on UEFI for the cert store, a lot of my issues would go away,
> > > > because then we can design better workflows for managing
> > > > certificates.
> > >
> > > Well, the thing is: a chain of trust is a *chain*, hence you must
> > > ultimately hook validation to what the firmware provides you with as
> > > root. And that ultimately is the SecureBoot db on commodity hardware.
> > >
> > > If I buy a boring laptop at a store it will come with a UEFI cert
> > > store, and nothing else. Linux cannot really ignore that. If it did,
> > > then you'd not have a trusted boot chain, hence the whole excercsie
> > > would be pointless.
> > >
> >
> > Shim trusts MS and the main distro cert, grub is trusted from there,
> > then the OS trusts those and anything else the admin adds. That's how
> > It should work. Trust chains are sensible as long as they're
> > extensible.
>
> Hmm, that chain is partly backwards? it's the firmware that has to
> trust the msft cert which trusts shim, which trusts the distro cert,
> which trusts grub and the kernel. The thing that comes first
> at boot must trust the next, otherwise we'd have to boot into
> untrusted stuff first, which really misses the point? not grokking
> what you are trying tosay?
>

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.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

[Lennart Poettering]

On Do, 22.12.22 10:52, Neal Gompa (ngomp...@gmail.com) wrote:
65;6800;1c
> > BTW, you keep talking of "these" problems, and are extremely vague
> > about those. I think I understood that you hit the NVRAM size limits
> > before, by enrolling private certs?
>
> Yes. Specifically for dealing with the NVIDIA driver, backports of
> Intel network card drivers, OpenZFS, ELRepo modules, etc.
>
> > What are those issues precisely? Did you file bugs? How many certs did
> > you try to enroll? Or did you try to enroll hashes? Were was this
> > dicussed?
>
> Anywhere between 1 to 3 UEFI certs, representing different vendors
> (machine-local, ELRepo, and OpenZFS).

OK, so what's left is exactly one issue you had: you tried to enroll 3
UEFI certs via mokutil and what exactly happened then? machine
bricked how precisely?

link for a bug report?

Please be specific, otherwise noone will be able to help you!

Lennart

--
Lennart Poettering, Berlin
___
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)

[Jiri Konecny]

Hi all,

Dne 20. 12. 22 v 16:22 Ben Cotton napsal(a):

https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1

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 ==
Add support for unified kernels images to Fedora.



== Feedback ==


== Benefit to Fedora ==
* Better secure boot support (specifically the initrd is covered by
the signature).
* Better confidential computing support (measurements are much more
useful if we know what hashes to expect for the initrd).
* More robust boot process (generating the initrd on the installed
system is fragile, root cause for kernel bugs reported is simply a
broken initrd sometimes).
Just want to add Anaconda installation environment is also fighting with 
the second point. Thanks to the PXE boot it's maybe even more fragile 
environment.
It could be pretty hard to find the root cause because it could fine on 
basically anything (mostly XFS modules).


Best Regards,
Jirka
___
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)

[Neal Gompa]

On Thu, Dec 22, 2022 at 10:46 AM Lennart Poettering
 wrote:
>
> On Do, 22.12.22 06:38, Neal Gompa (ngomp...@gmail.com) wrote:
>
> > I have to think about what happens when the cat is out of the bag.
> > What I want is not necessarily a solution to this now, but a
> > commitment that someone will actively work on fixing these problems
> > *before* proposing the next phase and have it ready *before* making
> > any future proposals on UKIs. If you can't do that, I can't in good
> > faith consider incrementally supporting UKIs, because there's
> > effectively no plan to make them work as a future default way of
> > shipping the Linux kernel.
>
> BTW, you keep talking of "these" problems, and are extremely vague
> about those. I think I understood that you hit the NVRAM size limits
> before, by enrolling private certs?
>

Yes. Specifically for dealing with the NVIDIA driver, backports of
Intel network card drivers, OpenZFS, ELRepo modules, etc.

> What are those issues precisely? Did you file bugs? How many certs did
> you try to enroll? Or did you try to enroll hashes? Were was this
> dicussed?
>

Anywhere between 1 to 3 UEFI certs, representing different vendors
(machine-local, ELRepo, and OpenZFS).

> Without any of that the vagueness just constitutes FUD... Hence,
> please be more specific!
>

You know better than that. Stop it.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

[Lennart Poettering]

On Do, 22.12.22 10:43, Neal Gompa (ngomp...@gmail.com) wrote:

> On Thu, Dec 22, 2022 at 10:39 AM Lennart Poettering
>  wrote:
> >
> > On Do, 22.12.22 05:38, Neal Gompa (ngomp...@gmail.com) wrote:
> >
> > > > I understand the big issue you have is that the certificate store for
> > > > Linux (i.e. the mokutil db) is limited in size because EFI variable
> > > > NVRAM is limited in size? If that's the big issue you are having then
> > > > that's absolutely something the Linux community can fix, and can
> > > > address. Specifically, shim could allow storing the cert store on
> > > > disk, and authenticate it at boot via the TPM. Not trivial, but
> > > > doable. And certainly not the firmware's fault...
> > > >
> > > > I mean, UEFI has its warts, but I don't see that it's UEFI's fault if
> > > > the way Linux/shim/mokutil implement the cert db is done the way it is
> > > > currently done.
> > >
> > > Frankly, I'm aggravated by the increased reliance on UEFI features
> > > without fixing Linux's problems with UEFI features. If we stopped
> > > relying on UEFI for the cert store, a lot of my issues would go away,
> > > because then we can design better workflows for managing
> > > certificates.
> >
> > Well, the thing is: a chain of trust is a *chain*, hence you must
> > ultimately hook validation to what the firmware provides you with as
> > root. And that ultimately is the SecureBoot db on commodity hardware.
> >
> > If I buy a boring laptop at a store it will come with a UEFI cert
> > store, and nothing else. Linux cannot really ignore that. If it did,
> > then you'd not have a trusted boot chain, hence the whole excercsie
> > would be pointless.
> >
>
> Shim trusts MS and the main distro cert, grub is trusted from there,
> then the OS trusts those and anything else the admin adds. That's how
> It should work. Trust chains are sensible as long as they're
> extensible.

Hmm, that chain is partly backwards? it's the firmware that has to
trust the msft cert which trusts shim, which trusts the distro cert,
which trusts grub and the kernel. The thing that comes first
at boot must trust the next, otherwise we'd have to boot into
untrusted stuff first, which really misses the point? not grokking
what you are trying tosay?

> > > You *need* to think about these problems when designing this stuff.
> > > You can't take a myopic x86-only view to this. I have not heard of
> > > anything about UKI security for non-x86 because it seems to all be
> > > tied up in UEFI stuff.
> >
> > I work for a company that is working on ARM UEFI systems booting UKIs
> > in massive scale.
>
> One company is one company. It's not a variety of people and users.
> Scale means nothing if it's not distributed.

Well, you said you have not "heard" of anyone doing UKI security on
non-x86. Now you have.

Lennart

--
Lennart Poettering, Berlin
___
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)

[Lennart Poettering]

On Do, 22.12.22 06:38, Neal Gompa (ngomp...@gmail.com) wrote:

> I have to think about what happens when the cat is out of the bag.
> What I want is not necessarily a solution to this now, but a
> commitment that someone will actively work on fixing these problems
> *before* proposing the next phase and have it ready *before* making
> any future proposals on UKIs. If you can't do that, I can't in good
> faith consider incrementally supporting UKIs, because there's
> effectively no plan to make them work as a future default way of
> shipping the Linux kernel.

BTW, you keep talking of "these" problems, and are extremely vague
about those. I think I understood that you hit the NVRAM size limits
before, by enrolling private certs?

What are those issues precisely? Did you file bugs? How many certs did
you try to enroll? Or did you try to enroll hashes? Were was this
dicussed?

Without any of that the vagueness just constitutes FUD... Hence,
please be more specific!

Lennart

--
Lennart Poettering, Berlin
___
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)

[Neal Gompa]

On Thu, Dec 22, 2022 at 10:39 AM Lennart Poettering
 wrote:
>
> On Do, 22.12.22 05:38, Neal Gompa (ngomp...@gmail.com) wrote:
>
> > > I understand the big issue you have is that the certificate store for
> > > Linux (i.e. the mokutil db) is limited in size because EFI variable
> > > NVRAM is limited in size? If that's the big issue you are having then
> > > that's absolutely something the Linux community can fix, and can
> > > address. Specifically, shim could allow storing the cert store on
> > > disk, and authenticate it at boot via the TPM. Not trivial, but
> > > doable. And certainly not the firmware's fault...
> > >
> > > I mean, UEFI has its warts, but I don't see that it's UEFI's fault if
> > > the way Linux/shim/mokutil implement the cert db is done the way it is
> > > currently done.
> >
> > Frankly, I'm aggravated by the increased reliance on UEFI features
> > without fixing Linux's problems with UEFI features. If we stopped
> > relying on UEFI for the cert store, a lot of my issues would go away,
> > because then we can design better workflows for managing
> > certificates.
>
> Well, the thing is: a chain of trust is a *chain*, hence you must
> ultimately hook validation to what the firmware provides you with as
> root. And that ultimately is the SecureBoot db on commodity hardware.
>
> If I buy a boring laptop at a store it will come with a UEFI cert
> store, and nothing else. Linux cannot really ignore that. If it did,
> then you'd not have a trusted boot chain, hence the whole excercsie
> would be pointless.
>

Shim trusts MS and the main distro cert, grub is trusted from there,
then the OS trusts those and anything else the admin adds. That's how
It should work. Trust chains are sensible as long as they're extensible.

In a perfect world, they would work properly at the lowest levels, but
between commercial and community malpractice, they don't.

> > It makes automation possible, it makes management possible, and it
> > opens the doors to experiment with how to do layered images for boot
> > (e.g. UKIs + system extension images) without bricking people's
> > computers.
>
> As mentioned before: note that the Fedora signing keys are only built
> into shim and the kernel, not stored in NVRAM.
>
> But anyway, I think it would be great if shim could manage a cert
> store on disk, I already said that. But that's truly orthogonal to
> UKIs and sysext really. You keep trying to change topics away from
> UKI/sysext towards your general discontent with UEFI.
>
> > That also has the side effect of us having half a chance of being able
> > to port this security capability to non-UEFI platforms where we use
> > fake UEFI implementations to bootstrap our boot process, because the
> > amount of coverage required for fake UEFI implementations is
> > considerably lower now.
> >
> > More generally, relying on UEFI-specific security features when most
> > platforms are not being brought up with UEFI is foolish. ARM is almost
> > entirely non-UEFI (except the tiny proportion of servers that almost
> > no one has) and RISC-V is not a UEFI platform either. POWER uses
> > OpenFirmware instead of UEFI, and IBM Z does something else entirely
> > different.
>
> Well, "foolish", eyh?
>
> The thing is that chain of trust works quite differently on each such
> system (if it exists at all). UEFI is a standardizing and unifying
> force that simplifies things greatly, since while not universal it's
> still the most widely adopted mechanism (and one of the more
> advanced).
>
> Generally, I am very sure we should focus on making the more limited
> stuff work like the modern stuff, and not the other way round. For
> example, there has already been work on making UKIs boot on grub/MBR,
> as mentioned, which is exactly how I think it should be done: move the
> old/legacy/simple stuff work more like the
> new/modern/featureful/standardized stuff, rather than the other way
> round.
>
> > You *need* to think about these problems when designing this stuff.
> > You can't take a myopic x86-only view to this. I have not heard of
> > anything about UKI security for non-x86 because it seems to all be
> > tied up in UEFI stuff.
>
> I work for a company that is working on ARM UEFI systems booting UKIs
> in massive scale.
>

One company is one company. It's not a variety of people and users.
Scale means nothing if it's not distributed.




--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

[Neal Gompa]

On Thu, Dec 22, 2022 at 10:35 AM Gerd Hoffmann  wrote:
>
>   Hi,
>
> > Hmm, the updated Change is mostly okay. I disagree that you have any
> > real security benefits since all the Secure Boot stuff in Linux is
> > still in a bad place.
>
> It's a step into the right direction, but I agree, it alone doesn't
> improve the situation much.  I think we need to overthink the whole
> secure boot signing process in Fedora.  For starters we need to use
> different signing keys for UKI and non-UKI kernels, so it is possible
> (for the user if he chooses so) to disable booting non-UKI kernels to
> really plug the unsigned initrd hole.
>
> shim project planning to move from compiled-in certificates to signed
> certificates in separate files should make it easier to manage this.
>

As part of this, we *really* need to make the process for managing
supported/enabled certificates reasonable and independent of the
firmware restrictions.

> But all that is probably worth a separate change proposal and a separate
> discussion.
>
> > I would like the Change document to be updated
> > to include feedback about Secure Boot in there to further justify how
> > restricted the scope will remain for Phase 1.
> >
> > Additionally, "discoverable partitions" fixes nothing for Fedora right
> > now. There are two problems here:
> > * We don't have a discoverable subvolume specification for Btrfs
> > * Discoverable partition specification falls over dead with snapshots.
> >
> > Don't plan on using systemd-boot. I've said why before in other
> > threads, so I'm not repeating it again.
> >
> > Drop locking out modified kernel command lines. That's pretty much a
> > non-starter.
> >
> > If you want to pursue a Fedora Cloud image with UKIs, please bring it
> > up with the Cloud SIG, keeping in mind the feedback I listed.
>
> Noted.  I'll rework the Change proposal early next year, I'm almost off
> into my xmas holidays.
>

Makes sense. Have a merry Christmas and a happy new year! :)



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

[Lennart Poettering]

On Do, 22.12.22 05:38, Neal Gompa (ngomp...@gmail.com) wrote:

> > I understand the big issue you have is that the certificate store for
> > Linux (i.e. the mokutil db) is limited in size because EFI variable
> > NVRAM is limited in size? If that's the big issue you are having then
> > that's absolutely something the Linux community can fix, and can
> > address. Specifically, shim could allow storing the cert store on
> > disk, and authenticate it at boot via the TPM. Not trivial, but
> > doable. And certainly not the firmware's fault...
> >
> > I mean, UEFI has its warts, but I don't see that it's UEFI's fault if
> > the way Linux/shim/mokutil implement the cert db is done the way it is
> > currently done.
>
> Frankly, I'm aggravated by the increased reliance on UEFI features
> without fixing Linux's problems with UEFI features. If we stopped
> relying on UEFI for the cert store, a lot of my issues would go away,
> because then we can design better workflows for managing
> certificates.

Well, the thing is: a chain of trust is a *chain*, hence you must
ultimately hook validation to what the firmware provides you with as
root. And that ultimately is the SecureBoot db on commodity hardware.

If I buy a boring laptop at a store it will come with a UEFI cert
store, and nothing else. Linux cannot really ignore that. If it did,
then you'd not have a trusted boot chain, hence the whole excercsie
would be pointless.

> It makes automation possible, it makes management possible, and it
> opens the doors to experiment with how to do layered images for boot
> (e.g. UKIs + system extension images) without bricking people's
> computers.

As mentioned before: note that the Fedora signing keys are only built
into shim and the kernel, not stored in NVRAM.

But anyway, I think it would be great if shim could manage a cert
store on disk, I already said that. But that's truly orthogonal to
UKIs and sysext really. You keep trying to change topics away from
UKI/sysext towards your general discontent with UEFI.

> That also has the side effect of us having half a chance of being able
> to port this security capability to non-UEFI platforms where we use
> fake UEFI implementations to bootstrap our boot process, because the
> amount of coverage required for fake UEFI implementations is
> considerably lower now.
>
> More generally, relying on UEFI-specific security features when most
> platforms are not being brought up with UEFI is foolish. ARM is almost
> entirely non-UEFI (except the tiny proportion of servers that almost
> no one has) and RISC-V is not a UEFI platform either. POWER uses
> OpenFirmware instead of UEFI, and IBM Z does something else entirely
> different.

Well, "foolish", eyh?

The thing is that chain of trust works quite differently on each such
system (if it exists at all). UEFI is a standardizing and unifying
force that simplifies things greatly, since while not universal it's
still the most widely adopted mechanism (and one of the more
advanced).

Generally, I am very sure we should focus on making the more limited
stuff work like the modern stuff, and not the other way round. For
example, there has already been work on making UKIs boot on grub/MBR,
as mentioned, which is exactly how I think it should be done: move the
old/legacy/simple stuff work more like the
new/modern/featureful/standardized stuff, rather than the other way
round.

> You *need* to think about these problems when designing this stuff.
> You can't take a myopic x86-only view to this. I have not heard of
> anything about UKI security for non-x86 because it seems to all be
> tied up in UEFI stuff.

I work for a company that is working on ARM UEFI systems booting UKIs
in massive scale.

Lennart

--
Lennart Poettering, Berlin
___
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)

[Gerd Hoffmann]

  Hi,

> Hmm, the updated Change is mostly okay. I disagree that you have any
> real security benefits since all the Secure Boot stuff in Linux is
> still in a bad place.

It's a step into the right direction, but I agree, it alone doesn't
improve the situation much.  I think we need to overthink the whole
secure boot signing process in Fedora.  For starters we need to use
different signing keys for UKI and non-UKI kernels, so it is possible
(for the user if he chooses so) to disable booting non-UKI kernels to
really plug the unsigned initrd hole.

shim project planning to move from compiled-in certificates to signed
certificates in separate files should make it easier to manage this.

But all that is probably worth a separate change proposal and a separate
discussion.

> I would like the Change document to be updated
> to include feedback about Secure Boot in there to further justify how
> restricted the scope will remain for Phase 1.
> 
> Additionally, "discoverable partitions" fixes nothing for Fedora right
> now. There are two problems here:
> * We don't have a discoverable subvolume specification for Btrfs
> * Discoverable partition specification falls over dead with snapshots.
> 
> Don't plan on using systemd-boot. I've said why before in other
> threads, so I'm not repeating it again.
> 
> Drop locking out modified kernel command lines. That's pretty much a
> non-starter.
> 
> If you want to pursue a Fedora Cloud image with UKIs, please bring it
> up with the Cloud SIG, keeping in mind the feedback I listed.

Noted.  I'll rework the Change proposal early next year, I'm almost off
into my xmas holidays.

take care,
  Gerd
___
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)

[Elizabeth K. Joseph]

> 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? 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.
___
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)

[Lennart Poettering]

On Do, 22.12.22 14:49, Daniel P. Berrangé (berra...@redhat.com) wrote:

> When you say it dooesn't get the offsets right, can you elaborate ?

dracut uses fixed offsets for the sections to be placed in memory
in. The values are simply hardcoded, literally specified address
offsets, that worked for the original authors. This typically works –
as long as your sections are not much larger than they were for the
people wo came up with these offsets initially. But as it turns out
this doesn't work for some cases. In such cases the sections will be
loaded into memory overlapped and bad things happen.

ukify hence calculates the offsets manually (by adding up the section
sizes so that this cannot happen.

Lennart

--
Lennart Poettering, Berlin
___
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)

[Daniel P . Berrangé]

On Thu, Dec 22, 2022 at 10:58:11AM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Dec 21, 2022 at 06:56:05PM +0100, Björn Persson wrote:
> > Gerd Hoffmann wrote:
> > > On Tue, Dec 20, 2022 at 04:31:20PM -0500, Simo Sorce wrote:
> > > > And if you chose your HW carefully you may even be able to register
> > > > your own public keys, generate and sign your own built UKIs and re-
> > > > enable SecureBoot after that... your choice!  
> > > 
> > > And when your hardware doesn't allow that you can still add your own
> > > keys with mokutil so shim.efi will accept your self-signed UKIs.
> > 
> > I'll see when I can take the time for a research project to figure out
> > how customized UKIs can be produced, and develop a tool to do that.
> > Probably never, because I have way too much to do already.
> > 
> > Apparently there is no such tool and no plan to provide one, because
> > surely that would have been mentioned under "User Experience".
> 
> The tools are already there. Essentially, any tool used in koji by the 
> official
> builds is also available to you on your machine.
> 
> There are at three ways that are used: 'dracut --uefi', systemd's ukify, and a
> manual objcopy invocation. The first two are wrappers around objcopy. I'm 
> biased
> because I wrote 'ukify', but I think that's the way to go. What dracut does is
> somewhat primitive and doesn't get the offsets right. Obviously it could be
> improved, but putting the code to generate UKIs inside of an initrd generator 
> is
> a historical accident, and bash is not the nicest language to do offset
> calculations. Thus I hope we can standarize on ukify instead.

When you say it dooesn't get the offsets right, can you elaborate ?
We've been using dracut --uefi to build the UKIs in koji and they
appear to work as expected. Are the offsets only incorrect in
certain circumstances.

We're pretty ambivalent about choice of tool though. We just picked
dracut as it was the first we came across and appeared to work. Any
other tool is viable as then should all (generally) end up doing the
same thing, whichever is most maintainable sounds good.

I can't  argue with Python being better than shell, so ukify certain
wins on that score :-)


> In particular, if some functionality is missing from ukify, feel free to 
> submit
> a PR or an issue. It's in Python, so fairly nice to modify. So far it's been
> written to take a kernel and an initrd and the stub, and produce an efi 
> binary.

Currently we just ask dracut to create the UKI and it creates
the intird as part of that process. If using ukify, we would
ask dracut to create the initrd, and then ask ukify to build
that into a UKI. Its more work, but if ukify does a better
job at the UKI bits that's fine, especially if we'd be suggesting
use of ukify for users in general.


With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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: Unannounced SONAME bump: wxGTK

[Richard Shaw]

On Thu, Dec 22, 2022 at 8:17 AM Scott Talbert  wrote:

> On Thu, 22 Dec 2022, Ian McInerney via devel wrote:
>
> >
> >
> > On Thu, Dec 22, 2022 at 1:55 PM Richard Shaw 
> wrote:
> >   I just had a chance to check out a bug[1] recently submitted
> >   against trustedqsl and it appears that a new version of wxGTK
> >   with a SONAME bump was built  for f37+ but not all dependencies
> >   rebuilt.
> >
> >
> > This was announced back in July while F37 was still Rawhide:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> >
> /thread/PD3EWAYG6HGKSWU5T337AXU4ONSK53VZ/#LYLHTVJQMLOWFFRB25MVM4S4726KPWMR
> >
> >
> > And looking at the commit history for the F37 branch of trustedqsl, it
> has a
> > commit referencing the wxGTK 3.2 version bump:
> > https://src.fedoraproject.org/rpms/trustedqsl/commits/f37, and that was
> > before the update you did to version 2.6.4. The build for 2.6.4 on F37(
> https://kojipkgs.fedoraproject.org//packages/trustedqsl/2.6.4/1.fc37/data/
> > logs/x86_64/build.log) also seems to have pulled the wxWidgets 3.2 dep
> > correctly, with CMake reporting:
> >
> > Found wxWidgets:
> -pthread;;;-lwx_gtk3u_core-3.2;-lwx_baseu-3.2;-lwx_gtk3u_ht
> > ml-3.2 (found version "3.2.0")
> > and the RPM dependency generator showing
> >
> > libwx_baseu-3.2.so.0()(64bit) libwx_baseu-3.2.so.0(WXU_3.2)(64bit)
> libwx_gtk
> > 3u_core-3.2.so.0()(64bit) libwx_gtk3u_core-3.2.so.0(WXU_3.2)(64bit)
> libwx_gt
> > k3u_html-3.2.so.0()(64bit) libwx_gtk3u_html-3.2.so.0(WXU_3.2)(64bit)
> >
> > I am therefore very confused how the user could have 2.6.4 with a 3.1.5
> > dependency when the koji build for 2.6.4-1 shows wxGTK 3.2 in the
> buildroot
> > and as a dependency.
>
> Agreed ^^^
>

Ok, just weird then ¯\_(ツ)_/¯

Committed but never built somehow? I don't see the rebuild attempt:

https://koji.fedoraproject.org/koji/packageinfo?packageID=6950

Thanks,
Richard
___
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: Unannounced SONAME bump: wxGTK

[Scott Talbert]

On Thu, 22 Dec 2022, Ian McInerney via devel wrote:




On Thu, Dec 22, 2022 at 1:55 PM Richard Shaw  wrote:
  I just had a chance to check out a bug[1] recently submitted
  against trustedqsl and it appears that a new version of wxGTK
  with a SONAME bump was built  for f37+ but not all dependencies
  rebuilt.


This was announced back in July while F37 was still 
Rawhide:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
/thread/PD3EWAYG6HGKSWU5T337AXU4ONSK53VZ/#LYLHTVJQMLOWFFRB25MVM4S4726KPWMR


And looking at the commit history for the F37 branch of trustedqsl, it has a
commit referencing the wxGTK 3.2 version bump:
https://src.fedoraproject.org/rpms/trustedqsl/commits/f37, and that was
before the update you did to version 2.6.4. The build for 2.6.4 on 
F37(https://kojipkgs.fedoraproject.org//packages/trustedqsl/2.6.4/1.fc37/data/
logs/x86_64/build.log) also seems to have pulled the wxWidgets 3.2 dep
correctly, with CMake reporting:

Found wxWidgets: -pthread;;;-lwx_gtk3u_core-3.2;-lwx_baseu-3.2;-lwx_gtk3u_ht
ml-3.2 (found version "3.2.0") 
and the RPM dependency generator showing


libwx_baseu-3.2.so.0()(64bit) libwx_baseu-3.2.so.0(WXU_3.2)(64bit) libwx_gtk
3u_core-3.2.so.0()(64bit) libwx_gtk3u_core-3.2.so.0(WXU_3.2)(64bit) libwx_gt
k3u_html-3.2.so.0()(64bit) libwx_gtk3u_html-3.2.so.0(WXU_3.2)(64bit)
 
I am therefore very confused how the user could have 2.6.4 with a 3.1.5
dependency when the koji build for 2.6.4-1 shows wxGTK 3.2 in the buildroot
and as a dependency.


Agreed ^^^

Scott___
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: Unannounced SONAME bump: wxGTK

[Scott Talbert]

On Thu, 22 Dec 2022, Richard Shaw wrote:


I just had a chance to check out a bug[1] recently submitted against
trustedqsl and it appears that a new version of wxGTK with a SONAME bump was
built  for f37+ but not all dependencies rebuilt.
I'm not too worried about trustedqsl since I'm about to take care of the
build but it does have a long dependency list and I'm unsure whether the
other builds have been completed:

0ad
4Pane
audacity
boinc-client
CubicSDR
diff-pdf
erlang
extrema
fityk
flamerobin
freedink-dfarc
freedv
fwknop-gui
gnuplot
guayadeque
hugin
iaxclient
kicad
mathgl
mediainfo
mrpt
openbabel
openmsx
OpenSceneGraph
p7zip
panoglview
pcem
phd2
plplot
poedit
python-wxpython4
rapidsvn
saga
scorched3d
scummvm-tools
sooperlooper
spatialite-gui
springlobby
trustedqsl
ucblogo
vavoom
visualboyadvance-m
wxmacmolplt
wxsqlite3
xchm
xmlcopyeditor
xylib

Thanks,
Richard

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2154622


Nope, this SONAME bump was definitely announced, see:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/PD3EWAYG6HGKSWU5T337AXU4ONSK53VZ/

trustedqsl did not depend on wxGTK at the time, but was moved over later.

I'm also not able to reproduce the issue that the user reported in that 
bug.  tsql launches fine for me on F37.


Scott___
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: Unannounced SONAME bump: wxGTK

[Ian McInerney via devel]

On Thu, Dec 22, 2022 at 1:55 PM Richard Shaw  wrote:

> I just had a chance to check out a bug[1] recently submitted against
> trustedqsl and it appears that a new version of wxGTK with a SONAME bump
> was built  for f37+ but not all dependencies rebuilt.
>
>
This was announced back in July while F37 was still Rawhide:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/PD3EWAYG6HGKSWU5T337AXU4ONSK53VZ/#LYLHTVJQMLOWFFRB25MVM4S4726KPWMR

And looking at the commit history for the F37 branch of trustedqsl, it has
a commit referencing the wxGTK 3.2 version bump:
https://src.fedoraproject.org/rpms/trustedqsl/commits/f37, and that was
before the update you did to version 2.6.4. The build for 2.6.4 on F37 (
https://kojipkgs.fedoraproject.org//packages/trustedqsl/2.6.4/1.fc37/data/logs/x86_64/build.log)
also seems to have pulled the wxWidgets 3.2 dep correctly, with CMake
reporting:

Found wxWidgets:
-pthread;;;-lwx_gtk3u_core-3.2;-lwx_baseu-3.2;-lwx_gtk3u_html-3.2
(found version "3.2.0")

and the RPM dependency generator showing

libwx_baseu-3.2.so.0()(64bit) libwx_baseu-3.2.so.0(WXU_3.2)(64bit)
libwx_gtk3u_core-3.2.so.0()(64bit)
libwx_gtk3u_core-3.2.so.0(WXU_3.2)(64bit)
libwx_gtk3u_html-3.2.so.0()(64bit)
libwx_gtk3u_html-3.2.so.0(WXU_3.2)(64bit)


I am therefore very confused how the user could have 2.6.4 with a 3.1.5
dependency when the koji build for 2.6.4-1 shows wxGTK 3.2 in the buildroot
and as a dependency.

-Ian

I'm not too worried about trustedqsl since I'm about to take care of the
> build but it does have a long dependency list and I'm unsure whether the
> other builds have been completed:
>
> 0ad
> 4Pane
> audacity
> boinc-client
> CubicSDR
> diff-pdf
> erlang
> extrema
> fityk
> flamerobin
> freedink-dfarc
> freedv
> fwknop-gui
> gnuplot
> guayadeque
> hugin
> iaxclient
> kicad
> mathgl
> mediainfo
> mrpt
> openbabel
> openmsx
> OpenSceneGraph
> p7zip
> panoglview
> pcem
> phd2
> plplot
> poedit
> python-wxpython4
> rapidsvn
> saga
> scorched3d
> scummvm-tools
> sooperlooper
> spatialite-gui
> springlobby
> trustedqsl
> ucblogo
> vavoom
> visualboyadvance-m
> wxmacmolplt
> wxsqlite3
> xchm
> xmlcopyeditor
> xylib
>
> Thanks,
> Richard
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=2154622
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Unannounced SONAME bump: wxGTK

[Richard Shaw]

I just had a chance to check out a bug[1] recently submitted against
trustedqsl and it appears that a new version of wxGTK with a SONAME bump
was built  for f37+ but not all dependencies rebuilt.

I'm not too worried about trustedqsl since I'm about to take care of the
build but it does have a long dependency list and I'm unsure whether the
other builds have been completed:

0ad
4Pane
audacity
boinc-client
CubicSDR
diff-pdf
erlang
extrema
fityk
flamerobin
freedink-dfarc
freedv
fwknop-gui
gnuplot
guayadeque
hugin
iaxclient
kicad
mathgl
mediainfo
mrpt
openbabel
openmsx
OpenSceneGraph
p7zip
panoglview
pcem
phd2
plplot
poedit
python-wxpython4
rapidsvn
saga
scorched3d
scummvm-tools
sooperlooper
spatialite-gui
springlobby
trustedqsl
ucblogo
vavoom
visualboyadvance-m
wxmacmolplt
wxsqlite3
xchm
xmlcopyeditor
xylib

Thanks,
Richard

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2154622
___
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)

[Neal Gompa]

On Thu, Dec 22, 2022 at 7:32 AM Gerd Hoffmann  wrote:
>
>   Hi,
>
> > > If something is proposed for bare metal in the future, then raise
> > > the problems at that point. It is unreasonable to demand that we
> > > fix problems for a use case that is not in scope for what is being
> > > proposed.  Anything related to bare metal was explicitly out of
> > > scope, precisely because it will massively increase the complexity
> > > of what needs to be addressed, making the task infeasible. We need
> > > an incremental path where we can tackle individual practical tasks
> > > rather than trying to solve everything in one go.
> >
> > Yeah, and what happens when it gets punted again when that happens? I
> > do not think it's unreasonable to bring these objections up front when
> > this is clearly marked as a "phase 1" Change that implies UKIs will be
> > used in more and more scenarios over time.
>
> I want UKIs becoming an option in more and more use cases.  I don't
> expect non-UKIs disappearing anytime soon though.  From the updated
> Change page:
>
> 
> long term plan:
> Phase 1: Get the basic building blocks into place, so it is possible
>  to work with and develop for UKIs in virtual machines.
> Phase 2+: Expand UKI support, tackling the use cases which depend on
>   a host-specific initrd or command line (see below) one by one.
> Phase X: Once UKIs have feature parity with non-UKI kernels discuss
>  whenever they should be used by default everywhere (specific
>  use cases like cloud images might switch earlier).
> NOT planed: remove support for non-UKI kernels.
> 
>
> I think at the end of the day this will be somewhat simliar to the Xorg
> -> Wayland transition.  First get basic support there, so it is possible
> to try out stuff, figure what works, figure what needs changes etc.
> Then a (probably long) phase adapting software, fixing bugs found etc,
> making more more use cases being able to work with the new stuff.
> Then at some point eventually flip the default.
>
> One notable difference is that with UKIs there isn't something simliar
> to Xwayland, so flipping the default requires really everything being
> able to work with UKIs.  And flipping the default can only happen for
> new installs, I don't think trying to migrate existing installs to UKIs
> automatically is a sane idea.
>

Hmm, the updated Change is mostly okay. I disagree that you have any
real security benefits since all the Secure Boot stuff in Linux is
still in a bad place. I would like the Change document to be updated
to include feedback about Secure Boot in there to further justify how
restricted the scope will remain for Phase 1.

Additionally, "discoverable partitions" fixes nothing for Fedora right
now. There are two problems here:
* We don't have a discoverable subvolume specification for Btrfs
* Discoverable partition specification falls over dead with snapshots.

Don't plan on using systemd-boot. I've said why before in other
threads, so I'm not repeating it again.

Drop locking out modified kernel command lines. That's pretty much a
non-starter.

If you want to pursue a Fedora Cloud image with UKIs, please bring it
up with the Cloud SIG, keeping in mind the feedback I listed.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

[Gerd Hoffmann]

  Hi,

> > If something is proposed for bare metal in the future, then raise
> > the problems at that point. It is unreasonable to demand that we
> > fix problems for a use case that is not in scope for what is being
> > proposed.  Anything related to bare metal was explicitly out of
> > scope, precisely because it will massively increase the complexity
> > of what needs to be addressed, making the task infeasible. We need
> > an incremental path where we can tackle individual practical tasks
> > rather than trying to solve everything in one go.
> 
> Yeah, and what happens when it gets punted again when that happens? I
> do not think it's unreasonable to bring these objections up front when
> this is clearly marked as a "phase 1" Change that implies UKIs will be
> used in more and more scenarios over time.

I want UKIs becoming an option in more and more use cases.  I don't
expect non-UKIs disappearing anytime soon though.  From the updated
Change page:


long term plan:
Phase 1: Get the basic building blocks into place, so it is possible
 to work with and develop for UKIs in virtual machines.
Phase 2+: Expand UKI support, tackling the use cases which depend on
  a host-specific initrd or command line (see below) one by one.
Phase X: Once UKIs have feature parity with non-UKI kernels discuss
 whenever they should be used by default everywhere (specific
 use cases like cloud images might switch earlier).
NOT planed: remove support for non-UKI kernels.


I think at the end of the day this will be somewhat simliar to the Xorg
-> Wayland transition.  First get basic support there, so it is possible
to try out stuff, figure what works, figure what needs changes etc.
Then a (probably long) phase adapting software, fixing bugs found etc,
making more more use cases being able to work with the new stuff.
Then at some point eventually flip the default.

One notable difference is that with UKIs there isn't something simliar
to Xwayland, so flipping the default requires really everything being
able to work with UKIs.  And flipping the default can only happen for
new installs, I don't think trying to migrate existing installs to UKIs
automatically is a sane idea.

take care,
  Gerd
___
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)

[Neal Gompa]

On Thu, Dec 22, 2022 at 7:07 AM Daniel P. Berrangé  wrote:
>
> On Thu, Dec 22, 2022 at 06:57:07AM -0500, Neal Gompa wrote:
> > On Thu, Dec 22, 2022 at 6:40 AM Daniel P. Berrangé  
> > wrote:
> > >
> > > On Wed, Dec 21, 2022 at 11:56:32AM -0600, Dennis Gilmore via devel wrote:
> > > > In my case, I have Network Manager config files included in my initrd
> > > > and bootargs to bring up the network so that I get automatic disk
> > > > decryption while on my home network, and prompted for a password when
> > > > I am not at home. I think this a reasonable enough use case it should
> > > > be considered in the long term plan. There was an effort many years
> > > > ago that built the initramfs with the kernel, it was abandoned due to
> > > > not being able to guarantee sources for the binaries in the initramfs,
> > > > trying to dig up the details I am having trouble finding it, but legal
> > > > blocked it there is a reference to it in an old FESCo meeting
> > > > https://lists.fedoraproject.org/pipermail/devel/2013-February/178220.html.
> > >
> > > I can't see any legal problem with source provision for the
> > > binaries inside the initramfs. We're building the initrds and
> > > UKIs inside koji, so we have a clear record of exactly what
> > > binary RPMs went into the package, and thus have knowledge
> > > of what sources are involved. This is the same situation we
> > > already have in Fedora with libguestfs, where we're building
> > > a disk image inside Koji bundling various binaries. Or for
> > > that matter, not really different from building cloud disk
> > > images, or any other deliverable that bundles together some
> > > binaries from other RPMs and spits out some kind of image
> > > or archive.
> > >
> > > > Additionally, we should also consider
> > > > https://fedoraproject.org/wiki/Features/DracutHostOnly and the size
> > > > implications and why we moved to have kernel-core, kernel-modules, and
> > > > kernel-modules-extra for cloud and different use cases.
> > >
> > > The UKI size for a VM should not be appreciably different from the
> > > combination of the vmluinuz + locally generated initrd. The UKI
> > > will contain a few more modules, as its initrd is built to cope
> > > with Xen, VMware, HyperV + KVM[1], but this only adds a small amount
> > > over a truly minimal initrd targetting 1 hypervisor. So I don't
> > > expect the size of the UKI will be a problem.
> > >
> >
> > You need to add VirtualBox too. That's an incredibly common platform
> > for Fedora to run as a guest.
>
> That's easy enough, what kmod is typically required for disks in
> VirtualBox ?
>

I'm not sure as I don't use VirtualBox myself, but Hans de Geode would
know, since he upstreamed the guest additions some time ago...


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

[Daniel P . Berrangé]

On Thu, Dec 22, 2022 at 06:57:07AM -0500, Neal Gompa wrote:
> On Thu, Dec 22, 2022 at 6:40 AM Daniel P. Berrangé  
> wrote:
> >
> > On Wed, Dec 21, 2022 at 11:56:32AM -0600, Dennis Gilmore via devel wrote:
> > > In my case, I have Network Manager config files included in my initrd
> > > and bootargs to bring up the network so that I get automatic disk
> > > decryption while on my home network, and prompted for a password when
> > > I am not at home. I think this a reasonable enough use case it should
> > > be considered in the long term plan. There was an effort many years
> > > ago that built the initramfs with the kernel, it was abandoned due to
> > > not being able to guarantee sources for the binaries in the initramfs,
> > > trying to dig up the details I am having trouble finding it, but legal
> > > blocked it there is a reference to it in an old FESCo meeting
> > > https://lists.fedoraproject.org/pipermail/devel/2013-February/178220.html.
> >
> > I can't see any legal problem with source provision for the
> > binaries inside the initramfs. We're building the initrds and
> > UKIs inside koji, so we have a clear record of exactly what
> > binary RPMs went into the package, and thus have knowledge
> > of what sources are involved. This is the same situation we
> > already have in Fedora with libguestfs, where we're building
> > a disk image inside Koji bundling various binaries. Or for
> > that matter, not really different from building cloud disk
> > images, or any other deliverable that bundles together some
> > binaries from other RPMs and spits out some kind of image
> > or archive.
> >
> > > Additionally, we should also consider
> > > https://fedoraproject.org/wiki/Features/DracutHostOnly and the size
> > > implications and why we moved to have kernel-core, kernel-modules, and
> > > kernel-modules-extra for cloud and different use cases.
> >
> > The UKI size for a VM should not be appreciably different from the
> > combination of the vmluinuz + locally generated initrd. The UKI
> > will contain a few more modules, as its initrd is built to cope
> > with Xen, VMware, HyperV + KVM[1], but this only adds a small amount
> > over a truly minimal initrd targetting 1 hypervisor. So I don't
> > expect the size of the UKI will be a problem.
> >
> 
> You need to add VirtualBox too. That's an incredibly common platform
> for Fedora to run as a guest.

That's easy enough, what kmod is typically required for disks in
VirtualBox ?

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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)

[Gerd Hoffmann]

  Hi,

> > I mean, UEFI has its warts, but I don't see that it's UEFI's fault if
> > the way Linux/shim/mokutil implement the cert db is done the way it is
> > currently done.

Well, UEFI *not* defining some standard way to enroll user certificates
actually is part of the problem.  It is one of reasons why shim+mokutil
exist in the first place.

> Frankly, I'm aggravated by the increased reliance on UEFI features
> without fixing Linux's problems with UEFI features. If we stopped
> relying on UEFI for the cert store, a lot of my issues would go away,
> because then we can design better workflows for managing certificates.

Ignoring the UEFI cert store is just not possible, that is the only one
available and used initially.  For booting the bootloader to have to
work with the capabilities provided by the firmware.  Doing something
simliar for ppc would likewise depend on ppc-specific firmware features.

Once shim is loaded both uefi and shim cert stores are available.
Once the kernel is loaded that expands to uefi + shim + kernel.

> It makes automation possible, it makes management possible, and it
> opens the doors to experiment with how to do layered images for boot
> (e.g. UKIs + system extension images) without bricking people's
> computers.

system extensions are verified after the kernel is loaded, so you are
not limited to the uefi/shim cert stores for them.

> That also has the side effect of us having half a chance of being able
> to port this security capability to non-UEFI platforms where we use
> fake UEFI implementations to bootstrap our boot process, because the
> amount of coverage required for fake UEFI implementations is
> considerably lower now.

Yep.  Because it's a standard.  Having u-boot (assuming this is what you
are referring to) provide standard UEFI protocols, then use standard efi
boot process is much less work because there is only one piece in the
boot process which needs to know the hardware specifics.  Which is
u-boot (playing the firmware role on many SBCs).

> More generally, relying on UEFI-specific security features when most
> platforms are not being brought up with UEFI is foolish. ARM is almost
> entirely non-UEFI (except the tiny proportion of servers that almost
> no one has)

Any aarch64 server I boot in some cloud is UEFI.
aarch64 virtual machines use UEFI.
UEFI implementations exist for RPI 3+4.

> and RISC-V is not a UEFI platform either.

https://github.com/tianocore/edk2-platforms/tree/master/Platform/RISC-V/PlatformPkg

> You *need* to think about these problems when designing this stuff.
> You can't take a myopic x86-only view to this. I have not heard of
> anything about UKI security for non-x86 because it seems to all be
> tied up in UEFI stuff.

Booting UKIs in BIOS mode works with a patched grub (needed for hybrid
bios/uefi cloud images).  Of course that doesn't improve security
because the bios lacks the features needed for that.  You can still get
the other advantages UKIs have like a more robust kernel update process.

ppc uses grub too, so being able to boot UKIs on ppc too should be
doable without too much effort when the platform maintainers think
it is useful.

> > Nah. UKIs + sysext are ultimately something that is simpler and much
> > better to test than the current mess. Yeah, for a while we'll have to
> > add complexity because to mechanisms will have to be supported, but
> > eventually things are going to be simple and easier to test.
> 
> Maybe. It's not super intuitive from where I'm standing, and I know
> how all this stuff works.

Because today fedora doesn't use sysexts and doesn't provide much
tooling.

Ideally the packages which drop some dracut module to
/usr/lib/dracut/modules.d/ today will also drop a sysext to the correct
place in the future.  No manual steps needed.  Users don't even need to
know how this works under the hood.

take care,
  Gerd
___
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)

[Neal Gompa]

On Thu, Dec 22, 2022 at 6:40 AM Daniel P. Berrangé  wrote:
>
> On Wed, Dec 21, 2022 at 11:56:32AM -0600, Dennis Gilmore via devel wrote:
> > In my case, I have Network Manager config files included in my initrd
> > and bootargs to bring up the network so that I get automatic disk
> > decryption while on my home network, and prompted for a password when
> > I am not at home. I think this a reasonable enough use case it should
> > be considered in the long term plan. There was an effort many years
> > ago that built the initramfs with the kernel, it was abandoned due to
> > not being able to guarantee sources for the binaries in the initramfs,
> > trying to dig up the details I am having trouble finding it, but legal
> > blocked it there is a reference to it in an old FESCo meeting
> > https://lists.fedoraproject.org/pipermail/devel/2013-February/178220.html.
>
> I can't see any legal problem with source provision for the
> binaries inside the initramfs. We're building the initrds and
> UKIs inside koji, so we have a clear record of exactly what
> binary RPMs went into the package, and thus have knowledge
> of what sources are involved. This is the same situation we
> already have in Fedora with libguestfs, where we're building
> a disk image inside Koji bundling various binaries. Or for
> that matter, not really different from building cloud disk
> images, or any other deliverable that bundles together some
> binaries from other RPMs and spits out some kind of image
> or archive.
>
> > Additionally, we should also consider
> > https://fedoraproject.org/wiki/Features/DracutHostOnly and the size
> > implications and why we moved to have kernel-core, kernel-modules, and
> > kernel-modules-extra for cloud and different use cases.
>
> The UKI size for a VM should not be appreciably different from the
> combination of the vmluinuz + locally generated initrd. The UKI
> will contain a few more modules, as its initrd is built to cope
> with Xen, VMware, HyperV + KVM[1], but this only adds a small amount
> over a truly minimal initrd targetting 1 hypervisor. So I don't
> expect the size of the UKI will be a problem.
>

You need to add VirtualBox too. That's an incredibly common platform
for Fedora to run as a guest.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

[Daniel P . Berrangé]

On Thu, Dec 22, 2022 at 06:38:56AM -0500, Neal Gompa wrote:
> On Thu, Dec 22, 2022 at 6:29 AM Daniel P. Berrangé  
> wrote:
> >
> > On Thu, Dec 22, 2022 at 05:38:01AM -0500, Neal Gompa wrote:
> > > On Wed, Dec 21, 2022 at 1:56 PM Lennart Poettering  
> > > wrote:
> > > >
> > > > On Di, 20.12.22 17:11, Neal Gompa (ngomp...@gmail.com) wrote:
> > > >
> > > > > > SecureBoot may not be to your liking but is what is installed on 
> > > > > > 99% of
> > > > > > modern hardware sold, so it is a good idea to first show you can
> > > > > > support it. Then if you have interested you can propose "something
> > > > > > better".
> > > > >
> > > > > We have supported Secure Boot for over a decade now. In that 
> > > > > timeframe,
> > > > > literally nobody did anything to make all the workflows you talk about
> > > > > easier and friendlier.
> > > > >
> > > > > In fact, everyone I talk to seems to think it's basically impossible
> > > > > because of how it works at the firmware level.
> > > > >
> > > > > It's telling that neither Windows nor macOS use Secure Boot like Linux
> > > > > does. And they don't precisely for the reasons I outlined.
> > > >
> > > > Yes, Linux never solved the initrd hole so far, but that's not really
> > > > the fault of SecureBoot, it's the fault of Linux if you so
> > > > will. And this proposal is an attempt to finally do something about
> > > > this, and get things in order to actually deliver what the other OSes
> > > > all are delivering.
> > > >
> > > > I understand the big issue you have is that the certificate store for
> > > > Linux (i.e. the mokutil db) is limited in size because EFI variable
> > > > NVRAM is limited in size? If that's the big issue you are having then
> > > > that's absolutely something the Linux community can fix, and can
> > > > address. Specifically, shim could allow storing the cert store on
> > > > disk, and authenticate it at boot via the TPM. Not trivial, but
> > > > doable. And certainly not the firmware's fault...
> > > >
> > > > I mean, UEFI has its warts, but I don't see that it's UEFI's fault if
> > > > the way Linux/shim/mokutil implement the cert db is done the way it is
> > > > currently done.
> > > >
> > >
> > > Frankly, I'm aggravated by the increased reliance on UEFI features
> > > without fixing Linux's problems with UEFI features. If we stopped
> > > relying on UEFI for the cert store, a lot of my issues would go away,
> > > because then we can design better workflows for managing certificates.
> > > It makes automation possible, it makes management possible, and it
> > > opens the doors to experiment with how to do layered images for boot
> > > (e.g. UKIs + system extension images) without bricking people's
> > > computers.
> >
> > So your objections are completely unrelated to the use of UKIs,
> > and should not be a blocker for this feature proposal. You're
> > just asking people to work on other UEFI related problems.
> >
> 
> It is not unreasonable to have to deal with it for VMs either. Having
> custom drivers needed for workloads where hardware passthrough occurs
> is not unusual. While you can kind of handwave graphics, I've seen
> storage and network devices passed in too.

The initrd  in the UKI only needs to provide kmods needed for getting
the rootfs up, once that's available all other kmods are available.
It is reasonable to assume that any passthrough storage is not likely
to be used for the VM rootfs, instead for data volumes.


> > > Just because today it's only about VMs doesn't mean I can't figure out
> > > you want to do more with it down the road. I want to see some
> > > demonstration of someone actually caring about the user experience for
> > > once with the boot stuff.
> >
> > If something is proposed for bare metal in the future, then raise
> > the problems at that point. It is unreasonable to demand that we
> > fix problems for a use case that is not in scope for what is being
> > proposed.  Anything related to bare metal was explicitly out of
> > scope, precisely because it will massively increase the complexity
> > of what needs to be addressed, making the task infeasible. We need
> > an incremental path where we can tackle individual practical tasks
> > rather than trying to solve everything in one go.
> >
> 
> Yeah, and what happens when it gets punted again when that happens? I
> do not think it's unreasonable to bring these objections up front when
> this is clearly marked as a "phase 1" Change that implies UKIs will be
> used in more and more scenarios over time.

The proposal gives an indication of what's expected

> Also, just because *you* intend it for VMs doesn't mean that's what is
> going to happen. Someone is going to do something to try to use that
> UKI in a bare metal deployment, possibly by using sysexts or squashfs
> or god forbid OCI images.

Well people can do all this today, because they can use dracut
to build a UKI and sign it with certs they're enrolled with
shim. That doesn't imply that 

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

[Daniel P . Berrangé]

On Wed, Dec 21, 2022 at 08:39:25PM +0100, Iñaki Ucar wrote:
> From the point of view of the workstation experience (with a laptop),
> I see no discussion on how this may impact hibernation. Currently, I
> have secure boot disabled essentially because I want my laptop to
> automatically hibernate (and recover from that state) whenever it is
> suspended for a number of hours. I would like to see a path forward
> here with secure boot enabled.

This proposal does NOT target bare metal, only virtual machines.
Further, it is not removing any existing functionality related
to split vmlinuz + locally generated initrds, nor is is mandating
the use of SecureBoot. IOW, there is zero impact on laptops and
hibernation, nor impact on people who choose to disable SecureBoot

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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: Scripts to rebuild dependencies in copr

[Gary Buhrmaster]

On Thu, Dec 22, 2022 at 4:46 AM Kevin Fenzi  wrote:
>
> On Wed, Dec 21, 2022 at 09:15:10PM -0700, Orion Poplawski wrote:
> > I've been using an old review_pr.py script produced by the Fedora
> > Stewardship SIG to rebuild the depedencies of a package in COPR to test
> > changes/updates to packages.  It's been incredibly useful.  However, it
> > seems that the github repo has disappeared.
> >
> > Is there anything else out there in use that is actively maintained?
>
> There's the mass pre build project that was recently announced here:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IT347SLVZ6QYNCMYRR3MNB25SJ7W5R3P/
>
> I've not tried it yet, but it's on my list to look at.

I have tried it on a simple package with only a few
dependencies, including a recursive one (for which
I had already manually done all the usual processes
needed to determine dependencies and rebuild so
I already knew how things should be expected to go)
and after a bit of a learning curve using a new tool,
I found it worked rather well, and certainly was less
error prone than doing things the way I had been
doing them (manually) on the occasion I had
needed to do such rebuilds.  The project is certainly
worth a look.
___
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)

[Daniel P . Berrangé]

On Wed, Dec 21, 2022 at 11:56:32AM -0600, Dennis Gilmore via devel wrote:
> In my case, I have Network Manager config files included in my initrd
> and bootargs to bring up the network so that I get automatic disk
> decryption while on my home network, and prompted for a password when
> I am not at home. I think this a reasonable enough use case it should
> be considered in the long term plan. There was an effort many years
> ago that built the initramfs with the kernel, it was abandoned due to
> not being able to guarantee sources for the binaries in the initramfs,
> trying to dig up the details I am having trouble finding it, but legal
> blocked it there is a reference to it in an old FESCo meeting
> https://lists.fedoraproject.org/pipermail/devel/2013-February/178220.html.

I can't see any legal problem with source provision for the
binaries inside the initramfs. We're building the initrds and
UKIs inside koji, so we have a clear record of exactly what
binary RPMs went into the package, and thus have knowledge
of what sources are involved. This is the same situation we
already have in Fedora with libguestfs, where we're building
a disk image inside Koji bundling various binaries. Or for
that matter, not really different from building cloud disk
images, or any other deliverable that bundles together some
binaries from other RPMs and spits out some kind of image
or archive.

> Additionally, we should also consider
> https://fedoraproject.org/wiki/Features/DracutHostOnly and the size
> implications and why we moved to have kernel-core, kernel-modules, and
> kernel-modules-extra for cloud and different use cases.

The UKI size for a VM should not be appreciably different from the
combination of the vmluinuz + locally generated initrd. The UKI
will contain a few more modules, as its initrd is built to cope
with Xen, VMware, HyperV + KVM[1], but this only adds a small amount
over a truly minimal initrd targetting 1 hypervisor. So I don't
expect the size of the UKI will be a problem.


With regards,
Daniel

[1] 
https://gitlab.com/kraxel/kernel-ark/-/commit/4395c8f99657d14d77622a1845727a4b1ddd6ac6
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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)

[Neal Gompa]

On Thu, Dec 22, 2022 at 6:29 AM Daniel P. Berrangé  wrote:
>
> On Thu, Dec 22, 2022 at 05:38:01AM -0500, Neal Gompa wrote:
> > On Wed, Dec 21, 2022 at 1:56 PM Lennart Poettering  
> > wrote:
> > >
> > > On Di, 20.12.22 17:11, Neal Gompa (ngomp...@gmail.com) wrote:
> > >
> > > > > SecureBoot may not be to your liking but is what is installed on 99% 
> > > > > of
> > > > > modern hardware sold, so it is a good idea to first show you can
> > > > > support it. Then if you have interested you can propose "something
> > > > > better".
> > > >
> > > > We have supported Secure Boot for over a decade now. In that timeframe,
> > > > literally nobody did anything to make all the workflows you talk about
> > > > easier and friendlier.
> > > >
> > > > In fact, everyone I talk to seems to think it's basically impossible
> > > > because of how it works at the firmware level.
> > > >
> > > > It's telling that neither Windows nor macOS use Secure Boot like Linux
> > > > does. And they don't precisely for the reasons I outlined.
> > >
> > > Yes, Linux never solved the initrd hole so far, but that's not really
> > > the fault of SecureBoot, it's the fault of Linux if you so
> > > will. And this proposal is an attempt to finally do something about
> > > this, and get things in order to actually deliver what the other OSes
> > > all are delivering.
> > >
> > > I understand the big issue you have is that the certificate store for
> > > Linux (i.e. the mokutil db) is limited in size because EFI variable
> > > NVRAM is limited in size? If that's the big issue you are having then
> > > that's absolutely something the Linux community can fix, and can
> > > address. Specifically, shim could allow storing the cert store on
> > > disk, and authenticate it at boot via the TPM. Not trivial, but
> > > doable. And certainly not the firmware's fault...
> > >
> > > I mean, UEFI has its warts, but I don't see that it's UEFI's fault if
> > > the way Linux/shim/mokutil implement the cert db is done the way it is
> > > currently done.
> > >
> >
> > Frankly, I'm aggravated by the increased reliance on UEFI features
> > without fixing Linux's problems with UEFI features. If we stopped
> > relying on UEFI for the cert store, a lot of my issues would go away,
> > because then we can design better workflows for managing certificates.
> > It makes automation possible, it makes management possible, and it
> > opens the doors to experiment with how to do layered images for boot
> > (e.g. UKIs + system extension images) without bricking people's
> > computers.
>
> So your objections are completely unrelated to the use of UKIs,
> and should not be a blocker for this feature proposal. You're
> just asking people to work on other UEFI related problems.
>

It is not unreasonable to have to deal with it for VMs either. Having
custom drivers needed for workloads where hardware passthrough occurs
is not unusual. While you can kind of handwave graphics, I've seen
storage and network devices passed in too.

> > > > I assert that the proposal has not yet met the bar to overcome those
> > > > issues.
> > >
> > > If the "those issues" is supposed to be that you hit the size of the
> > > mokutil cert store once, then I fail to see the relationship to
> > > UKI/sysext. After all, the fedora signing keys for sysexts would be
> > > built into the kernel and hence not be charged against NVRAM. And the
> > > fedora UKI is signed with the same key as our current kernels, which
> > > are also not charged against NVRAM but are built into fedora shim. And
> > > the shim signature key is the msft key.
> > >
> > > Yeah, if you want to build your own UKIs + sysext, then you have to
> > > use mokutil to enroll a cert, but it would be entirely sufficient to
> > > enroll one for that, and sign UKIS, kmods, sysext with them.
> > >
> > > (or, maybe you actually hit the NVRAM size limits because you enrolled
> > > hashes, not certs? if so, then maybe address that?)
> > >
> >
> > I do not want to add more things to Fedora that *will* cause people to
> > potentially brick their systems because they have to screw around with
> > UEFI to be able to extend what they can use to boot their systems.
>
> Bricking systems is not an issue for VMs, where this proposal
> is targetted.
>
> > Just because today it's only about VMs doesn't mean I can't figure out
> > you want to do more with it down the road. I want to see some
> > demonstration of someone actually caring about the user experience for
> > once with the boot stuff.
>
> If something is proposed for bare metal in the future, then raise
> the problems at that point. It is unreasonable to demand that we
> fix problems for a use case that is not in scope for what is being
> proposed.  Anything related to bare metal was explicitly out of
> scope, precisely because it will massively increase the complexity
> of what needs to be addressed, making the task infeasible. We need
> an incremental path where we can tackle individual practical 

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

[Daniel P . Berrangé]

On Thu, Dec 22, 2022 at 05:38:01AM -0500, Neal Gompa wrote:
> On Wed, Dec 21, 2022 at 1:56 PM Lennart Poettering  
> wrote:
> >
> > On Di, 20.12.22 17:11, Neal Gompa (ngomp...@gmail.com) wrote:
> >
> > > > SecureBoot may not be to your liking but is what is installed on 99% of
> > > > modern hardware sold, so it is a good idea to first show you can
> > > > support it. Then if you have interested you can propose "something
> > > > better".
> > >
> > > We have supported Secure Boot for over a decade now. In that timeframe,
> > > literally nobody did anything to make all the workflows you talk about
> > > easier and friendlier.
> > >
> > > In fact, everyone I talk to seems to think it's basically impossible
> > > because of how it works at the firmware level.
> > >
> > > It's telling that neither Windows nor macOS use Secure Boot like Linux
> > > does. And they don't precisely for the reasons I outlined.
> >
> > Yes, Linux never solved the initrd hole so far, but that's not really
> > the fault of SecureBoot, it's the fault of Linux if you so
> > will. And this proposal is an attempt to finally do something about
> > this, and get things in order to actually deliver what the other OSes
> > all are delivering.
> >
> > I understand the big issue you have is that the certificate store for
> > Linux (i.e. the mokutil db) is limited in size because EFI variable
> > NVRAM is limited in size? If that's the big issue you are having then
> > that's absolutely something the Linux community can fix, and can
> > address. Specifically, shim could allow storing the cert store on
> > disk, and authenticate it at boot via the TPM. Not trivial, but
> > doable. And certainly not the firmware's fault...
> >
> > I mean, UEFI has its warts, but I don't see that it's UEFI's fault if
> > the way Linux/shim/mokutil implement the cert db is done the way it is
> > currently done.
> >
> 
> Frankly, I'm aggravated by the increased reliance on UEFI features
> without fixing Linux's problems with UEFI features. If we stopped
> relying on UEFI for the cert store, a lot of my issues would go away,
> because then we can design better workflows for managing certificates.
> It makes automation possible, it makes management possible, and it
> opens the doors to experiment with how to do layered images for boot
> (e.g. UKIs + system extension images) without bricking people's
> computers.

So your objections are completely unrelated to the use of UKIs,
and should not be a blocker for this feature proposal. You're
just asking people to work on other UEFI related problems.

> > > I assert that the proposal has not yet met the bar to overcome those
> > > issues.
> >
> > If the "those issues" is supposed to be that you hit the size of the
> > mokutil cert store once, then I fail to see the relationship to
> > UKI/sysext. After all, the fedora signing keys for sysexts would be
> > built into the kernel and hence not be charged against NVRAM. And the
> > fedora UKI is signed with the same key as our current kernels, which
> > are also not charged against NVRAM but are built into fedora shim. And
> > the shim signature key is the msft key.
> >
> > Yeah, if you want to build your own UKIs + sysext, then you have to
> > use mokutil to enroll a cert, but it would be entirely sufficient to
> > enroll one for that, and sign UKIS, kmods, sysext with them.
> >
> > (or, maybe you actually hit the NVRAM size limits because you enrolled
> > hashes, not certs? if so, then maybe address that?)
> >
> 
> I do not want to add more things to Fedora that *will* cause people to
> potentially brick their systems because they have to screw around with
> UEFI to be able to extend what they can use to boot their systems.

Bricking systems is not an issue for VMs, where this proposal
is targetted.

> Just because today it's only about VMs doesn't mean I can't figure out
> you want to do more with it down the road. I want to see some
> demonstration of someone actually caring about the user experience for
> once with the boot stuff.

If something is proposed for bare metal in the future, then raise
the problems at that point. It is unreasonable to demand that we
fix problems for a use case that is not in scope for what is being
proposed.  Anything related to bare metal was explicitly out of
scope, precisely because it will massively increase the complexity
of what needs to be addressed, making the task infeasible. We need
an incremental path where we can tackle individual practical tasks
rather than trying to solve everything in one go.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of 

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

[Zbigniew Jędrzejewski-Szmek]

On Wed, Dec 21, 2022 at 11:56:32AM -0600, Dennis Gilmore via devel wrote:
> In my case, I have Network Manager config files included in my initrd
> and bootargs to bring up the network so that I get automatic disk
> decryption while on my home network, and prompted for a password when
> I am not at home. I think this a reasonable enough use case it should
> be considered in the long term plan. There was an effort many years
> ago that built the initramfs with the kernel, it was abandoned due to
> not being able to guarantee sources for the binaries in the initramfs,

If a UKI is built in koji, the initrd it embeds must also be built in koji. And
when the initrd is built in koji, it is just taking some binaries from rpms and
repacking them. We ensure that we have an srpm for any official srpm. Thus, 
going
back from the UKI, you look up the initrd, and the logs for the initrd build,
and get a list of rpms, and then look the appropriate srpms from that, and from
the srpms you get the sources. There's a few more steps, but the availability of
sources is guaranteed using the mechanism existing for normal rpms.

> trying to dig up the details I am having trouble finding it, but legal
> blocked it there is a reference to it in an old FESCo meeting
> https://lists.fedoraproject.org/pipermail/devel/2013-February/178220.html.
> Additionally, we should also consider
> https://fedoraproject.org/wiki/Features/DracutHostOnly and the size
> implications and why we moved to have kernel-core, kernel-modules, and
> kernel-modules-extra for cloud and different use cases.

Yes. That's why this proposal explicitly targets a narrow use case which doesn't
need many drivers and will support many different machines with the same
(relatively small) initrd.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

[Neal Gompa]

On Thu, Dec 22, 2022 at 5:58 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Wed, Dec 21, 2022 at 06:56:05PM +0100, Björn Persson wrote:
> > Gerd Hoffmann wrote:
> > > On Tue, Dec 20, 2022 at 04:31:20PM -0500, Simo Sorce wrote:
> > > > And if you chose your HW carefully you may even be able to register
> > > > your own public keys, generate and sign your own built UKIs and re-
> > > > enable SecureBoot after that... your choice!
> > >
> > > And when your hardware doesn't allow that you can still add your own
> > > keys with mokutil so shim.efi will accept your self-signed UKIs.
> >
> > I'll see when I can take the time for a research project to figure out
> > how customized UKIs can be produced, and develop a tool to do that.
> > Probably never, because I have way too much to do already.
> >
> > Apparently there is no such tool and no plan to provide one, because
> > surely that would have been mentioned under "User Experience".
>
> The tools are already there. Essentially, any tool used in koji by the 
> official
> builds is also available to you on your machine.
>
> There are at three ways that are used: 'dracut --uefi', systemd's ukify, and a
> manual objcopy invocation. The first two are wrappers around objcopy. I'm 
> biased
> because I wrote 'ukify', but I think that's the way to go. What dracut does is
> somewhat primitive and doesn't get the offsets right. Obviously it could be
> improved, but putting the code to generate UKIs inside of an initrd generator 
> is
> a historical accident, and bash is not the nicest language to do offset
> calculations. Thus I hope we can standarize on ukify instead.
>
> In particular, if some functionality is missing from ukify, feel free to 
> submit
> a PR or an issue. It's in Python, so fairly nice to modify. So far it's been
> written to take a kernel and an initrd and the stub, and produce an efi 
> binary.
> It could be extended to start with an existing efi binary and e.g. a new 
> initrd
> or a different commandline, but so far nobody has requested that.
>

It would definitely make sense to add some documentation about
preferred tools, since other distributions will eventually reference
our Change document to do UKIs on their own too.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2155351] perl-Module-CoreList-5.20221220 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2155351



--- Comment #2 from Fedora Update System  ---
FEDORA-2022-d837237b50 has been submitted as an update to Fedora 37.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-d837237b50


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2155351
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2155351] perl-Module-CoreList-5.20221220 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2155351



--- Comment #1 from Fedora Update System  ---
FEDORA-2022-3c99427018 has been submitted as an update to Fedora 36.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-3c99427018


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2155351
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2155351] perl-Module-CoreList-5.20221220 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2155351

Jitka Plesnikova  changed:

   What|Removed |Added

   Fixed In Version||perl-Module-CoreList-5.2022
   ||1220-1.fc38
 Status|ASSIGNED|MODIFIED




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2155351
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

[Zbigniew Jędrzejewski-Szmek]

On Wed, Dec 21, 2022 at 06:56:05PM +0100, Björn Persson wrote:
> Gerd Hoffmann wrote:
> > On Tue, Dec 20, 2022 at 04:31:20PM -0500, Simo Sorce wrote:
> > > And if you chose your HW carefully you may even be able to register
> > > your own public keys, generate and sign your own built UKIs and re-
> > > enable SecureBoot after that... your choice!  
> > 
> > And when your hardware doesn't allow that you can still add your own
> > keys with mokutil so shim.efi will accept your self-signed UKIs.
> 
> I'll see when I can take the time for a research project to figure out
> how customized UKIs can be produced, and develop a tool to do that.
> Probably never, because I have way too much to do already.
> 
> Apparently there is no such tool and no plan to provide one, because
> surely that would have been mentioned under "User Experience".

The tools are already there. Essentially, any tool used in koji by the official
builds is also available to you on your machine.

There are at three ways that are used: 'dracut --uefi', systemd's ukify, and a
manual objcopy invocation. The first two are wrappers around objcopy. I'm biased
because I wrote 'ukify', but I think that's the way to go. What dracut does is
somewhat primitive and doesn't get the offsets right. Obviously it could be
improved, but putting the code to generate UKIs inside of an initrd generator is
a historical accident, and bash is not the nicest language to do offset
calculations. Thus I hope we can standarize on ukify instead.

In particular, if some functionality is missing from ukify, feel free to submit
a PR or an issue. It's in Python, so fairly nice to modify. So far it's been
written to take a kernel and an initrd and the stub, and produce an efi binary.
It could be extended to start with an existing efi binary and e.g. a new initrd
or a different commandline, but so far nobody has requested that.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora rawhide compose report: 20221222.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20221221.n.1
NEW: Fedora-Rawhide-20221222.n.0

= SUMMARY =
Added images:1
Dropped images:  0
Added packages:  2
Dropped packages:0
Upgraded packages:   39
Downgraded packages: 0

Size of added packages:  806.30 KiB
Size of dropped packages:0 B
Size of upgraded packages:   331.88 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -1.60 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Silverblue dvd-ostree x86_64
Path: 
Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20221222.n.0.iso

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: last-resort-fonts-15.000-1.fc38
Summary: Special-purpose font that includes a collection of Unicode characters
RPMs:last-resort-fonts
Size:338.29 KiB

Package: python-glad2-2.0.2-1.fc38
Summary: Multi-Language GL/GLES/EGL/GLX/WGL Loader-Generator
RPMs:glad2 python3-glad2
Size:468.02 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  apptainer-1.1.4-2.fc38
Old package:  apptainer-1.1.4-1.fc38
Summary:  Application and environment virtualization formerly known as 
Singularity
RPMs: apptainer apptainer-suid
Size: 106.47 MiB
Size change:  11.30 KiB
Changelog:
  * Wed Dec 14 2022 Carl George  - 1.1.4-2
  - Add pivot provides/conflict of sif-runtime
  - Reduce singularity obsoletes upper bound
  - Remove singularity provides due to incompatibilities introduced in apptainer
  - Add the word singularity to the summary so it shows up in dnf search results
  - Move obsoletes to suid subpackage


Package:  awscli-1.27.35-1.fc38
Old package:  awscli-1.27.34-1.fc38
Summary:  Universal Command Line Environment for AWS
RPMs: awscli
Size: 3.25 MiB
Size change:  477 B
Changelog:
  * Wed Dec 21 2022 Gwyn Ciesla  - 1.27.35-1
  - 1.27.35


Package:  grub2-1:2.06-72.fc38
Old package:  grub2-1:2.06-71.fc38
Summary:  Bootloader with support for Linux, Multiboot and more
RPMs: grub2-common grub2-efi-aa64 grub2-efi-aa64-cdboot 
grub2-efi-aa64-modules grub2-efi-ia32 grub2-efi-ia32-cdboot 
grub2-efi-ia32-modules grub2-efi-x64 grub2-efi-x64-cdboot grub2-efi-x64-modules 
grub2-emu grub2-emu-modules grub2-pc grub2-pc-modules grub2-ppc64le 
grub2-ppc64le-modules grub2-tools grub2-tools-efi grub2-tools-extra 
grub2-tools-minimal
Size: 36.88 MiB
Size change:  -1.03 KiB
Changelog:
  * Wed Dec 21 2022 Robbie Harwood  - 2.06-72
  - Fix prefix setting with memdisk creation for network boot


Package:  hugin-2022.0.0-1.fc38
Old package:  hugin-2021.0.0-10.fc38
Summary:  A panoramic photo stitcher and more
RPMs: hugin hugin-base
Size: 50.50 MiB
Size change:  31.95 KiB
Changelog:
  * Wed Dec 21 2022 Bruno Postle  - 2022.0.0-1
  - Upstream stable release


Package:  js-jquery-3.6.3-1.fc38
Old package:  js-jquery-3.6.0-3.fc37
Summary:  JavaScript DOM manipulation, event handling, and AJAX library
RPMs: js-jquery
Size: 172.62 KiB
Size change:  1.86 KiB
Changelog:
  * Thu Dec 22 2022 Orion Poplawski  - 3.6.3-1
  - Update to 3.6.3


Package:  kdesdk-kioslaves-22.12.0-1.fc38
Old package:  kdesdk-kioslaves-22.04.3-2.fc37
Summary:  KDESDK KIOslaves
RPMs: kdesdk-kioslaves
Size: 331.21 KiB
Size change:  1.88 KiB
Changelog:
  * Thu Dec 22 2022 Justin Zobel  - 22.12.0-1
  - Update to 22.12.0


Package:  kdnssd-22.12.0-2.fc38
Old package:  kdnssd-22.04.3-2.fc37
Summary:  KDE Network Monitor for DNS-SD services (Zeroconf)
RPMs: kdnssd
Size: 489.90 KiB
Size change:  36.18 KiB
Changelog:
  * Thu Dec 22 2022 Justin Zobel  - 22.12.0-1
  - Update to 22.12.0 & package rename/obsolete 
https://community.kde.org/KDE_Gear/22.08_Release_notes


Package:  libinstpatch-1.1.6-14.fc38
Old package:  libinstpatch-1.1.6-13.fc38
Summary:  Instrument file software library
RPMs: libinstpatch libinstpatch-devel libinstpatch-doc
Size: 2.07 MiB
Size change:  5.00 KiB
Changelog:
  * Wed Dec 21 2022 Benjamin A. Beasley  1.1.6-14
  - Use constrain_build instead of setting _smp_build_ncpus


Package:  netcdf-4.9.0-4.fc38
Old package:  netcdf-4.9.0-3.fc37
Summary:  Libraries for the Unidata network Common Data Form
RPMs: netcdf netcdf-devel netcdf-mpich netcdf-mpich-devel 
netcdf-mpich-static netcdf-openmpi netcdf-openmpi-devel netcdf-openmpi-static 
netcdf-static
Size: 22.82 MiB
Size change:  33.17 KiB
Changelog:
  * Mon Dec 19 2022 Orion Poplawski  - 4.9.0-4
  - Apply upstream patch to fix infinite loop in file inferencing


Package:  pitivi-2022.06.0-3.fc38
Old package:  pitivi-2022.06.0-2.fc37
Summary:  Non-linear video editor
RPMs: pitivi
Size: 11.93 MiB
Size change:  3.33 KiB
Changelog:
  * Wed Dec 21 2022 Gwyn Ciesla  - 2022.06.0-3
  - Require gstreamer1-plugin-libav.


Package:  python-ZConfig-3.6.1-2.fc38
Old package:  python-ZCo

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

[Javier Martinez Canillas]

On Wed, Dec 21, 2022 at 6:13 PM Demi Marie Obenour
 wrote:
>

[...]

>
> Does vfat support atomic rename?  Is it possible to atomically upgrade
> a bootloader/UKI/etc?
> --

For Linux, renameat2 RENAME_EXCHANGE is supported in vfat since
version v6.0. The relevant commits FYI are:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=019a0c9e377c
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=204d03203a14
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=da87e1725ae2

Best regards,
Javier
___
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)

[Gerd Hoffmann]

On Wed, Dec 21, 2022 at 05:44:36PM +0100, Lennart Poettering wrote:
> 
> I mean, sure, if you use the Fedora supplied vanilla signed UKI
> without anything else then it won't boot from a network, because that
> would be a security hole. But I see no reason why a network boot UKI
> couldn't be build that maybe be booted via PXE and derives root fs
> info from DHCP alone.

I expect that is an area where we have to research how we want build
stuff in the future.  The UKI for virtual machines / cloud images is
simple and static enough that we can just build that as part of the
kernel build process.  For other use cases that might not be the best
approach though.

Also note that UKIs can be booted without an bootloader.  It's an EFI
binary the firmware can handle on its own.  That actually simplifies
network booting, your dhcp server can hand out URLs to the UKI.

take care,
  Gerd
___
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)

[Neal Gompa]

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?

regardless of architecture?



--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

[Neal Gompa]

On Wed, Dec 21, 2022 at 1:56 PM Lennart Poettering  wrote:
>
> On Di, 20.12.22 17:11, Neal Gompa (ngomp...@gmail.com) wrote:
>
> > > SecureBoot may not be to your liking but is what is installed on 99% of
> > > modern hardware sold, so it is a good idea to first show you can
> > > support it. Then if you have interested you can propose "something
> > > better".
> >
> > We have supported Secure Boot for over a decade now. In that timeframe,
> > literally nobody did anything to make all the workflows you talk about
> > easier and friendlier.
> >
> > In fact, everyone I talk to seems to think it's basically impossible
> > because of how it works at the firmware level.
> >
> > It's telling that neither Windows nor macOS use Secure Boot like Linux
> > does. And they don't precisely for the reasons I outlined.
>
> Yes, Linux never solved the initrd hole so far, but that's not really
> the fault of SecureBoot, it's the fault of Linux if you so
> will. And this proposal is an attempt to finally do something about
> this, and get things in order to actually deliver what the other OSes
> all are delivering.
>
> I understand the big issue you have is that the certificate store for
> Linux (i.e. the mokutil db) is limited in size because EFI variable
> NVRAM is limited in size? If that's the big issue you are having then
> that's absolutely something the Linux community can fix, and can
> address. Specifically, shim could allow storing the cert store on
> disk, and authenticate it at boot via the TPM. Not trivial, but
> doable. And certainly not the firmware's fault...
>
> I mean, UEFI has its warts, but I don't see that it's UEFI's fault if
> the way Linux/shim/mokutil implement the cert db is done the way it is
> currently done.
>

Frankly, I'm aggravated by the increased reliance on UEFI features
without fixing Linux's problems with UEFI features. If we stopped
relying on UEFI for the cert store, a lot of my issues would go away,
because then we can design better workflows for managing certificates.
It makes automation possible, it makes management possible, and it
opens the doors to experiment with how to do layered images for boot
(e.g. UKIs + system extension images) without bricking people's
computers.

That also has the side effect of us having half a chance of being able
to port this security capability to non-UEFI platforms where we use
fake UEFI implementations to bootstrap our boot process, because the
amount of coverage required for fake UEFI implementations is
considerably lower now.

More generally, relying on UEFI-specific security features when most
platforms are not being brought up with UEFI is foolish. ARM is almost
entirely non-UEFI (except the tiny proportion of servers that almost
no one has) and RISC-V is not a UEFI platform either. POWER uses
OpenFirmware instead of UEFI, and IBM Z does something else entirely
different.

You *need* to think about these problems when designing this stuff.
You can't take a myopic x86-only view to this. I have not heard of
anything about UKI security for non-x86 because it seems to all be
tied up in UEFI stuff.

Coming back to "my issue", I've had this problem for six years, and
for most of it "the Linux community" (specifically the Linux boot
community) has brushed me off saying my issue doesn't matter. Even if
it leads to bricked systems. Even if it makes it hard for people to
use their computers. Even if it leads to people turning off Secure
Boot. And finally, even if it means people don't use Linux at all
because they can't make it work.

> > > Finally, unless this proposal harms Fedora I do not see why oppose it.
> > > If, as you fear, it won't work ... then it won't and we'll try
> > > something else. However, having some knowledge of the (security side of
> > > the) matter I do not see why it wouldn't work, once all the pieces fall
> > > in place.
> >
> > This adds significant complexity to the Fedora kernel package and it
> > effectively increases what we need to test for virtualized Fedora Linux
> > environments.
>
> Nah. UKIs + sysext are ultimately something that is simpler and much
> better to test than the current mess. Yeah, for a while we'll have to
> add complexity because to mechanisms will have to be supported, but
> eventually things are going to be simple and easier to test.
>

Maybe. It's not super intuitive from where I'm standing, and I know
how all this stuff works.

> > I assert that the proposal has not yet met the bar to overcome those
> > issues.
>
> If the "those issues" is supposed to be that you hit the size of the
> mokutil cert store once, then I fail to see the relationship to
> UKI/sysext. After all, the fedora signing keys for sysexts would be
> built into the kernel and hence not be charged against NVRAM. And the
> fedora UKI is signed with the same key as our current kernels, which
> are also not charged against NVRAM but are built into fedora shim. And
> the shim signature key is the msft key.
>
> Yeah, if you want to 

Re: F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)

[Niklas Schnelle]

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.

Thanks,
Niklas Schnelle
___
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: Scripts to rebuild dependencies in copr

[Vít Ondruch]

Dne 22. 12. 22 v 5:45 Kevin Fenzi napsal(a):

On Wed, Dec 21, 2022 at 09:15:10PM -0700, Orion Poplawski wrote:

I've been using an old review_pr.py script produced by the Fedora
Stewardship SIG to rebuild the depedencies of a package in COPR to test
changes/updates to packages.  It's been incredibly useful.  However, it
seems that the github repo has disappeared.

Is there anything else out there in use that is actively maintained?

There's the mass pre build project that was recently announced here:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IT347SLVZ6QYNCMYRR3MNB25SJ7W5R3P/

I've not tried it yet, but it's on my list to look at.



I can just recommend it. It is great already and it quickly becomes even 
better.



Vít




It looks like it mostly does everything the review_pr.py script did,
except you have to give it a src.rpm instead of just the pr.
(possibly that could be a RFE on mass prebuild?)

kevin
___
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


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)

[Vít Ondruch]

Dne 22. 12. 22 v 9:56 Olivier Fourdan napsal(a):

Hi

On Thu, Dec 22, 2022 at 9:45 AM Peter Boy  wrote:

How should this be documented so that it can be found by users who want to 
connect to ppc64 (or s390x) a year from now, when no one has the change 
proposal in mind anymore? Is there at least a descriptive error message?

When the connection fails, the Xserver returns a reason in plain text.
In that case, the reason for the connection being rejected would be
„Swapped clients prohibited“.



Appreciate that there is at least some explanation, but if I saw this 
error, I would not be much smarter what is going on and how should I 
proceed 


Just saying. I don't think there is a chance I'll hit this in real life.


Vít





(Unfortunately, we have too many undocumented (or at any rate factually 
invisibly documented) features in our distro )

Cheers
Olivier
___
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


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: Unified Kernel Support Phase 1 (System-Wide Change proposal)

[Gerd Hoffmann]

On Wed, Dec 21, 2022 at 10:16:58AM -0600, Chris Adams wrote:
> Once upon a time, Zbigniew Jędrzejewski-Szmek  said:
> > Without an initrd we immediately have the following limitations:
> > - all kernel modules needed to mount root must be compiled in
> > - all that code is always loaded and remains in unswappable memory
> > - root= syntax is limited to what the kernel understands, i.e.
> >   no root=UUID=… o root=/dev/disk/by-path/… or other udev links,
> >   no encryption or dm-verity.
> > - no bluetooth keyboards or other fancy peripherals
> > - recovery is pretty hard
> 
> Also, the security lock-down for the kernel command line means:
> - no network root filesystem
> - no boot-time-only kernel/module configuration
> 
> The idea of switching from grub2 to sd-boot would also drop network boot
> and BIOS support.  Supporting boot loaders seems to be a bit of a issue
> sometimes, so trying to support multiple boot loaders seems like a bad
> idea to me.

The switch to BootLoaderSpec made switching boot loaders *much* easier.
The actual boot loader config is fixed and never touched, kernel updates
add/remove BLS config snippets, and all boot loaders handle that just
fine.

You can even have *two* bootloaders, sd-boot for efi mode and grub2 for
bios mode.

take care,
  Gerd
___
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: Replace DNF with DNF5 (System-Wide Change proposal)

[Vít Ondruch]

Dne 21. 12. 22 v 18:45 Chuck Anderson napsal(a):

On Wed, Dec 21, 2022 at 01:32:10PM +0100, Dominik 'Rathann' Mierzejewski wrote:

On Wednesday, 21 December 2022 at 12:31, Vít Ondruch wrote:
[...]

Let me put together a few points to sum this up:

1) DNF name is well established, keep the DNF name (and forget about YUM).

2) Keep the compatibility on reasonable level. 100% compatibility is myth
(even between the tiniest updates).

3) Changes are inevitable, especially between major versions. That is why we
version, right? While nobody likes them (especially breaking changes), they
are accepted. Please don't be afraid to do them for good!

4) Keep the package name, so if somebody don't want to update, they can do
`dnf update --exclude dnf` instead of looking for new package name to do
`dnf update --exclude dnf5`

5) I certainly wont combine DNF 4 and DNF 5 on one system. I don't think any
user want to combine these, unless they are desperate. Don't bet everything
on this.

6) Keep only one instance of documentation, if needed, document the old
behavior

7) Tooling and framework changes on background are unimportant to end users.

This is a very good summary of my opinion as well. Thanks, Vit!

Is the command line tool for DNF version 5 called /usr/bin/dnf?  Or
will users have to learn to use "dnf5 install ..." etc?  If the
latter, I think it is a bad idea.



Luckily the former should be the case, IOW `dnf` command stays.


Vít



Each time a new version of "ls"
comes out, they don't append a new digit to the command.  Users
shouldn't have to learn a new command name just to upgrade to a new
major version of a command.  If the syntax and functionality is
substantially the same, then the command name should remain the same.

If the UX (user experience) is sustantially changed such that a user
would have to learn a completely new syntax in order to use it, then
perhaps it would be better to rename the whole product/command to
something other than DNF.  For example, when we moved from
initscripts/service/chkconfig to systemd, the syntax changed enough
that it made sense to have a new command "systemctl" to replace the
previous commands "chkconfig" and "service".

As for the RPM package name, that is less important because it doesn't
really affect the UX much.  Guidance here should be taken from the
packaging guidelines.

https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple

Examples:

 The python-sqlalchemy package occasionally has multiple versions
 in Fedora for backwards compatibility. The most current version of
 python-sqlalchemy is named python-sqlalchemy and an older
 supported version is python-sqlalchemy0.5. No delimiter is used in
 this situation.

This seems to suggest that the package name should be "dnf" for the
latest version and "dnf4" for the previous version.
___
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


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

[Bug 2155351] perl-Module-CoreList-5.20221220 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2155351

Jitka Plesnikova  changed:

   What|Removed |Added

 CC|jose.p.oliveira.oss@gmail.c |
   |om, jples...@redhat.com,|
   |mspa...@redhat.com, |
   |spo...@gmail.com,   |
   |st...@silug.org |
 Status|NEW |ASSIGNED
   Doc Type|--- |If docs needed, set a value




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2155351
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2155345] perl-CPAN-Perl-Releases-5.20221220 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2155345



--- Comment #2 from Fedora Update System  ---
FEDORA-2022-441c08c2e6 has been submitted as an update to Fedora 37.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-441c08c2e6


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2155345
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2155345] perl-CPAN-Perl-Releases-5.20221220 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2155345



--- Comment #1 from Fedora Update System  ---
FEDORA-2022-bfd926fc14 has been submitted as an update to Fedora 36.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-bfd926fc14


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2155345
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)

[Olivier Fourdan]

Hi

On Thu, Dec 22, 2022 at 9:45 AM Peter Boy  wrote:
>
> How should this be documented so that it can be found by users who want to 
> connect to ppc64 (or s390x) a year from now, when no one has the change 
> proposal in mind anymore? Is there at least a descriptive error message?

When the connection fails, the Xserver returns a reason in plain text.
In that case, the reason for the connection being rejected would be
„Swapped clients prohibited“.

> (Unfortunately, we have too many undocumented (or at any rate factually 
> invisibly documented) features in our distro )

Cheers
Olivier
___
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)

[Peter Boy]

> Am 21.12.2022 um 22:49 schrieb Ben Cotton :
> 
> Users with X server and client on two different machines must add the
> `xorg.conf.d` snippet shown above on affected systems.

How should this be documented so that it can be found by users who want to 
connect to ppc64 (or s390x) a year from now, when no one has the change 
proposal in mind anymore? Is there at least a descriptive error message?

(Unfortunately, we have too many undocumented (or at any rate factually 
invisibly documented) features in our distro )

 
--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)


Fedora Server Edition Working Group member
Fedora docs team contributor and board member
Java developer and enthusiast


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2155345] perl-CPAN-Perl-Releases-5.20221220 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2155345

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-CPAN-Perl-Releases-5.2
   ||0221220-1.fc38




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2155345
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue