On Tue, Jan 21, 2025 at 05:13:07AM -0500, Neal Gompa wrote: > On Tue, Jan 21, 2025 at 4:58 AM Florian Weimer <fweimer@xxxxxxxxxx> wrote: > > * Gerd Hoffmann: > > > Note that in the go/rust world the unbundling does *not* make security > > > updates much easier. Due to the static linkling it is not enough to > > > update the buggy package. You have to rebuild packages depending on > > > the updated package too. > > > > But rebuilds can be automated. Generating patches for vendored > > dependencies may be possible to some extent (but of course the vendored > > package variants could have diverging versions). And then you have to > > integrate the patch somehow so that it is applied during %prep. This > > can be tricky to automate due to the varying preferences of package > > maintainers. > > Rebuilds can be automated, but they won't as it is right now. Existing > Fedora packaging infrastructure and rules prevent us from doing this. > There are minor changes that need to be made to our packaging macros > and policies to allow automated rebuilds, but fundamentally nothing in > use in Fedora now or being developed in the future (including Konflux) > is designed to help do this in a way that is useful for Fedora > packagers. I know that you'd like us to implement the OBS model, but you describe the state in Fedora as if everything was dire. This is pretty far from the truth. We don't have automated rebuilds, but we have mechanisms to do easy and quick rebuilds of packages. In particular with rpmautospec this becomes even easier to script. As Fabio precisly explained: On Mon, Jan 20, 2025 at 09:27:27PM +0100, Fabio Valentini wrote: > Also, in my experience, patching vendored dependencies downstream is > *really really annoying*, at least in the Rust world - because the > tools are just not made to handle the case of "vendor this dependency, > but apply this unverified patch on top of it - trust me, it's fine". > So if you need to apply any patch to a Rust library that is vendored > ... well, good luck. It *is* possible, with workarounds (disabling > checksum checks, etc.) but it's very gnarly. > > On the other hand, applying a security update for a packaged Rust > crate is basically trivial. This requires only *one* package to be > changed, and applications that statically link the library can be > rebuilt against the new version without requiring any spec changes. (That whole message is worth rereading a few times. It is very balanced and describes the tradeoffs.) We have at least two language ecosystems where the current approach with unbundling works nicely: Python and Rust. Based on the discussion so far, it seems that Golang is different and the tradeoffs fall on the side of bundling. So even if we change the rules for Golang, it seems very unlikely that we'd want to do the same for Rust or Python, so trying to push a "uniform approach" would just block any changes from happening. Zbyszek -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
