| # 04:38:06 | cpackham | quits : Ping timeout: 255 seconds |
| # 07:21:30 | realtime-neil_ | joins #crosstool-ng |
| # 07:21:54 | realtime-neil | quits : Ping timeout: 255 seconds |
| # 19:35:37 | cpackham | joins #crosstool-ng |
| # 19:45:38 | bhundven | milkylainen: iirc, you were asking previously about security scanning of ct-ng? |
| # 19:47:16 | bhundven | I might be wrong, and it could have been someone else. |
| # 19:48:24 | bhundven | I've been doing a lot of CI/CD work around security scanning for my work (specifically with GHA). |
| # 19:54:48 | milkylainen | bhundven: hmm? Can't say it rings a bell. But I do dabble a lot in those areas. I was hoping CVE fixes would more easily make into ct-ng, esp. glibc. Or targeting the stable branch with the fixes easier. |
| # 19:56:01 | milkylainen | We develop our own (now very large) tool to deal with devsecops. It's called MAIA. https://t2data.com/maia-software/ |
| # 19:56:36 | milkylainen | It's pretty complex. I mostly use it for CVE handling and telling me about software updates to my SBOMs. |
| # 19:57:08 | milkylainen | To the SBOM end it got a fork of that part called SBOM-central. https://t2data.com/sbom-central/ |
| # 19:57:22 | milkylainen | It's the part most people are interested in. |
| # 19:57:32 | milkylainen | heh. A whole lotta shameless plugs here. :) |
| # 19:58:09 | milkylainen | https://sbomcentral.com/ |
| # 20:00:03 | bhundven | For work we use Trivy and Twistlock |
| # 20:00:32 | bhundven | and lots of fedramp compliance stuff |
| # 20:01:26 | milkylainen | Mmm. MAIA is pretty general. I use it from the output of buildroot, yocto, ptxdist etc. |
| # 20:01:34 | milkylainen | Embedded mostly. |
| # 20:02:01 | milkylainen | But the MAIA people themselves use it otherwise. |
| # 20:02:09 | milkylainen | In another way even. |
| # 20:02:14 | milkylainen | Oh well. |
| # 20:04:11 | milkylainen | I tend to not regenerate the toolchains that often. But atleast on every glibc release. A lot of companies I've worked for are still using toolchains from the dark ages. |
| # 20:04:31 | milkylainen | Which is an interesting problem in itself. |
| # 20:05:02 | cpackham | The tricky part with glibc is that you can build the run time part for your target separate to what's in the toolchain (that's what we do at $dayjob) |
| # 20:05:41 | cpackham | Obviously the versions need to match but it is possible to add stuff that the compiler doesn't need to care about |
| # 20:05:51 | milkylainen | I know. But some use it directly from the toolchain. iirc yocto doesn't? Buildroot is optional and ptxdist always does? |
| # 20:08:30 | cpackham | I'm going to pass your shameless plugs on to the security folks at $dayjob we're starting to have a bit more of a push on making sure we're not shipping code with known exploits |
| # 20:09:59 | milkylainen | I think I'd like a new glibc option. Like "1. Released tarball, version x.y.z" and for GNU "Stable git branch, version x.y.z", then "3, vendor/custom" and "4. custom". |
| # 20:10:38 | milkylainen | I think it's already doable by pointing the vendor/custom repository correctly. |
| # 20:10:58 | cpackham | Conceptually sounds good. |
| # 20:11:30 | cpackham | I'm just not sure we can add the "Stable git branch, version x.y.z" to glibc without adding it as an option to every package |
| # 20:11:57 | cpackham | But definitely give it a go |
| # 20:12:15 | milkylainen | cpackham: Yeah. I think you came to that conclusion already. But it's still on the santa wishlist. |
| # 20:12:18 | milkylainen | :) |