At 10:33 AM 1/29/2002 +0100, you wrote:
Does/will Yast online update support HTTP (or at least http proxy)?
yes, they added http support with one of the latest YOU updates, however you cant' choose it - it only ususes it when it wants to. SuSE doesn't have HTTPD running on any of their FTP servers either (wish they did)
As ftp is a weird protocol anyway, I don't think it should be used so much, especially for important things like updates.
They should use scp :-)
I have some servers behind an MS Proxy Server and can't use online update, because yast doesn't support any proxy, and socksify + bouncer on a machine with MS Proxy client installed doesn't work, too (http/ssh works thoug). And once again, why is YOU not half as cool as apt-get ??
Because the people who are working on it don't seem to care enough. It's slowly getting better but I really don't understand why a little more effort isn't put into it, since it's a highly sought-after feature. Anyway, that's not the worst of YOU's problems - it uses it's own internal patch manager and never consults rpm. Due to this, a patch is always marked as "installed" unless you do some hacking. For instance the other day I fried my MySQL installation while testing and had to do an ftp reinstall from yast1. It installed the old original versions of MySQL & Co., and when I opened YOU the mysql updates that I _knew_ where there where not available to be selected. I had to hack some things to get YOU to wake up. This is very bad. Also if you download, say 5 updates (this actually happened to me) and during the install part rpm gives an error, say on the second package, the installation ceases (i.e. the remaining packages do _not_ get installed) yet YOU marks them as successfully installed anyway. This actually happened to me when I way trying up update at, netscape, openssh and w3m at the same time. The NS package was corrupt, and YOU just skipped over sshd and w3m without mentioning it. I only realized what was happening because YOU "finished" the installation too fast. If I had not been paying attention I would have _thought_ I'd upgraded sshd and would in fact have still been using the old version. This is very bad. I have submitted several bug reports to feedback@suse.com and bugs@suse.de and not heard back from them. I have a serious mind to submit this to BugTraq in the hope of forcing SuSE to do something about it. I've never done anything like that before - do you think I should? It's really quite important and SuSE _need_ to fix it. I'm not sure if it's serious enough for BugTraq though. JW ---------------------------------------------------- Jonathan Wilson System Administrator Cedar Creek Software http://www.cedarcreeksoftware.com Central Texas IT http://www.centraltexasit.com
On Tue, 2002-01-29 at 10:32, JW wrote:
Anyway, that's not the worst of YOU's problems - it uses it's own internal patch manager and never consults rpm.
What?!?!?! Holy crap... There are a number of dependencies I've resolved and indeed packages I've installed by searching the 'Net and rpm'ing into place, both from the command-line and using GUI package managers. It was my expectation with these tools, and with YOU, that the underlying rpm-database was sound, current, and accurate.
I had to hack some things to get YOU to wake up. This is very bad.
I agree! Wholeheartedly! Sync'ing should never be a problem, because a tool like YOU (or Webmin) should sit atop the database.
Also if you download, say 5 updates (this actually happened to me) and during the install part rpm gives an error, say on the second package, the installation ceases (i.e. the remaining packages do _not_ get installed) yet YOU marks them as successfully installed anyway.
Separate problem, to be sure, but again "Holy Crap!" :-(
This is very bad.
I did not know about these problems... Yes, I agree these are really serious issues, Jonathan. -Gord -- Gordon Pritchard, P.Eng., Member IEEE Technical University of B.C. - Research Lab Engineer mailto:gordon.pritchard@techbc.ca direct phone: 604-586-6186
At 10:48 AM 1/29/2002 -0800, you wrote:
On Tue, 2002-01-29 at 10:32, JW wrote:
Anyway, that's not the worst of YOU's problems - it uses it's own internal patch manager and never consults rpm.
What?!?!?! Holy crap...
There are a number of dependencies I've resolved and indeed packages I've installed by searching the 'Net and rpm'ing into place, both from the command-line and using GUI package managers. It was my expectation with these tools, and with YOU, that the underlying rpm-database was sound, current, and accurate.
I would like to point out here that I'm only referring to Yast Online Update, not the rest of YaST2 which does an admirable job of handling rpm. Which is why I don't understand the absurd patch handling of YOU - quite obviously the YaST2 programmers know how to work with rpm.
I did not know about these problems... Yes, I agree these are really serious issues, Jonathan.
Does anyone think I should post to BugTraq? Or is there a better place then that for these kinds of issues? I suppose I should start with suse-linux-e.... ---------------------------------------------------- Jonathan Wilson System Administrator Cedar Creek Software http://www.cedarcreeksoftware.com Central Texas IT http://www.centraltexasit.com
Hi Jonathan, just my 2 cent:
Does anyone think I should post to BugTraq? Or is there a better place then that for these kinds of issues? I suppose I should start with suse-linux-e....
No, calm down a little bit, the problem had time until you wrote to suse-security@suse.com about it, so it might just wait for some time to give the people at suse a chance to fix it. Besides that I agree a lot with the critism about YOU that was stated here, I really think that there has to be done a lot to make it faster and more secure. On the other side - I only use YAST2 on my workstation and as long as it does as it should. Everything else is done by YAST1 - that is always an option if YAST2 doesn't do as you like. And although it's not click and go it does as it's supposed to. I hope SuSE does not drop it somewhere in the future! Best regards, Ralf Ronneburger ------------------------------------------------------------ Ralf Ronneburger ralf@ronneburger.de Prefers to receive encrypted Mail, download public-key from http://www.ronneburger.net/gpg/ralf_ronneburger.asc ------------------------------------------------------------
Hi Ralf, I totally agree with you about the usefullness of yast1 and would really love to see it preserved and supported also in the future. Not in every ocasion one is able to launch yast2, even though it looks nicer... What about complains here (YOU does not do this and that and is a, to quote - "HOLY CRAP") - are you people *linux* users or what? If you don't like it - don't use it! If you like it in general but think it can be improved - take it and make it, period. I'm sure guys at SuSE will not hasitate to thank you for the help as well as other people who use it later! You may know that SuSE team is amazingly small for such a nice, robust and advantageous product they make. And if for this or that reason they can't get their hands on a certain thing - give them a credit of time, at least! I'm not talking about security-related stuff (again - one have to take care to report it correctly), but the rest (http, proxy blablabla support) is certainly not anything really missing. Would be good to have it, later :) Sorry for getting slightly offtopic! Eduard __________________________________________________ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com
What?!?!?! Holy crap...
There are a number of dependencies I've resolved and indeed packages I've installed by searching the 'Net and rpm'ing into place, both from the command-line and using GUI package managers. It was my expectation with these tools, and with YOU, that the underlying rpm-database was sound, current, and accurate.
What makes you think differently? besides, would somebody please answer this question: Why would anybody use an (semi-) automatic update mechanism for some specific package "abcpack" if you manually install newer versions of the package (which, in turn, can't be made by SuSE)? In addition to that: If you install your own package, then you can't claim SuSE to be responsible for the lack of proficiency on your side. If you change stuff in the system (be it exchanging a file that belongs to the rpm subsystem) and expect that things are still the same as before, then you are clearly wrong. Most of these little accidents are intercepted by the framework (rpm subsystem, yast, yast2, scripts, ...), but it is impossible to handle all of them. The better some software is, the better it can handle faulty situations. The only thing that is merely impossible to handle are defects that are caused by a human.
I had to hack some things to get YOU to wake up. This is very bad.
I agree! Wholeheartedly! Sync'ing should never be a problem, because a tool like YOU (or Webmin) should sit atop the database.
It does.
Also if you download, say 5 updates (this actually happened to me) and during the install part rpm gives an error, say on the second package, the installation ceases (i.e. the remaining packages do _not_ get installed) yet YOU marks them as successfully installed anyway.
Separate problem, to be sure, but again "Holy Crap!" :-(
This is very bad.
Indeed. To quote: "Holy Crap!"
I did not know about these problems... Yes, I agree these are really serious issues, Jonathan.
-Gord
Roman. -- - - | Roman Drahtmüller <draht@suse.de> // "You don't need eyes to see, | SuSE GmbH - Security Phone: // you need vision!" | Nürnberg, Germany +49-911-740530 // Maxi Jazz, Faithless | - -
On Tue, 2002-01-29 at 11:24, Roman Drahtmueller wrote:
What?!?!?! Holy crap...
It was my expectation with these tools, and with YOU, that the underlying rpm-database was sound, current, and accurate.
What makes you think differently?
Only JW's comments and observations. I don't yet think differently, but my spidey-senses are tingling. My opening expression of surprise was simply that I hadn't heard of problems with YOU, much less first-hand experience.
The better some software is, the better it can handle faulty situations. The only thing that is merely impossible to handle are defects that are caused by a human.
Hehehe! -Gord -- Gordon Pritchard, P.Eng., Member IEEE Technical University of B.C. - Research Lab Engineer mailto:gordon.pritchard@techbc.ca direct phone: 604-586-6186
At 08:24 PM 1/29/2002 +0100, you wrote:
There are a number of dependencies I've resolved and indeed packages I've installed by searching the 'Net and rpm'ing into place, both from the command-line and using GUI package managers. It was my expectation with these tools, and with YOU, that the underlying rpm-database was sound, current, and accurate.
What makes you think differently?
Dude, you didn't install any non-SuSE package with YOU. And I wasn't talking about the rest of YaST1/2 - I was referring to YOU only.
besides, would somebody please answer this question:
Why would anybody use an (semi-) automatic update mechanism for some specific package "abcpack" if you manually install newer versions of the package (which, in turn, can't be made by SuSE)?
I'm having trouble understanding what you're asking. If you're asking why you would use a tool like apt to auto-install packages, it's called time, and ease-of-use. Go ask a Debian user why they like it, they could probably explain it well.
In addition to that: If you install your own package, then you can't claim SuSE to be responsible for the lack of proficiency on your side.
If this is any refereance to me (not sure if it is or not) the answer is I didn''t and I wouldn't
If you change stuff in the system (be it exchanging a file that belongs to the rpm subsystem) and expect that things are still the same as before, then you are clearly wrong.
Obviously. Any sane system admin would understand that, I hope. <snip>
I had to hack some things to get YOU to wake up. This is very bad.
I agree! Wholeheartedly! Sync'ing should never be a problem, because a tool like YOU (or Webmin) should sit atop the database. It does.
Eh? No it doesn't.YaST2 and YaST installers do, but YOU does not, unless you are referring to the installation of the downloaded package (with rpm). As far as determining what needs to be downloaded/installed, ig goes by the files in /var/lib/YaST/patches/i386/update/7.3/patches/, not by rpm. Am I really the first one out of all of you to run into this? Tell me it's not true... ...? ---------------------------------------------------- Jonathan Wilson System Administrator Cedar Creek Software http://www.cedarcreeksoftware.com Central Texas IT http://www.centraltexasit.com
At 10:33 AM 1/29/2002 +0100, you wrote:
Does/will Yast online update support HTTP (or at least http proxy)?
yes, they added http support with one of the latest YOU updates, however you cant' choose it - it only ususes it when it wants to. SuSE doesn't have HTTPD running on any of their FTP servers either (wish they did)
We will likely run http servers at some time in the future. Currently, we do not. Most of the mirrors of the SuSE trees do not have http access as well. If we are the only ones who provide packages via http (eg without the majority of the mirrors), then our leased lines couldn't handle the load any more. We're talking global aspects here, not only some wishes. The local resource problem is solveable, but the bandwidth problem is not. It needs many many sold SuSE Linux packages to afford our connectivity. So far for the server-side. The client-side (YOU) needs http support so that proxies can be used in an easy fashion. As I said in an earlier mail, we are working on it. It's not trivial in some respects.
As ftp is a weird protocol anyway, I don't think it should be used so much, especially for important things like updates.
They should use scp :-)
Nobody would argue that a protocol that opens secondary connections opens up a lot of problems, many of which are security related (filtering). It's all a matter of alternatives.
I have some servers behind an MS Proxy Server and can't use online update, because yast doesn't support any proxy, and socksify + bouncer on a machine with MS Proxy client installed doesn't work, too (http/ssh works thoug). And once again, why is YOU not half as cool as apt-get ??
Because the people who are working on it don't seem to care enough. It's slowly getting better but I really don't understand why a little more effort isn't put into it, since it's a highly sought-after feature.
No comment to the clearly non-technical claims.
Anyway, that's not the worst of YOU's problems - it uses it's own internal patch manager and never consults rpm. Due to this, a patch is always marked as "installed" unless you do some hacking. For instance the other day I fried my MySQL installation while testing and had to do an ftp reinstall from yast1. It installed the old original versions of MySQL & Co., and when I opened YOU the mysql updates that I _knew_ where there where not available to be selected. I had to hack some things to get YOU to wake up. This is very bad.
There is no such thing as an "internal patch manager". YOU sees a file "openssh-3", has one called "openssh-2" and concludes that the "-3" version is newer. If you do everything as it wants to, then it will work. In particular, a defective portiono of code in YOU requires an update of YOU itself. If you do not approve to it, it won't see all the other updates as well. It's so easy. There used to be one problem with the naming of the openssh-2 patch description: We manually ++'ed the number to -3 b/c the mechanism to do this was a bit glitchy.
Also if you download, say 5 updates (this actually happened to me) and during the install part rpm gives an error, say on the second package, the installation ceases (i.e. the remaining packages do _not_ get installed) yet YOU marks them as successfully installed anyway.
This is a bug (among a bunch of others) that needs to be fixed.
This actually happened to me when I way trying up update at, netscape, openssh and w3m at the same time. The NS package was corrupt, and YOU just skipped over sshd and w3m without mentioning it. I only realized what was happening because YOU "finished" the installation too fast. If I had not been paying attention I would have _thought_ I'd upgraded sshd and would in fact have still been using the old version.
We have seen problems with corrupt packages on our mirrors lately, we don't know how this can happen.
This is very bad.
I have submitted several bug reports to feedback@suse.com and bugs@suse.de and not heard back from them. I have a serious mind to submit this to BugTraq in the hope of forcing SuSE to do something about it.
You have seen autogenerated mails from feedback@suse.com (and probably from bugs@suse.de as well). The mail clearly states that not everything can be handled, and it might take some time until you get anything back (if at all). You also seem to be aware of security announcements, are you? At least, you are reading this list. But then, you should be aware of the primary security contact of SuSE: <security@suse.de>. You will get answers usually in less than 24 hours if you write to this list. This issue is clearly security related, and it needs an urgent fix. It's just that we don't know of it. As a SuSE employee responsible for the security field, I am not in the position to rant at customers, and I don't want to do this here either. So please take this as a suggestion: What happens here is a communication problem. The information is valuable, but that is not everything that matters. Valuable information can be stored on some diskette in my mom's old computer, and it doesn't change anything in this world. What also counts are: 1) time 2) origin 3) destination 4) medium 5) mode (language-wise) and language 6) the history of the information 7) related information The thing with 3) and maybe 5) can be improved on your side in this case. Now we will go ahead and see if we can fix this as soon as possible and provide the update package/patch as people expect it. Then we can be happy again.
I've never done anything like that before - do you think I should? It's really quite important and SuSE _need_ to fix it. I'm not sure if it's serious enough for BugTraq though.
For sure it's serious enough for security@suse.de. Thanks for the effort of writing to this list, at least. Roman.
As ftp is a weird protocol anyway, I don't think it should be used so much, especially for important things like updates.
They should use scp :-)
Oh please. rpm's package signing is there to check the integrity of packages which have come from unknown sources (read ftp servers) and to protect against intentional corruption. Using scp would be an other waste of time, as yast should pop up a big box in bright red reading "integrity of this package can't be checked / fails to verify and it may be corrupted and contain a trojan/virus/othernasty - would you like me to permanently remove this package - default answer yes" if necessary. Note I'm talking about rpm signatures, not its md5 sum, which ony protects against accidental corruption on download. apt-get AFAIU does not check package signatures, nor are most debian packages signed anyway. Considering the ten zillion packagers sining in a way which makes somes sense is somewhat difficult, and may not yet be operational. I agree with Roman - use apt-get if you feel so inclined, I won't. Why not use microdaft straight away - it's all very easy too, and security is an afterthought at best. I find downloading a recursive ftp server dir listing tells me what's new (there are time stamps on files). wget and rpm -Kv immediately after download work well, so does rpm -UvhF on all machines I have. If it's urgent copy/paste from the advisory into wget does work too. I don't see a big problem, although yes it could be automated more to make it an absolut no-brainer. No doubt YOU will get there.
I have submitted several bug reports to feedback@suse.com and bugs@suse.de
It's feedback@suse.de as listed in every rpm info and stated on mailing lists many times. These reports are acted on, SuSE did say that many times too, and I know from experience that that is correct. Also, as it's security-relevant you ought to be using security@suse.de at least some days before contacting bugtraq.
and not heard back from them. I have a serious mind to submit this to BugTraq in the hope of forcing SuSE to do something about it. I've never done anything like that before - do you think I should?
I consider it to be a serious issue if true, but unless you correctly notify SuSE you can't claim "vendor notified" status on bugtraq, which does not look good on you. Volker -- Volker Kuhlmann Please do not CC list postings to me.
At 08:19 AM 1/30/2002 +1300, you wrote:
Oh please. rpm's package signing is there to check the integrity of packages which have come from unknown sources
Ok, ok.
<snip> I find downloading a recursive ftp server dir listing tells me what's new
a. Most of us are aware that updates can be applied manually. b. not all of use want to: I don't know about you, but time I spend on security comes mostly straight out of my small companies pocket. We can't really charge our customers for it. Thus, anything that speeds up the process is highly desirable. Besides, then less time I spend manually downloading and installing rpms, the more time I have to get serious work done, and do things like learn more about security /System Administration in general.
No doubt YOU will get there.
I truly hope so and think it will so long as SuSE cares about it.
I have submitted several bug reports to feedback@suse.com and bugs@suse.de
It's feedback@suse.de
I got feedback@suse.com directly from SuSE's web site. Perhaps you should tell SuSE their web site is wrong. And I did get auto replies from feedback@sues.com, so it's a valid feedback address, ok? If the US and German SuSE offices have problems communicating, it's their issue, not mine.
Also, as it's security-relevant you ought to be using security@suse.de at least some days before contacting bugtraq.
1. I have no memory of ever seeing that address. 2. I would have discussed it here or on suse-linux-e before posting to BugTraq (note: as a result of what CKM and Roman told me, I won't in the future be posting it to suse-linux-e. I'm just telling you what I would have done.) 3. As anyone wise soul would do, I would have asked on the SuSE mailing lists - or, if necessary, on BugTraq - for a security contact address at SuSE before posting any details. This is standard protocol. And I would have given them 1 to 2 months to do something about it first. - again, ~40 days seems to be the average standard for waiting. I probably would have asked how long I should wait for a small security issue (longer then for a large one, I would imagine) And
and not heard back from them. I have a serious mind to submit this to BugTraq in the hope of forcing SuSE to do something about it. I've never done anything like that before - do you think I should?
1. This was a question. I was asking the list for opinions on whether or not I should. Not when I should.
I consider it to be a serious issue if true,
I can't help but wonder at the sincerity of this statement. If you consider it potentially serious, perhaps you should participate in a little empirical science. What I said in my post is convincing enough. At worst, it would need to be replicated by another user, which would be easy to do and obviously would require someone else besides me.
but unless you correctly notify SuSE
And I would have...
you can't claim "vendor notified" status on bugtraq,
...and I wouldn't have...
which does not look good on you.
No it wouldn't, but I wouldn't do that.
Volker
---------------------------------------------------- Jonathan Wilson System Administrator Cedar Creek Software http://www.cedarcreeksoftware.com Central Texas IT http://www.centraltexasit.com
* JW (jw@centraltexasit.com) [020129 14:20]:
I have submitted several bug reports to feedback@suse.com and bugs@suse.de
It's feedback@suse.de
I got feedback@suse.com directly from SuSE's web site. Perhaps you should tell SuSE their web site is wrong.
It's an alias to feedback@suse.de. -- -c"We're not *that* incompetent"m
participants (7)
-
Christopher Mahmood -
Eduard Avetisyan -
Gordon Pritchard -
JW -
Ralf Ronneburger -
Roman Drahtmueller -
Volker Kuhlmann