Bug 1769437 - Chromium missing security updates
Summary: Chromium missing security updates
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: chromium
Version: 30
Hardware: All
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Tom "spot" Callaway
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-11-06 16:02 UTC by Demi Marie Obenour
Modified: 2020-01-19 01:00 UTC (History)
3 users (show)

Fixed In Version: chromium-79.0.3945.79-1.fc31 chromium-79.0.3945.117-1.fc30
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-12-18 01:55:04 UTC
Type: Bug


Attachments (Terms of Use)

Description Demi Marie Obenour 2019-11-06 16:02:27 UTC
Description of problem:

Chromium is missing critical security updates

Version-Release number of selected component (if applicable):

77

How reproducible:

Always

Steps to Reproduce:
1. Install chromium through DNF
2. Check the version of chromium that was installed
3. Compare it against the latest version released by Google

Actual results:

Fedora’s chromium is out of date, and so insecure.

Expected results:

The versions match.

Additional info:

Fedora 30 is still supported, so I expect that it will be getting updates for Chromium.

Comment 1 Tom "spot" Callaway 2019-11-06 16:44:43 UTC
It takes more than two _days_ to build chromium across all architectures. 

As you can see here:

https://bodhi.fedoraproject.org/updates/?search=chromium

78.0.3904.70 is in testing for all active branches

78.0.3904.87 is about to go to testing for all active branches, I was just waiting for the EPEL-8 build to finish.

Comment 2 Demi Marie Obenour 2019-11-06 17:00:23 UTC
(In reply to Tom "spot" Callaway from comment #1)
> It takes more than two _days_ to build chromium across all architectures. 
> 
> As you can see here:
> 
> https://bodhi.fedoraproject.org/updates/?search=chromium
> 
> 78.0.3904.70 is in testing for all active branches
> 
> 78.0.3904.87 is about to go to testing for all active branches, I was just
> waiting for the EPEL-8 build to finish.

Would it be possible to push out packages as soon as they are built, and build x86_64 (presumably the most used) first?   If I recall correctly, one of the security vulnerabilities patched in the latest release is being exploited in the wild, so speed is critical.

Comment 3 Tom "spot" Callaway 2019-11-06 17:08:36 UTC
(In reply to Demi Marie Obenour from comment #2)

> Would it be possible to push out packages as soon as they are built, and
> build x86_64 (presumably the most used) first?   If I recall correctly, one
> of the security vulnerabilities patched in the latest release is being
> exploited in the wild, so speed is critical.

Unfortunately, it is not currently possible to do this. 

Users could manually look at an ongoing chromium build in koji and see that x86_64 has finished and download/install those binary packages by hand, but I cannot push it as an update until all supported architectures have finished. 

(This is also why I have resisted efforts to enable armv7hl support, because I believe that will almost double the time necessary for chromium builds to finish).

Comment 4 Demi Marie Obenour 2019-11-06 18:23:57 UTC
(In reply to Tom "spot" Callaway from comment #3)
> (In reply to Demi Marie Obenour from comment #2)
> 
> > Would it be possible to push out packages as soon as they are built, and
> > build x86_64 (presumably the most used) first?   If I recall correctly, one
> > of the security vulnerabilities patched in the latest release is being
> > exploited in the wild, so speed is critical.
> 
> Unfortunately, it is not currently possible to do this. 
> 
> Users could manually look at an ongoing chromium build in koji and see that
> x86_64 has finished and download/install those binary packages by hand, but
> I cannot push it as an update until all supported architectures have
> finished. 

Why is this?

> (This is also why I have resisted efforts to enable armv7hl support, because
> I believe that will almost double the time necessary for chromium builds to
> finish).

What about running all builds for all architectures in parallel?  That would require more build machines, but I don’t think we have a choice if we want to keep users safe.  Perhaps we could support cancelling (and later restarting) low-priority builds if high-priority ones (such as security patches) come along.

Comment 5 Tom "spot" Callaway 2019-11-06 18:29:46 UTC
(In reply to Demi Marie Obenour from comment #4)
> (In reply to Tom "spot" Callaway from comment #3)

> > Unfortunately, it is not currently possible to do this. 
> > 
> > Users could manually look at an ongoing chromium build in koji and see that
> > x86_64 has finished and download/install those binary packages by hand, but
> > I cannot push it as an update until all supported architectures have
> > finished. 
> 
> Why is this?

The simple answer is that koji (our buildserver software) does not "tag" a build as complete until it finishes with success on all "primary" architectures that haven't been ExcludeArch'd inside the source rpm for that build. For chromium, that means it needs to build successfully on x86_64, i686, and aarch64 (this is the slow one). 
 
> > (This is also why I have resisted efforts to enable armv7hl support, because
> > I believe that will almost double the time necessary for chromium builds to
> > finish).
> 
> What about running all builds for all architectures in parallel?  That would
> require more build machines, but I don’t think we have a choice if we want
> to keep users safe.  Perhaps we could support cancelling (and later
> restarting) low-priority builds if high-priority ones (such as security
> patches) come along.

They are actually run in parallel. aarch64 is that slow (and chromium is that massive).

Comment 6 Demi Marie Obenour 2019-11-06 18:41:55 UTC
(In reply to Tom "spot" Callaway from comment #5)
> The simple answer is that koji (our buildserver software) does not "tag" a
> build as complete until it finishes with success on all "primary"
> architectures that haven't been ExcludeArch'd inside the source rpm for that
> build. For chromium, that means it needs to build successfully on x86_64,
> i686, and aarch64 (this is the slow one). 
>  
> > > (This is also why I have resisted efforts to enable armv7hl support, because
> > > I believe that will almost double the time necessary for chromium builds to
> > > finish).
> > 
> > What about running all builds for all architectures in parallel?  That would
> > require more build machines, but I don’t think we have a choice if we want
> > to keep users safe.  Perhaps we could support cancelling (and later
> > restarting) low-priority builds if high-priority ones (such as security
> > patches) come along.
> 
> They are actually run in parallel. aarch64 is that slow (and chromium is
> that massive).

The only solutions I can think of are:

* Drop aarch64 support.  This means either leaving users with an insecure system (which is not acceptable), or pushing an update that uninstalls Chromium (probably not acceptable either).
* Make an exception to Fedora policy to allow Chromium to be cross-compiled.  Chromium should support this.

Comment 7 Tom "spot" Callaway 2019-11-06 18:56:55 UTC
We will not be dropping aarch64 support at this point. Nor will I support cross-compiling chromium. While that might save some time (a few hours perhaps), it introduces a whole new world of odd compiler related bugs.

It might be possible to see if we could request that the builder instances spawned for chromium (specifically for aarch64) are somehow provisioned heavier (more RAM, more CPU).

Comment 8 Fedora Update System 2019-12-12 14:49:03 UTC
FEDORA-2019-8f27a14efa has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-8f27a14efa

Comment 9 Fedora Update System 2019-12-12 14:49:04 UTC
FEDORA-2019-1a10c04281 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-1a10c04281

Comment 10 Fedora Update System 2019-12-13 01:48:58 UTC
chromium-79.0.3945.79-1.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-1a10c04281

Comment 11 Fedora Update System 2019-12-13 02:56:18 UTC
chromium-79.0.3945.79-1.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-8f27a14efa

Comment 12 Fedora Update System 2019-12-18 01:55:04 UTC
chromium-79.0.3945.79-1.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.

Comment 13 Fedora Update System 2019-12-19 13:49:58 UTC
FEDORA-2019-2307619ddd has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-2307619ddd

Comment 14 Fedora Update System 2019-12-20 01:50:12 UTC
chromium-79.0.3945.88-1.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-2307619ddd

Comment 15 Fedora Update System 2020-01-19 01:00:45 UTC
chromium-79.0.3945.117-1.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.


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