Well, I'm doing a really bad job of it today. This is my first reply, unfortunately I sent it to the wrong list the first time :-/ Here it is.... ------------------------------------------------------------ Ok, First I want to apologize: I've had a rough day including one crashed server. I wrote the previous messages in a rush while feeling somewhat worked up about the issues. Add the to the fact that I'm already unhappy with SuSE on a couple of counts related to YOU and it all came out onto my keyboard with a worse altitude then it should have. At 08:12 PM 1/29/2002 +0100, you wrote:

No comment to the clearly non-technical claims.

No comment was desired. It was a snide remark that probably shouldn't have been made to begin with.

There is no such thing as an "internal patch manager".

I did not mean that in the sense of it's own package manager e.g. rpm or dkpg. What I meant was that it uses it's own system for determining what packages are/are not installed and does not query rpm for that info. Querying rpm would be much more reliable and would solve the some of the issues I mentioned.

YOU sees a file "openssh-3", has one called "openssh-2" and concludes that the "-3" version is newer.

Yeah, and that's exactly what causes it to be wrong about what is/is not currently installed. Also note that I have never seen any documentation or warnings "If you suspect a package is not really installed, please remove /var/lib/YaST/<snip> and try again". How are people supposed to know to do that? I simply worked it out on my own out of desperation, but not everyone can/would/should. And even that system could have been done better - quite apparently it writes those files out before it's truly finished, which is a (fairly serious ) design flaw. 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.

Ok, but in case you are suggesting that maybe that had something to do with the experience I spoke of in my previous post, it does not. We have seen problems with corrupt packages on our mirrors lately, we

don't know how this can happen.

Me neither. It happens ever over T1 and it's random - I can update several servers at the same time or nearly the same time, and one will find it corrupt while another one downloads it just fine. I have to remove the corrupted rpm file out of /var/lib/YaST/patches/<arch>/update/<version>/<series> before you can download a good file too - otherwise YOU just keeps trying to "finish downloading" the corrupted package (which doesn't work).

You have seen autogenerated mails from feedback@suse.com (and probably from bugs@suse.de as well).

As I attempted to state, an auto-generated "hello, our computer has received your email" is not sufficient for security issues. And I did say that I do understand SuSE can't reply to all emails. They actually did get back with me concerning the much-less-important corrupted netscape package (thus showing that humans at SuSE do read the messages and do reply at least sometimes.). Knowing that people who take security seriously often go to BugTraq with their info when the notified vendor does not respond, I would think SuSE would want to notify me personally for that reason alone. Apparently not.

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>.

Ok, well quite frankly I was not. Also, I viewed it as a bug report with security implications, not a security problem per se.

You will get answers usually in less than 24 hours if you write to this list.

That's true, this is a good list (was till I got here anyway ;-) ).

This issue is clearly security related, and it needs an urgent fix. It's just that we don't know of it.

Interesting that you see it that way, I simply didn't - to me it was more of a bug (for a software company, a somewhat naive bug at that) then a security issues. I simply noted that it could have security implications as a way of making it seem more urgent (quite frankly, it seems to me that vendors rarely pay attention to bug reports except when they are security related.)

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.

Again, sorry to upset you or anyone else.

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.

Sir, if your feedback@ and bugs@ have no way to communicate with the security crew, then SuSE has a serious problem. I'm not saying I didn't need to send in a report to security@, but I would think the feedback and bug people would forward anything that mentions security to the security department to be analyzed. If not, I feel more worried then ever to think that security reports that only go to feedback@ or bugs@ doesn't ever get reviewed by the SuSE security team :-[

Valuable information can be stored on some diskette in my mom's old computer, and it doesn't change anything in this world.

To me that statement is implying that I have the information but did not give it to SuSE. While I did not send it to the _best_ address, nonetheless I did indeed send it to 2 addresses at SuSE.

What also counts are:

I'm having a hard time following you here:

1) time

The time I discovered the problem

2) origin

Origin of what? The bug? YOU is the origin. And SuSE is the origin of YOU :-) That's kind obvious - are you saying something else that I'm missing?

3) destination

This one totally escapes me. Destination is my computers hard drive. Where I live is irreverent. Again, am I misunderstanding you?

4) medium

???

5) mode (language-wise) and language

English. I'm surprised I'd need to say that but ok, I will.

6) the history of the information 7) related information

i.e. the body of the bug report. FYI I gave all pertinent details (except for lang=en_US) when I submitted my bug reports.

The thing with 3) and maybe 5) can be improved on your side in this case.

5, yes, I cannot grasp the meaning of 3.

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.

Should I go ahead and submit a whole new report to security@suse.de or are you simply going to handle it now?

Then we can be happy again.

That would be nice :-)

...

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.

If I hadn't gotten all worked up by that one guy's post (I don't even remember what it was now) I never would have. Again, sorry for any strife I've caused. I didn't mean to be a pain - it just all got too me at once. ---------------------------------------------------- Jonathan Wilson System Administrator Cedar Creek Software http://www.cedarcreeksoftware.com Central Texas IT http://www.centraltexasit.com