1:17 p.m.
If you upgrade in f33 or rawhide to nss 3.59, all your firefox add-ons
will stop working. Worse they will appear corrupted, so you will have to
remove them and re-install them (after downgrading nss).
For now, downgrade nss or avoid updating to it until things can get
sorted out.
https://bugzilla.redhat.com/show_bug.cgi?id=1908018
kevin
1:59 p.m.
On Tuesday, December 15, 2020 7:17:21 PM WET Kevin Fenzi wrote:
If you upgrade in f33 or rawhide to nss 3.59, all your firefox
add-ons
will stop working. Worse they will appear corrupted, so you will have to
remove them and re-install them (after downgrading nss).
For now, downgrade nss or avoid updating to it until things can get
sorted out.
https://bugzilla.redhat.com/show_bug.cgi?id=1908018
kevin
Thank you Kevin for the note.
I had updated by I downgraded thanks to you. :-)
Regards,
--
José Abílio
2:04 p.m.
On Tue, Dec 15, 2020 at 8:17 PM Kevin Fenzi <kevin(a)scrye.com> wrote:
If you upgrade in f33 or rawhide to nss 3.59, all your firefox add-ons
will stop working. Worse they will appear corrupted, so you will have to
remove them and re-install them (after downgrading nss).
I'm running firefox 83.0-13.fc33.x86_64 with nss 3.59.0-2.fc33
installed since it hit my local updates-testing mirror and all my
add-ons are looking good. Could there be something else that's causing
trouble? I have the following from the nss family:
nss-3.59.0-2.fc33.i686
nss-3.59.0-2.fc33.x86_64
nss-softokn-3.59.0-2.fc33.i686
nss-softokn-3.59.0-2.fc33.x86_64
nss-softokn-freebl-3.59.0-2.fc33.i686
nss-softokn-freebl-3.59.0-2.fc33.x86_64
nss-sysinit-3.59.0-2.fc33.x86_64
nss-util-3.59.0-2.fc33.i686
nss-util-3.59.0-2.fc33.x86_64
2:13 p.m.
On Tuesday, December 15, 2020 8:04:24 PM WET Alexander Ploumistos wrote:
I'm running firefox 83.0-13.fc33.x86_64 with nss 3.59.0-2.fc33
installed since it hit my local updates-testing mirror and all my
add-ons are looking good. Could there be something else that's causing
trouble? I have the following from the nss family:
nss-3.59.0-2.fc33.i686
nss-3.59.0-2.fc33.x86_64
nss-softokn-3.59.0-2.fc33.i686
nss-softokn-3.59.0-2.fc33.x86_64
nss-softokn-freebl-3.59.0-2.fc33.i686
nss-softokn-freebl-3.59.0-2.fc33.x86_64
nss-sysinit-3.59.0-2.fc33.x86_64
nss-util-3.59.0-2.fc33.i686
nss-util-3.59.0-2.fc33.x86_64
Did you restart firefox since updating?
--
José Abílio
3:38 p.m.
On Tue, Dec 15, 2020 at 9:04 PM Alexander Ploumistos
<alex.ploumistos(a)gmail.com> wrote:
On Tue, Dec 15, 2020 at 8:17 PM Kevin Fenzi <kevin(a)scrye.com> wrote:
>
> If you upgrade in f33 or rawhide to nss 3.59, all your firefox add-ons
> will stop working. Worse they will appear corrupted, so you will have to
> remove them and re-install them (after downgrading nss).
I'm running firefox 83.0-13.fc33.x86_64 with nss 3.59.0-2.fc33
installed since it hit my local updates-testing mirror and all my
add-ons are looking good.
So, I spoke too soon. I just got notified that one of my add-ons is
misbehaving and it has been disabled. I'm still on the same session I
was when I sent the previous message, nothing was installed or updated
in the meantime. Is this bug time-based or something?
4:09 p.m.
On Tue, 2020-12-15 at 22:38 +0100, Alexander Ploumistos wrote:
On Tue, Dec 15, 2020 at 9:04 PM Alexander Ploumistos
<alex.ploumistos(a)gmail.com> wrote:
>
> On Tue, Dec 15, 2020 at 8:17 PM Kevin Fenzi <kevin(a)scrye.com> wrote:
> >
> > If you upgrade in f33 or rawhide to nss 3.59, all your firefox add-ons
> > will stop working. Worse they will appear corrupted, so you will have to
> > remove them and re-install them (after downgrading nss).
>
> I'm running firefox 83.0-13.fc33.x86_64 with nss 3.59.0-2.fc33
> installed since it hit my local updates-testing mirror and all my
> add-ons are looking good.
So, I spoke too soon. I just got notified that one of my add-ons is
misbehaving and it has been disabled. I'm still on the same session I
was when I sent the previous message, nothing was installed or updated
in the meantime. Is this bug time-based or something?
You didn't answer the question whether you had restarted Firefox since
installing the new nss.
Either way, probably Firefox is doing a periodic check of installed
add-ons and that fails whenever it happens now. The issue is they're
signed with SHA-1 certs, but nss is now not accepting SHA-1 per the
current system-wide policy.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
4:59 p.m.
On 12/15/20 5:09 PM, Adam Williamson wrote:
On Tue, 2020-12-15 at 22:38 +0100, Alexander Ploumistos wrote:
> On Tue, Dec 15, 2020 at 9:04 PM Alexander Ploumistos
> <alex.ploumistos(a)gmail.com> wrote:
>>
>> On Tue, Dec 15, 2020 at 8:17 PM Kevin Fenzi <kevin(a)scrye.com> wrote:
>>>
>>> If you upgrade in f33 or rawhide to nss 3.59, all your firefox add-ons
>>> will stop working. Worse they will appear corrupted, so you will have to
>>> remove them and re-install them (after downgrading nss).
>>
>> I'm running firefox 83.0-13.fc33.x86_64 with nss 3.59.0-2.fc33
>> installed since it hit my local updates-testing mirror and all my
>> add-ons are looking good.
>
> So, I spoke too soon. I just got notified that one of my add-ons is
> misbehaving and it has been disabled. I'm still on the same session I
> was when I sent the previous message, nothing was installed or updated
> in the meantime. Is this bug time-based or something?
You didn't answer the question whether you had restarted Firefox since
installing the new nss.
Either way, probably Firefox is doing a periodic check of installed
add-ons and that fails whenever it happens now. The issue is they're
signed with SHA-1 certs, but nss is now not accepting SHA-1 per the
current system-wide policy.
Since there is no great way for end-users to motivate the various add-on creators to
update their certs, this sounds like a serious problem.
For now I've put an exclude in my dnf.conf to prevent any nss upgrades, but that is
also not a great solution, for obvious reasons. Perhaps there will have to be a way for
end-users to override the check for critical add-ons. Hopefully the add-on creators will
eventually switch certs, but that could take a very long time.
Steve
5:45 p.m.
On Tue, 2020-12-15 at 17:59 -0500, Steven A. Falco wrote:
On 12/15/20 5:09 PM, Adam Williamson wrote:
> On Tue, 2020-12-15 at 22:38 +0100, Alexander Ploumistos wrote:
> > On Tue, Dec 15, 2020 at 9:04 PM Alexander Ploumistos
> > <alex.ploumistos(a)gmail.com> wrote:
> > >
> > > On Tue, Dec 15, 2020 at 8:17 PM Kevin Fenzi <kevin(a)scrye.com>
wrote:
> > > >
> > > > If you upgrade in f33 or rawhide to nss 3.59, all your firefox
add-ons
> > > > will stop working. Worse they will appear corrupted, so you will have
to
> > > > remove them and re-install them (after downgrading nss).
> > >
> > > I'm running firefox 83.0-13.fc33.x86_64 with nss 3.59.0-2.fc33
> > > installed since it hit my local updates-testing mirror and all my
> > > add-ons are looking good.
> >
> > So, I spoke too soon. I just got notified that one of my add-ons is
> > misbehaving and it has been disabled. I'm still on the same session I
> > was when I sent the previous message, nothing was installed or updated
> > in the meantime. Is this bug time-based or something?
>
> You didn't answer the question whether you had restarted Firefox since
> installing the new nss.
>
> Either way, probably Firefox is doing a periodic check of installed
> add-ons and that fails whenever it happens now. The issue is they're
> signed with SHA-1 certs, but nss is now not accepting SHA-1 per the
> current system-wide policy.
Since there is no great way for end-users to motivate the various add-on creators to
update their certs, this sounds like a serious problem.
For now I've put an exclude in my dnf.conf to prevent any nss upgrades, but that is
also not a great solution, for obvious reasons. Perhaps there will have to be a way for
end-users to override the check for critical add-ons. Hopefully the add-on creators will
eventually switch certs, but that could take a very long time.
To be clear, the update is not stable for F33 and should not go stable.
It's only in updates-testing.
I wrote in the update that in my opinion the solution for this bug
can't involve expecting add-ons to suddenly get re-signed en masse, or
users to change their local configuration. It needs to keep working as
it did before. If the policy is ahead of the real world, the policy
needs to be loosened.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
6:01 p.m.
On Wed, Dec 16, 2020 at 12:45 AM Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
On Tue, 2020-12-15 at 17:59 -0500, Steven A. Falco wrote:
> On 12/15/20 5:09 PM, Adam Williamson wrote:
> > On Tue, 2020-12-15 at 22:38 +0100, Alexander Ploumistos wrote:
> > > On Tue, Dec 15, 2020 at 9:04 PM Alexander Ploumistos
> > > <alex.ploumistos(a)gmail.com> wrote:
> > > >
> > > > On Tue, Dec 15, 2020 at 8:17 PM Kevin Fenzi <kevin(a)scrye.com>
wrote:
> > > > >
> > > > > If you upgrade in f33 or rawhide to nss 3.59, all your firefox
add-ons
> > > > > will stop working. Worse they will appear corrupted, so you will
have to
> > > > > remove them and re-install them (after downgrading nss).
> > > >
> > > > I'm running firefox 83.0-13.fc33.x86_64 with nss 3.59.0-2.fc33
> > > > installed since it hit my local updates-testing mirror and all my
> > > > add-ons are looking good.
> > >
> > > So, I spoke too soon. I just got notified that one of my add-ons is
> > > misbehaving and it has been disabled. I'm still on the same session I
> > > was when I sent the previous message, nothing was installed or updated
> > > in the meantime. Is this bug time-based or something?
> >
> > You didn't answer the question whether you had restarted Firefox since
> > installing the new nss.
I never received the above message. To answer the question, according
to my dnf history the update to nss was installed almost 24 hours ago
and by the time the bug appeared I had already shut down and restarted
my computer at least three times, firefox itself had been restarted a
few times more.
> >
> > Either way, probably Firefox is doing a periodic check of installed
> > add-ons and that fails whenever it happens now. The issue is they're
> > signed with SHA-1 certs, but nss is now not accepting SHA-1 per the
> > current system-wide policy.
Since I did not want to reconfigure all of my add-ons, I restored a
two-day-old backup of the ~/.mozilla folder (after renaming the
existing one) and oddly, the toolbar buttons of my add-ons were
invisible. I had to disable and re-enable them to get them to appear.
Firefox containers still had to be reinstalled and I can't understand
why. The backup was from before the problematic nss update, is
something else stored outside ~/.mozilla ?
6:08 p.m.
Off topic, is there a way to see the message headers in Hyperkitty?
I'm trying to figure out why 4 messages in this thread were never
delivered to me.
6:15 p.m.
On Tue, Dec 15, 2020 at 5:08 PM Alexander Ploumistos
<alex.ploumistos(a)gmail.com> wrote:
Off topic, is there a way to see the message headers in Hyperkitty?
I'm trying to figure out why 4 messages in this thread were never
delivered to me.
You're a gmail user like me. Between approximately 90 and 30 minutes
ago, I had several people call me to ask why I had deleted my email
account. Email sent to me was bouncing back with a message that the
account did not exist. Then I started receiving email again about 30
minutes ago. I don't know what happened, but something seems to have
hiccupped over at Google.
If anybody tried to send me email over the last couple of hours, I
probably didn't get it. Please try again.
--
Jerry James
http://www.jamezone.org/
6:35 p.m.
Hi Jerry,
On Tue, Dec 15, 2020 at 5:08 PM Alexander Ploumistos
<alex.ploumistos(a)gmail.com> wrote:
You're a gmail user like me. Between approximately 90 and 30 minutes
ago, I had several people call me to ask why I had deleted my email
account. Email sent to me was bouncing back with a message that the
account did not exist. Then I started receiving email again about 30
minutes ago. I don't know what happened, but something seems to have
hiccupped over at Google.
You're right, another Google outage has been reported and after managing to figure out
the time zones in the reports, it does coincide with the time frame of the missing
messages. Mystery solved.
Thank you!
A.
12:54 p.m.
On Tue, Dec 15, 2020 at 11:45 PM Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
I wrote in the update that in my opinion the solution for this bug
can't involve expecting add-ons to suddenly get re-signed en masse, or
users to change their local configuration. It needs to keep working as
it did before. If the policy is ahead of the real world, the policy
needs to be loosened.
It was my (possibly failing) recollection that Mozilla
has been signing add-ons with SHA2 (and SHA1
for compatibility) for a few years now. Is this just
an issue because Mozilla has not re-signed existing
add-ons (which while is obviously not something to
be taken lightly, because they do control the primary
distribution point(*) should be at least theoretically
possible to do a bulk re-signing, and probably a
good thing to do to avoid needing to downgrade
their security stance), or is Mozilla not signing
with SHA2 as I thought?
(*) Yes, there are other distribution points for
add-ons other than Mozilla itself, and they, too,
would need to consider such re-signing.
11:59 a.m.
On Tue, 2020-12-29 at 18:54 +0000, Gary Buhrmaster wrote:
On Tue, Dec 15, 2020 at 11:45 PM Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
> I wrote in the update that in my opinion the solution for this bug
> can't involve expecting add-ons to suddenly get re-signed en masse, or
> users to change their local configuration. It needs to keep working as
> it did before. If the policy is ahead of the real world, the policy
> needs to be loosened.
It was my (possibly failing) recollection that Mozilla
has been signing add-ons with SHA2 (and SHA1
for compatibility) for a few years now. Is this just
an issue because Mozilla has not re-signed existing
add-ons (which while is obviously not something to
be taken lightly, because they do control the primary
distribution point(*) should be at least theoretically
possible to do a bulk re-signing, and probably a
good thing to do to avoid needing to downgrade
their security stance), or is Mozilla not signing
with SHA2 as I thought?
Well, installing uBlock Origin (which is a pretty frequently updated
addon) on a fresh VM fails, with the change. So I suspect it's the
latter.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
7:40 p.m.
Sorry to be a bother, but is there another side effect from having
this update installed on a server? As far as I could tell from the
discussion on the update page, only the sha1 signed firefox add-ons
are concerned, but I could be missing something.
8:18 p.m.
On Wed, 2020-12-16 at 02:40 +0100, Alexander Ploumistos wrote:
Sorry to be a bother, but is there another side effect from having
this update installed on a server? As far as I could tell from the
discussion on the update page, only the sha1 signed firefox add-ons
are concerned, but I could be missing something.
From the comments on the update I'm not sure *precisely* what the scope
of the change is, but it's at least possible that the behaviour of
anything that uses NSS for cryptography could have changed with this
update. Things that don't use NSS won't be affected of course.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
4:46 a.m.
Am 15.12.20 um 20:17 schrieb Kevin Fenzi:
If you upgrade in f33 or rawhide to nss 3.59, all your firefox
add-ons
will stop working. Worse they will appear corrupted, so you will have to
remove them and re-install them (after downgrading nss).
apropos firefox: current builds for firefox are not finishing . If you
check the koji page for firefox, you see what I mean.
Of course, the information about the build could just not have reached
koji.
best regads,
Marius
8:33 a.m.
On Tue, 15 Dec 2020 11:17:21 -0800
Kevin Fenzi <kevin(a)scrye.com> wrote:
If you upgrade in f33 or rawhide to nss 3.59, all your firefox
add-ons
will stop working. Worse they will appear corrupted, so you will have
to remove them and re-install them (after downgrading nss).
For now, downgrade nss or avoid updating to it until things can get
sorted out.
https://bugzilla.redhat.com/show_bug.cgi?id=1908018
kevin
I see nss.x86_64 3.59.0-3.fc33 in today’s updates. Is this fixed or
are there going to be a lot of unhappy Firefox users? The bug is
still open.
Thanks,
Jim
8:35 a.m.
On 18/12/2020 14:33, James Szinger wrote:
I see nss.x86_64 3.59.0-3.fc33 in today’s updates. Is this fixed or
are there going to be a lot of unhappy Firefox users? The bug is
still open.
From https://koji.fedoraproject.org/koji/buildinfo?buildID=1658942:
* Tue Dec 15 2020 Bob Relyea <rrelyea(a)redhat.com> - 3.59.0-3
- Back out strict SHA-1 signature control because firefox
Addon system is still using sha-1 signatures
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
10:30 a.m.
On Fri, 2020-12-18 at 07:33 -0700, James Szinger wrote:
On Tue, 15 Dec 2020 11:17:21 -0800
Kevin Fenzi <kevin(a)scrye.com> wrote:
> If you upgrade in f33 or rawhide to nss 3.59, all your firefox add-ons
> will stop working. Worse they will appear corrupted, so you will have
> to remove them and re-install them (after downgrading nss).
>
> For now, downgrade nss or avoid updating to it until things can get
> sorted out.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1908018
>
> kevin
I see nss.x86_64 3.59.0-3.fc33 in today’s updates. Is this fixed or
are there going to be a lot of unhappy Firefox users?
It's fixed.
The bug is still open.
Because we still need to do something (or, rather, get Mozilla to do
something) about the underlying situation.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
10:33 a.m.
Am 18.12.20 um 15:33 schrieb James Szinger:
I see nss.x86_64 3.59.0-3.fc33 in today’s updates. Is this fixed or
are there going to be a lot of unhappy Firefox users? The bug is
still open.
Can someone pls lush this into rawhide? There is only -2 WITH the SHA-1
blockade.
Best regards,
Marius
2:32 p.m.
On Sat, Dec 19, 2020 at 05:33:57PM +0100, Marius Schwarz wrote:
Am 18.12.20 um 15:33 schrieb James Szinger:
> I see nss.x86_64 3.59.0-3.fc33 in today’s updates. Is this fixed or
> are there going to be a lot of unhappy Firefox users? The bug is
> still open.
>
Can someone pls lush this into rawhide? There is only -2 WITH the SHA-1
blockade.
firefox-84.0-6 in rawhide (the latest package available) has enabled
it's bundled nss that doesn't do that check. ;(
https://koji.fedoraproject.org/koji/buildinfo?buildID=1659741
So, upgrading to that should work around the problem.
Of course it causes other problems, like firefox exposing all the nss
provides.
The best workaround for now would be firefox adding some code to exempt
itself from the sha1 check for now and resume building against the
system nss and the system nss re-enabling the sha1 check.
The real solution is of course mozilla updaing add-ons to not use sha1.
;)
kevin
9:01 p.m.
Ok, I am the n00b here but I have experienced some nss related problems
since upgrading to Fedora 33. I found that the systemd-resolved service
interferes with
or corrupts previously normal nss functions, most related. to the
resolver.
For example, when some hosts used systemd-resolved and others used nss,
dig and nslookup don't resolve properly. Sometmes ping does work.
Sometimes extrernal
lookups work and internals don't and sometimes the other way round. But
the exact symptom can depend on which type of host you are working with.
I stopped and disabled systemd-resolved and all of those problems
disappeared. Firefox now works fine for me as do all my network services.
http://www.linux-databook.info/?page_id=5951
Thanks
--
*********************************************************
David P. Both, RHCE
He/Him/His
*********************************************************
www.both.org - My personal web site
www.Linux-Databook.info - Home of the DataBook for Linux
DataBook is a Registered Trademark of David Both
*********************************************************
The value of any software lies in its usefulness
not in its price.
— Linus Torvalds
*********************************************************
On Sat, 19 Dec 2020, Kevin Fenzi wrote:
> Date: Sat, 19 Dec 2020 12:32:28 -0800
> From: Kevin Fenzi <kevin(a)scrye.com>
> Reply-To: Development discussions related to Fedora
> <devel(a)lists.fedoraproject.org>
> To: Development discussions related to Fedora <devel(a)lists.fedoraproject.org>
> Subject: Re: heads up: nss 3.59 breaks firefox add-ons
>
> On Sat, Dec 19, 2020 at 05:33:57PM +0100, Marius Schwarz wrote:
>> Am 18.12.20 um 15:33 schrieb James Szinger:
>>> I see nss.x86_64 3.59.0-3.fc33 in today’s updates. Is this fixed or
>>> are there going to be a lot of unhappy Firefox users? The bug is
>>> still open.
>>>
>>
>> Can someone pls lush this into rawhide? There is only -2 WITH the SHA-1
>> blockade.
>
> firefox-84.0-6 in rawhide (the latest package available) has enabled
> it's bundled nss that doesn't do that check. ;(
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1659741
> So, upgrading to that should work around the problem.
>
> Of course it causes other problems, like firefox exposing all the nss
> provides.
>
> The best workaround for now would be firefox adding some code to exempt
> itself from the sha1 check for now and resume building against the
> system nss and the system nss re-enabling the sha1 check.
>
> The real solution is of course mozilla updaing add-ons to not use sha1.
> ;)
>
> kevin
>
3:58 p.m.
Am 18.12.20 um 15:33 schrieb James Szinger:
On Tue, 15 Dec 2020 11:17:21 -0800
Kevin Fenzi <kevin(a)scrye.com> wrote:
> If you upgrade in f33 or rawhide to nss 3.59, all your firefox add-ons
> will stop working. Worse they will appear corrupted, so you will have
> to remove them and re-install them (after downgrading nss).
>
> For now, downgrade nss or avoid updating to it until things can get
> sorted out.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1908018
>
> kevin
I see nss.x86_64 3.59.0-3.fc33 in today’s updates. Is this fixed or
are there going to be a lot of unhappy Firefox users? The bug is
still open.
nss 3.59.0-3 did not reach Rawhide AARCH64 repos and therefore firefox
addons can't be installed atm.
best regards,
Marius Schwarz
5:36 p.m.
On Mon, Dec 28, 2020 at 10:58:49PM +0100, Marius Schwarz wrote:
Am 18.12.20 um 15:33 schrieb James Szinger:
> On Tue, 15 Dec 2020 11:17:21 -0800
> Kevin Fenzi <kevin(a)scrye.com> wrote:
>
> > If you upgrade in f33 or rawhide to nss 3.59, all your firefox add-ons
> > will stop working. Worse they will appear corrupted, so you will have
> > to remove them and re-install them (after downgrading nss).
> >
> > For now, downgrade nss or avoid updating to it until things can get
> > sorted out.
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1908018
> >
> > kevin
> I see nss.x86_64 3.59.0-3.fc33 in today’s updates. Is this fixed or
> are there going to be a lot of unhappy Firefox users? The bug is
> still open.
>
nss 3.59.0-3 did not reach Rawhide AARCH64 repos and therefore firefox
addons can't be installed atm.
Yeah, workaround for now:
sudo update-crypto-policies --set FEDORA:32
PS: no need to cc me on posts to the list. :)
kevin
1:20 a.m.
On Mon, 2020-12-28 at 15:36 -0800, Kevin Fenzi wrote:
On Mon, Dec 28, 2020 at 10:58:49PM +0100, Marius Schwarz wrote:
> Am 18.12.20 um 15:33 schrieb James Szinger:
> > On Tue, 15 Dec 2020 11:17:21 -0800
> > Kevin Fenzi <kevin(a)scrye.com> wrote:
> >
> > > If you upgrade in f33 or rawhide to nss 3.59, all your firefox add-ons
> > > will stop working. Worse they will appear corrupted, so you will have
> > > to remove them and re-install them (after downgrading nss).
> > >
> > > For now, downgrade nss or avoid updating to it until things can get
> > > sorted out.
> > >
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1908018
> > >
> > > kevin
> > I see nss.x86_64 3.59.0-3.fc33 in today’s updates. Is this fixed or
> > are there going to be a lot of unhappy Firefox users? The bug is
> > still open.
> >
>
> nss 3.59.0-3 did not reach Rawhide AARCH64 repos and therefore firefox
> addons can't be installed atm.
Yeah, workaround for now:
sudo update-crypto-policies --set FEDORA:32
PS: no need to cc me on posts to the list. :)
It's not that something "didn't reach" Rawhide, either. The NSS
maintainer intends nss in Rawhide to respect the system-wide policy by
default. We need mstransky to patch Firefox to use the system-wide NSS
*but* allow SHA-1 signatures for add-ons.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
3:44 a.m.
Am 29.12.20 um 10:27 schrieb Marius Schwarz:
Am 29.12.20 um 00:36 schrieb Kevin Fenzi:
>
> Yeah, workaround for now:
>
> sudo update-crypto-policies --set FEDORA:32
>
No ...
# update-crypto-policies --set FEDORA:32
Error: Unknown policy: FEDORA
Workaround for now on Rawhides Pinephone:
update-crypto-policies --set LEGACY
reboot
.. waiting 2 minutes for systemd, because it does not react to it's
configured timeouts on User Managers...
.. hard shutdown due to impatiency ..
reinstalling firefox addons
best regards,
Marius
11:57 a.m.
On Tue, Dec 29, 2020 at 10:27:06AM +0100, Marius Schwarz wrote:
Am 29.12.20 um 00:36 schrieb Kevin Fenzi:
>
> Yeah, workaround for now:
>
> sudo update-crypto-policies --set FEDORA:32
>
No ...
# update-crypto-policies --set FEDORA:32
Error: Unknown policy: FEDORA
Sorry, that should be:
sudo update-crypto-policies --set DEFAULT:FEDORA32
kevin
1219
days inactive
1234
days old
28 comments
11 participants
participants (11)
-
Adam Williamson -
Alexander Ploumistos -
David Both -
Gary Buhrmaster -
James Szinger -
Jerry James -
José Abílio Matos -
Kevin Fenzi -
Marius Schwarz -
Steven A. Falco -
Tom Hughes