[Starlingx-discuss] how to deal with loop dependent in building stage

Waines, Greg Greg.Waines at windriver.com
Fri Sep 24 12:35:10 UTC 2021


Correct, IMA is not supported in StarlingX.
Greg.

From: Scott Little <scott.little at windriver.com>
Sent: Thursday, September 23, 2021 11:14 AM
To: starlingx-discuss at lists.starlingx.io
Subject: Re: [Starlingx-discuss] how to deal with loop dependent in building stage

Thanks for the reply Jeremy, but I think your discussing the signing of packages as a whole, not the signing of files within packages.

I'm trying to learn a bit about how Linux IMA works...

The point of the feature is to have the executable files within the package (deb or rpm) carry signatures that the Linux kernel will validate before allowing the executable to run.

I'm still a little fuzzy on why the signatures on the executables need to be injected as part of packaging rather than building.  Is that a requirement for the chain of trust, or a conveniently centralized place to apply the policy to all packages?  And what does that mean for packages not directly built by StarlingX?

Perhaps it's moot.

I'm pretty sure the IMA feature is not currently supported within StarlingX.  I'm hoping Greg can step in and confirm.

Scott


On 2021-09-23 10:43 a.m., Jeremy Stanley wrote:

[Please note: This e-mail is from an EXTERNAL e-mail address]



On 2021-09-23 10:08:41 -0400 (-0400), Scott Little wrote:

[...]

Do the Debian packaging tools need to support file signatures?

[...]



In Debian more generally, packages (these days mainly just source

packages) are signed by their maintainers or uploaders as a sort of

authentication to the build and distribution infrastructure the

project maintains, but those signatures aren't really distributed to

package consumers and may be irrelevant to your effort. If you do

want to sign source packages and changes files at build time, you

can supply signing keys to any of the usual package build tools

(debuild, gbp, et cetera), but I wouldn't bother unless your

solution assumes that the rebuilders and indexers can't trust the

mechanisms by which those packages are moved between those systems.

It's important for Debian proper because they have thousands of

people uploading packages and they want to be sure the packages are

really from authorized individuals, but that's a lot different from

how StarlingX's packages are likely to be supplied.



The apt-secure(8) manpage on any modern Debian system explains the

consumer-facing archive signatures, which are over the package

indices instead of individual packages, as those include lists of

checksums for each package being distributed. Any time the set of

packages/versions within the archive changes, the index is

regenerated and signed again with the published archive key(s). This

is what users installing software from the distribution rely on to

be sure the packages they're getting are really the ones the

distribution is serving and that they haven't been tampered with in

transit. The package management tooling verifies the signatures on

package indices any time it updates them, and then relies on the

checksums included in each signed index to confirm a particular

package is authentic.



I have no idea how much of this is useful for you, but hopefully it

helps.

--

Jeremy Stanley



_______________________________________________

Starlingx-discuss mailing list

Starlingx-discuss at lists.starlingx.io<mailto:Starlingx-discuss at lists.starlingx.io>

http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss<https://urldefense.com/v3/__http:/lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss__;!!AjveYdw8EvQ!PLgEuvehtMaSlbjG9M_B5XUJRDFWNa6G-BTL2umbfcHz5qTq27RNcsTY4SIWdWTbSPs$>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.starlingx.io/pipermail/starlingx-discuss/attachments/20210924/23895d68/attachment-0001.htm>


More information about the Starlingx-discuss mailing list