Release variants

We agreed that we need a way to generate different flavours of a release. This thread should include the related discussion.

Different versions of the system may vary in the kernel options, additional packages (for example debuggers in the development configuration) or configuration options. Those versions should be independent from the hardware platform.

In the discussion the following types of configurations have been discussed:

DEBUG - with additional options for development, eg. debuggers
PRODUCTION or RELEASE - to enable production options
HARD-RELEASE - production options with full hardening

Having too many options causes a risk in terms of testing coverage and increases the number of builds to be done.

This requirement is linked to the release process.

What can the different versions contain:

  • DEBUG - debuggers, additional debug options (like debug_tweaks activated by default), tracing systems. Basic hardening (kernel, compiler with options of small performance impact) activated in this version and all others.
  • PRODUCTION/RELEASE - debug options off, hardening like: root login off, safer file permissions, unneeded services removed, hardened compiler options
  • HARD-RELEASE - additionally hardened release, with options that have performance impact. Can also include secure boot, trusted execution
  • TEST - image for testing, can also include security testing (like audit tools)

Open questions:

  • do we need the debug options activated by default?
  • can the ‘release’ option be the default?
  • do we need the special hardened version? should it be the same as the release one?
  • secure boot/trusted execution: special flavour or enabled by default?
  • which version is used in the CI?

CI impact
Creating the flavours will have impact on the CI as we should test the versions we release. The differences should be as small as possible and allow dedicated tests only.

Can we use a word other than FLAVORS to avoid clashing with linux, zephyr and freertos flavors we already have? I don’t have a good suggestion of the top of my head.

Like configuration? or variant?

I like to word variant

I wonder if those are going to be separate distribution images or a new way to build the existing image set. How would the variants be realized in practice?

EDIT: and we have -tests images already, I assume this is identical to the proposed TEST variant for now.

I’d only change this to:

DEBUG - with additional options for development, eg. debuggers
RELEASE - to disable all debug options
HARD-RELEASE / PRODUCTION - production options with full hardening
TEST - image for testing, can also include security testing (like audit tools)

re: questions:

  • do we need the debug options activated by default? => I’d auto-build all variants when a tag is created (even though it’s not published outside) - as a reference, for tests etc
  • can the ‘release’ option be the default? => in most cases it’ll be used by developers, so, I’d go for DEBUG as default at the begining.
  • do we need the special hardened version? should it be the same as the release one? => see above my proposal
  • secure boot/trusted execution: special flavour or enabled by default? => only in PRODUCTION or TEST

Just my 2 cents.

secure boot/trusted execution: special flavour or enabled by default? => only in PRODUCTION or TEST

+1 (I would add "mandatory in PRODUCTION, to comply with “data protection by design and by default” principle)

I would advice us to design things we can implement.

Let’s start by having one variant, -test, which exists in our current images and see if it matches our vision as laid out by @marta. Every time we introduce another variant that is supposed to have other properties we must ask ourselves how we will make sure that those properties are upheld.

Assuming that it would be good to have all tools in the debug images and in the test images (so that they are tested!) assume that debug/test images can only contain MORE than the release/production ones?

In this case we can define the variants as:

Yes, I’ve added it because it already exists…

1 Like

About compiler options and build variants: Compiler flags to be used for All Scenarios OS

@marta @zyga This looks good. A couple of points from my side:

  1. Test images can easily be replaced with the same (main) image that includes different dependencies based on the variant (if TEST).
  2. DEBUG/PRODUCTION will be mutually exclusive, right?
  3. I think we need to start with at least DEBUG/PRODUCTION, TEST/MINIMAL.
1 Like

Yes. And it would be ideal if the test image were the main image with the test executables/libs in addition. Otherwise we might be testing a different thing than we want everyone to use…

Yes

Not sure what you mean? The alternative to have the debug and production image OR test and minimal one?

Yes - basically I think that we need initially two orthogonal build types:

  1. debug/production (changes the behavior of the OS along with building options of its software)
  2. test/minimal (dictates the composition of the rootfs)

An initial shortcut (which worked fine in the past) would be to tie debug and test options. A debug build would also bring in a rootfs with test packages. While a production build option would give you production images with production OS both for compile and runtime aspects. If that is deemed reasonable, debug/prod would be a good starting point.