Missing sftp-server in OpenSSH RPM
Hello, I have the latest OpenSSH RPM as installed from the SuSE update FTP site. I am running SuSE 7.0 Professional. I'd like to try out the sftp server, but it looks like the support isn't included. From sshd_config: # Uncomment if you want to enable sftp #Subsystem sftp /usr/lib/ssh/sftp-server #MaxStartups 10:30:60 The file /usr/lib/ssh/sftp-server doesn't exist, however. Will an OpenSSH 2.5.1p1 RPM for SuSE 7.0 be made available with sftp server support any time soon, or should I just compile it myself? Thanks, Ian Scott
Hi Ian,
Hello, I have the latest OpenSSH RPM as installed from the SuSE update FTP site. I am running SuSE 7.0 Professional. I'd like to try out the sftp server, but it looks like the support isn't included.
From sshd_config:
# Uncomment if you want to enable sftp #Subsystem sftp /usr/lib/ssh/sftp-server #MaxStartups 10:30:60
The file /usr/lib/ssh/sftp-server doesn't exist, however. Will an OpenSSH 2.5.1p1 RPM for SuSE 7.0 be made available with sftp server support any time soon, or should I just compile it myself?
We're glad that 2.3.0 can be considered stable right now. Though, it is a bug that the files are not included in the openssh package, but this failure does not justify a security update of the package (yet). The same is valid for the new version. Security updates only increase the version number of a package if the new version fixes the bugs from the last version and if the new version does not cause any compatibility problems at last. Anyway, I'll let our package maintainer know what's the problem. Maybe he wants to make an update for 7.0... No promises.
Thanks, Ian Scott
Thanks,
Roman.
--
- -
| Roman Drahtmüller
2.5.1 is out Roman =) And there are some security issues that justify an upgrade to it (to be announced) -Kurt ==== We're glad that 2.3.0 can be considered stable right now. Though, it is a bug that the files are not included in the openssh package, but this failure does not justify a security update of the package (yet). The same is valid for the new version. Security updates only increase the version number of a package if the new version fixes the bugs from the last version and if the new version does not cause any compatibility problems at last. Anyway, I'll let our package maintainer know what's the problem. Maybe he wants to make an update for 7.0... No promises.
Thanks, Ian Scott
Thanks, Roman. --
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
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 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 =) 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 =).
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?
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?
Kind regards, Roman.
-Kurt
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
Ok. I'll buy the next one. You'll suffer from the offering after round #5. :-)
Drinking contest, right (pencil that into my schedule =).
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.
Well some old stuff that Tatu has basically said they won't be fixing, and some new stuff. Not like remote root hack, but it is an issue. Also 2.5.0 was tested against every single client/server and fully interoperated (AFAIK it's the only software to accomplish that), as well they have the sftp client now, those two alone are worth it for a major vendor I should think.
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.
Yeah sometimes outlook goofs so I ignore it (not like I can ever fix it).
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.
I have it set to wrap at 80, maybe should use 76 or something, hrmm.
Roman.
-Kurt
* 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.
Hi, the problem here is the lack of a standard, e.g. the author of a program may set the default path and SuSE (for whatever reason) put it somewhere else in the fs. That is why I use to build some programs I experienced to change often from the authors source (proftpd for example) and take responsibility for security from SuSE (but I have to admit I only do this with programs that do nat have many dependencies:)). The SuSE poeple have the ungrateful job to take care that the system as a whole is working and secure and all the apps work well together (and that it is not too hard to install). That is their disadvantage to the people developing only one program. mike
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
On Wednesday 21 February 2001 16:44, Roman Drahtmueller wrote:
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.
If I may add something that been a longtime bother to me, I think the current update solution in place lacks in several key points... [Sorry if I drift off-topic.] First, I would like it if SuSE indeed made more of a difference between bugfixes and securityfixes. Now they're in the same ftp-updates tree. An approach where there are several different trees for several different levels of severity is much more pleasant, and it helps people avoiding upgrading several huge CMap-Adobe-* rpms on systems that do not need those rpms even if they did have holes big enough to drive trucks through. What I'm wishing for is a single update-directory containing all critical-level security fixes. Preferably not divided in series sec, n1, ap etc. because it only confuses ftpclients and it doesn't matter; if it's critical that's enough, and it doesn't really matter whether it comes from n1, sec, d1 or ap. Or does it. On a side note, those symlinks are a pest too, because they're retrieved completely as well, thus take double bandwidth. (just try it with wget) [sendmail.rpm -> sendmail-8.8.8.i386.rpm] To cut this story short, I personally would be much happier with this: critical/ server/ workstation/ security/ server/ workstation/ bugfixes server/ workstation/ Oh and by the way, I think yast2 needs upgrading with a few more install choices than just minimal / default / default with office / full. Like this it is neither; minimal is too minimal for use, full is way too big, default is okay but serves only one purpose. What I miss is "server", "server w/o X", "basic FW", "complete", "multimedia", "gaming" and the like. I myself just carry a floppy around with some custom configs, but that's tedious and besides, not everybody takes that effort. 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. That ehm... suc^H^H^Hcosts time. and resources.
That's true. We are about to restructure parts of the internal process of providing updates to guarantee a more sophisticated quality management.
Keep up the good work, SuSE. Maarten
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
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.
Isn't this all going to be adressed with the YOU (Yast Online Update )? (Still waiting for my 7.1 upgrade, so I cannot check yet ;) ) Gerhard, (@jasongeo.com) == The Acoustic Motorbiker == -- __0 I realized quickly when I knew I should =`\<, That the world was made up of this 'Brotherhood of Man' (=)/(=) For whatever that means ...
* 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 Thu, 22 Feb 2001, Steffen Dettmer wrote:
* 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
Exactly, you're right! And that's why problems with too many symlinks or too many subdirs on the ftp server are without any importance... Pete -- Peter Münster http://notrix.net/pm-vcard
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
Dear Maarten, I very much agree with your sentiments, and I have attempted to provide an ad hoc solution for the benefit of users at this institution. I hope it will be rendered obsolete by whatever features SuSE provide in 7.1, though I suspect it won't. On suse.cs.rhul.ac.uk we maintain a mirror of the SuSE ftp site. The main distribution is restricted to local users, but the update sections are publicly accessable. Alongside the updates I have created directories important-7.0 and important-7.1. Every time a security alert comes out I add a link in here to the new RPM, and maybe in the future I will add some non-security updates if they seem especially relevant to users here. Anyway, I'm happy for other people to use these directories if they find them useful. You may not want to...you have no reason to trust either my competence or integrity. If so, please don't flame me. Constructive comments are welcome, and certainly I want to hear about any mistakes (the process is manual and it is easy to make errors). The directories can be found at ftp://suse.cs.rhul.ac.uk/pub/rhul_suse/ Regards, Bob On Wed, 21 Feb 2001, maarten van den Berg wrote:
If I may add something that been a longtime bother to me, I think the current update solution in place lacks in several key points... [Sorry if I drift off-topic.]
First, I would like it if SuSE indeed made more of a difference between bugfixes and securityfixes. Now they're in the same ftp-updates tree. An approach where there are several different trees for several different levels of severity is much more pleasant, and it helps people avoiding upgrading several huge CMap-Adobe-* rpms on systems that do not need those rpms even if they did have holes big enough to drive trucks through.
What I'm wishing for is a single update-directory containing all critical-level security fixes. Preferably not divided in series sec, n1, ap etc. because it only confuses ftpclients and it doesn't matter; if it's critical that's enough, and it doesn't really matter whether it comes from n1, sec, d1 or ap. Or does it.
============================================================== Bob Vickers R.Vickers@cs.rhul.ac.uk Dept of Computer Science, Royal Holloway, University of London WWW: http://www.cs.rhul.ac.uk/home/bobv Phone: +44 1784 443691
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
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.
And do you know anyone that actually runs Caldera? I don't. They haven't done anything interesting since Lizard. I think it's been over a years since the last release of their distro. They seem to either be focusing solely on embedded Linux and their new network monitoring software (Debian has a new one that is free) or they're just asleep at the wheel. As I see it, unless Caldera does something quickly to generate interest in its products it's going to become about as popular as the SCO software they just bought. ;) SuSE on the other hand was becoming known here in the US. I think the question SuSE users should ask is "Why should we keep paying these people if they aren't going to give us the support we want"? I really think someone needs to clue the folks in Germany about just how demanding American consumers really are. We want it now and we don't want excuses. I like SuSE. I'd recommend it to users over Red Hat any day. The one think I dislike about SuSE is the fact that updates/patches/fixes often take a very, very long time or don't get done at all until someone complains so much that it becomes an unavoidable issue. M
**strings of ones and zeros arranged themselves into a message from Roman Drahtmueller
On Wed, 21 Feb 2001 00:47:29 +0100 (MET), Roman Drahtmueller
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
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
On Wed, 21 Feb 2001 17:08:46 +0100 (MET), Roman Drahtmueller
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. Egan.
On Wednesday, February 21, 2001 11:20:54 AM -0500 Egan
Hi Egan,
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?
That's probably what Roman said. But you might want to read one of his last eMails and meanwhile calm down a little bit ;-)
If that is SuSE policy, I will be tempted to look elsewhere.
The grass is always greener on the other side ;-) No-one forces you to use SuSE, so if you don't like it - skip it. Cheers, Andreas -- Andreas Otto OgilvyInteractive | Floor 2, Canberra House 315 - 317 Regent Street | London W1B 2HS Reception +44 207 299 3434 | Fax +44 207 631 5050 http://www.ogilvy.com
On Wed, 21 Feb 2001 16:17:42 +0000, Andreas Otto
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
Hi Egan,
No-one forces you to use SuSE, so if you don't like it - skip it.
Ok, my mistake - the above line should have been written: 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?
That's not what I said. But this is not security related anymore and should not be discussed on this list any further. Sorry for the Off Topic response, Andreas -- Andreas Otto OgilvyInteractive | Floor 2, Canberra House 315 - 317 Regent Street | London W1B 2HS Reception +44 207 299 3434 | Fax +44 207 631 5050 http://www.ogilvy.com
On Wed, 21 Feb 2001 16:35:57 +0000, Andreas Otto
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
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?
I'm not forced, and I read them anyway. Wait and see...
Egan
Roman.
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
On Wed, 21 Feb 2001 17:34:07 +0100, Martin Leweling
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?
Since you ask where I draw it, I draw it at OpenSSH. That is a key component of security, and I would like to have sftp working without needing to build the package myself.
If that is SuSE policy, I will be tempted to look elsewhere.
You are free to do what you like - Linux is about choice ... ;-)
For now, SuSE is still my choice. Should I never complain, though, and just switch distributions the moment I become dissatisfied? Egan
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
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?
we wait until suse thinks it is time, that is what they sell us, or does anyone on this list want to have always the latest/greatest.
On Wed, 21 Feb 2001, Ralf Ronneburger wrote: this was romans note: and that is sure because he is not maintainer of openssh he does security fixes, upgrades are to be done by the package maintainer, as roman noted in his 2nd or so mail. therefore roman puts the point at the end of the sentence. this can only be done without any testing and thinking about extra (extra initialization, extra dependencies, extra documentation). this must be checked by suse, and takes time. (that is apoint too)
If that is SuSE policy, I will be tempted to look elsewhere.
you should look at the source, building one package is not really hard (./configure; make;...) but read the README, CHANGELOG to see how secure it can be.
and it is managable because it is only one package to you, and it is more secure, because it is one package which you know and can watch. suse cant watch youre system so they have to do it at tha labs and this takes time. when suse is up to my package version, i will remove it from my system and install the syse version.
-- BINGO: broaden horizons --- Engelbert Gruber ----=~ SSG Fintl,Gruber,Lassnig A6140 Telfs Untermarkt 9 Tel. ++43-5262-64727 ----=~
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
On Thu, 22 Feb 2001 09:49:15 +0100, "Alexander Bien"
So we have to wait for the next SuSE release to get important feature upgrades?
This thread is sooo useless.
Then why are you prolonging it?
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. Why do I want to pay SuSE $80 for every new release if I have to do a lot of work myself?
Just my 5 cents..
Thanks for the free advice. Egan
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
participants (18)
-
Alexander Bien
-
Andreas Otto
-
Bob Vickers
-
Egan
-
engelbert.gruber@ssg.co.at
-
Gerhard den Hollander
-
Ian Scott
-
jfweber@eternal.net
-
Kurt Seifried
-
maarten van den Berg
-
Martin Leweling
-
Michael Salmon
-
Mr. M
-
Peter Münster
-
Ralf Ronneburger
-
Roman Drahtmueller
-
Steffen Dettmer
-
Thomas Michael Wanka