On Tue, May 31, 2022 at 08:59:28AM +0200, Petr Pisar wrote:
> V Tue, May 31, 2022 at 08:07:57AM +0200, Alexander Sosedkin napsal(a):
> > On Mon, May 30, 2022 at 10:34 PM Garry T. Williams
> > wrote:
> > > On Friday, April 29, 2022 5:49:05 PM EDT Ben Cotton wrote:
> > > > Cryptographic policies
V Tue, May 31, 2022 at 04:25:28PM +0200, Alexander Sosedkin napsal(a):
> On Tue, May 31, 2022 at 4:09 PM Petr Pisar wrote:
> >
> > V Tue, May 31, 2022 at 03:51:26PM +0200, Alexander Sosedkin napsal(a):
> > > On Tue, May 31, 2022 at 3:45 PM Petr Pisar wrote:
> > > >
> > > > V Tue, May 31, 2022 at
On Tue, May 31, 2022 at 4:09 PM Petr Pisar wrote:
>
> V Tue, May 31, 2022 at 03:51:26PM +0200, Alexander Sosedkin napsal(a):
> > On Tue, May 31, 2022 at 3:45 PM Petr Pisar wrote:
> > >
> > > V Tue, May 31, 2022 at 02:56:56PM +0200, Alexander Sosedkin napsal(a):
> > > > On Tue, May 31, 2022 at
V Tue, May 31, 2022 at 03:51:26PM +0200, Alexander Sosedkin napsal(a):
> On Tue, May 31, 2022 at 3:45 PM Petr Pisar wrote:
> >
> > V Tue, May 31, 2022 at 02:56:56PM +0200, Alexander Sosedkin napsal(a):
> > > On Tue, May 31, 2022 at 12:28 PM Vitaly Zaitsev via devel
> > > wrote:
> > > > On
On Tue, May 31, 2022 at 3:45 PM Petr Pisar wrote:
>
> V Tue, May 31, 2022 at 02:56:56PM +0200, Alexander Sosedkin napsal(a):
> > On Tue, May 31, 2022 at 12:28 PM Vitaly Zaitsev via devel
> > wrote:
> > > On 31/05/2022 10:21, Petr Pisar wrote:
> > > > Not in current F37 FUTURE policy the user
V Tue, May 31, 2022 at 02:56:56PM +0200, Alexander Sosedkin napsal(a):
> On Tue, May 31, 2022 at 12:28 PM Vitaly Zaitsev via devel
> wrote:
> > On 31/05/2022 10:21, Petr Pisar wrote:
> > > Not in current F37 FUTURE policy the user tested.
> >
> > Yes. If the new F37 cryptographic policy considers
On Tue, May 31, 2022 at 12:28 PM Vitaly Zaitsev via devel
wrote:
> On 31/05/2022 10:21, Petr Pisar wrote:
> > Not in current F37 FUTURE policy the user tested.
>
> Yes. If the new F37 cryptographic policy considers RSA-2048 to be weak,
> it should be reverted.
The actual proposal is in the OP.
On 31/05/2022 10:21, Petr Pisar wrote:
Not in current F37 FUTURE policy the user tested.
Yes. If the new F37 cryptographic policy considers RSA-2048 to be weak,
it should be reverted. Many servers still use RSA-2048 (the default in
Let's Encrypt).
--
Sincerely,
Vitaly Zaitsev
V Tue, May 31, 2022 at 10:20:10AM +0200, Vitaly Zaitsev via devel napsal(a):
> On 31/05/2022 08:59, Petr Pisar wrote:
> > It's a 2048-bit RSA key of an intermediate certificate.
>
> RSA-2048 is still okay. It should work without errors.
>
Not in current F37 FUTURE policy the user tested.
--
On 31/05/2022 08:59, Petr Pisar wrote:
It's a 2048-bit RSA key of an intermediate certificate.
RSA-2048 is still okay. It should work without errors.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list --
V Tue, May 31, 2022 at 08:07:57AM +0200, Alexander Sosedkin napsal(a):
> On Mon, May 30, 2022 at 10:34 PM Garry T. Williams
> wrote:
> > On Friday, April 29, 2022 5:49:05 PM EDT Ben Cotton wrote:
> > > Cryptographic policies will be tightened in Fedora 38-39,
> > > SHA-1 signatures will no
On Mon, May 30, 2022 at 10:34 PM Garry T. Williams wrote:
>
> On Friday, April 29, 2022 5:49:05 PM EDT Ben Cotton wrote:
> > Cryptographic policies will be tightened in Fedora 38-39,
> > SHA-1 signatures will no longer be trusted by default.
> > Fedora 37 specifically doesn't come with any change
On Friday, April 29, 2022 5:49:05 PM EDT Ben Cotton wrote:
> Cryptographic policies will be tightened in Fedora 38-39,
> SHA-1 signatures will no longer be trusted by default.
> Fedora 37 specifically doesn't come with any change of defaults,
> and this Fedora Change is an advance warning filed
On 5/2/22 08:56, Ian Pilcher wrote:
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.
Just FYI, I managed to bang out a proof of concept of a "wrapper"
On 5/3/22 1:51 PM, Clemens Lang wrote:
I don’t believe this would be in the best interest of our users. Setting a
crypto-policy to REALLY_LEGACY would basically mean “I don’t care about
encryption”. In these cases, why not just use plain HTTP, or other
unencrypted protocols instead?
Easy
On Wed, May 4, 2022 at 12:52 PM Vít Ondruch wrote:
>
> Dne 04. 05. 22 v 9:32 Alexander Sosedkin napsal(a):
> > On Wed, May 4, 2022 at 12:43 AM David Woodhouse wrote:
> >> On Mon, 2022-05-02 at 19:33 +0200, Clemens Lang wrote:
> >>> This is the reason why the proposal contains extensive methods
Dne 04. 05. 22 v 9:32 Alexander Sosedkin napsal(a):
On Wed, May 4, 2022 at 12:43 AM David Woodhouse wrote:
On Mon, 2022-05-02 at 19:33 +0200, Clemens Lang wrote:
This is the reason why the proposal contains extensive methods to test
whether things are going to break by modifying the
On Wed, May 4, 2022 at 12:43 AM David Woodhouse wrote:
>
> On Mon, 2022-05-02 at 19:33 +0200, Clemens Lang wrote:
> > This is the reason why the proposal contains extensive methods to test
> > whether things are going to break by modifying the crypto-policy or using
> > bpftrace. Unfortunately
On 5/3/22 18:41, David Woodhouse wrote:
> On Mon, 2022-05-02 at 19:33 +0200, Clemens Lang wrote:
>> This is the reason why the proposal contains extensive methods to test
>> whether things are going to break by modifying the crypto-policy or using
>> bpftrace. Unfortunately there are hundreds of
On Mon, 2022-05-02 at 19:33 +0200, Clemens Lang wrote:
> This is the reason why the proposal contains extensive methods to test
> whether things are going to break by modifying the crypto-policy or using
> bpftrace. Unfortunately there are hundreds of packages that depend on
> cryptographic
On Tue, May 3, 2022 at 1:20 PM Kevin Kofler via devel
wrote:
>
> Ian Pilcher wrote:
> > 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
On Mon, May 02, 2022 at 08:56:06AM -0500, Ian Pilcher wrote:
> 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.
See
Hi,
Kevin Kofler via devel wrote:
I think we need a REALLY_LEGACY that continues allowing MD5 and the like.
According to https://github.com/corkami/collisions#chosen-prefix-collisions,
a chosen-prefix collision on MD5 took 72 hours to compute in 2009. 13 years
later, you really should treat
Ian Pilcher wrote:
> 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.
Even worse is that even the LEGACY policy is
* 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
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
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
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
>
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.
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
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
> 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
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
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
>
> 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
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-
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
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
Hi David,
David Woodhouse writes:
> 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 implemented if
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 implemented if approved
> by the Fedora Engineering Steering
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.
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.
44 matches
Mail list logo
