Commit f3d0e3d1 authored by Denis Pynkin's avatar Denis Pynkin

updates-rollback: improve the OSTree description

* add some details about OSTree static deltas usage
* some typos fixups
Signed-off-by: default avatarDenis Pynkin <denis.pynkin@collabora.com>
Signed-off-by: Emanuele Aina's avatarEmanuele Aina <emanuele.aina@collabora.co.uk>
Reviewed-by: Frédéric Dalleau's avatarFrédéric Dalleau <frederic.dalleau@collabora.co.uk>

Be more explict about invalid updates
parent f701d7c5
......@@ -206,7 +206,7 @@ In this case, all user data and all system configuration will be destroyed.
### Kernel requirements
The kernel must have a minimal level of functionnality, it must be able
The kernel must have a minimal level of functionality, it must be able
to connect to the internet and provide a way so that the update system
can recover to the latest or last known good configuration.
......@@ -349,7 +349,7 @@ reserve for rollback). The fallback image would take around 300
Megabytes for a system this size. It is probable that final images will
be less than half this size. Some research shown that it is possible to
strip a system down to 50 Megabytes, but this is at the expense of
functionnality. The full system partition can hold several OSTree
functionality. The full system partition can hold several OSTree
deployments. The use of hardlinks reduces the space needed to store
those.
......@@ -649,8 +649,9 @@ As discussed in the security design, there is a chain of trust that
needs to be validated so that only authentic and valid packages reach
the device.
The root of that chain is the OSTree repository, which provides a GPGP-signed
`summary` file that contains a list of all static deltas, along with their
metadata checksums.
`summary` file that contains a list of all static deltas and references, along
with their metadata checksums. Each commit must be GPG-signed with the key trusted
by the system update manager.
For system-wide upgrades a simple HTTPS service will be required to
provide the repository. For greater
......@@ -684,13 +685,16 @@ daemon would look for files with a specific name pattern in the root of
the drive. If an appropriate file is found, it is checked to be a valid
ostree static bundle with the right metadata, and if that verification
passes, the user would get a notification saying that updates are
available from the drive.
available from the drive. If the update file is corrupted, is targeted
to other platforms or devices, or is otherwise invalid, the upgrade
process must stop leaving the system unchanged and a notification may
be reported to the user about the identified issues.
Upon telling the system that the upgrade should be started the user
would be asked not to remove the drive, and a similar upgrade procedure
as described in the previous sections would be carried out (with the
notable exception that the files will be used directly from the
device instead of dowloaded to internal storage), with an announcement
device instead of downloaded to internal storage), with an announcement
at the end that it is safe to remove the drive. If the user ignores the
previous warning and removes the drive while the upgrade is still
running the upgrade will be stopped.
......@@ -715,9 +719,21 @@ image for decompression.
Care will be taken during the installation to only read the contents of
the mass storage device once, performing verification and decompression
in a single pass. This could potentially result in invalid files being
written to an inactive system volume, but the boot flags will never be
set to allow launching the invalid subvolume.
in a single pass.
OSTree static deltas can provide the GPG signature for the contained commit
as inlined metadata to check if the file is provided by a valid provider and
its integrity.
The signed commit is unpacked to a temporary directory and verified by OSTree
before being integrated in the OSTree repository on the device,
from which it can be deployed at the next reboot.
This is the same mechanism used for commit verification when doing OTA upgrades
from remote servers and provides the same features and guarantees.
Usage of inlined signed metadata ensures that the provided update
file is aimed to the target platform or device.
### Update procedure temporary storage requirements
......@@ -822,8 +838,10 @@ On the server, OSTree commits can be signed using GPG. GPG ensures that the
commit was not modified, damaged, or corrupted.
This occurs via the `ostree gpg-sign` command line.
On the client, GPG is also used to ensure that the updates comes from a trusted
host. OSTree searches for keyring files in
On the client, GPG is also used to ensure that the commit comes from a trusted
provider since updates could be acquired through different methods like OTA over
a network connection, offline updates on plug-in mass storage devices,
or even mesh-based distribution mechanism. OSTree searches for keyring files in
`/usr/share/ostree/trusted.gpg.d`. Any public key in a keyring file in that
directory will be trusted by the client. No private keys should be present in
this directory.
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment