Steve Langasek <[EMAIL PROTECTED]> writes:
> So if there's no evidence of arbitrary code execution, I think
> it's appropriate here to downgrade the bug -- but the security
> team should also be apprised.
Fine with me.
--
,''`.
: :' :Romain Francoise <[EMAIL PROTECTED]>
`. `'
* Moritz Muehlenhoff:
> glibc 2.3.4 introduced more secure heap management, which renders several
> code injection attacks moot.
I think these additional checks have already been bypassed. Shall I
dig up a reference?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe
Steve Langasek wrote:
> So if there's no evidence of arbitrary code execution, I think it's
> appropriate here to downgrade the bug -- but the security team should also
> be apprised.
glibc 2.3.4 introduced more secure heap management, which renders several
code injection attacks moot. (most notab
severity 408929 important
thanks
On Sun, Feb 04, 2007 at 01:56:40PM +0100, Jérôme Marant wrote:
> I'll ask that we tag this bug as etch-ignore: there are tons of bugs like
> this one in Emacs and there are multiple chances to expose such bugs
> by using many different packages.
> Futhermore, emac
Hi,
I'll ask that we tag this bug as etch-ignore: there are tons of bugs like
this one in Emacs and there are multiple chances to expose such bugs
by using many different packages.
Futhermore, emacs21 is (and more generally stable emacs releases are) not
supported upstream so we have no chances t
5 matches
Mail list logo
