-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings,
> > > >> Does this mean, that a well known exploit was kept back for nearly > > > >> three weeks, just because some odd vendors were unable to build > > > >> there kernels in time? > > > > > > > > Yes, this is the norm. Debian hides security bugs from its users for > > > > extended periods of time. > > > > > > Yes but this have a reason. Before upload a fix this need be available > > > in all supported archs and tested since major or users install it > > > trusting Debian Security Team and 'cause of this, should not fail ;-) > > > > Well, of course you might have quite good reasons for doing so, but for > > me, this is quite a good reason for changing the distri or os. > > Hiding unfixed holes is one thing (and I appreciate that partly) but > > hiding already fixed packages is quite astonishing and you cannot tell me > > you need more than two weeks to test a simple correction. > > Take it easy. I take security threads serious. Think of beeing avoidable vulnerable for nearly three weeks is a pain in my stomach. > Maybe you are right, you should switch to another O/S. I > bet you they coordinate and delay disclosure as well. Or better yet, > you can switch to MS, which you are lucky if you get a patch in 2 weeks > time. M$, you are kidding ;) > Look at it this way: > > Debian Security Team (DST) finds out about a security bug from an > organization (let's say CERT for the sake of discussion). CERT asks > Debian to prepare for release but delay disclosure until further notice > so all the CERT Coordinated Vendors (I believe Debian is one) can get on > board. Debian decides to go against CERT and release immediately after > the fix is made. CERT then decides they will no longer tell DST in > advance since they breached trust. DST then finds out about the > vulnerability the same time the "rest" of the world does. DST then > rushes about (after the announcement) to put together a package and > release a DSA. By now they are several hours or a day behind everyone > else. > > Would you still prefer DST ignore coordinated release schedules? If > so...perhaps you are correct...you could switch to a different O/S or > Distro. Let's see: > > RedHat....Going Commercial..hope you have a deep pocket book. (BTW, they > obey coordinated releases also). > Fedora....Still in it's infancy and organizing from the RedHat break > off. > Mandrake...They have Coordinated releases too. > Any other distro....do they have security releases? But the dominance of the CERT is excactly the point I'm criticising. Even it is necessary to coordinate the sec affords - imho fixies should be applied if they are ready and not if some organisation say so. > Anyhow, please sit back, take a few deep breaths and stop throwing such > a stink. ok. > > May I ask you what local / remote root exploit-fixes are you holding back > > currently? Should I switch of my sshd for the next few days or does the > > current bash have an unfixed local root exploit? > > Not worth answering Please don't take it serious - it was meant to be ironic. I beg you pardon, if you are insulted by that. > > This is exactly the same policy M$ have - but the point is, you could at > > least inform your users. > > Yes, inform the users, let the ENTIRE hack community know, don't provide > a fix. Then the release coordinator (CERT) gets mad at you...see above. > How is this any better? This is not what I'm talking about - unfixed vuln. must be held back. > > An unknown local root exploit was one of the key parts in the debian > > server compromise and we have all seen the consequences. > > Yes, it was. There are probably several hundred "unknown local root > exploits". The source code is open, why not put your words into action > and start finding some flaws? I neither have the knowlegde nor the time for doing that. But the point at is, that these vuln. are not avoidable at the moment - the last has been avoidable for nearly three weeks. > > Surely, you can see, that I want to keep this risk as small as possible > > on my servers. > > I do also. well, it seems, that we agreed at last ;) Keep smiling yanosz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iQIVAwUBQDPmqNAHMQ8GQaYRAQJRPA//QsTfQrTC4AS6TGwZMQz6mo2t+0TI5Ulq 93bquRnk+mXSYTgOoOC925YJ5O5Vj/9qUMqk8aQq0LQx5g+qOM31vTKRCUBY8XIp aWuVXiL1iMvncwJGURzyweew0QHb1RYsl7zr9RMZS2M1QwxdfnI2INcevwaBUG3n QDUnxWAokSxkNMRDlojaFEzzlW3iFauVrzPqr1AfO0+xv78mi6YGxBVvLIWbx/0S lw0yc2Pm0Cd3YzSFx5tqKortMeTYt1rkiCyPPlq/uCSLoIygtHrII4N/IuBPKFMW I3xAuNs2cHM92V33Oac4juUs7j35jaQecEZPNKQZ0QPp4pgcSSQ2Mda56/bNC0sl SzjLJPiVN6akLx4naxssmF2Rw61J/Z9PiEXnwX2/kc6gCs2y4+s5SFY8FKnyIjVe 7tBdilImLMt63CgdRRb332Ji3MNXjmdx8lbyJep0wHvvixslAwhfKjkv0bV/6+lB r+7c2bQ5uOvWS+TXZg9GCVeuBH2l8tRcWnuN7OWfV7H5XdAWGZ6ewVxgg6Vf2FFC bgqJ79PMDHFj8/zBmihedefKXu06qGQs/4tCBqQH3xKmgsArmSvsfxLx4CFfB5/X J6Bt66N2S58ZMkrRp+wiQqkFrI24euAPcHxQLloi2zSYuItilMF3/Stqkedgr/09 BSms9+Cean8= =Sp85 -----END PGP SIGNATURE-----