maintainer should do.
Aren't there any closed lists that actually discuss vulnerabilities and
possible fixes before the embargo ends? And couldn't these lists be
opened afterwards?
For example, if you search by CVE the Xpdf vulnerability related to
CAN-2005-0206 you will get to BID-11501
Hubert Chan [EMAIL PROTECTED] wrote:
On 2005-03-22 08:20:32 -0500 Frank Küster [EMAIL PROTECTED] wrote:
However, that doesn't invalidate the check.
The main point of CAN-2004-0206, as I understand it, is that the
upstream/original check will be performed in the limits of the widest
integer
On 2005-03-23 04:07:47 -0500 Frank Küster [EMAIL PROTECTED] wrote:
Hubert Chan [EMAIL PROTECTED] wrote:
Is it an int or a size_t (like what malloc uses)? If it is an int,
then INT_MAX would work as expected. If it's size_t, then you should
use SIZE_MAX (defined in stdint.h).
from
On Fri, Mar 18, 2005 at 09:38:14AM +0100, Hilmar Preusse wrote:
As thex extension to CAN-2004-0888 (CAN-2005-0206) came in after the
latest tetex-bin upload we can't have the fix in sarge. I'll file a
bug against tetex-bin and I guess Frank will upload ASAP. I'll check
the woody version too.
Hamish Moffatt [EMAIL PROTECTED] wrote:
On Fri, Mar 18, 2005 at 09:38:14AM +0100, Hilmar Preusse wrote:
As thex extension to CAN-2004-0888 (CAN-2005-0206) came in after the
latest tetex-bin upload we can't have the fix in sarge. I'll file a
bug against tetex-bin and I guess Frank will upload
On Fri, Mar 18, 2005 at 12:04:21PM -0500, Hubert Chan wrote:
(which, if you're using from C++ code, you'll
have to #define __STDC_LIMIT_MACROS before you include stdint.h).
This name is reserved. It is undefined behaviour if you define it.
Bastian
--
You! What PLANET
On Tue, Mar 22, 2005 at 11:57:01AM +0100, Frank Küster wrote:
Me neither. I find these CVE pages on mitre.org annyoing, giving no
real information, only meta-information which is again just vendor stuff
without code.
CVE is not a database, it's a dictionary. If you are looking into more
Please please keep the bugnumber in the Cc!
Bastian Blank wrote:
On Fri, Mar 18, 2005 at 12:04:21PM -0500, Hubert Chan wrote:
(which, if you're using from C++ code, you'll
have to #define __STDC_LIMIT_MACROS before you include stdint.h).
This name is reserved. It
On Tue, Mar 22, 2005 at 11:57:01AM +0100, Frank Küster wrote:
Hamish Moffatt [EMAIL PROTECTED] wrote:
I was tempted to revert all the security patches and apply upstream's
versions, but I'm not sure that all the changes are there. Especially as
I don't know how 0888 and 0889 differ.
Note
On Tue, Mar 22, 2005 at 11:11:08PM +1100, Hamish Moffatt wrote:
INT_MAX is still 2^31 and XRefEntry is an enum, so I guess it's OK.
(I checked my amd64 system, but I expect INT_MAX is actually defined by
the C spec.)
No. It is not portable to assume that INT_MAX is defined in terms of a
32 bit
[restricting Cc to the lists]
Javier Fernández-Sanguino Peña [EMAIL PROTECTED] wrote:
On Tue, Mar 22, 2005 at 11:57:01AM +0100, Frank Küster wrote:
Me neither. I find these CVE pages on mitre.org annyoing, giving no
real information, only meta-information which is again just vendor stuff
Hamish Moffatt [EMAIL PROTECTED] wrote:
On Tue, Mar 22, 2005 at 11:57:01AM +0100, Frank Küster wrote:
Hamish Moffatt [EMAIL PROTECTED] wrote:
I was tempted to revert all the security patches and apply upstream's
versions, but I'm not sure that all the changes are there. Especially as
I
On 2005-03-22 08:20:32 -0500 Frank Küster [EMAIL PROTECTED] wrote:
However, that doesn't invalidate the check.
The main point of CAN-2004-0206, as I understand it, is that the
upstream/original check will be performed in the limits of the widest
integer type involved, sizeof(XRefEntry) which
the
Bugtraq database, actually Securityfocus' vulnerability database available
at http://www.securityfocus.com/bid/
For example, if you search by CVE the Xpdf vulnerability related to
CAN-2005-0206 you will get to BID-11501:
http://www.securityfocus.com/bid/11501
In the 'solution' section you can see
On 18.03.05 Micah Anderson ([EMAIL PROTECTED]) wrote:
On Wed, 16 Mar 2005, Frank Küster wrote:
Hi .*,
Can anybody point me to a place where I can find the patch for
the 64-bit-specific issue? The CVE only lists the RedHat and
Mandrake security announcements, but I don't know how to get
Micah Anderson [EMAIL PROTECTED] wrote:
Unfortunately, it takes some deep digging sometimes.
Thank you very much for that work.
I searched Redhat's Bugzilla, and found this:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=135393
[...]
Can you determine if tetex-bin, pdftohtml and xpdf
On 2005-03-18 09:53:49 -0500 Frank Küster [EMAIL PROTECTED] wrote:
So the question is whether our changed patch is vulnerable to this:
+if (size 0 || size = INT_MAX/sizeof(XRefEntry)) {
The value of INT_MAX, as defined in /usr/include/limits.h, does not
depend on the
On Wed, 16 Mar 2005, Frank Küster wrote:
Frank Küster [EMAIL PROTECTED] wrote:
Micah Anderson [EMAIL PROTECTED] wrote:
7. Is our xpdf vulnerable to CAN-2005-0206[13]?
This also needs to be checked for pdftex (in tetex-bin) and pdftohtml,
and perhaps others that include xpdf code.
Micah Anderson [EMAIL PROTECTED] wrote:
7. Is our xpdf vulnerable to CAN-2005-0206[13]?
This also needs to be checked for pdftex (in tetex-bin) and pdftohtml,
and perhaps others that include xpdf code.
Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer
Frank Küster [EMAIL PROTECTED] wrote:
Micah Anderson [EMAIL PROTECTED] wrote:
7. Is our xpdf vulnerable to CAN-2005-0206[13]?
This also needs to be checked for pdftex (in tetex-bin) and pdftohtml,
and perhaps others that include xpdf code.
Can anybody point me to a place where I can find
On 16.03.05 Frank Küster ([EMAIL PROTECTED]) wrote:
Frank Küster [EMAIL PROTECTED] wrote:
Micah Anderson [EMAIL PROTECTED] wrote:
Hi all,
7. Is our xpdf vulnerable to CAN-2005-0206[13]?
This also needs to be checked for pdftex (in tetex-bin) and
pdftohtml, and perhaps others that
21 matches
Mail list logo
