I don't think we have all that many security-specific updates, but since we update so frequently, we do have a lot of updates with security-related fixes. Probably the majority of releases have a security fix of some sort, though maybe not always a high severity one, and given the number of commits that go into each release, I don't think we have a good way to identify when a particular release may or may not contain such a fix. We could probably create such a thing, by looking up the bugs for each new commit in a release, and seeing if any have a security label, but there is no such process now, and it would be a pretty substantial change to our build process to add it.

Also there's the issue that we don't release every build, so if there's a security patch in 1.0.0.1, but we don't release that for some reason, and instead release 1.0.0.2, which has no other security fixes, any process looking for security fixes would need to know to compare 1.0.0.2 against the 1.0.0.0 version, and not against the unused 1.0.0.1 version. And then there's the issue that some of the builds happen when a release is still being qualified, so if the 1.0.0.3 build compared itself against 1.0.0.0, because 1.0.0.2 hadn't actually gone live yet, it might think it's a security release, even though it might not have any new security fixes beyond what is already in, and about to be pushed with, 1.0.0.2.

Basically, it's complicated, and short of marking every release as a security release, I don't know that there's a good way to apply this flag to Chrome.

Ok, if it's this complicated I would just mark all the stable releases as the security ones as this would basically solve the issue. The thing is that some users are only installing the security updates and with the current workflow they are missing the updates for Chrome.

Note that it's not just users who intentionally only install security updates. GNOME Software delays notification about non-security updates for up to a week, whereas security updates get an immediate notification.

Oh, how about this. Mark all non-.0 builds as security releases. This would cover all stable and beta releases, and a good chunk of dev (unstable) releases. It's not exactly true that all incremental releases have security fixes, or that no .0 releases have them, but it's probably as close as we'll get with a generic rule, and it would ensure that all channels get flagged periodically, and thus more people would get updated sooner.

I think that we need to mark only the stable releases as the security ones as the beta and dev one are not intended for general use - are used by developers, beta testers, .. .

The way how you build and publish the RPM packages is a black box for me, but I thought it works this way:

1) build the packages with src/chrome/installer/linux/rpm/build.sh (this script knows which channel it builds)
2) generate the updateinfo.xml for it
3) upload RPMs and updateinfo.xml to the repo

If it works like this, then marking only the stable builds as the security ones should not be that hard, but as I said I don't know the infrastructure.

Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Still valid