Hi Folks,
Currently there are a some ciritical security issues for Firefox and Chrome-Based Browsers already seen in the wild. There is a hotfix for this and it’s also in snapcraft.
this is good so far, but snap refresh tells me “All snaps up to date” which simply is a lie, since It’s missing the security fix!
When I do a sudo snap refresh --stable firefoxit tells me that “cannot refresh “firefox”: snap “firefox” has running apps (firefox)”
If I wasn’t looking for it explicitly, I would not have noticed. This is a huge security issue in my opinion.
In my opinion:
A Package Manager must not lie to me
I must not be forced to check every installed package for Updates. If I really want to do this, I can still use Windows.
I see you’re incurring in some misconceptions here.
Snap is not lying to you when it says all your snaps are up to date; problem lies in your interpretation of “up to date”. When refreshing, Snap contact the store on internet and checks that versions of all packages you have installed on your machine matches the most current one on the store. Whether this means that a specific package on the store have or haven’t been patched for some vulnerability is the responsibility of the publisher, not Snap.
This is, in essence, no different from other very known package managers (in their default configs) such as Apt and Yum. In the end, they check versions of your installed packages with distribution packages - and that not necessarily means distribution’s are the newest, upstream patched versions. Main difference, when it comes to Snap, is that the figure of “publisher” is very different (in general) from Apt or Yum: in the latters, publisher means distro maintainers, as on Snaps it generally means upstream directly or package creator, and those might not have any connection with distro at all.
In your specific case, whene Mozilla (the publisher of Firefox Snap) releases a patched version of the package, youl’ll get it.
For the second point: you don’t even need to check for it yourself, as Snap does this several times a day and updates automatically. In fact, many people hate this so called “Windows behavior” of auto update, but you can disable this if you want (this toggle is somewhat recent, but it’s there).
If you want to check your system against know vulnerabilities, there may have free tools to help with this, but that’s outside of package managers scope (generally speaking).
He said that the update is already in snapcraft. The fact that he tried to update firefox directly confirms this - instead of an error like “no updates”, he can’t update because firefox is already running.
Apparently, he is really right here: snap says that everything is updated and at the same time marks packages that it cannot update as “everything is fine”.
This is really misleading.
In the second case, the fact that the snap package is running already makes it impossible to update it (both manual and automatic way).
This is a feature of snap packages (which, IMHO, is a disadvantage).
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 snapcraft.io-Version 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.
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.
Note that some snaps use phasing to roll out updates… so the Metadata on snapcraft.io 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)
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 …
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).
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”.
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
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: https://bugs.launchpad.net/snapd/+bug/2019158. 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 (https://www.mozilla.org/en-US/security/advisories/mfsa2023-40/), 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
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 …
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: https://bugs.launchpad.net/snapd/+bug/2019158/comments/21
