Refresh-"Awareness" kills Security


Thank you for clarifying. As you wrote, there was an updated package available on the store. I know that snap only knows about things in the store and on my computer. I checked the before the update and I checked my Firefox version - even the channel.

So I knew, there should be a way to update FF to the safe version. Running snap refresh --stable firefox was actually just a lucky guess that led me to the source of the problem - I had no clue, why snap didn’t update my packages before. If I hadn’t known of and looked for this particular update, I would have thought I’m on the current version and safe.

At least snap should tell me “I skipped the package firefox because it’s running”. Then I can close it and update again. Having an option to say --f...orce it would even be better. Most people running refresh manually do this, when they can handle disruptions from updates.

Btw: This is default behaviour in Ubuntu 22.04 so a lot of people are affected by this - in this case especially those who update their system by hand.

1 Like

A side-note: i think the title of the thread is not good. I do not see why refresh-awareness (which is a specific feature) is the problem here. Actually it should be the solution for many users.

In my view: The firefox snap should have given you a notice that you should restart firefox (didnt it do this? - would consider that a bug in the firefox snap)

I agree that snap refresh should give a better indication if and why it skipped a refresh. I am actually aware of at least two reasons why new revisions are not available for install/refreshes get skipped (being in a different cohort or snap on hold). Actually i use a wrapper for snap refresh, which calls snap refresh --list before actually calling snap refresh. So I get a list of refreshables and then I see what actually got refreshed.

Maybe ‘snap refresh does not give an indication that SECURITY relevant revisions are skipped’ would be a better title.

1 Like

Note that some snaps use phasing to roll out updates… so the Metadata on might show a new revision but your local machine might still be behind the phasing barrier…IIRC if you properly use snap refresh --list locally, that even tells you about the phasing status…

Note also that this is not snap specific at all, apt does exactly the same (if you would go to the package page on launchpad you would see the newer revision while your local update call would not see it yet and you need to use the apt policy <package name> command to see its phasing state)

I’m really not sure how security relevant this is since phasing usually delays a release by 24h max if you are on the low end of the phasing randomization…

The problem is that snap only shows the update when it can update it. If it can’t update it, it still says everything is fine. If you close the app and run refresh - the update succeeds.

I don’t see this having anything to do with local availability of updates.

And it’s this “everything is fine” when, in fact, the refresh can happen but only if the application is closed that is misleading.


yes, exactly like apt does it … locally you will only see the update once it is actually available, launchpad will already show the new revision … (apt has the big disadvantage that it uses dependencies which will even tell you a package is “uninstallable” (held back) when a dependency is in phasing)

both tools have ways to check for phasing with less well known commands (apt: apt policy <packagename>, snap: snap refresh --list) that should probably be better documented … but in either case, both package systems will not phase longer than 24h which is really not a security issue, especially in the light that typically highly critical vulnerabilities will simply not be phased but be immediately rolled out and in the case of snaps will be automatically applied (unless you disallowed this in which case i’d expect you to know what you are doing and to also know about phasing and the --list option … if you don’t, then do better not disable automatic updates)

The problem is that a new version is available.

But snap cannot update it, because the snap package is currently running, and snap cannot update (or postpone updating) packages that the user has now triggered to update.

I agree that automatic updates will cover these security gaps… but this does not negate the fact that when snap cannot update the package (because the application is running) and says that “everything is updated” is misleading.


These are two completely distinct things … if the snap sees an update because it is up in line for the phasing, it tells you about the fact that the application is running and asks you to close it (it even shows the PIDs of the running processes) … this either happens automatically, where you get a desktop notification to please close the app, or manually, were you call snap refresh and get the message on cmdline in return …

note that the problem as described by the OP has absolutely nothing to do with refresh app awareness, things have been mixed up there … refresh app awareness has exactly the two features i described above … either showing a desktop notification in the GUI or telling you on cmdline to close the app when an update is available … it is solely a UI messaging thing in context of the detected update and has no influence on anything else …

The prob of the OP is that the update is not detected, refresh awareness is a stand alone feature only kicking in after an update was detected, it has no ability to “hide updates” or in any way take influence here

The issue i see here is that someone relied on the metadata from the website, which does not reflect the local status that would have been shown by snap refresh --list (including the phasing info) … and i agree that we should solve this discrepancy (i.e. not show updated metadata while phasing is still in progress), but there is no security issue here unless you forcefully disable auto-updates and do not know what you do when applying them manually …

I was not lazy and started a VM with the Live version of Ubuntu 22.04

  1. I started firefox and tried to update it via snap refresh. Everything updated except firefox.
  2. An attempt to repeat refresh also showed that everything was supposedly updated.
  3. However, if I specify snap refresh firefox, then it will say that there is a problem.
  4. But even after that, a repeated snap refresh will tell me that everything is fine.

And only when I close firefox, I will launch an update and finally see that, it turns out, there is an update and it will launch it (although it was before that).

I repeated the situation of OP.

The message “All snaps are up to date” is not true and user does not need to know the special --list key to detect that “Not all snaps are up to date”.

1 Like

Right, but this has still nothing to do with refresh-app-awareness which is solely responsible for the UI messages (either in the terminal or as a message on cmdline were it asks you to please close the app) …

the bug lies in the refresh handling itself or in the interaction with the phasing :slight_smile:

Do I understand correctly that what I have indicated (and what OP pointed out) is considered an error/bug?

The connection to refresh-app-awareness probably comes from the fact that prior to its introduction a global snap refresh would indicate if any app could not be updated because it was running. In this situation, snap is clearly aware that there is a pending update (which it indicates when doing a specific app refresh), so it should also show the same message during a global app refresh. In that sense, the refresh-app-awareness introduced a regression.

The issue raised here is further compounded by this bug, for which a fix should hopefully be coming soon: While the title is perhaps a bit sensationalist, I do agree that the current update situation for firefox is quite problematic. The refresh-app-awareness system currently does not function properly for firefox because closing the browser when notified of an update will not actually trigger an automatic update as happens for other snap apps (due to the staged roll-out feature for firefox). Then, because of the issue raised in this post, a global sudo snap refresh while firefox is still running leads one to believe that firefox is up-to-date when it is not. Indeed, it may actually lead one to believe that the refresh-awareness mechanism worked when an update was in fact never applied.

That means that, currently, users need to actively close firefox and run sudo snap refresh to ensure that they are using the latest version of firefox, which I doubt many people are aware of. As a result, many users may not currently receive updates in a timely manner. That is problematic given e.g. the recent webp zero-day vulnerability that is being exploited in the wild (, which I suspect is the issue referred to by the original poster. Perhaps the fix for #2019158 could be expedited to help alleviate this concern while the original behavior of sudo snap refresh is restored?


There is clearly some bug somewhere (as you have proven by reproducing it) and looking above it has already been filed, lets leave it to the snapd team to decide where exactly it resides :slight_smile:

feel free to click the “affects me too” at the top of the bug page to raise its heat …

It does work for me here just fine for firefox … (and i guess for the devs that maintain it as well, else it would have been noticed earlier) … it works likewise well for chromium or any other GUI app when it is open here for me …

Is that on the stable channel or edge? I believe the fix has already landed on edge but is not yet in stable.

And I should add that the issue with the refresh-app-awareness system is specific to firefox, not to other apps. This is apparently due to the fact that firefox uses a throttling mechanism (in addition to or instead of staged roll-out). This specific comment has more details:

1 Like

Hmm, my snapd is on stable on all my machines…

ogra commented on the bug/bugfix which made firefox misbehave (which looks it will be in snap 2.61). It fixes some interaction with the store where firefox uses some throttling feature for staging releases. From the bugfix PR description:

But what you write is the another issue - the default output of snap refresh. If I remember correctly, output got minimized so it does not interfere with CI builds(?). I think the default should not be so silent (rather provide a flag for silent/CI) or it would be good to have different commands (like apt is for humans, apt-get… are for machines/scripts). But I am unsure how to proceed. Maybe a feature request?

There is a simple solution

But it relies on old and almost unused warnings code which may be buggy.
Also users will be required to execute snap warnings to see what is wrong.

$ sudo snap refresh
WARNING: There is 1 new warning. See 'snap warnings'.
$ snap warnings
last-occurrence:  today at 11:17 UTC
warning: |
  cannot refresh "snapname": snap "snapname" has running apps (appname), pids: 1374296
1 Like

Sorry if I blamed the wrong function for the problem.

There are new Security updates so I checked again and either the problem isn’t firefox itself, or chromium has the same issue:

# snap refresh	
Alle Snaps sind aktuell.
# snap refresh --list
Name      Version        Rev   Size   Publisher   Notes
chromium  117.0.5938.92  2642  162MB  canonical✓  -
firefox   118.0-1        3166  251MB  mozilla✓    -
# snap refresh
Alle Snaps sind aktuell.
# # closed chromium
# snap refresh
chromium 117.0.5938.92 von Canonical✓ aufgefrischt

refresh says “All snaps are up to date” but refresh --list tells another story: neither chromium nor firefox are up to date.

Knowing about --list is helping here, but I strongly believe the default should at least a “There are updates pending, try --list for details” or similar and not a “All snaps are up to date” which is clearly false and misleading.

Ps: Sorry for the german output, I forgot to change locale.