Good morning everyone, sitting with a coffee in the garden so we'll have a bit more time today. On 2024-08-11 05:53, David C. Rankin wrote:
Old issue and it is solely up to the powers that be.
Contrary to that I believe we have a project structure that allows for things to happen if people step up to do this. It may be apparent that I think that the request very bad idea, but if someone steps up why not. That has not happened, maybe that is a data point.
There are packages that do not exist in TW
This is why it is essential for all packages to be brought into the distribution if they have an upstream. Not the case for kde3, but for all others this allows the following...
that cause issues with with kde3 like botan/libbotan versions preventing install of the kde-gtk package (the one that works)
Angel and I spent time to bring the whole distribution to Botan 3. This was needed because Botan 2 will be end-of-life at the end of 2024 and is will be implicitly insecure after. We needed to touch keepassxc, rehex, rnp, ueberzugpp either at spec level or upstream. The whole Tumbleweed distribution now runs on Botan 3 and we could retire the legacy version. It's not really a big deal with the limited set. We completed this for Tumbleweed because we feel strong ownership for it, to keep it secure next year. Also this was something interesting to do on one or two slow weekends / evenings. With the same notion I take liberty to not care as much for legacy things - because it is not as much fun or fulfilling. In practice a kde3 hold-out represents the ask for someone to fix a problem now, possibly to do more than zero to maintain Botan 2 next year too - not something I would want to do in the context of community work. (Except of someone bakes me a cake, or similar goodwill guestures) I even made a transitional package for Botan 2 that would have keep old library consumers running, but in the context of the distribution it is no longer needed. Grab it from devel:libraries:c_c++/Botan2 and do what you need with it. Don't expect this to be there for long, and certainly not next year. The sources are there forever. This example may show the types of bugs that the project is most likely to work on, and why continued availability for development project repositories for openSUSE Leap 15.4 are not on the top of that list.
The issues creep in when CVE's would impact packages just sitting there. Like the recent xz/ssh issue or the curl issue. Then somebody would have to determine if the versions were vulnerable and rebuild. SUSE does have a vested interest in not having broken vulnerable packages laying around -- I get that.
For the packages: There is no security tracking coverage at all by anyone for packages not in a currently maintained distribution. And never for project repositories. For the CVE creep: Yes I believe that people should recognize a responsibility for the IT infrastructure they operate. At home you can run anything you want, but don't expect other people to do any work supporting that over the previous lifetime commitments. The points made were "it's not that hard", "disk space does not cost much", and "don't break my running system", "I can't upgrade because of this bug" - I will fix a Tumbleweed bug if I can, but please let's do it there and on maintained Leap releases trailing it. I also have a larger concern about habit forming that translates into engineering or business decisions.
So I see the concerns on both sides,
Insightful, yes, both sides are valid. But one is more right than the other in the grand scheme of things.
but granted, there are very few xz/ssh or curl CVE's that come along (and 15.4 wasn't vulnerable to begin with in the version of xz it had). openSUSE Leap 15.5 and 15.6 were never affected by the xz issue.
The larger concern is what once a release is EOL there will be neither tracking nor fixes. The lack of tracking alone is why upgrades should be done in due time. cya, Andreas