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 st
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` /
`update-crypto-polic
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 imp
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 v
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?) br
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
> > outstanding
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 wrot
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 question
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. It
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 th
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 https://fedora
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 st
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 u
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 thin
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 believe
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 http
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 htt
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 believe
> 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 exis
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 tempor
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 signat
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 for
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 wher
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 rawhide,
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 fil
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
> > "$CRY
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 the
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 we'll
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 http
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 w
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, requi
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 L
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é
wrot
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 usag
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 d
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 t
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 fo
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 l
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 t
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 verifi
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 i
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 change
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 w
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 si
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 numerou
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 verif
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
Of
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 s
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 tighten
61 matches
Mail list logo
