| 15 Feb 2024 | |||
| tonyo | sbom? | 04:16 | |
| lizmat | software bill of materials | 08:25 | |
| sjn | tonyo: there are a couple of new laws coming in EU in 2024 that require lots of businesses to keep track of exactly what software they use, how it is put together (complete dependency tree) and use this information to regularly check for vulnerabilities | 11:49 | |
| to make this work, there are a bunch of SBOM standards and tooling out there | 11:50 | ||
| but common for almost all of them is that they try to figure out what's installed by basically looking what's there and infer things by filenames, decompiling, looking at compilation artifacts and symbols and whatever they can | 11:52 | ||
| the result is that very few (if any) can get a real idea of what's actually in use on a system | 11:53 | ||
| so that's where it's interesting for upstream publishers and package distributers (like #raku-land and the toolchains using it) can help the situation by publishing SBOM files together with the software | 11:54 | ||
| s/can help/to help/ | 11:59 | ||
| 18 Feb 2024 | |||
| tonyo | ahh gotcha | 20:00 | |
| does it expose proprietary software (eg if you're selling a product everyone knows under the hood you're just using FOSS and branding it or something)? | 20:01 | ||
| but you have everything as closed source? | |||
| sjn | tonyo: yes, though it's the seller's reponsibility to ensure any components they use are rolled into a vulnerability detection regime. Unsure if they have to share an SBOM of their product with downstream/customers, though I guess so if it's something that runs on customer equipment? | 20:34 | |
| tonyo | interesting, what prompted that in the EU? i guess i can just sesarch all of this | 20:36 | |
| sjn | a little unsure of the specifics here, though in any case that doesn't change much from an ecosystem perspective. downstream users still need to know what's going on, and if they can learn this in the form of SBOM files from their upstream providers, it'll be quite a bit easier for them (and us) | ||
| tonyo | i've done something that should help with this already, it was written initially to make a dependency graph but could help on the sbom side | 20:37 | |
| github.com/tony-o/p6-Uxmal <- this can make the graph but you can use it programmatically to just get the dep tree - not sure if it's a good starting point for the EU reqs though | 20:39 | ||
| sjn | tonyo: it started with the Log4J vulnerability some years ago, which triggered EO 14028 (Biden's "Improving the Nation’s Cybersecurity" Executive Order), followed by EU updating the NIS directive and then the Cyber Resilience Act (both two are arriving in 2024) | 20:40 | |
| tonyo | wonder if it'll stop car manufacturers from requiring a monthly subscription to fully use the thing you've bought already | 20:41 | |
| sjn | there are a whole lot of consequences coming from these laws, so getting into the material is better done sooner than later | 20:42 | |
| tonyo | gotcha, yea this looks like a massive undertaking | ||
| sjn | at the CPAN Security Group, we've tried to put together some info on these matters, and (if all goes well) we'll get to do some real progress at the PTS in April | 20:43 | |
| tonyo: I _think_ a lot can be done with just a few careful changes, actually. It really doesn't have to be a massive undertaking for the language ecosystem providers out there (e.g. the CPAN toolchain folks, and anyone involved in making the Raku ecosystem work) | 20:47 | ||
| happy to have a chat on this matter, btw | 20:48 | ||
| I'm also (ongoing) sharing my findings on the CPAN Security Group website | |||
| I, for one, would love to see some of you guys invited to PTS, to work in this stuff | 20:49 | ||
| 19 Feb 2024 | |||
| tonyo | bless, would be fun to go to another pts | 01:28 | |
| 27 May 2024 | |||
| tbrowder | if i want to work on raku.land prs, how do i do that using github? | 13:11 | |
| lizmat | you don't, you'd need to work on gitlab | 13:13 | |
| ? | |||
| tbrowder | hm, ok. i looked at lots of places comparing gitlab, github, etc. the casual survey said github is best for FOSS because of ease of use for helpers. i do think raku.land would be best if moved to github. my 2 cents | 13:55 | |
| and no offense to its developer, it's an important project but it needs love to be more useful | 13:56 | ||
| for instance, dingbats like moi need some way to have bad modules in zef/fez flagged as such. that should be relatively easy to do with zef/raku.land interface | 13:59 | ||
| lizmat | re github vs gitlab: some people do not want to be involved with Github anymore because of MS | 14:04 | |
| and we have to accept that | |||
| tbrowder | lizmat, we don't accept behavior we don't like, so, in some way, what is the difference? imho, we should be trying to unify the community to grow use of raku. splintering into little-used infra doesn't help. | 14:42 | |
| i love raku. i want to see if grow. | |||
| *it | |||
| the avg age of users is not decreasing | 14:43 | ||
| lizmat | true, but we're all volunteers, and if a volunteer decides to open source their project on a different place than that we're used to | 14:44 | |
| there's not a lot we can do but to kindly ask them if they'd be willing to move | |||
| and that question has been asked in the past, and the answer was no | 14:45 | ||
| so we will have to either live with it, or set up a similar service of your own | |||
| I chose live with it :-) | |||
| tbrowder | sigh..., ok then, thnx | 14:46 | |
| jjatria | FWIW, I think I'm on the record as saying that I don't really care where the code is hosted, but that it would be a pity if we got to a point where things _had_ to be hosted on a specific platform for them to work | 16:43 | |
| In that sense, I'm more against monopolies than I am against MS | |||
| But if there's a feature someone would want to implement on RL, and they prefer the GH interface, I'd be happy to review a GH fork and make sure the code ends up where it needs to be, even if we don't move away from GL | 16:44 | ||
| coleman | GitLab even lets you log in with a GitHub account. It's quite accessible. | 17:43 | |
| jjatria: if you haven't already, a GitLab->GitHub read-only push fork could aid discoverability. Then, if you are willing, people could indeed fork that and you could review the diffs if you so choose. But to be honest, I think we are too concentrated on GitHub, but it is hard to unwind, because we use GitHub authorization groups to govern some important stuff. | 17:45 | ||
| Actually, a pull-fork from GitHub might be easier... | 17:47 | ||
| Ah it looks like GitHub doesn't do automatic mirroring | 17:54 | ||
| 11 Jul 2024 | |||
| Hetzner is reporting an incident. But it is unclear why it would affect us. | 18:09 | ||
| 22 Jul 2024 | |||
| sjn | \o | 18:15 | |