| tonyo | wonder, what is meant by take back? | 03:34 | |
| lizmat++ | |||
| jjatria | Thanks lizmat | 09:05 | |
|
13:49
coleman left,
coleman joined
16:05
sjn left
|
|||
| tonyo | okay the stats has been caught up for a few days and it looks like the job is running well every two hours | 17:56 | |
| tbrowder__ | still seeing dups on raku.land | 19:43 | |
| tonyo | jjatria++ love raku.land | 19:48 | |
| tbrowder__ | but what causes the dups? | 19:56 | |
| tonyo: raku.land showing bailador (and maybe panda) as popular seems to show the need for some way to tag obsolete or otherwise not-to-be-listed modules in such places as raku.land | 20:00 | ||
| Bailador closed its doors years ago | 20:01 | ||
| lizmat | tbrowder__: please report any dups that you see | 20:20 | |
|
20:22
lizmat left
|
|||
| tbrowder__ | *Santagata | 20:29 | |
|
22:28
sjn joined
|
|||
| jjatria | This is a hard problem to solve, because they are not really duplicates: the duplicate author, for example, links to raku.land/zef:FRITH and raku.land/cpan:FRITH. Those are two different auths, so for Raku their distributions are different, even if they have the same name | 22:46 | |
| Unless we have a way to mark auths as being logically the same, we cannot do much other than eg. drop CPAN | 22:47 | ||
| But even then, as desirable as that might be, that doesn't really solve the problem, because this is by design: Raku is designed to support multiple ecos | 22:48 | ||
| So even if we drop CPAN, there'll still be GH. And even if we only keep zef, the problem will be the same when zefpp (or whatever) comes around | 22:49 | ||
| sjn | why not just interprete the ecosystem name (e.g. "zef:" or "cpan:") as a namespace, and make a required part of the name? | ||
| … make it* a … | |||
| also, on that note, have had a look at the PackageURL spec? github.com/package-url/purl-spec | 22:51 | ||
| … have you* had … | |||
| jjatria | But what would that solve? Because there's nothing stopping me from creating `zef:sjn` (if that doesn't already exist), even if `github:sjn` does | 22:53 | |
| And then how can we tell that those belong to the same person? | |||
| Re. PackageURLs I did! It'd be nice to add those to RL | 22:54 | ||
| I think, at least. I haven't seen that much discussion on that over on this side | 22:55 | ||
| sjn | well, if you have to have names represent the same person across ecosystems, then I think the solution would have to include a way to ensure that one namespace is fully subservient to another. (e.g. the authority of "sjn" comes from the github account) | ||
| this can be done by requiring login to the zef publishing infrastructure only using github accounts | 22:56 | ||
| jjatria | Right, but I don't think the "multiple ecosystem support" design ever really considered the possibility that there would be a "canonical" ecosystem that all the other ones would refer to | 22:57 | |
| sjn | jjatria: about PackageURLs, see github.com/giterlizzi/perl-URI-Pac...L/issues/8 for work on getting support for this into CPAN | ||
| jjatria | That feels like a pretty big design change. But if that feature existed, we could use it in RL | 22:58 | |
| Until then, I'm not sure how much RL can do about this problem... :| | |||
| sjn | jjatria: yeah, that's the problem with namespaces - either you have to allow for different people with the same id in different ecosystems, or you have to derive authority somehow | 22:59 | |
| jjatria | We have thought about the possibility of some sort of internal RL-specific user-management, but it's nice that we don't actually keep any user data (means there's nothing for us to leak), so we'd rather not have to go that way | ||
| sjn | the simplest is to accept the discrepancies, but make it visible in the tooling that there may be sources of confusion | 23:00 | |
| jjatria | For context: this has come up in the past: gitlab.com/raku-land/raku-land/-/issues/12 | ||
| sjn | yeah | 23:01 | |
| Another option (which would probably be useful wrt. the upcoming EU laws regarding supply chain security), would be to introduce ways to cryptograhpically verify authors, and then use this information to merge package entries that are published on different channels | 23:03 | ||
| personally, I think that would be fantastic, and probably the best solution to this problem | 23:04 | ||
| though not the easiest one to implement :-D | |||
| one way to do it, is to upgrade the META6.json spec to something that contains the necessary information for creating SBOM documents, and then find a way to cryptographically sign these | 23:07 | ||
| we're having discussions around these topics in the #cpan-security channel nowadays, and with FOSDEM getting a Perl & Raku devroom next year, there's a really good motivation to come to some decisions on this there, at least | 23:08 | ||
| (feel free to join the channel & discussion if these topics interest you! :-D) | 23:09 | ||
| jjatria | I'm planning to attend FOSDEM, so it'll be interesting to see what comes up then :D | 23:12 | |
| sjn | sweet! | 23:13 | |
| there's an SBOM track too, plus a track on the EU legislative landscape (which I expect to share a lot of info on supply chain-related laws coming in 2024), and a track on identity and access management... :-D | 23:15 | ||
| fosdem.org/2024/news/2023-11-08-de...announced/ | |||
| jjatria | re. your idea about author verification, etc: that's the kind of thing that cannot be implemented in RL (since we consume ecos, we don't manage them), but that if implemented RL can definitely use | ||
| I've been keeping my eyes peeled for the CfP for the Perl & Raku devrooms, but I haven't seen anything yet 🍿 | |||
| sjn | jjatria: remember, as a consumer, you can set expectations :-D | ||
| jjatria: CfP is being prepared as we speak, and should be out (hopefully) tomorrow | 23:16 | ||
| jjatria | sjn++ | ||
| sjn | discussions are ongoing in the #fosdem-organisers channel on the TPRF slack | 23:17 | |
| (happy to invite you there, if you care and have calories to spare :-D) | 23:18 | ||
| jjatria | Ah, I had joined plain #fosdem 😅 | 23:25 | |
| I feel like I'm already stretched a little thin, but I'm happy to lurk | 23:26 | ||
| lizmat | how about adding a "superseded" field to the META6.json that would be added by the author to the old distribution (e.g. on CPAN) with the auth of the new dist ? | 23:34 | |
| superseded-by | 23:35 | ||
| and/or have a list in the ecosystem repo with mapping from old to new | 23:37 | ||
| sjn | that would probably work great in addition to author verification | 23:38 | |
| another (softer) option would be a "preferred-ecosystem" or "primary-ecosystem" field, that could have values like "zef", "cpan" and "git" | 23:39 | ||
| a third option (which maybe already is supported? I don't know) may be to just allow the author to specify a primary ecosystem namespace | 23:42 | ||
| that might create some lock-in issues for the ecosystem providers, should the need to move/rename (though I guess that's unlikely) | 23:43 | ||
| jjatria | lizmat++ | 23:58 | |
| I think even if not to solve this particular issue, the `supersedes` fields and friends are a neat idea I miss from the META spec | 23:59 | ||