There should be an exception: If the version has a bug which causes trouble you should offer an update. A good example was the protftpd-update RPM which included a buggy version. That version is not able to so passive FTP, a important thing.
All people that upgraded "destroyed" their passive-FTP possibility, which is a problem that needs attention.
I far future I dream of installing the updates without haveing the fear of occuring new bugs, it's not possible to test the RPMs deeply for myself of course - that's what's SuSE is for. If a bug gets reported, an action is nessesary in such a case.
What do you think about that issues?
We provide update packages for two different reasons: 1) Bugfix 2) Update to a new version just to offer it. Examples: XFree86-4.0.x and kde2 for the not-too-recent distributions. Item 1) divides up into two major categories: a) sec fixes b) bug fixes (plain bugs) a) gets more and more attention (we're working at it), and b) is something that we just owe to our customers, especially if some bug is critical. Sometimes it takes a bit longer to have the bugfix out, but we have to live with that. In all cases, the bugfix may be faulty (see the mutt update rpm for 7.1), something that can be minimized but not excluded. Unfortunately you only see the (bad) updates that made their way through to the ftp server, but not the ones that get eliminated before.
There are thousands of people using this software, and there is no way we can afford to harrass these users by feeding them with updates that fix problems but introduce tons of new ones.
Yes, and this is a problem. There were updates that required more actions that "rpm -F", since packages got new depencies or get splitted into to RPMs or similar. It may be possible that default behaivoir changes or similar which could damage working networks - in worst case the admin wouldn't take notice to other problems.
For such cases non-security-related updates are nessecary I think.
That's true. We are about to restructure parts of the internal process of providing updates to guarantee a more sophisticated quality management.
Yep, that's an important point. On the other hand, backporting patches may be difficult and dangerous, too. So it may be the onliest possibility to annouce the needed actions. For instance, if a kernel updated comes up, the annoucement needs to point out if freeswan.o is not working with that version, and a new freeswan RPM needs to be build, even if it has no security problem. Otherwise people would upgrade, and other things stop working.
I think you test the installation of the RPMs before annoucing. If you install (especially for an older version), and the tester needs to install other things, or depenies have changed or whatever, the tester should write down how to make a workaround. That information should be part of the annoucements.
Some things are really minor issues. For example, a simple buffer overflow is very easy to fix, and the fix usually doesn't trigger another bug. In these cases where the actual change is extremely small, we don't do much testing, for the sake of saving time. It always depends on whether the package maintainer knows what he's doing.
What do you think?
I have had a brief talk to some people about the openssh thing, and it turned out that the issues are not that urgent (the bugs are mostly harmless). I've read half of the 500kB patch last night, and some oddities were fixed. Some people who had to do with the bugs said that the bug's severities were far from a root exploit. We prepare for new packages in the meanwhile.
oki,
Steffen
Thank you for the constructive thoughts.
Roman.
--
- -
| Roman Drahtmüller