Another status update:
1. USDT/eBPF tracing turned out to be a fruitful logging approach.
Clemens Lang has kindly added USDT probes to the latest openssl builds,
traceable with a small tool [1] available from a copr [2].
Yes, this way it doesn't log into your face unpromptedly,
like
Another status update for transparency purposes:
1. openssl-3.0.2-3 and crypto-policies-20220412-1.git97fe449
now distrust SHA-1 signatures in FUTURE policy or NO-SHA1 subpolicy.
Meaning that updating the packages and issuing
`update-crypto-policies --set FUTURE` /
Dne 07. 04. 22 v 16:13 Stephen Gallagher napsal(a):
On Thu, Apr 7, 2022 at 10:12 AM Kamil Dudka wrote:
On Thursday, April 7, 2022 3:45:45 PM CEST Stephen Gallagher wrote:
Sorry for keeping asking naive questions, but is there a chance to do
some mass rebuild prior this lands, to asses the
On Thu, Apr 7, 2022 at 9:06 PM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Tue, Mar 29, 2022 at 03:34:49PM -0700, Kevin Fenzi wrote:
> > On Tue, Mar 29, 2022 at 08:12:47PM +0200, Alexander Sosedkin wrote:
> > >
> > > "You know these lights in the theaters that go out gradually?
> > > When the guy
On Tue, Mar 29, 2022 at 03:34:49PM -0700, Kevin Fenzi wrote:
> On Tue, Mar 29, 2022 at 08:12:47PM +0200, Alexander Sosedkin wrote:
> >
> > "You know these lights in the theaters that go out gradually?
> > When the guy ve-ery slo-o-owly pulls the plug out?"
> > - a joke from my childhood.
> >
>
Hi Stephen,
Stephen Gallagher wrote:
On Wed, Apr 6, 2022 at 10:43 AM Stephen Gallagher
wrote:
I put together a potential solution for testing this in ELN and
submitted an MR:
https://src.fedoraproject.org/rpms/crypto-policies/pull-request/10
It's a little bit heavy-handed of an approach,
On Thu, Apr 7, 2022 at 10:12 AM Kamil Dudka wrote:
>
> On Thursday, April 7, 2022 3:45:45 PM CEST Stephen Gallagher wrote:
> > > Sorry for keeping asking naive questions, but is there a chance to do
> > > some mass rebuild prior this lands, to asses the impact? Better to avoid
> > > (complete?)
On Thursday, April 7, 2022 3:45:45 PM CEST Stephen Gallagher wrote:
> > Sorry for keeping asking naive questions, but is there a chance to do
> > some mass rebuild prior this lands, to asses the impact? Better to avoid
> > (complete?) breakage of ELN and give change to fix the (most
> >
On Thu, Apr 7, 2022 at 4:53 AM Vít Ondruch wrote:
>
>
> Dne 06. 04. 22 v 22:29 Stephen Gallagher napsal(a):
> > On Wed, Apr 6, 2022 at 10:43 AM Stephen Gallagher
> > wrote:
> >> On Wed, Apr 6, 2022 at 7:09 AM Alexander Sosedkin
> >> wrote:
> >>> On Wed, Apr 6, 2022 at 1:00 PM Vít Ondruch
Dne 06. 04. 22 v 22:29 Stephen Gallagher napsal(a):
On Wed, Apr 6, 2022 at 10:43 AM Stephen Gallagher wrote:
On Wed, Apr 6, 2022 at 7:09 AM Alexander Sosedkin wrote:
On Wed, Apr 6, 2022 at 1:00 PM Vít Ondruch wrote:
...
Alexander,
Could this be enabled in ELN? This is not really
On Wed, Apr 6, 2022 at 10:43 AM Stephen Gallagher wrote:
>
> On Wed, Apr 6, 2022 at 7:09 AM Alexander Sosedkin
> wrote:
> >
> > On Wed, Apr 6, 2022 at 1:00 PM Vít Ondruch wrote:
> ...
> > > Alexander,
> > >
> > > Could this be enabled in ELN? This is not really question but
> > > suggestion.
On Wed, Apr 6, 2022 at 7:09 AM Alexander Sosedkin wrote:
>
> On Wed, Apr 6, 2022 at 1:00 PM Vít Ondruch wrote:
...
> > Alexander,
> >
> > Could this be enabled in ELN? This is not really question but
> > suggestion. It is unfortunate, that ELN, while intermediate step for c9s
> > does not have
On Wed, Apr 6, 2022 at 1:00 PM Vít Ondruch wrote:
>
>
> Dne 08. 03. 22 v 19:40 Alexander Sosedkin napsal(a):
> > Hello, community, I need your wisdom for planning a disruptive change.
> >
> > Fedora 28 had https://fedoraproject.org/wiki/Changes/StrongCryptoSettings
> > Fedora 33 had
Dne 08. 03. 22 v 19:40 Alexander Sosedkin napsal(a):
Hello, community, I need your wisdom for planning a disruptive change.
Fedora 28 had https://fedoraproject.org/wiki/Changes/StrongCryptoSettings
Fedora 33 had https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2
I believe we should
FWIW Alexander's plan sounds reasonable to me.
On Tue, Mar 29 2022 at 03:34:49 PM -0700, Kevin Fenzi
wrote:
Well, we just shipped beta today, so I think it's too late to land any
f36 changes at this point.
This is a non-default configuration that I strongly suspect nobody or
almost nobody
On Tue, Mar 29, 2022 at 08:12:47PM +0200, Alexander Sosedkin wrote:
>
> "You know these lights in the theaters that go out gradually?
> When the guy ve-ery slo-o-owly pulls the plug out?"
> - a joke from my childhood.
>
>
> Hello, it's been quiet for a while, and I've been busy
> but kept
On Tue, Mar 8, 2022 at 7:40 PM Alexander Sosedkin wrote:
>
> Hello, community, I need your wisdom for planning a disruptive change.
>
> Fedora 28 had https://fedoraproject.org/wiki/Changes/StrongCryptoSettings
> Fedora 33 had https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2
> I
On Wed, Mar 23, 2022 at 7:05 AM Alexander Sosedkin wrote:
>
> On Wed, Mar 23, 2022 at 12:51 AM Josh Boyer wrote:
> >
> > On Tue, Mar 8, 2022 at 1:40 PM Alexander Sosedkin
> > wrote:
> > >
> > > Hello, community, I need your wisdom for planning a disruptive change.
> > >
> > > Fedora 28 had
On Wed, Mar 23, 2022 at 12:51 AM Josh Boyer wrote:
>
> On Tue, Mar 8, 2022 at 1:40 PM Alexander Sosedkin
> wrote:
> >
> > Hello, community, I need your wisdom for planning a disruptive change.
> >
> > Fedora 28 had https://fedoraproject.org/wiki/Changes/StrongCryptoSettings
> > Fedora 33 had
On Tue, Mar 8, 2022 at 1:40 PM Alexander Sosedkin wrote:
>
> Hello, community, I need your wisdom for planning a disruptive change.
>
> Fedora 28 had https://fedoraproject.org/wiki/Changes/StrongCryptoSettings
> Fedora 33 had https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2
> I
> On 16. Mar 2022, at 00:04, Tom Hughes via devel
> wrote:
>
> On 15/03/2022 22:45, Robert Relyea wrote:
>
>> 1) in fedora 37, provide a policy that turns SHA-1 off. in our testing, we
>> encourage people to run with that policy and write bugs against components.
>
> That policy already
Robert Relyea wrote:
> 2) in fedora 38, SHA-1 gets turned of in the default policy and ships
> that way.
Isn't that the default already? I use the default crypto policy, and I
had a case last year where Seamonkey and Firefox refused to talk to a
certain web server, which I worked around by
On 15/03/2022 22:45, Robert Relyea wrote:
1) in fedora 37, provide a policy that turns SHA-1 off. in our testing,
we encourage people to run with that policy and write bugs against
components.
That policy already exists in Fedora 34 and 35 where the FUTURE policy
does not allow SHA1 in
On 3/9/22 1:56 AM, Daniel P. Berrangé wrote:
On Wed, Mar 09, 2022 at 10:46:21AM +0100, Alexander Sosedkin wrote:
On Wed, Mar 9, 2022 at 10:20 AM Daniel P. Berrangé wrote:
On Tue, Mar 08, 2022 at 07:40:15PM +0100, Alexander Sosedkin wrote:
We've been disabling it in TLS, but its usage is much
On 3/9/22 08:52, Alexander Sosedkin wrote:
> On Wed, Mar 9, 2022 at 2:47 PM Richard W.M. Jones wrote:
>>
>> Previous tightening of crypto defaults caused problems with us
>> connecting to older ssh servers.
>>
>> I am particularly interested / worried about sshd from RHEL 5, 6 & 7
>> for virt-p2v
On Wed, Mar 9, 2022 at 7:19 PM Daniel P. Berrangé wrote:
>
> On Wed, Mar 09, 2022 at 01:05:38PM -0500, Matthew Miller wrote:
> > On Wed, Mar 09, 2022 at 05:40:50PM +, Daniel P. Berrangé wrote:
> > > > But: maybe if we logged it _and_ had a tool people could run to
> > > > look specifically
On Wed, Mar 09, 2022 at 07:13:14PM +0100, Alexander Sosedkin wrote:
> On Wed, Mar 9, 2022 at 7:05 PM Daniel P. Berrangé wrote:
> >
> > On Wed, Mar 09, 2022 at 06:45:49PM +0100, Alexander Sosedkin wrote:
> > > On Wed, Mar 9, 2022 at 6:22 PM Matthew Miller
> > > wrote:
> > > >
> > > > On Wed, Mar
On Wed, Mar 09, 2022 at 01:05:38PM -0500, Matthew Miller wrote:
> On Wed, Mar 09, 2022 at 05:40:50PM +, Daniel P. Berrangé wrote:
> > > But: maybe if we logged it _and_ had a tool people could run to
> > > look specifically for those log entries, we could do something like a Test
> > > Day
On Wed, Mar 9, 2022 at 7:05 PM Daniel P. Berrangé wrote:
>
> On Wed, Mar 09, 2022 at 06:45:49PM +0100, Alexander Sosedkin wrote:
> > On Wed, Mar 9, 2022 at 6:22 PM Matthew Miller
> > wrote:
> > >
> > > On Wed, Mar 09, 2022 at 12:14:28PM +0100, Alexander Sosedkin wrote:
> > > > I left my crystal
On Wed, Mar 09, 2022 at 05:40:50PM +, Daniel P. Berrangé wrote:
> > But: maybe if we logged it _and_ had a tool people could run to
> > look specifically for those log entries, we could do something like a Test
> > Day where people could send in reports?
>
> Or just have it logging in
On Wed, Mar 09, 2022 at 06:45:49PM +0100, Alexander Sosedkin wrote:
> On Wed, Mar 9, 2022 at 6:22 PM Matthew Miller
> wrote:
> >
> > On Wed, Mar 09, 2022 at 12:14:28PM +0100, Alexander Sosedkin wrote:
> > > I left my crystal ball at home today,
> > > but I don't need it to say it'd be ~0 bugs
On Wed, Mar 9, 2022 at 6:22 PM Matthew Miller wrote:
>
> On Wed, Mar 09, 2022 at 12:14:28PM +0100, Alexander Sosedkin wrote:
> > I left my crystal ball at home today,
> > but I don't need it to say it'd be ~0 bugs filed if we log to syslog
> > and ~3 if we log to stderr/stdout, all named
> >
On Wed, Mar 09, 2022 at 12:21:18PM -0500, Matthew Miller wrote:
> On Wed, Mar 09, 2022 at 12:14:28PM +0100, Alexander Sosedkin wrote:
> > I left my crystal ball at home today,
> > but I don't need it to say it'd be ~0 bugs filed if we log to syslog
> > and ~3 if we log to stderr/stdout, all named
On Wed, Mar 9, 2022 at 4:40 PM Robbie Harwood wrote:
>
> Alexander Sosedkin writes:
>
> > Daniel P. Berrangé wrote:
> >
> >> Perhaps a useful first step is to just modify the three main
> >> crypto libs (gnutls, openssl, and nss) to send a scary warnihg
> >> message to stderr/syslog any time
On Wed, Mar 09, 2022 at 12:14:28PM +0100, Alexander Sosedkin wrote:
> I left my crystal ball at home today,
> but I don't need it to say it'd be ~0 bugs filed if we log to syslog
> and ~3 if we log to stderr/stdout, all named
> "$CRYPTOLIB has no business messing up my stderr/stdout",
> which
Alexander Sosedkin writes:
> Daniel P. Berrangé wrote:
>
>> Perhaps a useful first step is to just modify the three main
>> crypto libs (gnutls, openssl, and nss) to send a scary warnihg
>> message to stderr/syslog any time they get use of SHA1 in a
>> signature. Leave that active for a release
On Wednesday, 09 March 2022 at 15:59, Chris Adams wrote:
[...]
> I am very much not a UI/UX person, but Firefox and other browsers really
> could use a good way to override system crypto policy on a per-site
> basis.
Have you opened a ticket in Firefox bugzilla?
Regards,
Dominik
--
Fedora
Once upon a time, Richard W.M. Jones said:
> Previous tightening of crypto defaults caused problems with us
> connecting to older ssh servers.
I also have had trouble connecting to major vendor websites. The vendor
response is just "works in Chrome and Firefox on Windows, must be your
problem".
On Wed, Mar 09, 2022 at 02:54:40PM +0100, Dmitry Belyavskiy wrote:
> At least RHEL 6 issues can be fixed server-side generating an ecdsa key...
If you can log in ...
This doesn't really work for us because of the way virt-v2v works --
it wants to ssh to the RHEL 5/6/7 server to fetch some files
At least RHEL 6 issues can be fixed server-side generating an ecdsa key...
On Wed, Mar 9, 2022 at 2:47 PM Richard W.M. Jones wrote:
> Previous tightening of crypto defaults caused problems with us
> connecting to older ssh servers.
>
> I am particularly interested / worried about sshd from RHEL
On Wed, Mar 9, 2022 at 2:47 PM Richard W.M. Jones wrote:
>
> Previous tightening of crypto defaults caused problems with us
> connecting to older ssh servers.
>
> I am particularly interested / worried about sshd from RHEL 5, 6 & 7
> for virt-p2v and virt-v2v conversions. This broke before,
Previous tightening of crypto defaults caused problems with us
connecting to older ssh servers.
I am particularly interested / worried about sshd from RHEL 5, 6 & 7
for virt-p2v and virt-v2v conversions. This broke before, requiring
us to advise users to set the global policy for the machine to
On ke, 09 maalis 2022, Daniel P. Berrangé wrote:
On Wed, Mar 09, 2022 at 02:32:48PM +0200, Alexander Bokovoy wrote:
On ke, 09 maalis 2022, Daniel P. Berrangé wrote:
> On Wed, Mar 09, 2022 at 10:46:21AM +0100, Alexander Sosedkin wrote:
> > On Wed, Mar 9, 2022 at 10:20 AM Daniel P. Berrangé
On Wed, Mar 09, 2022 at 02:32:48PM +0200, Alexander Bokovoy wrote:
> On ke, 09 maalis 2022, Daniel P. Berrangé wrote:
> > On Wed, Mar 09, 2022 at 10:46:21AM +0100, Alexander Sosedkin wrote:
> > > On Wed, Mar 9, 2022 at 10:20 AM Daniel P. Berrangé
> > > wrote:
> > > >
> > > > On Tue, Mar 08, 2022
On ke, 09 maalis 2022, Daniel P. Berrangé wrote:
On Wed, Mar 09, 2022 at 10:46:21AM +0100, Alexander Sosedkin wrote:
On Wed, Mar 9, 2022 at 10:20 AM Daniel P. Berrangé wrote:
>
> On Tue, Mar 08, 2022 at 07:40:15PM +0100, Alexander Sosedkin wrote:
> > We've been disabling it in TLS, but its
On Wed, Mar 9, 2022 at 10:57 AM Daniel P. Berrangé wrote:
>
> On Wed, Mar 09, 2022 at 10:46:21AM +0100, Alexander Sosedkin wrote:
> > On Wed, Mar 9, 2022 at 10:20 AM Daniel P. Berrangé
> > wrote:
> > >
> > > On Tue, Mar 08, 2022 at 07:40:15PM +0100, Alexander Sosedkin wrote:
> > > > We've been
On 3/9/22 04:48, Daniel P. Berrangé wrote:
> On Wed, Mar 09, 2022 at 10:44:28AM +0100, Miroslav Lichvar wrote:
>> On Tue, Mar 08, 2022 at 07:40:15PM +0100, Alexander Sosedkin wrote:
>>> Took git years to migrate from SHA-1, and some others haven't even started.
>>
>> git is a good example showing
On Wed, Mar 09, 2022 at 10:46:21AM +0100, Alexander Sosedkin wrote:
> On Wed, Mar 9, 2022 at 10:20 AM Daniel P. Berrangé
> wrote:
> >
> > On Tue, Mar 08, 2022 at 07:40:15PM +0100, Alexander Sosedkin wrote:
> > > We've been disabling it in TLS, but its usage is much wider than TLS.
> > > The next
On Wed, Mar 09, 2022 at 10:44:28AM +0100, Miroslav Lichvar wrote:
> On Tue, Mar 08, 2022 at 07:40:15PM +0100, Alexander Sosedkin wrote:
> > Took git years to migrate from SHA-1, and some others haven't even started.
>
> git is a good example showing that this won't be easy. The SHA-256
> object
On Wed, Mar 9, 2022 at 10:20 AM Daniel P. Berrangé wrote:
>
> On Tue, Mar 08, 2022 at 07:40:15PM +0100, Alexander Sosedkin wrote:
> > We've been disabling it in TLS, but its usage is much wider than TLS.
> > The next agonizing step is to restrict its usage for signatures
> > on the cryptographic
On Tue, Mar 08, 2022 at 07:40:15PM +0100, Alexander Sosedkin wrote:
> Took git years to migrate from SHA-1, and some others haven't even started.
git is a good example showing that this won't be easy. The SHA-256
object format is still marked as experimental and not the default.
Is there a plan
On Tue, Mar 8, 2022 at 8:52 PM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Tue, Mar 08, 2022 at 07:40:15PM +0100, Alexander Sosedkin wrote:
> > the only realistic way to weed out its reliance on SHA-1 signatures
> > from all of its numerous dark corners is to break them.
> > Make creation and
On Tue, Mar 08, 2022 at 07:40:15PM +0100, Alexander Sosedkin wrote:
> We've been disabling it in TLS, but its usage is much wider than TLS.
> The next agonizing step is to restrict its usage for signatures
> on the cryptographic libraries level, with openssl being the scariest one.
>
> Good news
On Tue, Mar 8, 2022 at 6:40 PM Alexander Sosedkin wrote:
> Good news is, RHEL-9 is gonna lead the way
> and thus will take a lot of the hits first.
> Fedora doesn't have to pioneer it.
> Bad news is, Fedora has to follow suit someday anyway,
> and this brings me to how does one land such a
On Tue, Mar 8, 2022 at 3:34 PM Demi Marie Obenour wrote:
>
> On 3/8/22 15:23, Neal Gompa wrote:
> > On Tue, Mar 8, 2022 at 3:11 PM Simo Sorce wrote:
> >>
> >> On Tue, 2022-03-08 at 20:51 +0100, Zbigniew Jędrzejewski-Szmek wrote:
> >>> On Tue, Mar 08, 2022 at 07:40:15PM +0100, Alexander Sosedkin
On 3/8/22 15:23, Neal Gompa wrote:
> On Tue, Mar 8, 2022 at 3:11 PM Simo Sorce wrote:
>>
>> On Tue, 2022-03-08 at 20:51 +0100, Zbigniew Jędrzejewski-Szmek wrote:
>>> On Tue, Mar 08, 2022 at 07:40:15PM +0100, Alexander Sosedkin wrote:
the only realistic way to weed out its reliance on SHA-1
On Tue, Mar 8, 2022 at 3:11 PM Simo Sorce wrote:
>
> On Tue, 2022-03-08 at 20:51 +0100, Zbigniew Jędrzejewski-Szmek wrote:
> > On Tue, Mar 08, 2022 at 07:40:15PM +0100, Alexander Sosedkin wrote:
> > > the only realistic way to weed out its reliance on SHA-1 signatures
> > > from all of its
On Tue, 2022-03-08 at 20:51 +0100, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Mar 08, 2022 at 07:40:15PM +0100, Alexander Sosedkin wrote:
> > the only realistic way to weed out its reliance on SHA-1 signatures
> > from all of its numerous dark corners is to break them.
> > Make creation and
On Tue, Mar 8, 2022, at 1:40 PM, Alexander Sosedkin wrote:
>
> But these are all rather... crude?
> Sure there should be better ways,
> preferably something explored before.
One general technique I like is the "warn and sleep" approach; example:
https://github.com/coreos/rpm-ostree/pull/2098
On Tue, Mar 08, 2022 at 07:40:15PM +0100, Alexander Sosedkin wrote:
> the only realistic way to weed out its reliance on SHA-1 signatures
> from all of its numerous dark corners is to break them.
> Make creation and verification fail in default configuration.
That sounds like a terrible plan. We
Hello, community, I need your wisdom for planning a disruptive change.
Fedora 28 had https://fedoraproject.org/wiki/Changes/StrongCryptoSettings
Fedora 33 had https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2
I believe we should start planning
for the next cryptographic defaults
61 matches
Mail list logo
