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
* 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
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
>
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 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
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 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
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 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
* 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
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
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
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
> 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
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
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
==
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
> 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
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
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
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
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 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
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
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_
25 matches
Mail list logo
