Is there a way to support a downgrade with offline updates? The scenario being a version being released and installed prior to discovering a significant bug in the software. The desire would be to allow installing an older version than what is currently installed. Currently aktualizr will not install an older version and displays a log message accordingly.
Hi, I’m the Toradex AI Assistant.
I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.
Did you like my answer? 
Hello! Thank you for your question.
In TorizonCore’s secure offline update system, downgrading to an older software version using offline updates is intentionally prevented as a security measure to protect against downgrade attacks (source). When you distribute a new lockbox (which packages your updates), older lockboxes (and the versions they contain) are automatically revoked. As a result, devices that have already received newer updates will not accept older versions, and aktualizr (the update client) enforces this policy.
If you discover a significant bug in a released version, the recommended approach is to:
- Remove the problematic version from the lockbox.
- Create a new, fixed version (e.g., replace 1.7.4 with 1.7.5) that addresses the bug.
- Prepare and distribute the updated lockbox to your devices.
This keeps the update flow secure while allowing you to quickly address critical bugs (details).
In summary, downgrades are not possible by design, but you can always address issues by releasing a new version through the lockbox update process.
Best regards,
Toradex AI Assistant.
Greetings @gfrrankel,
I see you marked the AI’s response as a solution. Is everything clear for you now?
Just to be clear as the AI’s response is somewhat incorrect in my perspective.
You can issue an update for “older” software. Our update client doesn’t really have a perception of what is “older” and what is “newer”. The only thing that matters is what is currently installed and what is being requested in the update. If what is being requested is different than what is currently installed it should perform the update.
For example if you do an offline update from version A to version B, then later you realize you want to go back. You would just do an update from version B to version A. For offline updates this would mean you need to create a new Lockox containing version A, since the Lockbox you used to go from A to B, only contains version B. Does that make sense?
Currently aktualizr will not install an older version and displays a log message accordingly.
Could you elaborate on this point please. Sharing the exact log message would help with clarity. As I said Aktualizr should allow this, as long as what you are requesting to be installed is not the same as what is currently installed on the device.
Best Regards,
Jeremias
I have only tried inserting an SD card with the previous version.
We were hoping for a way a customer could rollback in this scenario.
I have only tried inserting an SD card with the previous version.
I’m still not sure I’m fully understanding you regarding your procedure in this case. You inserted an SD with a previous version of what exactly? What did you observe? What were the logs from this operation? What were your full steps?
We need precise details so that I can understand your setup and what you did.
We were hoping for a way a customer could rollback in this scenario.
As I said prior, this is possible if you create a fresh Lockbox that contains the version of the software that you want the device to update to.
Best Regards,
Jeremias
Hi @gfrrankel,
Just wanted to check in and see if you had a chance to look over my previous reply along with my questions.
Best Regards,
Jeremias
The behavior I have seen is exactly as you described. The use case we are trying to accommodate is this:
- A new version is released to our customers and installed
- A customer discovers a major bug
- The customer has the option to rollback to a previous version (Instead of waiting for us to deploy a new one)
Hi, @gfrrankel,
I just tried this use-case and it works fine.
I did a docker-compose offline update to a version A, then I did another update to a version B. I was able to then do an “update” back to the previous version A and it works fine.
Do note you may need to re-download the Lockbox containing version A for the update to succeed. Offline updates Lockboxes contain metadata specific to the time the Lockbox was download with TorizonCore Builder. So if you downloaded Lockbox A 1 month ago, then downloaded Lockbox B yesterday for example. And you try to go from B back to A, there may be an error during the update cause you can’t go backwards on metadata. Packages you can go backwards, metadata you can’t. Therefore just re-download Lockbox A and it will contain the old package, but with new updated metadata.
Do you understand?
Best Regards,
Jeremias
Thank you for the information. We will be providing all package files to our customers, they will not have the ability to access the lockbox. Yes we could quickly provide a new version once we know about it but they will not be able to rollback themselves in the meantime.
Hi @gfrrankel,
I’m confused now, you said:
We will be providing all package files to our customers, they will not have the ability to access the lockbox.
What do you mean by this exactly? If your customers will not have access to the Lockboxes, how will they do offline updates at all?
A Lockbox is required to perform an offline update. You can’t just give them the raw package.
Yes we could quickly provide a new version once we know about it but they will not be able to rollback themselves in the meantime.
Again, I’m not saying you give the customer a new version. You just need to give the customer a freshly downloaded Lockbox, containing the OLD VERSION, of whatever you want to rollback to. Then they perform an offline update using this Lockbox, and it will “update” to the old version. Effectively rolling-back the device to an older version of the software.
I feel as if there is a fundamental misunderstanding here. Would a call to explain things be of interest to you and your team?
Best Regards,
Jeremias
We will providing all upgrades as zip files for them to download and install. You have answered my question, customers will not be able to rollback without action on our end beforehand.
For the record, I already have upgrades working from zip files that were generated from the lockbox results.
Hi @gfrrankel,
You have answered my question, customers will not be able to rollback without action on our end beforehand.
I mean you’d have just have to re-download and provide customers with a Lockbox for the old version. Since you already have a process for giving them the upgrades, is it different than giving them the “downgrades”?
Keep in mind that allowing customers to arbitrarily rollback software on their own, comes with security risks. This would mean customers or potential attackers would have an avenue to rollback software to a previous version that has known vulnerabilities.
This is why we suggest doing another “update” to downgrade your software to a previous version. This way the change in software is verified and validated through the usual update mechanisms.
For the record, I already have upgrades working from zip files that were generated from the lockbox results.
Please elaborate on these “zip files” you are talking about. Are we still talking about the offline updates feature provided by Torizon Cloud?
Are you putting the Lockbox files inside zip archives?
We want to help you achieve your use-case, and it sounds possible to do. But we really need to understand what you’re doing here.
Again I would recommend a call so we can go over your use-case and come to a mutual understanding on how you can achieve your goal.
Best Regards,
Jeremias
1 Like