On Wed Sep 17, 2003 at 02:56:02AM +0200, Tibor Pittich wrote: > > Typically, when I update openssh, I've tested it for a few days on my > > own machine first. > > > > 8.2 came with 3.1p1; 3.6.1p2 was provided for updates today > > 9.0 came with 3.4p1; 3.6.1p2 was likewise provided today > > a-ha, you'r tested today's update for older version of mdk few days > before with latest patch and it don't break anything and it work > perfectly. you and qa team can say that this was carefully tested, yes??
Don't try to teach me lessons about QA and doing updates, Tibor. It won't work. Yes, I can say it was carefully tested. Who says that this version was only built for the first time today? I've been working with this version of openssh on the older versions for a while now due to timing attacks in openssh that 3.6.1p2 was supposed to clear up. Yes, it is stable and yes it works. > i have another example about latest kernel updates which contain > freeswan 2.0 and there is no freeswan user space package update for > these versions which makes ipsec implementation unusable.. This is different. I don't use ipsec, and I don't use freeswan and apparently none of the other secteam folks do either. Likewise, I didn't do the kernel updates; I didn't upgrade freeswan. If this was a problem, it should have been raised before now. > > What makes you think that 9.1 will have 3.6.1p2 for the next 2 years? > > I don't think you bothered to look at how the updates work; please > > don't make blanket statements like this when they are so obviously > > incorrect. > > ok, please tell me where is information how _exactly_ updates work? > maybe i search anyhow, but i can't find any information about this on > "Security updates" link at mandralinux site, wiki site and i make some > google search without success. Would you rather I take the time to document an internal process that has absolutely no bearing by the community, or would you rather have me build and test updates? Please give me your opinion since it seems that a) you want to give it and b) apparently everything we do needs to be consulted via cooker first. No, you won't find the procedure. There is no reason for you to have the procedure. There is no reason for me to document for you when it would purely be academic. Rest assured that the people who need to know how the system works, know how the system works. There is no "cooker for updates". Leave it alone. Anyways, the "looking" would have been determined by looking at how older advisories were handled, not by looking for a non-existant policy document. > i only think, that backporting is more usefull than "it can compiles, > starting without errors -> good candidate for updates" policy. Excuse me? Where did you determine this was policy? Here is another example of inept thinking... you yourself found there was no document policy so now you're posting flame bait about a policy you couldn't find and really have no clue about? (Why am I wasting my time replying to this?) > let's look how openssh problem was fixed in redhat: > for example rh 7.3 openssh package changelog: Let's not. We're not Red Hat. > * St sep 17 2003 Nalin Dahyabhai <[EMAIL PROTECTED]> 3.1p1-9 > - apply patch to store the correct buffer size in allocated buffers > (CAN-2003-0693) > > check version number; there is strictly backported all patches into too > old version of openssh but he has confidence that this updated package > can't break anything. > and this is reason why redhat tell how long want support older > distribution, imho. if mandrake follow this, why don't follow update > policy too? Sorry, I don't fully understand what you're talking about here. Are you talking about RH's support life? We didn't "follow" them on it. I proposed the current EOL policy months before RH announced their change. It wasn't until RH did it that someone decided we could do it to. Nevermind that at the time we had somewhere on the order of 14-15 different distros we were supporting. Anyways, you know just as much about Red Hat's policy as you do about MandrakeSoft's. Nothing. Nill. Zilch. Nada. The above statement proves it. You think RH patches everything? Think again. Look through their advisories; you will see where they have upgraded to new versions for various reasons. We do the same thing as well. But you wouldn't know this since you didn't bother to look at the one place where it counted: the advisories listings. > only thing what i want discuss is: > during cooker freeze can't be updated newer version in this special > situation, but for older releases it is ok? why don't only backported > patch into older releases? This isn't a special situation, and I've already explained my actions. I don't need to explain them again. Get it right now: OpenSSH 3.7.1 will *not* be in 9.2. Period. Stop asking. > > And, BTW, support is 18mos, not 2 years. > > hm, what about this: > http://www.mandrakesecure.net/en/productlifetime.php > > "Finally, specialized "server" products, will have a full life updates > support of no less than 24 months." > > i understand this that maximum support life is 24 months, and this is > 2 years.. it doesn't matter that download edition/desktop applications > is supported for shorter period. Right. Mandrake Linux 9.2 is not a specialized "server" product. It's a desktop product. It has 18mos life. The 2 years is for MNF, SNF, etc. Corporate Server has 3 years. Sorry, wrong again. > p.s.: i respect your authority about updates, but i think that this > process isn't fully clear long time ago and there is some things which > can be improved and give exactness in this process. > p.s.2.: i promise, that my worst english ever can't lead to > misunderstanding my things in this email. I respect the fact that you respect my authority. That's good. But what really has absolutely no bearing is how the updates are handled. They've worked pretty good for the last 3+ years that I've been handling it and while there is always room for improvement, a public forum/discussion about it is really a big waste of time. Feel free to debate it amongst yourselves; I have much more important things to do. I find that discussion about the most trivial things on this list end up doing nothing of importance, and that's when it's related to cooker! Cooker has nothing to do with updates, the process doesn't need to be documented, reviewed by cookers, or anything else you're likely to propose. Valuable input is appreciated, but please have some working knowledge of how things work on the public end before asking me to change how they work on the internal end. Thanks. P.S. This is another thread I no longer feel like contributing to. As Olivier just pointed out, 3.7.1 and another patch is available which means I have more work to do tonight, and I've just delayed the new packages by 15 minutes to respond to this. -- MandrakeSoft Security; http://www.mandrakesecure.net/ Online Security Resource Book; http://linsec.ca/ "lynx -source http://linsec.ca/vdanen.asc | gpg --import" {FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD}
pgp00000.pgp
Description: PGP signature
