The term isn't widely used, what might be common instead are rolling release systems like Arch Linux and stable release distributions like Debian. From a technical term, froozen release is equal that the End of life (EOL) is at the same date like deployment of the software.
Let me give an example: A new embedded device is sold on day 1 to the market. And the vendor explains, that the EOL for this product is also on day 1. That means, the product won't receive any updates which includes security fixes and feature improvements.
The question left open is, if such a strategy is a best practice or an anti pattern. There are many real world examples available for froozen release models like Slackware Linux (has no dedicated package manager), FreeBSD (same like Slackware) and very important most existing embedded devices are working as froozen release without mention it explicit.
From a technical standpoint a microcontroller has no update mechanism, because the installed software is a slim down version of an operating system and has no ability to change the software. Mostly the software is stored on ROM chips which can't be modified. The only option to update such embedded device is to replace the hardware physically.
Its a fact that such systems are not the exception but the normal situation in today's IoT landscape, there are billion of such devices available. There are two possible discourse space available to talk about the situation. First assumption is, that computer security is only possible by frequent software updates. This is the Arch Linux philosophy which implies that the system will become more stable with every update. The counter argument is, that froozen release is the here to stay strategy, which means, that existing embedded systems which can't be updated are more stable than Arch Linux and other rolling operating systems.
The mismatch between froozen release and rolling release has to do with the difference between software development and production environment. Software development works with a rolling release model. A certain git repository is modified every day by the programmers, they are editing the source code of the software, introducing new features and removing other parts. These source code repositories are useless for the end user, because he needs only the executable binary file which provides useful functionality. In case of Debian like stable releease management, the gap is solved with a fixed schedule. Every two years, a copy of the source code is made which gets compiled into binary files and deployed to the end user. That means, Debian users won't get any updates between two releases.
In case of a froozen release model, the freeze duration is extended. That means, the production system is static and only the upstream source code is modified. In case of embedded system the software is combined with hardware, that means the only option to get a new software version is to replace the hardware.
The interesting situation is, that its possible to design a froozen release software in a secure way. The developers need an awareness, that no further changes are possible which means, they have to program the software with security in mind and bug free from day 1. That means, the software gets deployed similar to a ROM cartridge in the 1980s. This doesn't mean, that the software is unsafe, but it means simply that a different development model was applied.
No comments:
Post a Comment