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

[Scott Little]

Thanks for the pointers

Scott

On 2021-09-23 12:11 p.m., Jeremy Stanley wrote:
> [Please note: This e-mail is from an EXTERNAL e-mail address]
>
> On 2021-09-23 11:13:32 -0400 (-0400), Scott Little wrote:
>> 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...
> Oh, thanks, I did indeed misread and thought you were asking about
> an equivalent for the signing of .rpm files (packages), rather than
> files within the packages for consumption by the kernel's integrity
> measurement. Yes very different topics.
>
>> 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?
> [...]
>
> I'm a little fuzzy on the distinction between packaging and
> building, since package building (in the Debian context at least)
> drives executable compilation via policy included within the source
> package.
>
> Anyway, this looks like a relevant feature request for it along with
> a proof of concept implementation (albeit with 7 years of cobwebs):
>
>      https://bugs.debian.org/766267
>      https://lists.debian.org/debian-dpkg/2014/08/threads.html#00006
>
> The implementation looks fairly straightforward, the file signatures
> would be generated when the packages are assembled and stored with
> the file checksums normally tracked, then at installation those
> signatures would be copied into extended filesystem attributes for
> the relevant files, to be consumed by the kernel.
>
> If this is of interest to the StarlingX community, it might be an
> activity worth reigniting in Debian. It looks like the developers at
> IBM who originally proposed support for it did not pursue it
> further, at least that I can find any record of.
> --
> Jeremy Stanley
>
> _______________________________________________
> Starlingx-discuss mailing list
> Starlingx-discuss at lists.starlingx.io
> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.starlingx.io/pipermail/starlingx-discuss/attachments/20210923/421ec4c8/attachment.htm>