Specifying the password of the SUIT private key on the command line
and thereby committing it to shell history is a security issue.
Instead ask for the password interactively when an encrypted private
key is used.
This makes it easier to work with encrypted keys and multiple keys.
The firmware binary can contain multiple public keys that are used
to verify the manifest.
The use case is that we want to include the production public key
in the debug build, so we can seamlessly update to the production
version without re-flashing the device.
If the public keys is always generated on the fly, this would still
require the production key password even for the debug build.
Instead if we store the (unencrypted) public key, we can always
include it in the debug build.
The assumption that every MCU has this feature turned out wrong. Hence,
add a feature to allow testing for support of edge triggered IRQs on
both flanks.
We had a number of issues being reported that in the end were caused
by building with a version of riotbuild incompatible with the source,
because CI and source were updated in lock-step but users forgot to
run `docker pull` to update theirs.
In addition, checking out a random old release/commit will likely fail,
as older source may contain bugs that did not trigger with older
toolchains. To reliably succeed at building, a matching version of
riotbuild needs to be used for `BUILD_IN_DOCKER=1`.
This just pins the version of riotbuild manually, so it needs to be
updated by hand in lock step with updating the docker container.
In addition, the latest image is pulled automatically on mismatch.
Ideally, this would pull the tagged image. But that fails for unknown
reason when using the documented command for this with both docker and
podman with:
manifest for riot/riotbuild@sha256:f5951bc41dfface6cac869181d703e62cbdd3b7976b0946130a38f2e658000b3 not found: manifest unknown: manifest unknown
Co-authored-by: mguetschow <mikolai.guetschow@tu-dresden.de>
The `ethernet` feature has not yet been used, so renaming it should not
cause any issue.
The goal is to eventually have a number of `netif_<type>` features that
would allow filtering boards by the time of connectivity the have.
This gets rid of a long list of boards with network interfaces and
instead let's boards (or MCUs with peripheral network interfaces)
provide the netif feature.
The apps that before used the long list are not depending on the
feature instead (in case of the default example, this is an
optional dependency).
Co-authored-by: mguetschow <mikolai.guetschow@tu-dresden.de>
Co-authored-by: mewen.berthelot <mewen.berthelot@orange.com>
