we need more standardized BOM reporting. a common signal "kill -s BOM <PID>" that has the process dump it's BOM to /dev/ttys3 . the lowest-level most common / primitive interface. no APIs, exec()s needed.

75% of the problem is the detective work identifying among 1000 dependency trees running in your datacenter, and reporting the BOMs typically requires a bespoke step for each one. Every process should take a dump-BOM signal to make gathering the BOM from every cpu common , quick & instant.

▲

Normal_gaussian 3 hours ago | parent | next [-]

Its probably better to embed clearer strings in the binary that conform to some spec. Then searching over binaries would find them.

Trying to respond to a signal is a nightmare of routing and lifecycle bugs. Never mind the fact that most dependencies won't be registered. Currently file/process signature matching is ok for major runtimes, and tends to fail on specific version detection. This would effectively formalise that.

I could see it being a successful standardisation for major runtimes and many libraries that wouldn't currently be detected - but take up would never be universal. A kind of CVE search stamp.

▲

tonymet an hour ago | parent [-]

if it's in the elf then the kernel could handle the interrupting. that way every app wouldn't need to implement the handler. just a named BOM symbol and when the kernel sees the `kill -s BOM <PID>` it reads that BOM symbol without calling any app code.

	▲	tonymet an hour ago \| parent [-]
		but there needs to be a way to query the running tasks so the control plane could query running VMs without querying the FS

▲

kg 3 hours ago | parent | prev [-]

You'd still need a spec for this because of cross-language considerations, but that doesn't make it a bad idea.

i.e. if an app is written in javascript and running on mac there are potentially 4 different languages all running inside the executable that need to cooperate to handle the BOM signal and report their deps - C/ObjC, Swift, C++ and JS. Presumably you'd want to report not only the native libraries being used in the process but also things like npm packages.

	▲	tonymet 3 hours ago \| parent [-]
		Good point on that. The bom signal could be relayed. E.g. for a runtime, or multi tenant app, the parent runtime would relay the bom signal. Presumably the runtime would have the loaded symbol table, which could be used in lieu of a BOM summary.