Hi,
I was wondering if someone could help me.
I stopped (co-)maintaining weechat and adobe-source-code-pro-fonts
several years ago, but I discovered I'm still listed as the Bugzilla
Assignee for EPEL on both packages [1][2] despite not have commit
access. (FAS username: jamielinux)
I contac
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 systemd-n
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 --setopt=inst
> 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 devel-le...@lis
> 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.
__
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
>
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
accep
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 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 from
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 ne
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 e
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 kerne
* 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 (b
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 from
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] https:/
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
- CVE-2022-2832
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 ask
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
>
> Failed
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 under
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 attestati
> 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.
_
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 -- devel@lists.fed
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 wo
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 ab
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
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 the
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
> 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 no
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:
https://user-images.githubusercontent.com/9395011/177169145-d19bab77-cd
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 th
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 question
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
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 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 /Le
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 k
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 thos
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 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
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 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 w
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.
>>
>> gru
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. According
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 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.
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: https://op
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 in
47 matches
Mail list logo
