[Tom]
> This analysis provides a bill of
> materials that enables vulnerability assessments to be performed when
> security weaknesses are identified in common components.

This sort of tighter understanding of what the build system is doing -- from the part of any tool claiming to understand (at some level) what the software is supposed to do without running it -- is necessary when considering the direction of the regulations that the software industry is headed. We might just as well embrace it and make good use of it.

-- Gaby


-----Original Message-----
From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Tom Honermann via SG15
Sent: Wednesday, December 13, 2023 8:41 AM
To: sg15_at_[hidden]
Cc: Tom Honermann <tom_at_[hidden]>
Subject: Re: [SG15] Proposal for module metadata format to be used by the std library and others

On 12/13/23 8:58 AM, Ben Boeckel via SG15 wrote:
> On Wed, Dec 13, 2023 at 07:17:16 +0000, Olga Arkhipova via SG15 wrote:
>> Thanks, Daniel, for writing all this down.
>>
>> Looks like there is not much difference between library manifest and
>> module metadata currently. So I think it should not be much harm in
>> threat it as a library manifest v0, we can always ignore fields later
>> if we decide otherwise.
>>
>> If we do it as a library manifest, we have to have the library name
>> there. Besides being useful in diagnostic messages and output location
>> (and we do use it in current MS implementation), it is needed to allow
>> future library reference resolution. At least on Windows the location
>> of the manifest does not give any information about the library it
>> represents, so we need it in the manifest itself.
> Given this context from the original email:
>
> * Module discovery should be subordinate to ABI decisions having been made
> already. The outcome is that we don't expect the module metadata to be used
> to discover which ABI settings are available for a given standard library
> or how to choose between them. The way that this manifests is that,
> following the lead from P2577R2, we expect the libraries to ship those
> metadata files on a one-to-one mapping with the library binary used as
> input to the linker.
>
> the "module metadata" will be found based on the library in use, so it
> seems redundant to me. Or are there tools that want to discover modules
> without reference to the library in use that...still care about library in
> some way? It seems to be backwards because one cannot just divine object
> code availability like that; you have to work with confines the ABI
> decisions made in the SDK offering (if you care about the library).
> Static analysis may want to "play pretend" to analyze alternative ABIs,
> but they don't care about the library AFAIK.

A bit of a tangent related to static analysis being ambivalent with
regard to libraries...

Historically, static analysis has been blissfully unaware of program
composition from a linkage perspective, but there are good incentives in
place for that to change. Coverity now supports an integration with
Black Duck that allows for Coverity's build capture to record how TUs
are compiled to object files which are then composed into libraries
which are then linked into programs. The primary motivation for that
support is to enable software composition analysis of both source and
binary files used in an application. This analysis provides a bill of
materials that enables vulnerability assessments to be performed when
security weaknesses are identified in common components. A secondary
motivation is to enable more efficient analysis by only analyzing TU
groups that are actually combined into a program and to prune false
positives that can result when TUs that are never linked together are
analyzed as a group (this can happen when a primary source file is
compiled in multiple distinct ways for different purposes or for
different targets; static analysis has to pick one variant and does not
necessarily have sufficient information to pick the right one in the
absence of linkage information).

Tom.

>
>> {
>> "version": 1,
>> "revision": 0,
>> "library": "unique name like Microsoft.STL",
>> "library-common-name":"std"
>> "c++": {
>> "modules": []
>> }
>> "referenced-libraries":[] <-- not present for std libs, but other libraries can reference "std" and other libs.
>> }
> Standard libraries may have library dependencies (e.g., `libstdc++` may
> use `libc` or `libatomic` to implement its APIs). If the answer is "but
> they won't have modules", are we saying that this is only relevant for
> module-providing referenced libraries? Then it seems quite inadequate
> for packaging. I'd say let's leave CPS to tackle package descriptions
> and this to handle what-modules-do-we-have-to-consider once we've
> determined what libraries to use (via CPS, innate knowledge of
> platforms, .pc files, user-specified dependencies, etc.).
>
> --Ben
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
_______________________________________________
SG15 mailing list
SG15_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/sg15