2.5.1 is out Roman =) And there are some security issues that justify an upgrade to it (to be announced)

-Kurt

Kurt, I don't want to be rude or anything. Really. But I have a few words for this. Basically, the two of us do a similar job. We gather information, hold it together, with the slight difference that you're not kicked in the butt if you miss something. You're not the one who makes or tests patches, you don't provide update packages. Your contribution to security is communication. This is a very important job that needs experience, awareness of the power of a journalist and the strong will to never abuse it. I repeat: We will not provide update packages if there is no security problem with 2.3.0p1. 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. The behaviour of software changes over versions, and part of a distributor's job is to balance stability/reliability, security and actuality. We try to fill this gap as consciously as at all possible, but providing updates for nothing but a version number plus a ton of new features doesn't help as many people as it is generally believed if the software needs more attention than just the rpm upgrade command. With these two mails you don't really support my job - it's meant to be a communication failure of some kind in the first place. Either you provide us with details of what you're talking about, privately to myself (you have the key), or to the list, I don't care. I care about security. You're the one who can help it.

Thanks, Roman.

I will allow you in the future to quote with a leading "> " at the beginning of each quoted line for better readability, conforming to written and non-written standards. You may safely remove lines that do not need quoting. Can Outlook Express be adjusted for this? Kind regards, Roman. -- - - | Roman Drahtmüller "Caution: Cape does not | SuSE GmbH - Security enable user to fly." | Nürnberg, Germany (Batman Costume warning label) | - -

You haven't read email people send me :P I missed the debian changelog thing (backporting fixes to "frozen" code and not changing version numbers) and spent the better part of a day cleaning out my inbox. Basically anytime I say something isn't perfect and problem free I get roasted (remember ssl/ssh article =). Ahwell.. I'll buy you a beer =)

Ok. I'll buy the next one. You'll suffer from the offering after round #5. :-)

There are security issues in 2.3. Just because they haven't been publically announced doesn't mean they don't exist (I've been spending entirely to much time around Theo lately =).

Ok. Specifics welcome. I've been reading half of the 500kB patch and I've seen some buffer overflow countermeasures, along with some code fixes with user's password weirdness. But digging through the patch is tideous.

Huh? I have been using ">" to indent. How the heck else am I supposed to quote, pine uses ">" as well.... You want me to use html based email and indent it or something?

No, your mail appeared just like as if you have forwarded it to me, with an additional remark (your two cents) on top of it. No quotation "> ". Maybe Outlook Express does show them differently. And nope, please don't send html mail. :o) But please forgive me if I justify your lines in the quote for readability with MUAs that do not autowrap. Roman. -- - - | Roman Drahtmüller "Caution: Cape does not | SuSE GmbH - Security enable user to fly." | Nürnberg, Germany (Batman Costume warning label) | - -

* Roman Drahtmueller wrote on Wed, Feb 21, 2001 at 00:47 +0100: Hi, of course you're right when you tell it's difficult to keep the stuff uptodate.

I repeat: We will not provide update packages if there is no security problem with 2.3.0p1.

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?

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.

fill this gap as consciously as at all possible, but providing updates for nothing but a version number plus a ton of new features doesn't help as many people as it is generally believed if the software needs more attention than just the rpm upgrade command.

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. What do you think? oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.

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 "Caution: Cape does not | SuSE GmbH - Security enable user to fly." | Nürnberg, Germany (Batman Costume warning label) | - -

On Wed, 21 Feb 2001, maarten van den Berg wrote:

Back to updates. If one day I can get a server completely up to date with just 1 wget command, and one rpm -F command that'd be perfect. Up until now I have to choose between downloading ALL and let rpm -F sort it all out, or manually (with an ftp/web client) lookup the name of the package and retrieving it with wget.

Why is this all so complicate? I think, that's why there are security announcements. Copy and paste the ftp://... line to your wget should do it. And for other updates, there is a WEB page with the right links. Really, I don't see any problem with updating... Peter -- Peter Münster http://notrix.net/pm-vcard

* Peter Münster wrote on Wed, Feb 21, 2001 at 19:56 +0100:

Why is this all so complicate? I think, that's why there are security announcements. Copy and paste the ftp://... line to your wget should do it.

That's theory. In practise you have at least to restart the service. You have to test the package, for that you need a non-productive testserver. That costs time. Remember i.e. the proftpd package. After upgrading passive FTP won't work. Bad, takes time. After upgrading the kernel freeswan won't work. Really bad, since it's difficult to recompile the kernel SRPM and freeswan.srpm. We had problems at bind updates (i.e. package splitting, at today's harddisk prices!). Sometimes configuration file syntax or semantics may change, adaption takes time. Those changes are not part of the annoucements but they should be I think. Sometimes the annouced packages came online later, the MD5 sums were wrong, the version numbers were wrong or misleading, old RPMs were announced as new ones or RPMs hab problems (especially for older SuSE versions) at installing (i.e. changes depencies). It's quite clear that such things happens. I will use the example of proftpd to explain it a litte. Proftpd had a securtiy problem. The package maintainer took the newest version and built an RPM. The version of the sources contained a little logical bug causing passive FTP to be not working. Such silly mistakes just happen, every programmer knows that. A patch was out (a time before the update came out). The pachager cannot read every mailling list, so it just may happen that buggy updates came out. (OK, I thing it's not a special thing to TEST passive FTP on a FTP server, but that's a different topic). The new RPM gets installed on a SuSE test host before publishing. If they don't install that system every time from scratch, many updated packages are installed on this test host. So the new RPMs may have new depencies (an updated lib or similar). So the package may work only on the test (or build-) host. If you install that package, you may have not updated such a package, and RPM may refuse to install, since you have an old lib (or whatever). Usually you don't even know what package you need to update to get this new version, and maybe it's not published, that may happen. All in all, you cannot expect a SuSE update to work or even that it's installable. So you need to test it for yourself, which is expensive and you cannot test is as well as SuSE could do, if they would try it, since you may have no people have enough time. A solution could be, that SuSEs test hosts get a plain installation back after testing (maybe from a disk image). But the build hosts cannot build useing insecure libs. Depencies are very complex, so it's not easily possible to make secure package without new depencies. SuSE should "diff" the depencies, announce the differences and what packages are required to solve the new depencies. You know what I'm talking about if you ever maintained RPMs for different versions in different installtions. If you do it on your own, you have a nice advance: mostly you will so all the same updates on all hosts, so you have all the same versions on every host, and you won't even notice new depencies, since they are solved on all hosts. Here we cannot rely that all admins install the same updates (especially if not security-relevant). oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.

On Wednesday 21 February 2001 19:56, Peter Münster wrote:

On Wed, 21 Feb 2001, maarten van den Berg wrote:

...

Back to updates. If one day I can get a server completely up to date with just 1 wget command, and one rpm -F command that'd be perfect. Up until now I have to choose between downloading ALL and let rpm -F sort it all out, or manually (with an ftp/web client) lookup the name of the package and retrieving it with wget.

Why is this all so complicate? I think, that's why there are security announcements. Copy and paste the ftp://... line to your wget should do it. And for other updates, there is a WEB page with the right links. Really, I don't see any problem with updating...

That may be true for servers that are kept perfectly up to date, you notice a new version, paste the URL and that's it. Fine. In reality, -at least my reality- I am confronted very often with a new (or too lax) customer who didn't upgrade his or her box. In that case I need to check the current state of the box and then have all security-patches up to this date applied. You see where the problem lies... Granted, If you only have a couple of boxen to manage and you do it meticulously, there is no problem with the current setup. If you have the -unfortunate- task of securing many boxes after the fact because the owner didn't, it's another story. Also, I tend to keep a (disk-)copy of the full DVD online on an intranet ftp/nfs server for install-purposes. Of course I need that kept up to date, so a fresh install from nfs is automatically up to date. While retrieving updates with wget, I get all symlinks too, thus double traffic. I understand and appreciate it's not a problem for you, but it may be for others, and that definitely includes me. Maarten

While people on SuSE are complaining about being stuck with an old version of (Open)SSH I've discovered Caldera doesn't seem to ship OpenSSL or OpenSSH at all. Sigh. Kurt Seifried, seifried@securityportal.com Securityportal - your focal point for security on the 'net

**strings of ones and zeros arranged themselves into a message from Roman Drahtmueller on Wed, 21 Feb 2001 16:44:49 +0100 (MET) which said... **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) Roman, and all .. I have been wondering about something related to this.... is it posible , on the website to post configuration information for updates adn security updates specifically ? A lot of self described newbies ( and more "not quite newbies" than any would like to admit ) coming in to Suse specifically and linux generally, from that "OS which shall remain nameless" MAy very well install the securith updates , and any other updates w/o any needed configuration, Either becuase they dont know things need configuring ( how many of us know "Redmond" boxes w/ gaping sucurity holes that have been "updated" regularly ???) So , at the risk of starting a flame war I wonder if their shouldn't be a degree of hand-holding on the website pages especially those that have to do w/ security?? Or perhaps a seperate section of the security updates pages ???? ( So those that already know everythign dont have to scroll past the information and be offended >heavy sigh> ) It would make my life easier soemtimes to point people at the "official" SuSE pages for the reasons the work will have to be done... ( back up your cr*p or risk losing it , because we are going to update all in house computers tonight. REason for updates are at www.suse.com/security/blah/ or something like that .. BLondely j afterthought: If everything is coming your way, you're in the wrong lane.

...

I repeat: We will not provide update packages if there is no security problem with 2.3.0p1.

So we have to wait for the next SuSE release to get important feature upgrades?

If that is SuSE policy, I will be tempted to look elsewhere.

*sigh* Go ahead and read what has been written to this thread. This is not as trivial as your single-sentence contribution might imply it is.

Egan

Roman. -- - - | Roman Drahtmüller "Caution: Cape does not | SuSE GmbH - Security enable user to fly." | Nürnberg, Germany (Batman Costume warning label) | - -

On Wednesday, February 21, 2001 11:20:54 AM -0500 Egan wrote: +------ | On Wed, 21 Feb 2001 17:08:46 +0100 (MET), Roman Drahtmueller | wrote: | | >> So we have to wait for the next SuSE release to get important feature | >> upgrades? | >> | >> If that is SuSE policy, I will be tempted to look elsewhere. | > | >*sigh* Go ahead and read what has been written to this thread. | >This is not as trivial as your single-sentence contribution might imply | >it is. | | No, it's hard work. But if SuSE wants to maintain a competitive edge, | there is no substitute for the hard work. | | Policy statements are not nearly as well received by customers, as the | hard work will be. +-----X8 I think that a certain company in Redmond has demonstrated this statement to be false. IBM developed the technique, M$ perfected it. /Michael -- This space intentionally left non-blank.

On Wed, 21 Feb 2001 16:17:42 +0000, Andreas Otto wrote:

No-one forces you to use SuSE, so if you don't like it - skip it.

So no one should ever complain, and just change products without ever saying why they were dissatisfied? No one forces you to read my emails, do they? Egan

On Wed, 21 Feb 2001 16:35:57 +0000, Andreas Otto wrote:

...

So no one should ever complain, and just change products without ever saying why they were dissatisfied?

That's not what I said.

Smiley or not, that's the way it sounds.

But this is not security related anymore and should not be discussed on this list any further.

It's hard to follow advice given by one who does not follow it themselves.

Sorry for the Off Topic response,

If you want the last word, you can post another off topic response. This is my last reply to yours. Egan

Hi all,

wrote:

...

I repeat: We will not provide update packages if there is no security problem with 2.3.0p1.

So we have to wait for the next SuSE release to get important feature upgrades?

So do you really expect a major Linux distributor who has to pay a lot of employees to upgrade packages every time a new version comes out? I mean where do you draw the line here? E.g., can we expect KDE 2.0, 2.0.1, 2.1, ... packaged for SuSE 6.1, 6.2, 6.3, 6.4, 7.0, 7.1? Remember, SuSE has to support more than one distribution, and on a number of different architectures (ix86, alpha, sparc, ppc, s390), and customers expect that a distribution is supported for about two years. And even if SuSE offers upgrades to openssh 2.5.1 this still does not free them from supporting the version shipped with the CDs, as this is what most customers use. I think what you request here simply isn't manageable. Getting security holes fixed is a reasonable approach, versionitis is not.

If that is SuSE policy, I will be tempted to look elsewhere.

You are free to do what you like - Linux is about choice ... ;-) Regards, Martin -- Martin Leweling Institut fuer Planetologie, WWU Muenster Wilhelm-Klemm-Str. 10, 48149 Muenster, Germany E-Mail (work): lewelin@uni-muenster.de

Hi Egan, On Wed, 21 Feb 2001, Egan wrote:

On Wed, 21 Feb 2001 00:47:29 +0100 (MET), Roman Drahtmueller wrote:

...

I repeat: We will not provide update packages if there is no security problem with 2.3.0p1.

So we have to wait for the next SuSE release to get important feature upgrades?

If that is SuSE policy, I will be tempted to look elsewhere.

Egan

Good point there - just take the sources and compile your own if it matters that much to you. That's the advantage of Linux - you don't have to wait, if you don't want to! ;-) For me it's much more important to have a secure server than having every new software that appears almost every day. I'll sleep quite well knowing that I don't have the latest openssh as long as my version is safe. That's why I'd rather have the suse people fix all those bugs out there than playing with all those new versions. If that's what you want, then you'll have to compile them yourself or look for a linux-vendor having all the new stuff by the next day and fixing bugs imediatly. Good luck searching! Greetings, Ralf

...

I repeat: We will not provide update packages if there is no security problem with 2.3.0p1.

So we have to wait for the next SuSE release to get important feature upgrades?

If that is SuSE policy, I will be tempted to look elsewhere.

Egan

This thread is sooo useless.. If you cant build a package, or arent able to compile software from the source, with the propper argument (installdir etc), you simply have to wait untill your vendor provides updated packages. If you NEED new funktions or something simillar .. go, and buid/make the programm. Thats the native intention of open source software. So learn how to compile things, installing isnt that hard. And please dont depend on SuSE to provide setup.exe like solutions.. Thats what allready failed on another platform so.. Just my 5 cents.. -- Mit freundlichen Grüßen Alexander Bien -- PIRONET NDH Alexander Bien - Technical Assistant - SBU Services Josef-Lammerting-Allee 14-18, 50933 Cologne - Germany mailto:abien@pironet.com - http://www.pironet-ndh.com

Hi all,

...

If you cant build a package, or arent able to compile software from the source, with the propper argument (installdir etc), you simply have to wait untill your vendor provides updated packages.

Ability to build my own packages is one thing. Time and desire to build my own packages is another. ... Thanks for the free advice.

Egan

Ok since so many people's sanity seems so depend on this new version of OpenSSH I finally took the time to build a binary RPM for SuSE 7.0. The RPM, along with the spec file, are available here: http://ifp.uni-muenster.de/~lewelin/linux/sicherheit.html It's all the way down to the bottom of the page. The RPM pretty much follows the standard paths of the previous SuSE version, except that it does NOT contain the x11-ssh-askpass executable. Otherwise, it's functional. I didn't do much testing yet, though. Don't even think of asking me for RPMs on any other platform than SuSE 7.0. This build is not supported, neither by me nor by SuSE GmbH. And don't complain if anything breaks your installation. Build options: ./configure --prefix=/usr --libexecdir=/usr/lib/ssh --sysconfdir=/etc/ssh --mandir=/usr/share/man --with-pam --with-tcp-wrappers --with-ipv4-default Read the spec file if you care about what it does to your system. BTW the only guarantee I can give is that the build host is script kiddie free (it's a non-networked VMware virtual machine ...) Have fun, Martin -- Martin Leweling Institut fuer Planetologie, WWU Muenster Wilhelm-Klemm-Str. 10, 48149 Muenster, Germany E-Mail (work): lewelin@uni-muenster.de