Riverbend's Desktop Migration and the Vendor-Bundled Runtime
Riverbend's IT department is migrating 260 front-desk workstations in three service centers from Windows to a Linux distribution. Two applications drive the plan. First, the property-tax client is a vendor-supplied Java application certified only against Java 8; the vendor ships a 480 MB tarball that bundles its own copy of OpenSSL 1.0.2 and a handful of .jar files. Second, the city's in-house permit portal is a Python service that depends on a library the distribution already packages at a newer major version. The distribution's Java 8 packages are still maintained, but its OpenSSL is 3.0 and its Python library is two major releases ahead. The vendor refuses to certify any runtime it does not bundle. The migration team has one budget cycle, no vendor-source access, and a requirement that security patches reach workstations within 14 days. A proposal circulates to ship the tax client as a Flatpak and the portal as a distribution package.
1. Classify the software in this migration by layer and explain which update path applies to each layer.
Read the worked answer
The stack separates into layers with different owners:
- Firmware/BIOS on the workstations: patched by the hardware vendor, outside the distribution and outside the 14-day window unless the hardware vendor cooperates.
- OS kernel and userland (
apt/dnfpackages): owned by the distribution, which is the only layer that can realistically meet a 14-day patch SLA. - Runtime/middleware: Java 8 and the Python interpreter. The distribution's Java 8 packages follow the distro patch flow; the vendor-bundled JRE and its OpenSSL copy do not.
- Applications: the tax client and the permit portal.
The judgement is that 'the application' is not one unit. The portal's dependency on a distro library keeps it inside the distro patch flow; the tax client's bundled runtime pulls part of the stack out of that flow, so it needs a separate patching agreement or isolation. A plan that treats all software as 'the distro's job' will silently leave the tax client on an unpatched OpenSSL.
2. The tax client bundles OpenSSL 1.0.2 while the system provides 3.0. Explain the risk and the realistic options for meeting the 14-day patch window.
Read the worked answer
Bundling OpenSSL decides who patches it. A shared system library gets one security update that every dependent picks up, and the distribution tracks CVEs; a private copy is frozen at whatever the vendor shipped. OpenSSL 1.0.2 left upstream support at the end of 2019, so no new fixes will appear there - the 14-day requirement is unachievable for that component unless the vendor backports fixes itself.
Also note that 1.0.2 and 3.0 are not ABI-compatible. You cannot satisfy the vendor by pointing its loader at the system 3.0 library; forcing it would risk silent runtime failures rather than a clean error.
Realistic options: (1) contract the vendor for a patching commitment and indemnity; (2) run the client in an isolated runtime on a segmented VLAN so an exploit has limited reach; (3) replace the client. Overlaying the system library is the one option to reject.
3. Evaluate Flatpak for the tax client and a distribution package for the portal. What principle should guide the choice?
Read the worked answer
Different packaging for different jobs:
- Tax client (desktop): Flatpak fits. It gives the app a private runtime with the old libraries, so it does not fight the system's OpenSSL 3.0, and the desktop can still be patched independently. The catch is that the Flatpak runtime itself must be a maintained branch - check its support window and make runtime updates part of the 14-day process.
- Permit portal (server): Flatpak is a desktop technology and the wrong tool. Either port the portal to the current distro library (preferred, keeps it in the fast patch path) or ship it as a container with pinned dependencies and a documented rebuild cadence.
The principle: isolation buys compatibility at the price of moving patch responsibility to whoever owns the bundle. Choose isolation where you cannot port, and only with a named owner for updates.