Further, right now system upgrades from Fedora 32 will downgrade users to Firefox 78. There's no guarantee that Firefox can properly handle downgrade with respect to user configuration files - in fact the user profile could break as a result of the downgrade.

(In reply to Chris Murphy from comment #1)
> Further, right now system upgrades from Fedora 32 will downgrade users to
> Firefox 78. There's no guarantee that Firefox can properly handle downgrade
> with respect to user configuration files - in fact the user profile could
> break as a result of the downgrade.

No, that's not a problem, because F32 also contains just FF78 and nothing newer.

> The Fedora Workstation Working Group decided that we don't want to ship Fedora 33 with that outdated default web browser.

Is there some criterion broken? There can be some security fixes but that's just a Final criterion. Is there something else? Otherwise this might be more fit as a freeze exception.

(In reply to Kamil Páral from comment #2)
> No, that's not a problem, because F32 also contains just FF78 and nothing
> newer.

And I was wrong! F32 contains FF80 and FF81 is in testing now. So the user configuration issue during a downgrade is a real threat. Has anyone tested if it blows up?

(In reply to Kamil Páral from comment #2)
> > The Fedora Workstation Working Group decided that we don't want to ship Fedora 33 with that outdated default web browser.
> 
> Is there some criterion broken? There can be some security fixes but that's
> just a Final criterion. Is there something else? Otherwise this might be
> more fit as a freeze exception.

Do we need a criterion Kamil? If it would be some system library, then I wouldn't mind providing something, but this is about the default web browser that people use to access their online banking and so on. If it would be just one release, eg. shipping F33 Beta with Firefox 80, then we are "probably" fine with that, but this is several releases with multiple high severity CVEs:

Firefox 81 - https://www.mozilla.org/en-US/security/advisories/mfsa2020-42/
Firefox 80 - https://www.mozilla.org/en-US/security/advisories/mfsa2020-36/
Firefox 79 - https://www.mozilla.org/en-US/security/advisories/mfsa2020-30/

(In reply to Kamil Páral from comment #3)
> (In reply to Kamil Páral from comment #2)
> > No, that's not a problem, because F32 also contains just FF78 and nothing
> > newer.
> 
> And I was wrong! F32 contains FF80 and FF81 is in testing now. So the user
> configuration issue during a downgrade is a real threat. Has anyone tested
> if it blows up?

Yes, AFAIK Felipe and Neal had these problems and their profiles were nuked.

I talked to stransky and trying to help this along a bit. I've created a buildroot override for the nss build that Firefox 81 needs, and also went ahead disabled LTO for firefox (it was one of the issues blocking the F33+ builds) in https://src.fedoraproject.org/rpms/firefox/c/bcd30e838ba1620a5413970cac2334454cb2d643?branch=f33 and kicked off a new build attempt:

https://koji.fedoraproject.org/koji/taskinfo?taskID=52025342

Let's see how this goes.

(In reply to Tomas Popela from comment #5)
> (In reply to Kamil Páral from comment #3)
> > (In reply to Kamil Páral from comment #2)
> > > No, that's not a problem, because F32 also contains just FF78 and nothing
> > > newer.
> > 
> > And I was wrong! F32 contains FF80 and FF81 is in testing now. So the user
> > configuration issue during a downgrade is a real threat. Has anyone tested
> > if it blows up?
> 
> Yes, AFAIK Felipe and Neal had these problems and their profiles were nuked.

Yup, I lost everything when I upgraded from F32 to F33 on Sunday.

(In reply to Tomas Popela from comment #4)
> Do we need a criterion Kamil? If it would be some system library, then I
> wouldn't mind providing something, but this is about the default web browser
> that people use to access their online banking and so on. 

But we're talking about Beta here. I agree that for a Final release it wouldn't be acceptable (and we have that covered).

Yes, we prefer to have a criterion instead of ad-hoc decisions. It doesn't need to exist now, we can all agree that this is something we really want to do - but it should then trigger a process to define the criterion later, or make some other change, so that the next time this situation occurs, it's a systematic process instead of an ad-hoc one.

Sadly, both security and user corruption criteria are Final:
https://fedoraproject.org/wiki/Fedora_33_Final_Release_Criteria#Security_bugs
https://fedoraproject.org/wiki/Fedora_33_Final_Release_Criteria#Data_corruption

We can decide that one or both should be moved to Beta. I just want to point out that there should be a justification why we're blocking the Beta release on this.

For Beta, there is https://fedoraproject.org/wiki/Fedora_33_Beta_Release_Criteria#Upgrade_requirements :
"For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from a fully updated, clean default installation of each of the last two stable Fedora releases with that package set installed. 
The upgraded system must meet all release criteria."

One could argue that losing your user profile during the upgrade fails the "you can run the web browser" criterion, at least how people normally understand it (your changes are persisted between sessions). But it's stretching it quite a bit, this is definitely a user data corruption instead.

I think the most reasonable here is to agree that the data corruption criterion should be moved to Beta. The way it is written, it even gives us some flexibility, because we can either wait for a fix or just document it, based on how severe it is and what the milestone is.

If there wasn't the data loss scenario, I'd say "this is fine", because it's Beta and there can be a 0-day update waiting. But the data loss scenario would be really unpleasant for everyone who'd decide to upgrade to F33 Beta to test it and had their Firefox user profile nuked.

Bug 1872111 complicates this. Workstation/aarch64/images/Fedora-Workstation-aarch64-_RELEASE_MILESTONE_-sda.raw.xz is release blocking.

https://fedoraproject.org/wiki/Releases/33/ReleaseBlocking

Our blocker discussion has been split into two, unfortunately, so interested parties should also follow our blocker-review ticket here:
https://pagure.io/fedora-qa/blocker-review/issue/118

The freeze exception has been approved:
https://pagure.io/fedora-qa/blocker-review/issue/118

FEDORA-2020-299af333c6 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-299af333c6

Added the i686/x86_64 builds for now to have Intel covered at least.

Also note that https://bodhi.fedoraproject.org/updates/FEDORA-2020-99834af551 (nss update) is needed for this bug.

FEDORA-2020-299af333c6 has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-299af333c6`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-299af333c6

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

OK, arm and aarch64 builds are now fixed in firefox-81.0-6.fc33. I also went ahead and merged the firefox builds into the nss update so they go out together in the same update.

FEDORA-2020-99834af551 has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-99834af551`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-99834af551

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Discussed during the 2020-09-24 Fedora 33 Go/No-Go meeting: [0]

The decision to classify this bug as a "RejectedBlocker (Beta)" was made as a fixed package has been built and will be available in the stable repo on release day.

[0] https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2020-09-24/f33-beta-go_no_go-meeting.2020-09-24-17.00.txt

FEDORA-2020-99834af551 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.

Bug fixed, commonbugs not needed.