-
Notifications
You must be signed in to change notification settings - Fork 410
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wip/hughsie/fwupd sync.service #6337
base: main
Are you sure you want to change the base?
Conversation
…ranch This allows the device to set a branch (e.g. the modem carrier configuration) and for the client to be able to *downgrade* the firmware version to make the device work.
@superm1 insane? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens when PK authentication is required? There could potentially be devices that need PK in the update.
Ohh for downgrade -- maybe we could run the -sync service as root always? |
A service that runs as root and potentially fetches stuff from the web? I'm a bit wary of that. |
Ew, indeed -- agreed. I guess it could work for things we already have in the cache -- e.g. an "offline only" mode -- we already store the firmware .cab for all modem carrier configs and so that's more likely than you'd expect. Similarly for a BKC, in that case a directory remote is going to be much more common as you probably don't want random things downloading GBs of data without some kind of user confirmation. |
How about instead having a mode for the daemon to auto-sync without a client? |
Thought about it more, here's my idea. When a bkc is specified in fwupd.conf you change fwupd refresh service behavior to cache not just metadata but also anything that is part of the bkc. The daemon reads the same key and if those devices show up will automatically upgrade/downgrade to match them. It will also forbid clients from upgrading/downgrading them manually. |
Type of pull request: