On Mon, Jul 04, 2022 at 10:13:23AM +0200, Lennart Poettering wrote:
> On Fr, 01.07.22 08:30, Gerd Hoffmann (kra...@redhat.com) wrote:
>
> > > I do wonder if it's possible to use multiple initrds, and maybe have
> > > the firmware in a separate initrd shared between all installed kernels
> > > if
On Monday, 04 July 2022 at 10:07, Lennart Poettering wrote:
> On Sa, 02.07.22 00:15, Marius Schwarz (fedora...@cloud-foo.de) wrote:
>
> > Hi,
> >
> > I have some bug reports for PA opening BZ and only one ever got a response.
> >
> > Is it possible that this is the cause:
> >
> > You can't ask
OLD: Fedora-Rawhide-20220703.n.0
NEW: Fedora-Rawhide-20220704.n.0
= SUMMARY =
Added images:8
Dropped images: 0
Added packages: 2
Dropped packages:0
Upgraded packages: 71
Downgraded packages: 0
Size of added packages: 38.76 KiB
Size of dropped packages:0 B
On Sa, 25.06.22 20:43, Neal Gompa (ngomp...@gmail.com) wrote:
> > It’s necessary for secure boot to actually be meaningful in
> > practice. I expect that people who care about secure boot
> > will want this.
>
> I don't. I only care about secure boot enough to bootstrap a Free
> platform. Secure
No missing expected images.
Failed openQA tests: 1/8 (aarch64)
New failures (same test not failed in Fedora-Cloud-35-20220703.0):
ID: 1314834 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1314834
Soft failed openQA tests: 1/8 (x86_64)
On So, 19.06.22 20:54, Fedora Development ML (devel@lists.fedoraproject.org)
wrote:
> Use unified kernel images by default for new releases. This can
> allow for the local installation to sign the kernel and the initrd,
> so the boot chain can be verified until after the uefi. Currently,
> the
On Fr, 01.07.22 08:30, Gerd Hoffmann (kra...@redhat.com) wrote:
> > I do wonder if it's possible to use multiple initrds, and maybe have
> > the firmware in a separate initrd shared between all installed kernels
> > if we go down this route.
>
> grub supports multiple initrds just fine.
On 7/4/22 04:13, Lennart Poettering wrote:
> On Fr, 01.07.22 08:30, Gerd Hoffmann (kra...@redhat.com) wrote:
>
>>> I do wonder if it's possible to use multiple initrds, and maybe have
>>> the firmware in a separate initrd shared between all installed kernels
>>> if we go down this route.
>>
>>
On Sa, 02.07.22 00:15, Marius Schwarz (fedora...@cloud-foo.de) wrote:
> Hi,
>
> I have some bug reports for PA opening BZ and only one ever got a response.
>
> Is it possible that this is the cause:
>
> You can't ask /Lennart Poettering / because that
> account is disabled.
>
> I tried a needinfo
On Mo, 04.07.22 11:32, Gerd Hoffmann (kra...@redhat.com) wrote:
> Hi,
>
> > We have been working on building tools and filling gaps to make that
> > workable reasonably in systemd upstream, and with a focus on
> > Fedora. The difficulty is in both being able to prebuild everything
> > but also
On Mo, 04.07.22 09:30, Daniel P. Berrangé (berra...@redhat.com) wrote:
> > > When going for multiple initrds the best approach is probably to simply
> > > split out the kernel modules into a version-specific initrd and store
> > > everything else in another, shared initrd.
> >
> > In the approach
Hi,
> We have been working on building tools and filling gaps to make that
> workable reasonably in systemd upstream, and with a focus on
> Fedora. The difficulty is in both being able to prebuild everything
> but also keeping things somewhat modular and parameterizable. Because
> right now
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
No missing expected images.
Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)
Old soft failures (same test soft failed in Fedora-Cloud-36-20220703.0):
ID: 1314793 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL:
On Mo, 04.07.22 04:19, Demi Marie Obenour (demioben...@gmail.com) wrote:
> On 7/4/22 04:13, Lennart Poettering wrote:
> > On Fr, 01.07.22 08:30, Gerd Hoffmann (kra...@redhat.com) wrote:
> >
> >>> I do wonder if it's possible to use multiple initrds, and maybe have
> >>> the firmware in a separate
On 03. 07. 22 13:00, Fabio Valentini wrote:
- Go binaries that are used by non-Go packages.
Those (and all their dependencies) would need to stay, unless those
non-Go packages would also stop building on i686.
This includes both build-time and run-time dependencies.
Or, if the package in
Daan De Meyer via devel wrote:
> Our results are as follows:
>
> https://user-images.githubusercontent.com/9395011/177169145-d19bab77-cd97-44d0-9c0b-a0a76b16712e.png
This is a 4% slowdown, on a RAM-bound (not even CPU-bound) benchmark!
I do not see at all how this is even considered to possibly
Daan De Meyer via devel wrote:
> As mentioned in the change proposal, when using sampling profilers that
> rely on fast access to the stacktrace, there is currently no viable
> alternative to frame pointers. DWARF unwinding in absence of frame
> pointers is too slow because of the complexity of
Missing expected images:
Minimal raw-xz armhfp
Compose FAILS proposed Rawhide gating check!
9 of 43 required tests failed
openQA tests matching unsatisfied gating requirements shown with **GATING**
below
Failed openQA tests: 59/236 (x86_64), 15/165 (aarch64)
New failures (same test not failed
Hi,
> https://raw.githubusercontent.com/keszybz/mkosi-initrd-talk/main/mkosi-initrd.pdf
Hmm. Nice ideas (reproducible initrds, yay!), but it feels more like
being at proof-of-concept state. mkosi going fetch stuff from the
internet to generate the initrd is clearly a non-starter (maybe not
Similarly, for the sysbench RAM test, which was the other test in the phoronix
benchmark showing substantial regressions when compiled with frame pointers, we
were unable to reproduce the results. Our results are as follows:
> I have had to use frame pointers, but only for deeply embedded projects where
> the cost
> tradeoffs are different and a smaller constrained unwinder was needed.
As mentioned in the change proposal, when using sampling profilers that rely on
fast access to the stacktrace, there is currently
> My expectation would be that by default we'd just use the GPT auto
discovery stuff
Existing Fedora installations do not follow the GPT auto discovery spec. Also,
I think the existing system for the root device can still work, it is passed in
the command line, not the initrd.
Once upon a time, Sharpened Blade said:
> With virtual machines, nothing can actually be verified completely, the host
> running the vm can, 1) Modify the firmware to intercept anything the attacker
> wants, or 2) directly intercept things at the cpu level.
There are CPU extensions that I
On Sat, 2022-07-02 at 15:57 +, Fedora compose checker wrote:
> Missing expected images:
>
> Minimal raw-xz armhfp
>
> Compose FAILS proposed Rawhide gating check!
> 9 of 43 required tests failed
> openQA tests matching unsatisfied gating requirements shown with **GATING**
> below
>
>
Hello,
I've been trying to contact the current nextcloud package maintainer
because there's a blocker bug [1]. I've created a non responsive maintainer
bug https://bugzilla.redhat.com/show_bug.cgi?id=2103756 to see if he
answers or start a take over process.
Cheers,
Iván
[1]
On Mon, Jul 04, 2022 at 03:59:25PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > https://raw.githubusercontent.com/keszybz/mkosi-initrd-talk/main/mkosi-initrd.pdf
>
> Hmm. Nice ideas (reproducible initrds, yay!), but it feels more like
> being at proof-of-concept state. mkosi going fetch stuff
* Ivan Chavero [04/07/2022 15:09] :
>
> I've been trying to contact the current nextcloud package maintainer
> because there's a blocker bug [1].
Folks, when you're asking us if anyone knows how to contact the
maintainer of a given package, you might want to consider actually
giving us his name
With virtual machines, nothing can actually be verified completely, the host
running the vm can, 1) Modify the firmware to intercept anything the attacker
wants, or 2) directly intercept things at the cpu level.
___
devel mailing list --
Hi Fedorians and Gophers,
Later this week, I will be a doing a mass rebuild in F35 for all packages that
require `golang` and provide binaries to mitigate the following CVEs:
`golang` (affects all go binaries):
- CVE-2022-24675 golang: encoding/pem: fix stack overflow in Decode
-
Greetings.
We were having some issues with the management interface on our primary
signing vault. The server was power cycled, but the management is still
not functioning, and now the server isn't processing signing requests
further.
Due to the US holidays there's no one on site right now, but
Even if initrds are (somehow) signed, the kernel command line can still be
modified, like adding `init=/usr/bin/bash`. Also, if everything is signed by
fedora, then the user can not modify the command line. There is a lot of
hardware that needs command line modifications to boot. Also, fedora
I think using credentials for the rootfs is not very useful, the user already
enters the LUKS password on boot. Also, if the encryption keys are not stored
locally, then they have no use, an attacker can just get them from the external
storage. Many users also would not like needing an
On July 4, 2022 2:54:11 PM UTC, Kevin Kofler via devel
wrote:
>Daan De Meyer via devel wrote:
>> As mentioned in the change proposal, when using sampling profilers that
>> rely on fast access to the stacktrace, there is currently no viable
>> alternative to frame pointers. DWARF unwinding in
On Mon, 2022-07-04 at 10:07 +0200, Lennart Poettering wrote:
> On Sa, 02.07.22 00:15, Marius Schwarz (fedora...@cloud-foo.de) wrote:
>
> > Hi,
> >
> > I have some bug reports for PA opening BZ and only one ever got a response.
> >
> > Is it possible that this is the cause:
> >
> > You can't
On Mo, 04.07.22 19:18, Fedora Development ML (devel@lists.fedoraproject.org)
wrote:
> Even if initrds are (somehow) signed, the kernel command line can
> still be modified, like adding `init=/usr/bin/bash`.
Hmm? sd-stub refused any kernel cmdline passed in manually if
SecureBoot is on. The
On Mo, 04.07.22 19:24, Fedora Development ML (devel@lists.fedoraproject.org)
wrote:
> > My expectation would be that by default we'd just use the GPT auto
> discovery stuff
>
> Existing Fedora installations do not follow the GPT auto discovery
> spec.
If it is desirable to automatically switch
On Mo, 04.07.22 15:59, Gerd Hoffmann (kra...@redhat.com) wrote:
> Hi,
>
> > https://raw.githubusercontent.com/keszybz/mkosi-initrd-talk/main/mkosi-initrd.pdf
>
> Hmm. Nice ideas (reproducible initrds, yay!), but it feels more like
> being at proof-of-concept state. mkosi going fetch stuff
> Like what?
I know there are some efi implementations that need pcie_ports=compat. I also
know that sometimes you need intel_iommu or amd_iommu=off.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
You are right, my bad here.
Maintainer name: Christopher Engelhard
FAS Account: lcts https://accounts.fedoraproject.org/user/lcts/
Cheers,
Iván
El lun, 4 jul 2022 a las 15:38, Emmanuel Seyman ()
escribió:
> * Ivan Chavero [04/07/2022 15:09] :
> >
> > I've been trying to contact the current
On Mo, 04.07.22 19:27, Fedora Development ML (devel@lists.fedoraproject.org)
wrote:
> I think using credentials for the rootfs is not very useful, the
> user already enters the LUKS password on boot.
I can't parse this.
the systemd credentials stuff are not just for passing secrets or
so. They
On Mon, Jul 4 2022 at 09:55:20 AM +0200, Lennart Poettering
wrote:
Signing and authenticating the code is a good thing to protect
systems – it's a good thing if we can do so for the boot code too as
we boot.
Tangent:
After installing or upgrading your Fedora or RHEL system, you have to
Michael Catanzaro wrote on Mon, Jul 04, 2022 at 05:48:28PM -0500:
> After installing or upgrading your Fedora or RHEL system, you have to accept
> a "do you trust this official Fedora project key" prompt or you cannot
> install packages from the official repos. So all our users have been trained
>
> level of tweaking then it's probably totally OK to just turn
>of Secureboot, at which point you can change it freely.
The user having choice and the user having secure shouldn't be mutually
exclusive. Also, if users have "special" hardware, shouldn't they also have
security.
We use a systemd-nspawn container to set up a test environment, among others.
With F36 this is currently not workable for us because the login process is
broken.
I set up a container as usual using dnf to create a container file system, e.g.
using
[…]# dnf --releasever=36 --best
Peter Boy wrote on Tue, Jul 05, 2022 at 07:19:28AM +0200:
> […]# dnf --releasever=36 --best --setopt=install_weak_deps=False \
> --installroot=/var/lib/machines/testf36 install dhcp-client dnf \
> fedora-release glibc glibc-langpack-en iputils less ncurses passwd \
> systemd
https://bugzilla.redhat.com/show_bug.cgi?id=2103511
Paul Howarth changed:
What|Removed |Added
Fixed In Version||perl-Finance-Quote-1.52-1.f
https://bugzilla.redhat.com/show_bug.cgi?id=2102644
Fedora Update System changed:
What|Removed |Added
Status|ASSIGNED|MODIFIED
--- Comment #2 from
https://bugzilla.redhat.com/show_bug.cgi?id=2102647
Fedora Update System changed:
What|Removed |Added
Status|ASSIGNED|MODIFIED
--- Comment #2 from
https://bugzilla.redhat.com/show_bug.cgi?id=2102661
Fedora Update System changed:
What|Removed |Added
Status|ASSIGNED|MODIFIED
--- Comment #2 from
https://bugzilla.redhat.com/show_bug.cgi?id=2102671
Fedora Update System changed:
What|Removed |Added
Status|ASSIGNED|MODIFIED
--- Comment #2 from
https://bugzilla.redhat.com/show_bug.cgi?id=2102655
Fedora Update System changed:
What|Removed |Added
Status|ASSIGNED|MODIFIED
--- Comment #2 from
https://bugzilla.redhat.com/show_bug.cgi?id=2102624
--- Comment #2 from Fedora Update System ---
FEDORA-EPEL-2022-deef165038 has been submitted as an update to Fedora EPEL 9.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-deef165038
--
You are receiving this mail because:
You are
https://bugzilla.redhat.com/show_bug.cgi?id=2102624
Petr Pisar changed:
What|Removed |Added
Status|ASSIGNED|MODIFIED
Fixed In Version|
https://bugzilla.redhat.com/show_bug.cgi?id=2103511
--- Comment #5 from Fedora Update System ---
FEDORA-EPEL-2022-3e813929e6 has been submitted as an update to Fedora EPEL 9.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-3e813929e6
--
You are receiving this mail because:
You are
https://bugzilla.redhat.com/show_bug.cgi?id=2103511
--- Comment #4 from Fedora Update System ---
FEDORA-2022-b92bd8e9e8 has been submitted as an update to Fedora 35.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-b92bd8e9e8
--
You are receiving this mail because:
You are on the CC list
https://bugzilla.redhat.com/show_bug.cgi?id=2103511
--- Comment #6 from Fedora Update System ---
FEDORA-EPEL-2022-77cfe39c7b has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-77cfe39c7b
--
You are receiving this mail because:
You are
https://bugzilla.redhat.com/show_bug.cgi?id=2103511
--- Comment #3 from Fedora Update System ---
FEDORA-2022-2af2d277e2 has been submitted as an update to Fedora 36.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-2af2d277e2
--
You are receiving this mail because:
You are on the CC list
https://bugzilla.redhat.com/show_bug.cgi?id=2103742
Bug ID: 2103742
Summary: perl-SNMP-Info-3.84 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-SNMP-Info
Keywords: FutureFeature, Triaged
https://bugzilla.redhat.com/show_bug.cgi?id=2103742
--- Comment #1 from Upstream Release Monitoring
---
Created attachment 1894550
--> https://bugzilla.redhat.com/attachment.cgi?id=1894550=edit
Update to 3.84 (#2103742)
--
You are receiving this mail because:
You are on the CC list for
https://bugzilla.redhat.com/show_bug.cgi?id=2103763
Bug ID: 2103763
Summary: perl-Text-Bidi-2.18 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-Text-Bidi
Keywords: FutureFeature, Triaged
https://bugzilla.redhat.com/show_bug.cgi?id=2103364
Sergio Basto changed:
What|Removed |Added
Flags||needinfo?(spo...@gmail.com)
Greetings.
We were having some issues with the management interface on our primary
signing vault. The server was power cycled, but the management is still
not functioning, and now the server isn't processing signing requests
further.
Due to the US holidays there's no one on site right now, but
https://bugzilla.redhat.com/show_bug.cgi?id=2103742
--- Comment #2 from Upstream Release Monitoring
---
the-new-hotness/release-monitoring.org's scratch build of
perl-SNMP-Info-3.84-1.fc36.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=89083052
--
You are
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
https://bugzilla.redhat.com/show_bug.cgi?id=2103762
Bug ID: 2103762
Summary: perl-Sys-Virt-8.5.0 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-Sys-Virt
Keywords: FutureFeature, Triaged
The following builds have been pushed to Fedora EPEL 8 updates-testing
ansible-collection-netbox-netbox-3.7.1-1.el8
libmatekbd-1.26.0-2.el8
libmatemixer-1.26.0-2.el8
libmateweather-1.26.0-2.el8
mate-common-1.26.0-2.el8
mate-desktop-1.26.0-2.el8
https://bugzilla.redhat.com/show_bug.cgi?id=2103511
Fedora Update System changed:
What|Removed |Added
Status|MODIFIED|ON_QA
--- Comment #7 from
https://bugzilla.redhat.com/show_bug.cgi?id=2103793
Bug ID: 2103793
Summary: perl-WWW-Mechanize-2.10 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-WWW-Mechanize
Keywords: FutureFeature, Triaged
https://bugzilla.redhat.com/show_bug.cgi?id=2103792
Bug ID: 2103792
Summary: perl-URI-5.11 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-URI
Keywords: FutureFeature, Triaged
Assignee:
70 matches
Mail list logo