Bug 28218 - Firefox 78.7
Summary: Firefox 78.7
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 7
Hardware: All Linux
Priority: Normal critical
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
URL:
Whiteboard: MGA7-64-OK
Keywords: advisory, validated_update
Depends on:
Blocks: 28247
  Show dependency treegraph
 
Reported: 2021-01-25 19:01 CET by David Walser
Modified: 2021-02-10 22:28 CET (History)
8 users (show)

See Also:
Source RPM: nss, firefox
CVE:
Status comment:


Attachments

Description David Walser 2021-01-25 19:01:13 CET
Mozilla has released Firefox 78.7.0 today (January 25):
https://www.mozilla.org/en-US/firefox/78.7.0/releasenotes/

Release notes not out yet.

NSS 3.61 is also out:
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.61_release_notes

NSS is failing to build locally, giving this error:
BUILDSTDERR: make[3]: *** No rule to make target '../../../dist/Linux5.7_x86_64_
cc_glibc_PTH_64_OPT.OBJ/lib/libgtest.a', needed by 'Linux5.7_x86_64_cc_glibc_PTH
_64_OPT.OBJ/freebl_gtest'.  Stop.
BUILDSTDERR: make[3]: *** Waiting for unfinished jobs....
BUILDSTDERR: make[2]: *** [../coreconf/rules.mk:44: freebl_gtest] Error 2
David Walser 2021-01-25 19:01:55 CET

Status comment: (none) => nss fails to build
Whiteboard: (none) => MGA8TOO, MGA7TOO

Comment 1 David Walser 2021-01-25 19:14:36 CET
Note from Fedora that we need to push updated crypto-policies too:
# need to update crypto-policies (20210118) as we added new
# algorithms under nss policy control
# (or all RSA and ECDSA signatures will fail)
Comment 2 Lewis Smith 2021-01-25 21:49:40 CET
David, I do not like assigning anything to you; but you have done most of the Firefox version updates... If you agree, please do that.
If not, CC'ing NicolasS who has done likewise in the past
or assign to All packagers.

CC: (none) => nicolas.salguero

Lewis Smith 2021-01-28 17:51:10 CET

Assignee: bugsquad => pkg-bugs

David Walser 2021-01-29 00:56:29 CET

Blocks: (none) => 28247

Comment 3 David Walser 2021-01-29 00:57:33 CET
RedHat has issued an advisory for this on January 27:
https://access.redhat.com/errata/RHSA-2021:0288

Security issues fixed:
https://www.mozilla.org/en-US/security/advisories/mfsa2021-04/
Comment 4 David Walser 2021-01-29 19:04:50 CET
I updated mozjs78 in Cauldron SVN to 78.7.0 as well, to be pushed when this is fixed.  gjs will need to be rebuilt against it.
Comment 5 David Walser 2021-01-30 20:18:48 CET
A new binary has been added in nss, freebl_gtest, which breaks the parallel build (in the make all step).  Temporarily disabling the parallel build and adding the binary to the files list...

Status comment: nss fails to build => (none)

David Walser 2021-01-31 04:59:14 CET

Whiteboard: MGA8TOO, MGA7TOO => (none)
Version: Cauldron => 7

Comment 6 David Walser 2021-01-31 07:44:49 CET
Advisory:
========================

Updated firefox packages fix security vulnerabilities:

When a HTTPS page was embedded in a HTTP page, and there was a service worker
registered for the former, the service worker could have intercepted the
request for the secure page despite the iframe not being a secure context due
to the (insecure) framing (CVE-2020-26976).

If a user clicked into a specifically crafted PDF, the PDF reader could be
confused into leaking cross-origin information, when said information is
served as chunked data (CVE-2021-23953).

Using the new logical assignment operators in a JavaScript switch statement
could have caused a type confusion, leading to a memory corruption and a
potentially exploitable crash (CVE-2021-23954).

Performing garbage collection on re-declared JavaScript variables resulted in
a user-after-poison, and a potentially exploitable crash (CVE-2021-23960).

Mozilla developers Alexis Beingessner, Christian Holler, Andrew McCreight,
Tyson Smith, Jon Coppeard, André Bargull, Jason Kratzer, Jesse
Schwartzentruber, Steve Fink, Byron Campen reported memory safety bugs present
in Firefox ESR 78.6. Some of these bugs showed evidence of memory corruption
and we presume that with enough effort some of these could have been exploited
to run arbitrary code (CVE-2021-23964).

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-26976
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-23953
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-23954
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-23960
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-23964
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.61_release_notes
https://www.mozilla.org/en-US/security/advisories/mfsa2021-04/
========================

Updated packages in core/updates_testing:
========================
crypto-policies-20210118-1.mga7
nss-3.61.0-1.mga7
nss-doc-3.61.0-1.mga7
libnss3-3.61.0-1.mga7
libnss-devel-3.61.0-1.mga7
libnss-static-devel-3.61.0-1.mga7
firefox-78.7.0-1.mga7
firefox-devel-78.7.0-1.mga7
firefox-af-78.7.0-1.mga7
firefox-an-78.7.0-1.mga7
firefox-ar-78.7.0-1.mga7
firefox-ast-78.7.0-1.mga7
firefox-az-78.7.0-1.mga7
firefox-be-78.7.0-1.mga7
firefox-bg-78.7.0-1.mga7
firefox-bn-78.7.0-1.mga7
firefox-br-78.7.0-1.mga7
firefox-bs-78.7.0-1.mga7
firefox-ca-78.7.0-1.mga7
firefox-cs-78.7.0-1.mga7
firefox-cy-78.7.0-1.mga7
firefox-da-78.7.0-1.mga7
firefox-de-78.7.0-1.mga7
firefox-el-78.7.0-1.mga7
firefox-en_CA-78.7.0-1.mga7
firefox-en_GB-78.7.0-1.mga7
firefox-en_US-78.7.0-1.mga7
firefox-eo-78.7.0-1.mga7
firefox-es_AR-78.7.0-1.mga7
firefox-es_CL-78.7.0-1.mga7
firefox-es_ES-78.7.0-1.mga7
firefox-es_MX-78.7.0-1.mga7
firefox-et-78.7.0-1.mga7
firefox-eu-78.7.0-1.mga7
firefox-fa-78.7.0-1.mga7
firefox-ff-78.7.0-1.mga7
firefox-fi-78.7.0-1.mga7
firefox-fr-78.7.0-1.mga7
firefox-fy_NL-78.7.0-1.mga7
firefox-ga_IE-78.7.0-1.mga7
firefox-gd-78.7.0-1.mga7
firefox-gl-78.7.0-1.mga7
firefox-gu_IN-78.7.0-1.mga7
firefox-he-78.7.0-1.mga7
firefox-hi_IN-78.7.0-1.mga7
firefox-hr-78.7.0-1.mga7
firefox-hsb-78.7.0-1.mga7
firefox-hu-78.7.0-1.mga7
firefox-hy_AM-78.7.0-1.mga7
firefox-ia-78.7.0-1.mga7
firefox-id-78.7.0-1.mga7
firefox-is-78.7.0-1.mga7
firefox-it-78.7.0-1.mga7
firefox-ja-78.7.0-1.mga7
firefox-ka-78.7.0-1.mga7
firefox-kab-78.7.0-1.mga7
firefox-kk-78.7.0-1.mga7
firefox-km-78.7.0-1.mga7
firefox-kn-78.7.0-1.mga7
firefox-ko-78.7.0-1.mga7
firefox-lij-78.7.0-1.mga7
firefox-lt-78.7.0-1.mga7
firefox-lv-78.7.0-1.mga7
firefox-mk-78.7.0-1.mga7
firefox-mr-78.7.0-1.mga7
firefox-ms-78.7.0-1.mga7
firefox-my-78.7.0-1.mga7
firefox-nb_NO-78.7.0-1.mga7
firefox-nl-78.7.0-1.mga7
firefox-nn_NO-78.7.0-1.mga7
firefox-oc-78.7.0-1.mga7
firefox-pa_IN-78.7.0-1.mga7
firefox-pl-78.7.0-1.mga7
firefox-pt_BR-78.7.0-1.mga7
firefox-pt_PT-78.7.0-1.mga7
firefox-ro-78.7.0-1.mga7
firefox-ru-78.7.0-1.mga7
firefox-si-78.7.0-1.mga7
firefox-sk-78.7.0-1.mga7
firefox-sl-78.7.0-1.mga7
firefox-sq-78.7.0-1.mga7
firefox-sr-78.7.0-1.mga7
firefox-sv_SE-78.7.0-1.mga7
firefox-ta-78.7.0-1.mga7
firefox-te-78.7.0-1.mga7
firefox-th-78.7.0-1.mga7
firefox-tl-78.7.0-1.mga7
firefox-tr-78.7.0-1.mga7
firefox-uk-78.7.0-1.mga7
firefox-ur-78.7.0-1.mga7
firefox-uz-78.7.0-1.mga7
firefox-vi-78.7.0-1.mga7
firefox-xh-78.7.0-1.mga7
firefox-zh_CN-78.7.0-1.mga7
firefox-zh_TW-78.7.0-1.mga7

from SRPMS:
crypto-policies-20210118-1.mga7.src.rpm
nss-3.61.0-1.mga7.src.rpm
firefox-78.7.0-1.mga7.src.rpm
firefox-l10n-78.7.0-1.mga7.src.rpm

Assignee: pkg-bugs => qa-bugs

Comment 7 Aurelien Oudelet 2021-02-01 15:29:12 CET
M7 Plasma x86_64, Classic ISO install.

Using QA Repo.
Update other existing is OK:
crypto-policies-20210118-1.mga7
nss-3.61.0-1.mga7
libnss3-3.61.0-1.mga7
firefox-fr-78.7.0-1.mga7

Firefox restarts. UI still in French. OK
Basic navigation OK
Bank account/SSL websites OK
Widevine DRM enabled websites OK

OK for me.
Even in Cauldron.

CC: (none) => ouaurelien

Comment 8 Morgan Leijström 2021-02-01 16:53:45 CET
M7 64 Plasma Swedish, my usual desktop system
Clean update
Restored a hundred tabs, user settings, plugins
Used today with bank sites, web order, web video... bugzilla ;)

CC: (none) => fri

Comment 9 Guillaume Royer 2021-02-02 16:46:29 CET
M7 Plasma x86_64 on VM

Using QA repo
crypto-policies-20210118-1.mga7.noarch.rpm
firefox-78.7.0-1.mga7.x86_64.rpm
firefox-fr-78.7.0-1.mga7.noarch.rpm
lib64nss3-3.61.0-1.mga7.x86_64.rpm
nss-3.61.0-1.mga7.x86_64.rpm

Firefox start correctly.
I don't saw any problems load user settings ok.
Classic navigation ok
Element web client doesn't work (since previous version)

CC: (none) => guillaume.royer

Comment 10 Aurelien Oudelet 2021-02-02 17:22:09 CET
Oh yeah, in comment 7, s/libnss3/lib64nss3 sorry.
Comment 11 James Kerr 2021-02-03 19:09:52 CET
on mga7-64  kernel-desktop  plasma

packages installed cleanly:
firefox-en_US-78.7.0-1.mga7.noarch 
firefox-78.7.0-1.mga7.x86_64 
lib64nss3-3.61.0-1.mga7.x86_64 
firefox-en_GB-78.7.0-1.mga7.noarch 
nss-3.61.0-1.mga7.x86_64 
crypto-policies-20210118-1.mga7.noarch 

no regressions observed

looks OK for mga7-64

CC: (none) => jim

Comment 12 Brian Rockwell 2021-02-04 02:57:30 CET
gnome MGA7 - phys hardware

[brian@linux ~]$ uname -a
Linux linux.local 5.10.12-desktop-1.mga7 #1 SMP Sat Jan 30 14:29:33 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux


The following 4 packages are going to be installed:

- firefox-78.7.0-1.mga7.x86_64
- firefox-en_GB-78.7.0-1.mga7.noarch
- firefox-en_US-78.7.0-1.mga7.noarch
- lib64nss3-3.61.0-1.mga7.x86_64

working for me

CC: (none) => brtians1

Comment 13 Aurelien Oudelet 2021-02-04 09:18:18 CET
Validating.
Advisory commited to SVN.

Keywords: (none) => advisory, validated_update
Whiteboard: (none) => MGA7-64-OK
CC: (none) => sysadmin-bugs

Comment 14 Mageia Robot 2021-02-04 14:41:48 CET
An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2021-0065.html

Resolution: (none) => FIXED
Status: NEW => RESOLVED

Comment 15 Thomas Backlund 2021-02-09 23:46:58 CET
the crypto-policies update that was part of this broke fips keys usage, so we will need to either fix or revert the update
Comment 16 David Walser 2021-02-09 23:50:13 CET
(In reply to Thomas Backlund from comment #15)
> the crypto-policies update that was part of this broke fips keys usage, so
> we will need to either fix or revert the update

We don't support FIPS in Mageia, and no it didn't break anything.  It was actually needed to retain compatibility with later nss versions.
Comment 17 Nicolas Lécureuil 2021-02-09 23:51:18 CET
I think in a first step we need to revert but as our QA can't test all ( or think to all ) i think we need some process on how to test some specific rpms ( crypto-policy being one of them ).

CC: (none) => mageia

Comment 18 Nicolas Lécureuil 2021-02-09 23:53:11 CET
(In reply to David Walser from comment #16)
> (In reply to Thomas Backlund from comment #15)
> > the crypto-policies update that was part of this broke fips keys usage, so
> > we will need to either fix or revert the update
> 
> We don't support FIPS in Mageia, and no it didn't break anything.  It was
> actually needed to retain compatibility with later nss versions.

we couldn't update nss w/o updating this ?
Comment 19 David Walser 2021-02-09 23:57:21 CET
See the abbreviated changelog here:
https://src.fedoraproject.org/rpms/crypto-policies/blob/22c6077e4ea098bceea92dd8c92b8ce9ff753d8c/f/crypto-policies.spec

the full commit history is here:
https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/commits/master

So it sounds like it was needed.

Status: RESOLVED => UNCONFIRMED
Resolution: FIXED => (none)
Ever confirmed: 1 => 0

Comment 20 David Walser 2021-02-09 23:58:03 CET
Why does bugzilla keep re-opening bugs?  I didn't ask it to do that.

Status: UNCONFIRMED => RESOLVED
Resolution: (none) => FIXED

Comment 21 Nicolas Lécureuil 2021-02-10 00:02:52 CET
i agree for one point. "So it sounds like it was needed." from fedora changelog.

I don't agree for "We don't support FIPS in Mageia"


I think that we need to dig and find what broke the FIPS support
Comment 22 David Walser 2021-02-10 00:11:08 CET
We definitely don't support FIPS in Mageia.  It requires patching all kinds of stuff.  I think only Fedora/RedHat supports it.  You can see the FIPS bits in crypto-policies are not in our package for this one (never have been).
Comment 23 David Walser 2021-02-10 00:38:57 CET
Here's documentation on FIPS:
https://www.redhat.com/en/blog/how-rhel-8-designed-fips-140-2-requirements

It's patched into Red Hat's kernel, and other packages are patched for it to.  Enabling fips mode (which adds a kernel command line argument fips=1) ensures your system only uses FIPS 140-2 approved encryption algorithms in certain libraries.

It can be enabled with:
fips-mode-setup --enable
update-crypto-policies --set FIPS:OSPP

but only on Fedora/RedHat, not Mageia.
Comment 24 Thomas Backlund 2021-02-10 08:28:48 CET
actually re-reading the report on cauldron shows it was not fips, it sessm to be the blind dropping of tls 1.0 support.

that should not happend in a stable release... 
we basically turned a security update into a DoS...
Comment 25 Nicolas Lécureuil 2021-02-10 09:34:53 CET
is it something that can be reenabled on our current rpm ?
Comment 26 Thomas Backlund 2021-02-10 09:37:00 CET
so basically the real bug here is pushing a new nss (that firefox build actually didnt require), and that lead to adding adding another useless crypto-policies update)

We really need to re-think bumping nss/nspr/crypto at firefox updates in stable releases...
Comment 27 Nicolas Lécureuil 2021-02-10 09:43:04 CET
and/or add basics tests to test this specific package. So if we really need to update i we make sure we do not break any already installed packages ( like nagios for ex ).
Comment 28 Nicolas Lécureuil 2021-02-10 09:50:44 CET
test by the QA i mean. This can be in a wiki page for example
Comment 29 Brian Rockwell 2021-02-10 14:55:10 CET
tls1.0

Kind of insecure, does make sense to retire that, but that is the my opinion, from the peanut gallery.

What test (website) would I run (visit) to confirm?
Comment 30 Thomas Backlund 2021-02-10 15:09:48 CET
yes,
improved security is always good.
 
I guess the biggest problem here is no notification what so ever why stuff stopped working.

a simple README.update.urpmi would have notified users what they can do instead of just sitting there wondering why stuff broke.

or they will start blocking updates, and the intended security actually goes down the drain...

we can do better than this... and this is the second time with the same package within ~half a year...
Comment 31 David Walser 2021-02-10 16:31:14 CET
Second time?  No, if this update caused any issues, that would be the first time.

I'm not happy about the upstream changes in NSS that forced us to use more of Fedora's packaging, but it is what it is.  It did simplify things in terms of rootcerts not being built into nss, so there are some advantages.  This crypto-policies package seems a bit opaque and they need to do a much better job documenting changes in it (and they shouldn't randomly make breaking changes in it).  NSS also needs to do a better job of backporting security fixes to supposed stable branches (they've done an inconsistent and bad job of this over the years).

We need our upstreams to do better.
Comment 32 Thomas Backlund 2021-02-10 16:51:20 CET
well, mozilla did not force the new nss on us, we did...

baseline nss for 78-esr is 3.53.1

so our "lets bump nss/nspr" every time a new one is out introduced new issues ...

and blindly copying fedora packages, well... once again we got screwed... and people still dont seem to learn...

and as for rebuilding for rootcerts that would not introduce regressions like this...
Comment 33 David Walser 2021-02-10 17:02:35 CET
The NSS that caused the changes was 3.53 Thomas.  There was nothing we could do about this.  As for the rest, well you're not being fair, helpful, or constructive here.
Comment 34 Thomas Backlund 2021-02-10 17:32:24 CET
but if 3.53 caused the changes, why did the build break appear first at 3.61 as reported in the start of this report?

anyway, the nss change  made us do a blind merge of crypto-policies from fedora and flushing it out here:
http://advisories.mageia.org/MGASA-2020-0377.html

breaking stuff with a forced key length update that people reported some months ago... and some certs disappearing breaking other bits...

and now the second time crypto-polices gets updated, it breaks more stuff, this time a yubikey setup that actually is for improving security is part of this update

so 2 breakages for no good reason... there is clear thread here...

we relly need to get better at this...
Comment 35 David Walser 2021-02-10 17:38:54 CET
(In reply to Thomas Backlund from comment #34)
> but if 3.53 caused the changes, why did the build break appear first at 3.61
> as reported in the start of this report?

NSS 3.53 is what stopped building libnssckbi.so and forced us to rebase our rootcerts/nss packaging on Fedora's, which use crypto-policies underneath.  There was no actual breakage report here, just something you've only vaguely alluded to which is apparently from somewhere else, but that wasn't caused directly by the change in packaging, just supposedly by a change in crypto-policies, which we're only dependent on because of the change in NSS 3.53.

> anyway, the nss change  made us do a blind merge of crypto-policies from
> fedora and flushing it out here:
> http://advisories.mageia.org/MGASA-2020-0377.html

It wasn't a "blind merge" and please stop using that phrase where it isn't correct or warranted, it's *very* insulting.

> breaking stuff with a forced key length update that people reported some
> months ago... and some certs disappearing breaking other bits...

The key length change turned out to be user error, as those two users had changed the default crypto policy on their own system.  It was not a package problem.  As for "some certs disappearing" I don't know what you're referring to.

> and now the second time crypto-polices gets updated, it breaks more stuff,
> this time a yubikey setup that actually is for improving security is part of
> this update

To be fair I've asked for people who use things like smartcards and such devices that are more deeply affected by this stuff to test going back as far as the Firefox 78 update, and nobody helped test.

> so 2 breakages for no good reason... there is clear thread here...

One, not two.

> we relly need to get better at this...

And it's easy to throw stones and cast blame where it doesn't belong, rather than dealing with the real issues.
Comment 36 Thomas Backlund 2021-02-10 22:11:02 CET
(In reply to David Walser from comment #35)
> (In reply to Thomas Backlund from comment #34)
> > but if 3.53 caused the changes, why did the build break appear first at 3.61
> > as reported in the start of this report?
> 
> NSS 3.53 is what stopped building libnssckbi.so and forced us to rebase our
> rootcerts/nss packaging on Fedora's, which use crypto-policies underneath. 
> There was no actual breakage report here, just something you've only vaguely
> alluded to which is apparently from somewhere else, but that wasn't caused
> directly by the change in packaging, just supposedly by a change in
> crypto-policies, which we're only dependent on because of the change in NSS
> 3.53.
> 

Read again please :)

here:
http://advisories.mageia.org/MGASA-2020-0377.html
we shipped: 
crypto-policies-20200813-1.mga7
nss-3.57.0-1.mga7

and they built and worked together.

then in _this_ bugreport at comment 0, you yourself state:
<quote>
NSS is failing to build locally, giving this error:
BUILDSTDERR: make[3]: *** No rule to make target '../../../dist/Linux5.7_x86_64_
cc_glibc_PTH_64_OPT.OBJ/lib/libgtest.a', needed by 'Linux5.7_x86_64_cc_glibc_PTH
_64_OPT.OBJ/freebl_gtest'.  Stop.
BUILDSTDERR: make[3]: *** Waiting for unfinished jobs....
BUILDSTDERR: make[2]: *** [../coreconf/rules.mk:44: freebl_gtest] Error 2
</quote>

and that according to your comment 1 that forced a new crypto-policies
that seems to have introduced more regressions for us...


> It wasn't a "blind merge" and please stop using that phrase where it isn't
> correct or warranted, it's *very* insulting.

sorry, I guess I get too allergic whenever I see packages pulled from fedora gets involved in broken stuff... 
it's not the first time people have re-used fedora stuff and broken working setups, without even thinking about the fallout about how they have been integrated in Mageia, and then leaving others to figure out the mess after...

So, it was not really against you... 
you just got caught in the crossfire here...
I'm sorry about flaming you on this point...

it's just that it seems fedora does not seem to care as much as us about user experience and not breaking stuff on updates/upgrades...

 
> > breaking stuff with a forced key length update that people reported some
> > months ago... and some certs disappearing breaking other bits...
> 
> The key length change turned out to be user error, as those two users had
> changed the default crypto policy on their own system.  It was not a package
> problem.  As for "some certs disappearing" I don't know what you're
> referring to.

ok, so the key length was not an issue then.
bet as guillaume pointed out here:
https://ml.mageia.org/l/arc/dev/2020-10/msg00037.html we actually dropped a rootcert we had been carrying.

Yes, Mageia was maybe the only distro carrying it, but that was definately a regression introduced in a stable update... and without notification for the enduser. and he pointed out some other reports about issues with that crypto-policies update in that thread..

> 
> > and now the second time crypto-polices gets updated, it breaks more stuff,
> > this time a yubikey setup that actually is for improving security is part of
> > this update
> 
> To be fair I've asked for people who use things like smartcards and such
> devices that are more deeply affected by this stuff to test going back as
> far as the Firefox 78 update, and nobody helped test.
>

Yes, this is one of the "we really need to get better ..."

> > so 2 breakages for no good reason... there is clear thread here...
> 
> One, not two.
>

Well,
didn't the first switch (in MGASA-2020-0377) raise security level and dropped a rootcert without notification... and got some problem reports...
the second update of the crypto stuff (this update, MGASA-2020-0377) broke a yubikey setup, and he recovered by reverting to the MGASA-2020-0377 update...

but anyway... no point in beating on that part anymore...


> > we relly need to get better at this...
> 
> And it's easy to throw stones and cast blame where it doesn't belong, rather
> than dealing with the real issues.

sorry, but here I wrote *we*. That means all of Mageia, not a specific person

This was/is basically a post-mortem about how can we (maybe) prevent this from happening again.

For example we could/should add README.upgrade.urpmi info whenever we do changes that can/will break stuff... and try to figure out / write better testing procedures to hopefully catch issues like this next time...

I see Guillaume posted questions like this on dev ml, so I guess we should move the rest of the discussion there...
Comment 37 David Walser 2021-02-10 22:28:22 CET
> Read again please :)

No need to be a smart alec, but you've misread me.

> then in _this_ bugreport at comment 0, you yourself state:
> <snip>
> 
> and that according to your comment 1 that forced a new crypto-policies
> that seems to have introduced more regressions for us...

Incorrect.  The build error in NSS is because they added a new file in NSS but their Makefiles were incorrect and it didn't work with a parallel build.  That has nothing to do with any of this and nobody ever claimed that it did.  The reasons the crypto-policies update was needed were stated in Comment 1 and Comment 19.

> > It wasn't a "blind merge" and please stop using that phrase where it isn't
> > correct or warranted, it's *very* insulting.
> 
> sorry, I guess I get too allergic whenever I see packages pulled from fedora
> gets involved in broken stuff... 
> it's not the first time people have re-used fedora stuff and broken working
> setups, without even thinking about the fallout about how they have been
> integrated in Mageia, and then leaving others to figure out the mess after...
> 
> So, it was not really against you... 
> you just got caught in the crossfire here...
> I'm sorry about flaming you on this point...
> 
> it's just that it seems fedora does not seem to care as much as us about
> user experience and not breaking stuff on updates/upgrades...

Yes but here's my problem with this.  We have been over this point several times now.  I am well aware of these issues with people actually, truly, blindly copying things from Fedora.  I am just as frustrated as you are by that, and I have stated as much on the dev list.  You have repeatedly, without justification, accused me of doing the same.  You know well enough that this is not right, and yet it keeps happening.  We should not be continually fighting over this point, when you and I are in totally agreement philosophically!

> > > breaking stuff with a forced key length update that people reported some
> > > months ago... and some certs disappearing breaking other bits...
> > 
> > The key length change turned out to be user error, as those two users had
> > changed the default crypto policy on their own system.  It was not a package
> > problem.  As for "some certs disappearing" I don't know what you're
> > referring to.
> 
> ok, so the key length was not an issue then.
> bet as guillaume pointed out here:
> https://ml.mageia.org/l/arc/dev/2020-10/msg00037.html we actually dropped a
> rootcert we had been carrying.
> 
> Yes, Mageia was maybe the only distro carrying it, but that was definately a
> regression introduced in a stable update... and without notification for the
> enduser. and he pointed out some other reports about issues with that
> crypto-policies update in that thread..

No, we discussed that further beyond that message.  He was not talking about us actually dropping any certs.  I believe we dropped CAcert.org and maybe some really old expired CA certs that weren't being used any more, but that's not what this discussion was about.  It was simply about a change in the rootcerts packaging where the individual root certs had been exposed as individual files and no longer were (but the way the package was meant to be used never relied on them).  And yes we did notify the user of the extensive packaging changes with the initial Firefox 78.x update.  As for the "other reports" it was one bug report by one user who had also changed his default policy on his own system.  It was not a packaging issue.  Also keep in mind that Guillaume likes to troll me because he hates me.

> > > and now the second time crypto-polices gets updated, it breaks more stuff,
> > > this time a yubikey setup that actually is for improving security is part of
> > > this update
> > 
> > To be fair I've asked for people who use things like smartcards and such
> > devices that are more deeply affected by this stuff to test going back as
> > far as the Firefox 78 update, and nobody helped test.
> >
> 
> Yes, this is one of the "we really need to get better ..."

Sure, and I'm equally disappointed at the lack of help in QA from our user base.

> > > we relly need to get better at this...
> > 
> > And it's easy to throw stones and cast blame where it doesn't belong, rather
> > than dealing with the real issues.
> 
> sorry, but here I wrote *we*. That means all of Mageia, not a specific person

Perhaps, but the things you were criticizing were all things that I did (and furthermore were things that were not wrong).

> This was/is basically a post-mortem about how can we (maybe) prevent this
> from happening again.
> 
> For example we could/should add README.upgrade.urpmi info whenever we do
> changes that can/will break stuff... and try to figure out / write better
> testing procedures to hopefully catch issues like this next time...

We would have to know that there is potential for such breakage to begin with.  With the Firefox 78 update, I was well aware of it and I asked for specific things that I was concerned about to be tested.  For this update, there was nothing that gave me any reason to believe that there was any potential for issues.  It's not about *us* documenting things better, it's about *upstream* (for crypto-policies specifically), that being both Fedora and the crypto-policies authors themselves, documenting things better.  That's where the issue was here.

> I see Guillaume posted questions like this on dev ml, so I guess we should
> move the rest of the discussion there...

Please don't.  I am way behind on following the dev list at the moment and don't immediately have time to catch up.  Furthermore, Nicolas pointed out to me the initial message Guillaume sent about this, which was completely full of untruths and was just an attempt by him to antagonize me, personally.

What actually needs to happen is that he needs to file a bug report upstream, as well as one in Mageia so that we can track it.  No further "discussion" is needed, especially when it is going to devolve into lies, accusations, and attacks.

Note You need to log in before you can comment on or make changes to this bug.