Post AWyNDFSmJFnM9uTTfc by brainblasted@crab.garden
(DIR) More posts by brainblasted@crab.garden
(DIR) Post #AWyNDFSmJFnM9uTTfc by brainblasted@crab.garden
2023-06-21T17:07:11Z
0 likes, 0 repeats
I feel like the distro model of dependencies and the rust model of dependencies are very incompatible. Not sure what the best way to meld them together is.
(DIR) Post #AWyNDGVeQ3gfP6pHmq by brion@bikeshed.vibber.net
2023-06-21T17:13:40Z
0 likes, 0 repeats
@brainblasted imo the sensible thing is to consider cargo dependencies to be part of the source of the package, that may happen to have some duplicates of files that appear in other packages but also might not, or might have the same code but compile it with different options.grab the whole deps graph and save it to a local tree to make your source package. i have the vaguest impression cargo can already do something like this, though I haven't tried it on my rust/c mixed projects yet ;)
(DIR) Post #AWyNDHL3KwntyWsKuG by bugaevc@floss.social
2023-06-23T04:13:54Z
0 likes, 0 repeats
@brion @brainblasted "some duplicates" is really an understatement, there are *so many* of them(Which means lots of software is getting written in Rust and shipped in distros, yay for that part)
(DIR) Post #AWyNDHjrqgeZDUU9aK by brion@bikeshed.vibber.net
2023-06-21T17:15:11Z
0 likes, 0 repeats
@brainblasted the only objection i can image is "what if someone uses THE WRONG CODE and it's hard for me, the packager, to replace it for non-functional reasons of purity" but that's not a use case I consider super favorable :D
(DIR) Post #AWyNDI6CVeWAKkvzOa by brion@bikeshed.vibber.net
2023-06-23T04:18:27Z
0 likes, 0 repeats
@bugaevc @brainblasted hehe true ;)on the 'it's harder to ship a single update of everything using a library' front --i will say that having standard per-language package managers, rather than, "anything goes" as in C, makes it *way* more tractable to automate discovery of vulnerable packages and dealing with either holding them for upstream updates or doing a local patchclassic distro model still doesn't save you from random vendored C/C++ ;) [without manual patching]
(DIR) Post #AWyNDIjY9LzeInLPjE by bugaevc@floss.social
2023-06-23T04:29:30Z
1 likes, 0 repeats
@brion @brainblasted why? Whatever shitty build system for C/C++ (Autotools, looking at you), the distro has the dependencies of the package figured out, it'll know which packages bundle the vulnerable dependency without asking Autotools about it.
(DIR) Post #AWyNDKZLKH17ziaI64 by bugaevc@floss.social
2023-06-23T04:29:39Z
0 likes, 0 repeats
@brion @brainblasted Fedora has "Provides: bundled(<libname>) = <version>" as a part of package metadata for example. You could do this on the distro's infra or on end user's machine too, to figure out which packages of those you have installed bundle a vulnerable dependency.
(DIR) Post #AWyNDMWw2CHO4pTOca by bugaevc@floss.social
2023-06-23T04:32:59Z
1 likes, 0 repeats
@brion @brainblasted clearly this wouldn't work (as you're saying) if the distro has no idea that a dependency is being vendored in the first place, but that's just not how packaging is done. You don't just take random crap, call configure && make && make install and call it ~~a day~~ a package.
(DIR) Post #AWyNDOWIdWxYFRBuuO by bugaevc@floss.social
2023-06-23T04:33:04Z
0 likes, 0 repeats
@brion @brainblasted You carefully study and review it, patch it if necessary to fit the distro specifics & guidelines better, and you make every effort to unbundle the bundled code and build against the system version of it. Only if it's impossible you resort to bundling, and you're very much aware that it's happening, and you mark it up in the package metadata => what I said above.