zip sarge's package vulnerable to CAN-2004-1010
Hello, Current CAN-2004-1010 was fixed on zip 2.30-8 but current sarge version still vulnerable. This package need to be included on sarge to solve it. Thanks in advance, Otavio -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - "Microsoft gives you Windows ... Linux gives you the whole house." pgpbVo2rLESj4.pgp Description: PGP signature
Re: DSA 438 - bad server time, bad kernel version or information delayed?
Jan Lühr <[EMAIL PROTECTED]> writes: > Greetings, > > Am Mittwoch, 18. Februar 2004 21:31 schrieb Otavio Salvador: >> Florian Weimer <[EMAIL PROTECTED]> writes: >> > Jan Lühr wrote: >> >> 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. I doesn't do that. I'm only talk about a possibility. > 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? > This is exactly the same policy M$ have - but the point is, you could at > least > inform your users. > An unknown local root exploit was one of the key parts in the debian server > compromise and we have all seen the consequences. > Surely, you can see, that I want to keep this risk as small as possible on my > servers. Of course, we should keep the risk small as possible but this include in work with others distros to solve in major groups of archs in less time possible to minimize the possibility of brekage. []s -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio -
Re: DSA 438 - bad server time, bad kernel version or information delayed?
Florian Weimer <[EMAIL PROTECTED]> writes: > Otavio Salvador wrote: > >> If we provide an i386 image to fix a vulnerability and the same is >> found in other arch, then, someone can try to explore this. We need >> release all affected at same time to solve this. > > But Debian doesn't do this any longer. Do you really think Red Hat, > SuSE and all the others (including the majority of Debian users on x86) > should wait because Debian can't backport a security fix to, say, kernel > 2.4.18 on the s390 architecture? If the time between is small, IMHO, yes. Of course, on major archs (i386, powerpc, I think) this should be release at same time. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio -
Re: DSA 438 - bad server time, bad kernel version or information delayed?
Jan Lühr <[EMAIL PROTECTED]> writes: > Greetings, > > Am Mittwoch, 18. Februar 2004 21:31 schrieb Otavio Salvador: >> Florian Weimer <[EMAIL PROTECTED]> writes: >> > Jan Lühr wrote: >> >> 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. I doesn't do that. I'm only talk about a possibility. > 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? > This is exactly the same policy M$ have - but the point is, you could at least > inform your users. > An unknown local root exploit was one of the key parts in the debian server > compromise and we have all seen the consequences. > Surely, you can see, that I want to keep this risk as small as possible on my > servers. Of course, we should keep the risk small as possible but this include in work with others distros to solve in major groups of archs in less time possible to minimize the possibility of brekage. []s -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DSA 438 - bad server time, bad kernel version or information delayed?
Florian Weimer <[EMAIL PROTECTED]> writes: > Otavio Salvador wrote: > >> If we provide an i386 image to fix a vulnerability and the same is >> found in other arch, then, someone can try to explore this. We need >> release all affected at same time to solve this. > > But Debian doesn't do this any longer. Do you really think Red Hat, > SuSE and all the others (including the majority of Debian users on x86) > should wait because Debian can't backport a security fix to, say, kernel > 2.4.18 on the s390 architecture? If the time between is small, IMHO, yes. Of course, on major archs (i386, powerpc, I think) this should be release at same time. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DSA 438 - bad server time, bad kernel version or information delayed?
Florian Weimer <[EMAIL PROTECTED]> writes: > Otavio Salvador wrote: > >> Florian Weimer <[EMAIL PROTECTED]> writes: >> >> > Jan Lühr wrote: >> > >> >> 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. > > There are several justifications and explanations, yes. > >> Before upload a fix this need be available in all supported archs > > Fortunately, you are wrong. Kernel security updates are no longer > synchronized among architectures. If we provide an i386 image to fix a vulnerability and the same is found in other arch, then, someone can try to explore this. We need release all affected at same time to solve this. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio -
Re: DSA 438 - bad server time, bad kernel version or information delayed?
Florian Weimer <[EMAIL PROTECTED]> writes: > Jan Lühr wrote: > >> 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 ;-) -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio -
Re: DSA 438 - bad server time, bad kernel version or information delayed?
Florian Weimer <[EMAIL PROTECTED]> writes: > Otavio Salvador wrote: > >> Florian Weimer <[EMAIL PROTECTED]> writes: >> >> > Jan Lühr wrote: >> > >> >> 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. > > There are several justifications and explanations, yes. > >> Before upload a fix this need be available in all supported archs > > Fortunately, you are wrong. Kernel security updates are no longer > synchronized among architectures. If we provide an i386 image to fix a vulnerability and the same is found in other arch, then, someone can try to explore this. We need release all affected at same time to solve this. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DSA 438 - bad server time, bad kernel version or information delayed?
Florian Weimer <[EMAIL PROTECTED]> writes: > Jan Lühr wrote: > >> 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 ;-) -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
