No missing expected images.
Failed openQA tests: 1/8 (aarch64)
New failures (same test not failed in Fedora-Cloud-34-20220501.0):
ID: 1249327 Test: aarch64 Cloud_Base-qcow2-qcow2 base_reboot_unmount@uefi
URL: https://openqa.fedoraproject.org/tests/1249327
Soft failed openQA tests: 1/8 (x86_
OLD: Fedora-Rawhide-20220501.n.0
NEW: Fedora-Rawhide-20220502.n.0
= SUMMARY =
Added images:1
Dropped images: 1
Added packages: 0
Dropped packages:3
Upgraded packages: 26
Downgraded packages: 0
Size of added packages: 0 B
Size of dropped packages:142.41
On Sun, May 1, 2022 at 12:14 PM Dan Čermák
wrote:
>
> They are going to break things, but Ubuntu 22.04 deprecated SHA1
> signatures already, so it's very likely that a good chunk of the fallout
> will be cleared by the time Fedora 38 and 39 ship.
>
>
In a similar (parallel) discussion related to
Once upon a time, Kevin P. Fleming said:
> In a similar (parallel) discussion related to future RHEL, it has been
> found this change also breaks resolution of many DNSSEC-secured domains
> which are still using SHA1 signatures. It is impossible to know how long it
> will be before those domains u
On Sat, Apr 30, 2022 at 4:28 PM David Woodhouse wrote:
> On Fri, 2022-04-29 at 17:49 -0400, Ben Cotton wrote:
> > 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
It sure feels like we're reaching the point where anyone who has to work
with any sort of older equipment or servers is going to to forced to
switch their entire system to the LEGACY policy, which seems really
unfortunate.
IMO, there's a rather desperate need to be able to override the system-
wi
Missing expected images:
Minimal raw-xz armhfp
Compose PASSES proposed Rawhide gating check!
All required tests passed
Failed openQA tests: 12/231 (x86_64), 25/161 (aarch64)
New failures (same test not failed in Fedora-Rawhide-20220501.n.0):
ID: 1249464 Test: x86_64 Cloud_Base-qcow2-qcow2
> IMO, there's a rather desperate need to be able to override the
system-wide policy for individual processes, maybe via some sort of wrapper
around one of the containerization technologies.
There's part of me that's almost surprised that there's not an SELinux
Policy flag of some kind that would
On Mon, May 2, 2022 at 12:54 PM Kevin P. Fleming wrote:
> In a similar (parallel) discussion related to future RHEL, it has been found
> this change also breaks resolution of many DNSSEC-secured domains which are
> still using SHA1 signatures. It is impossible to know how long it will be
> bef
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.
https://fedoraproject.org/wiki/Changes/perl5.36
==
JT writes:
>> IMO, there's a rather desperate need to be able to override the
>> system-wide policy for individual processes, maybe via some sort of
>> wrapper around one of the containerization technologies.
>
> Alternatively I wouldn't be surprised if at some point the industry
> doesn't unoffi
> While I agree that per-application policy overrides would be really
helpful, these suggested solutions are overkill.
Overkill is SELinux's middle name isn't it. :P It always struck me as being
intentionally heavy handed... which is kind of a good thing if you're
looking for control above all els
On Mon, May 2, 2022 at 6:28 PM Robbie Harwood wrote:
>
> JT writes:
>
> >> IMO, there's a rather desperate need to be able to override the
> >> system-wide policy for individual processes, maybe via some sort of
> >> wrapper around one of the containerization technologies.
> >
> > Alternatively I
Alexander Sosedkin writes:
> crypto-policies' goal is to define system-wide *defaults*.
Well, that's certainly part of it, but...
"The purpose is to unify the crypto policies used by different
applications and libraries. That is allow setting a consistent security
level for crypto on all applic
Hi,
On Fri, 2022-04-29 at 17:49 -0400, Ben Cotton wrote:
Changes like this have been very disruptive in the past because they
haven't been completely thought through.
Can we please make 100% sure these policies are not going to break
things like VPN clients in the way that we have before.
Th
* Kevin P. Fleming:
> In a similar (parallel) discussion related to future RHEL, it has been
> found this change also breaks resolution of many DNSSEC-secured
> domains which are still using SHA1 signatures. It is impossible to
> know how long it will be before those domains upgrade to better
> si
On Mon, May 2, 2022 at 7:18 PM Robbie Harwood wrote:
>
> Alexander Sosedkin writes:
>
> > crypto-policies' goal is to define system-wide *defaults*.
>
> Well, that's certainly part of it, but...
>
> "The purpose is to unify the crypto policies used by different
> applications and libraries. That
Once upon a time, Florian Weimer said:
> At least that's a solvable problem: perform DNSSEC validation (to
> prevent actual attacks) and pretend to clients that you didn't do it (to
> avoid relying on signatures which aren't policy-confiorming). DNSSEC
> supports that approach quite well for ordi
On Mon, May 2, 2022 at 3:28 PM Chris Adams wrote:
> Once upon a time, Florian Weimer said:
> > At least that's a solvable problem: perform DNSSEC validation (to
> > prevent actual attacks) and pretend to clients that you didn't do it (to
> > avoid relying on signatures which aren't policy-confio
On Wed, Apr 27, 2022 at 7:52 PM Matthew Miller wrote:
>
> On Wed, Apr 27, 2022 at 04:00:28PM +0200, Vitaly Zaitsev via devel wrote:
> > Legal ML ignored this question, so I'll post it here.
>
> Please be patient. Messages involving legal sometimes take more than a few
> days to respond to.
On a r
On 4/6/22 12:57, Neal Gompa wrote:
(trimming)
* NVIDIA graphics
* Broadcom wireless
The former case is excessively common, and the latter case is fairly
common with HP and Dell machines as well as some smaller OEMs. I
literally helped someone this past week with both[1][2][3]. The
Workstation WG
Hi,
we have a proposal to drop redhat-lsb , shouldn't we try to keep it ?
redhat-lsb still in version 4 when LSB 5.0 was released June 3, 2015.
https://bugzilla.redhat.com/show_bug.cgi?id=2076968
https://src.fedoraproject.org/rpms/redhat-lsb
Best regards,
--
Sérgio M. B.
On Mon, May 2, 2022 at 5:29 PM Jeremy Linton wrote:
>
> On 4/6/22 12:57, Neal Gompa wrote:
> (trimming)
> > * NVIDIA graphics
> > * Broadcom wireless
> >
> > The former case is excessively common, and the latter case is fairly
> > common with HP and Dell machines as well as some smaller OEMs. I
>
* Chris Adams:
> Once upon a time, Florian Weimer said:
>> At least that's a solvable problem: perform DNSSEC validation (to
>> prevent actual attacks) and pretend to clients that you didn't do it (to
>> avoid relying on signatures which aren't policy-confiorming). DNSSEC
>> supports that approa
No missing expected images.
Failed openQA tests: 6/229 (x86_64), 7/161 (aarch64)
ID: 1251048 Test: x86_64 Workstation-live-iso gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1251048
ID: 1251053 Test: x86_64 Workstation-live-iso evince
URL: https://openqa.fedoraproject.org/t
25 matches
Mail list logo