Bug#1054119: data loss patch for qpdf targeted at stable (11.3.0)
On Tue, Oct 17, 2023, at 12:15 PM, Adam D. Barratt wrote: > # bcc control@bugs.d.o > user release.debian@packages.debian.org > usertags 1054119 pu > tags 1054119 bookworm moreinfo > retitle 1054119 bookworm-pu: package qpdf/11.3.0-1 > thanks Thanks for fixing the tags. I'll reply to this instead of starting over. > On Tue, 2023-10-17 at 07:32 -0400, Jay Berkenbilt wrote: > > The attached patch to qpdf 11.3.0 fixes a bug that could potentially > > result in loss of data. I'd like permission from the release team to > > . . . > > > > Close, but a few rough edges. :-) > Ah, thanks for helping me get past my brain rot. When I used to maintain several packages, including tiff and icu, which had lots of security updates, I was much more familiar with this. It's funny how we can forget something so thoroughly that we can forget we knew it at one time. The doc reference was perfect and jogged my memory. > As noted in the dev-ref section, please use "reportbug > release.debian.org" for p-u requests, or set equivalent metadata. That > helps ensure that the request ends up in the correct section of our BTS > web view, where uncategorised bugs may get overlooked for some time. > I've fixed up the relevant bits for this request (see the start of my > reply). Thanks for fixing it up. Rather than starting over, I am replying with the information from reportbug. I'll let you remove the moreinfo tag assuming I have provided enough information. -- [ Reason ] Between qpdf 10.6.3 and 11.0.0, a contributor did substantial refactoring and performance optimizations on qpdf, ultimately achieving better than a 2x performance boost. In spite of careful testing and review, a bug to the lexical layer of qpdf snuck in. From the changelog: Fix data loss bug introduced in 11.0.0 and fixed in 11.6.3. The bug causes the qpdf tokenizer to discard the character after a one-digit or two-digit quoted octal string. Most writers don't create these, and they are rare outside of content streams. By default, qpdf doesn't parse content streams. The most common place for this to occur would be in a document's /ID string, but in the worst case, this bug could cause silent damage to some strings in a PDF file's metadata, such as bookmark names or form field values. The fix is in upstream version 11.6.3 which has been uploaded to unstable and has migrated to testing. Given that this bug can cause potential data loss, updating stable is warranted. The version in oldstable is not affected by this bug. [ Impact ] In rare cases, qpdf may silently corrupt data in the user's PDF file. [ Tests ] The commit that includes the fix: https://github.com/qpdf/qpdf/commit/1ecc6bb29e24a4f89470ff91b2682b46e0576ad4 includes a number of new automated tests to specifically exercise this bug. (I have not included the additional automated tests in the patch.) Additionally, the user who reported the original upstream bug: https://github.com/qpdf/qpdf/issues/1050 has confirmed that the issue is fixed. I also verified with the user's file. [ Risks ] This is a very low-risk patch. The fix is small and targeted. qpdf has a rigorous test suite and a very good track record for stability. A bug of this sort is a very rare event. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable [ Changes ] The character following the short octal quoted character was used to cause a state transition in the tokenizer but not reprocessed in the new state. The bug fixes this. Prior to refactoring, the code did not suffer from this logic error because a different mechanism was used to re-process a character used in a state transition. [ Other info ] Note: I am the upstream author of qpdf as well as the debian maintainer of the package. The user who submitted the pull request that contained this bug is a reliable and steady contributor to qpdf who has made great improvements to the code base. Heavy refactoring carries risks. qpdf processes millions of pages a day in commercial and open source applications. It is very important to get this fix out to avoid silent and hard-to-detect damage to PDF files. qpdf_11.30.0-1--11.30.0-1+deb12u1.debdiff Description: Binary data
Bug#1054119: data loss patch for qpdf targeted at stable (11.3.0)
Package: release.debian.org
X-Debbugs-CC: q...@debian.org
The attached patch to qpdf 11.3.0 fixes a bug that could potentially
result in loss of data. I'd like permission from the release team to
upload this to stable. I've been a debian developer since 2005, but
it's been years since I've last prepared a release to the stable
distribution. As far as I can tell, the current procedure is to upload
with the target distribution as "stable" and upload to ftp-master.
This will direct the package the proposed-updates queue. Is this
correct?
The nature of the bug is that, if a quoted octal character with one or
two digits instead of three digits appears in the file, the following
character will be dropped from the string. This bug snuck in in a pull
request I accepted that performed significant performance optimization
on the tokenizer. Because it only affects strings in metadata when
qpdf is used in its default configuration, and because such quoted
characters of this type don't appear very often, it's somewhat of a
corner case, but I think the bug is critical to fix because there is a
chance that it could silently damage files in ways that would be hard
to detect.
Please let me know if I should proceed with an update to stable.
--Jay Berkenbilt (a.k.a. q...@debian.org)--- libqpdf/QPDFTokenizer.cc.orig 2023-10-17 07:19:31.829119946 -0400
+++ libqpdf/QPDFTokenizer.cc 2023-10-17 07:20:55.689510562 -0400
@@ -739,17 +739,22 @@
void
QPDFTokenizer::inCharCode(char ch)
{
+bool handled = false;
if (('0' <= ch) && (ch <= '7')) {
this->char_code = 8 * this->char_code + (int(ch) - int('0'));
if (++(this->digit_count) < 3) {
return;
}
-// We've accumulated \ddd. PDF Spec says to ignore
-// high-order overflow.
+handled = true;
}
+// We've accumulated \ddd or we have \d or \dd followed by other
+// than an octal digit. The PDF Spec says to ignore high-order
+// overflow.
this->val += char(this->char_code % 256);
this->state = st_in_string;
-return;
+if (!handled) {
+inString(ch);
+}
}
void
Re: Should qpdf depend on gnutls?
Yeah, that's what what I decided to do. Thanks. On Thu, Apr 9, 2020, at 2:08 PM, Florian Weimer wrote: > * Jay Berkenbilt: > > > I'm about to release qpdf 10. Someone contributed an openssl crypto > > provider. Do you think I should build with the qpdf packages for > > debian with 1) only gnutls, 2) only openssl, or 3) both gnutls and > > openssl? Option 3 allows users to select at runtime but makes qpdf > > dependent on both packages. I notice that systemd also depends on > > openssl. My impulse is to go with option 1 (gnutls only) because I > > really don't see any advantage in the OS package letting users > > choose at runtime which crypto to use, but including both cryptos > > probably doesn't ultimately affect what gets installed on anyone's > > system since openssl is basically always going to be there. > > This seems to be more of a query for debian-devel, to be honest. > > Two packages do not seem particularly useful to me. Since apt depends > on libgnutls30, I don't see how an OpenSSL backend for qpdf could > minimize installation size. This suggests to me that you should stick > with GNUTLS for Debian. >
Re: Should qpdf depend on gnutls?
I'm about to release qpdf 10. Someone contributed an openssl crypto provider. Do you think I should build with the qpdf packages for debian with 1) only gnutls, 2) only openssl, or 3) both gnutls and openssl? Option 3 allows users to select at runtime but makes qpdf dependent on both packages. I notice that systemd also depends on openssl. My impulse is to go with option 1 (gnutls only) because I really don't see any advantage in the OS package letting users choose at runtime which crypto to use, but including both cryptos probably doesn't ultimately affect what gets installed on anyone's system since openssl is basically always going to be there. Opinions welcome. Thanks! On Sun, Nov 10, 2019, at 9:10 PM, Jay Berkenbilt wrote: > Okay, thanks for all the response, public and private. There seems to be > broad consensus to use the gnutls crypto and disable the native one, so > that's what I'll do. Appreciate the advice! > > --Jay > > On Sun, Nov 10, 2019 at 2:05 PM Moritz Mühlenhoff wrote: >> On Sat, Nov 09, 2019 at 07:10:44PM -0500, Jay Berkenbilt wrote: >> > I am the upstream author and the debian maintainer of qpdf. >> > >> > At the request of RedHat, I have made an enhancement to qpdf that >> > allows an external library to be used for crypto functions rather than >> > using qpdf's native crypto implementations. The qpdf library includes >> > code to compute hashes with md5 and sha2 (256, 384, and 512) as well >> > as encryption functions for rc4 and aes256 with and without CBC. >> > Disabling insecure crypto is not a practical option because of the way >> > these things are used in the PDF spec, but it is possible create PDFs >> > that don't use insecure crypto by just using 256-bit encryption. >> > >> > I can build qpdf 9.1 for Debian in one of three ways: 1) use only the >> > native crypto as in all previous releases, thus avoiding a dependency >> > on gnutls; 2) build only the gnutls crypto provider thus causing a >> > dependency on gnutls but eliminating the native crypto entirely; or 3) >> > building both crypto providers, in which case gnutls will be used by >> > default, but developers and end users will have the ability to select >> > the native crypto provider at runtime if desired. >> > >> > Do you have an opinion about which way I should go? I believe RHEL and >> > Fedora are going to use the second option of building with only gnutls >> > and dropping native crypto, but I have also enjoyed the fact that qpdf >> > has so few build dependencies. It is possible that a future version of >> > qpdf may support digital signature, in which case I will definitely >> > have to add either openssl or gnutls as a dependency. >> >> I'd recommend to go with 2); there's a lot of value in using a common / >> scrutinised crypto library over a custom implementation and for all >> practical purposes gnutls would not be an additional dep as systemd >> already pulls it in on virtually every Linux system these days. >> >> Cheers, >> Moritz >>
Re: Should qpdf depend on gnutls?
Okay, thanks for all the response, public and private. There seems to be broad consensus to use the gnutls crypto and disable the native one, so that's what I'll do. Appreciate the advice! --Jay On Sun, Nov 10, 2019 at 2:05 PM Moritz Mühlenhoff wrote: > On Sat, Nov 09, 2019 at 07:10:44PM -0500, Jay Berkenbilt wrote: > > I am the upstream author and the debian maintainer of qpdf. > > > > At the request of RedHat, I have made an enhancement to qpdf that > > allows an external library to be used for crypto functions rather than > > using qpdf's native crypto implementations. The qpdf library includes > > code to compute hashes with md5 and sha2 (256, 384, and 512) as well > > as encryption functions for rc4 and aes256 with and without CBC. > > Disabling insecure crypto is not a practical option because of the way > > these things are used in the PDF spec, but it is possible create PDFs > > that don't use insecure crypto by just using 256-bit encryption. > > > > I can build qpdf 9.1 for Debian in one of three ways: 1) use only the > > native crypto as in all previous releases, thus avoiding a dependency > > on gnutls; 2) build only the gnutls crypto provider thus causing a > > dependency on gnutls but eliminating the native crypto entirely; or 3) > > building both crypto providers, in which case gnutls will be used by > > default, but developers and end users will have the ability to select > > the native crypto provider at runtime if desired. > > > > Do you have an opinion about which way I should go? I believe RHEL and > > Fedora are going to use the second option of building with only gnutls > > and dropping native crypto, but I have also enjoyed the fact that qpdf > > has so few build dependencies. It is possible that a future version of > > qpdf may support digital signature, in which case I will definitely > > have to add either openssl or gnutls as a dependency. > > I'd recommend to go with 2); there's a lot of value in using a common / > scrutinised crypto library over a custom implementation and for all > practical purposes gnutls would not be an additional dep as systemd > already pulls it in on virtually every Linux system these days. > > Cheers, > Moritz > >
Should qpdf depend on gnutls?
I am the upstream author and the debian maintainer of qpdf. At the request of RedHat, I have made an enhancement to qpdf that allows an external library to be used for crypto functions rather than using qpdf's native crypto implementations. The qpdf library includes code to compute hashes with md5 and sha2 (256, 384, and 512) as well as encryption functions for rc4 and aes256 with and without CBC. Disabling insecure crypto is not a practical option because of the way these things are used in the PDF spec, but it is possible create PDFs that don't use insecure crypto by just using 256-bit encryption. I can build qpdf 9.1 for Debian in one of three ways: 1) use only the native crypto as in all previous releases, thus avoiding a dependency on gnutls; 2) build only the gnutls crypto provider thus causing a dependency on gnutls but eliminating the native crypto entirely; or 3) building both crypto providers, in which case gnutls will be used by default, but developers and end users will have the ability to select the native crypto provider at runtime if desired. Do you have an opinion about which way I should go? I believe RHEL and Fedora are going to use the second option of building with only gnutls and dropping native crypto, but I have also enjoyed the fact that qpdf has so few build dependencies. It is possible that a future version of qpdf may support digital signature, in which case I will definitely have to add either openssl or gnutls as a dependency. --Jay
Bug#929252: unblock: qpdf/8.4.2-1
On Mon, May 27, 2019 at 4:14 PM Paul Gevers wrote: > Control: tags -1 moreinfo > > On Sun, 19 May 2019 20:43:29 -0400 Jay Berkenbilt wrote: > > The changes between qpdf 8.4.0 and 8.4.2 are bug fixes, but I am > > asking for consideration because this update includes fixes to a > > serious performance bug (CLI), a CLI non-compatibility bug, and a > > library fix that could cause data loss in rare cases. These bugs are > > all in the part of the code concerned with splitting and merging > > documents, which is one of the main things people use the qpdf CLI > > for. While these changes are not critical, it would be disappointing > > if the version of qpdf in the next debian stable has these > > already-fixed bugs. > > How would a targeted fix look like? I don't think we'll unblock the new > upstream version. > I could extract the changes between 8.4.0 and 8.4.2 and apply them as a patch to 8.4.0, but I don't think I'll do it. It will be confusing if the debian stable version is called 8.4.0 but actually includes most of the fixes from 8.4.2. If it's too late to accept this unblock request, that's fine; we'll just leave things as they are. I plan on releasing a version 9 this summer, and I can just do a backport. If the unblock request is rejected, please feel free to close the request. Thanks! --Jay
Bug#805093: transition: qpdf
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition The latest version of qpdf includes an soname bump. The qpdf transition is very small. The only other source package with a dependency on libqpdf is cups-filters. qpdf 6.0.0 with libqpdf17 has already passed the NEW and is waiting in experimental. As soon as I get the green light, I can upload to unstable and a rebuild of cups-filters can be triggered. This is completely source compatible with the pervious versions. Ben file: title = "qpdf"; is_affected = .depends ~ "libqpdf13v5" | .depends ~ "libqpdf17"; is_good = .depends ~ "libqpdf17"; is_bad = .depends ~ "libqpdf13v5"; -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.2.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#757025: icu 53 is no longer current
I am not going to be able to handle the ICU transition and am looking for a new maintainer for ICU (an RFA is open). Whoever takes over ICU will have to manage the transition to whatever version of ICU is current at the time, and it will have to be handled after jessie is released. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150211132946.0261508682.qww314...@jberkenbilt-linux.appiancorp.com
Bug#775968: unblock: icu/52.1-7
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package icu
A small, localized fix to ICU fixes CVE-2014-6591 and CVE-2014-6585. ICU
passes its test suite after application of this patch. The security team
requested that this be included for Jessie. See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775884 for additional
details.
unblock icu/52.1-7
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru icu-52.1/debian/changelog icu-52.1/debian/changelog
--- icu-52.1/debian/changelog 2014-09-29 10:27:22.0 -0400
+++ icu-52.1/debian/changelog 2015-01-21 21:47:39.0 -0500
@@ -1,3 +1,10 @@
+icu (52.1-7) unstable; urgency=high
+
+ * Patch to CVE-2014-6591, CVE-2014-6585 a font parsing bug.
+(Closes: #775884)
+
+ -- Jay Berkenbilt q...@debian.org Wed, 21 Jan 2015 21:33:19 -0500
+
icu (52.1-6) unstable; urgency=medium
* Ensure that only flags intended to be set by users make it into
diff -Nru icu-52.1/debian/patches/CVE-2014-6591.patch icu-52.1/debian/patches/CVE-2014-6591.patch
--- icu-52.1/debian/patches/CVE-2014-6591.patch 1969-12-31 19:00:00.0 -0500
+++ icu-52.1/debian/patches/CVE-2014-6591.patch 2015-01-21 21:47:39.0 -0500
@@ -0,0 +1,59 @@
+Description: fix ICU font parsing problem
+Bug-Debian: http://bugs.debian.org/775884
+Bug-RedHat: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2014-6591
+
+Index: icu/source/layout/CursiveAttachmentSubtables.cpp
+===
+--- icu.orig/source/layout/CursiveAttachmentSubtables.cpp
icu/source/layout/CursiveAttachmentSubtables.cpp
+@@ -20,6 +20,9 @@ le_uint32 CursiveAttachmentSubtable::pro
+ le_int32 coverageIndex = getGlyphCoverage(base, glyphID, success);
+ le_uint16 eeCount = SWAPW(entryExitCount);
+
++LEReferenceToArrayOfEntryExitRecord
++entryExitRecordsArrayRef(base, success, entryExitRecords, coverageIndex);
++
+ if (coverageIndex 0 || coverageIndex = eeCount) {
+ glyphIterator-setCursiveGlyph();
+ return 0;
+Index: icu/source/layout/Features.cpp
+===
+--- icu.orig/source/layout/Features.cpp
icu/source/layout/Features.cpp
+@@ -15,6 +15,9 @@ U_NAMESPACE_BEGIN
+
+ LEReferenceToFeatureTable FeatureListTable::getFeatureTable(const LETableReference base, le_uint16 featureIndex, LETag *featureTag, LEErrorCode success) const
+ {
++LEReferenceToArrayOfFeatureRecord
++featureRecordArrayRef(base, success, featureRecordArray, featureIndex);
++
+ if (featureIndex = SWAPW(featureCount) || LE_FAILURE(success)) {
+ return LEReferenceToFeatureTable();
+ }
+Index: icu/source/layout/LigatureSubstSubtables.cpp
+===
+--- icu.orig/source/layout/LigatureSubstSubtables.cpp
icu/source/layout/LigatureSubstSubtables.cpp
+@@ -27,6 +27,9 @@ le_uint32 LigatureSubstitutionSubtable::
+ Offset ligTableOffset = SWAPW(ligSetTable-ligatureTableOffsetArray[lig]);
+ const LigatureTable *ligTable = (const LigatureTable *) ((char *)ligSetTable + ligTableOffset);
+ le_uint16 compCount = SWAPW(ligTable-compCount) - 1;
++LEReferenceToArrayOfTTGlyphID
++componentArrayRef(base, success, ligTable-componentArray, compCount);
++if (LE_FAILURE(success)) { return 0; }
+ le_int32 startPosition = glyphIterator-getCurrStreamPosition();
+ TTGlyphID ligGlyph = SWAPW(ligTable-ligGlyph);
+ le_uint16 comp;
+Index: icu/source/layout/MultipleSubstSubtables.cpp
+===
+--- icu.orig/source/layout/MultipleSubstSubtables.cpp
icu/source/layout/MultipleSubstSubtables.cpp
+@@ -35,6 +35,8 @@ le_uint32 MultipleSubstitutionSubtable::
+
+ le_int32 coverageIndex = getGlyphCoverage(base, glyph, success);
+ le_uint16 seqCount = SWAPW(sequenceCount);
++LEReferenceToArrayOfOffset
++sequenceTableOffsetArrayRef(base, success, sequenceTableOffsetArray, seqCount);
+
+ if (coverageIndex = 0 coverageIndex seqCount) {
+ Offset sequenceTableOffset = SWAPW(sequenceTableOffsetArray[coverageIndex]);
diff -Nru icu-52.1/debian/patches/series icu-52.1/debian/patches/series
--- icu-52.1/debian/patches/series 2014-09-29 10:27:22.0 -0400
+++ icu-52.1/debian/patches/series 2015-01-21 21:47:39.0 -0500
@@ -6,3 +6,4 @@
mlym-crash.patch
two-digit-year-test.patch
icu-config.patch
+CVE-2014-6591.patch
Bug#774235: unblock: tiff/4.0.3-12
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package tiff
This is a narrowly targeted fix from upstream for CVE-2014-9330. It
changes only bmp2tiff, one of the tools that is part of libtiff-tools.
Although the bug was not created as RC, other similar bugs that only
affect tools in libtiff-tools have been classified as RC, and this fixes
a security issue with an assigned CVE number, so I think it would be
best if it goes through.
debdiff attached.
unblock tiff/4.0.3-12
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru tiff-4.0.3/debian/changelog tiff-4.0.3/debian/changelog
--- tiff-4.0.3/debian/changelog 2014-12-23 15:52:13.0 -0500
+++ tiff-4.0.3/debian/changelog 2014-12-30 11:32:33.0 -0500
@@ -1,3 +1,9 @@
+tiff (4.0.3-12) unstable; urgency=high
+
+ * Fix integer overflow in bmp2tiff. CVE-2014-9330. (Closes: #773987)
+
+ -- Jay Berkenbilt q...@debian.org Tue, 30 Dec 2014 11:32:04 -0500
+
tiff (4.0.3-11) unstable; urgency=medium
* Don't crash on JPEG = non-JPEG conversion (Closes: #741451)
diff -Nru tiff-4.0.3/debian/patches/CVE-2014-9330.patch tiff-4.0.3/debian/patches/CVE-2014-9330.patch
--- tiff-4.0.3/debian/patches/CVE-2014-9330.patch 1969-12-31 19:00:00.0 -0500
+++ tiff-4.0.3/debian/patches/CVE-2014-9330.patch 2014-12-30 11:32:33.0 -0500
@@ -0,0 +1,45 @@
+Description: CVE-2014-9330
+ Integer overflow in bmp2tiff
+Origin: upstream, http://bugzilla.maptools.org/show_bug.cgi?id=2494
+Bug: http://bugzilla.maptools.org/show_bug.cgi?id=2494
+Bug-Debian: http://bugs.debian.org/773987
+
+Index: tiff/tools/bmp2tiff.c
+===
+--- tiff.orig/tools/bmp2tiff.c
tiff/tools/bmp2tiff.c
+@@ -1,4 +1,4 @@
+-/* $Id: bmp2tiff.c,v 1.23 2010-03-10 18:56:49 bfriesen Exp $
++/* $Id: bmp2tiff.c,v 1.24 2014-12-21 15:15:32 erouault Exp $
+ *
+ * Project: libtiff tools
+ * Purpose: Convert Windows BMP files in TIFF.
+@@ -403,6 +403,13 @@ main(int argc, char* argv[])
+
+ width = info_hdr.iWidth;
+ length = (info_hdr.iHeight 0) ? info_hdr.iHeight : -info_hdr.iHeight;
++if( width = 0 || length = 0 )
++{
++TIFFError(infilename,
++ Invalid dimensions of BMP file );
++close(fd);
++return -1;
++}
+
+ switch (info_hdr.iBitCount)
+ {
+@@ -593,6 +600,14 @@ main(int argc, char* argv[])
+
+ compr_size = file_hdr.iSize - file_hdr.iOffBits;
+ uncompr_size = width * length;
++/* Detect int overflow */
++if( uncompr_size / width != length )
++{
++TIFFError(infilename,
++Invalid dimensions of BMP file );
++close(fd);
++return -1;
++}
+ comprbuf = (unsigned char *) _TIFFmalloc( compr_size );
+ if (!comprbuf) {
+ TIFFError(infilename,
diff -Nru tiff-4.0.3/debian/patches/series tiff-4.0.3/debian/patches/series
--- tiff-4.0.3/debian/patches/series 2014-12-23 15:52:13.0 -0500
+++ tiff-4.0.3/debian/patches/series 2014-12-30 11:32:33.0 -0500
@@ -7,3 +7,4 @@
CVE-2013-4244.patch
CVE-2013-4243.patch
jpeg-colorspace.patch
+CVE-2014-9330.patch
Bug#773837: unblock: tiff/4.0.3-11
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package tiff
This is a very localized patch to the tiffcp utility (doesn't even
affect the tiff library) to fix a potential crash, fixing RC bug
#741451. The originated from upstream where it was based on a fix
previously submitted by the original reporter.
(include/attach the debdiff against the package in testing)
unblock tiff/4.0.3-11
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru tiff-4.0.3/debian/changelog tiff-4.0.3/debian/changelog
--- tiff-4.0.3/debian/changelog 2014-06-29 17:32:44.0 -0400
+++ tiff-4.0.3/debian/changelog 2014-12-23 15:52:13.0 -0500
@@ -1,3 +1,10 @@
+tiff (4.0.3-11) unstable; urgency=medium
+
+ * Don't crash on JPEG = non-JPEG conversion (Closes: #741451)
+ * Thanks Tomasz Buchert tomasz.buch...@inria.fr for preparing the fix!
+
+ -- Jay Berkenbilt q...@debian.org Tue, 23 Dec 2014 15:51:40 -0500
+
tiff (4.0.3-10) unstable; urgency=medium
* Remove libtiff4-dev, completing the tiff transition. Packages that
diff -Nru tiff-4.0.3/debian/patches/jpeg-colorspace.patch tiff-4.0.3/debian/patches/jpeg-colorspace.patch
--- tiff-4.0.3/debian/patches/jpeg-colorspace.patch 1969-12-31 19:00:00.0 -0500
+++ tiff-4.0.3/debian/patches/jpeg-colorspace.patch 2014-12-23 15:52:13.0 -0500
@@ -0,0 +1,38 @@
+Description: fix for Debian bug #741451
+ tiffcp crashes when converting JPEG-encoded TIFF to a different
+ encoding (like none or lzw). For example this will probably fail:
+ .
+tiffcp -c none jpeg_encoded_file.tif output.tif
+ .
+ The reason is that when the input file contains JPEG data,
+ the tiffcp code forces conversion to RGB space. However,
+ the output normally inherits YCbCr subsampling parameters
+ from the input, which leads to a smaller working buffer
+ than necessary. The buffer is subsequently overrun inside
+ cpStripToTile() (called from writeBufferToContigTiles).
+ Note that the resulting TIFF file would be scrambled even
+ if tiffcp wouldn't crash, since the output file would contain
+ RGB data intepreted as subsampled YCbCr values.
+ .
+ This patch fixes the problem by forcing RGB space on the output
+ TIF if the input is JPEG-encoded and output is *not* JPEG-encoded.
+Origin: upstream, http://bugzilla.maptools.org/show_bug.cgi?id=2480
+Author: Tomasz Buchert tomasz.buch...@inria.fr
+Bug: http://bugzilla.maptools.org/show_bug.cgi?id=2480
+Bug-Debian: http://bugs.debian.org/741451
+
+--- a/tools/tiffcp.c
b/tools/tiffcp.c
+@@ -629,6 +629,12 @@
+ TIFFSetField(out, TIFFTAG_PHOTOMETRIC,
+ samplesperpixel == 1 ?
+ PHOTOMETRIC_LOGL : PHOTOMETRIC_LOGLUV);
++ else if (input_compression == COMPRESSION_JPEG
++ samplesperpixel == 3) {
++ /* RGB conversion was forced above
++ hence the output will be of the same type */
++ TIFFSetField(out, TIFFTAG_PHOTOMETRIC, PHOTOMETRIC_RGB);
++ }
+ else
+ CopyTag(TIFFTAG_PHOTOMETRIC, 1, TIFF_SHORT);
+ if (fillorder != 0)
diff -Nru tiff-4.0.3/debian/patches/series tiff-4.0.3/debian/patches/series
--- tiff-4.0.3/debian/patches/series 2014-06-29 17:32:44.0 -0400
+++ tiff-4.0.3/debian/patches/series 2014-12-23 15:52:13.0 -0500
@@ -6,3 +6,4 @@
CVE-2013-4232.patch
CVE-2013-4244.patch
CVE-2013-4243.patch
+jpeg-colorspace.patch
Bug#769618: unblock: qpdf/5.1.2-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package qpdf
Version 5.1.2-2 fixes bug #769599, originally reported as
https://bugs.launchpad.net/ubuntu/+source/qpdf/+bug/1392048.
One-sentence summary: this one-line code change fixes a bug that makes
it impossible to print certain PDF files that contain blank pages.
Detailed description: a PDF file may contain a page that lacks a
/Contents key in its page dictionary. This is one way to represent a
blank page in a PDF file. (The other, more common way is to include
/Contents but have it be empty.) The /usr/lib/cups/filter/pdftopdf
program, which is part of cups-filters, uses the qpdf library in this
way, so without this fix, it is not possible to print PDF files that
contain blank pages implemented in this way. The fix to this bug is one
line of code, and I have already committed the fix upstream. (I am
upstream for qpdf.) The patch attached here includes only the code
change, but the original commit also includes updates to the extensive
test suite.
Changelog entry:
--
qpdf (5.1.2-2) unstable; urgency=medium
* Properly handle pages with no /Content in the page dictionary,
enabling printing of files with blank pages as produced by some
software. (Closes: #769599)
-- Jay Berkenbilt q...@debian.org Fri, 14 Nov 2014 21:07:25 -0500
--
unblock qpdf/5.1.2-2
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru qpdf-5.1.2/debian/changelog qpdf-5.1.2/debian/changelog
--- qpdf-5.1.2/debian/changelog 2014-06-07 17:14:59.0 -0400
+++ qpdf-5.1.2/debian/changelog 2014-11-14 21:22:24.0 -0500
@@ -1,3 +1,11 @@
+qpdf (5.1.2-2) unstable; urgency=medium
+
+ * Properly handle pages with no /Content in the page dictionary,
+enabling printing of files with blank pages as produced by some
+software. (Closes: #769599)
+
+ -- Jay Berkenbilt q...@debian.org Fri, 14 Nov 2014 21:07:25 -0500
+
qpdf (5.1.2-1) unstable; urgency=medium
* New upstream release.
diff -Nru qpdf-5.1.2/debian/patches/page-no-content.patch qpdf-5.1.2/debian/patches/page-no-content.patch
--- qpdf-5.1.2/debian/patches/page-no-content.patch 1969-12-31 19:00:00.0 -0500
+++ qpdf-5.1.2/debian/patches/page-no-content.patch 2014-11-14 21:22:24.0 -0500
@@ -0,0 +1,44 @@
+Description: properly handle page with no /Content
+Origin: upstream, https://github.com/qpdf/qpdf/commit/caab1b0e1642bc6ee0194c7ab4c4a4de2ab22f2c
+Bug-Debian: http://bugs.debian.org/769599
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/qpdf/+bug/1392048
+
+commit caab1b0e1642bc6ee0194c7ab4c4a4de2ab22f2c
+Author: Jay Berkenbilt e...@ql.org
+Date: Fri Nov 14 13:43:34 2014 -0500
+
+Handle pages with no /Contents from getPageContents()
+
+The spec allows /Contents to be omitted for pages that are blank, but
+QPDFObjectHandle::getPageContents() was throwing an exception in this
+case.
+
+Index: qpdf/ChangeLog
+===
+--- qpdf.orig/ChangeLog
qpdf/ChangeLog
+@@ -1,3 +1,11 @@
++2014-11-14 Jay Berkenbilt e...@ql.org
++
++ * Bug fix: QPDFObjectHandle::getPageContents() no longer throws an
++ exception when called on a page that has no /Contents key in its
++ dictionary. This is allowed by the spec, and some software
++ packages generate files like this for pages that are blank in the
++ original.
++
+ 2014-06-07 Jay Berkenbilt e...@ql.org
+
+ * 5.1.2: release
+Index: qpdf/libqpdf/QPDFObjectHandle.cc
+===
+--- qpdf.orig/libqpdf/QPDFObjectHandle.cc
qpdf/libqpdf/QPDFObjectHandle.cc
+@@ -633,7 +633,7 @@ QPDFObjectHandle::getPageContents()
+ {
+ result.push_back(contents);
+ }
+-else
++else if (! contents.isNull())
+ {
+ throw std::runtime_error(unknown object type inspecting /Contents
+ key in page dictionary);
diff -Nru qpdf-5.1.2/debian/patches/series qpdf-5.1.2/debian/patches/series
--- qpdf-5.1.2/debian/patches/series 2014-06-07 17:14:59.0 -0400
+++ qpdf-5.1.2/debian/patches/series 2014-11-14 21:22:24.0 -0500
@@ -0,0 +1 @@
+page-no-content.patch
Bug#757025: transition: icu
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition ICU version 53 is out, and this is the latest version of ICU that will be available before the freeze for Jesse, so this will be the only remaining ICU transition the Jesse freeze.. (ICU does releases by the calendar.) ICU transitions have historically been quite painless. The dev package is just called libicu-dev, and the API is very stable. Failure to keep ICU reasonably current results in important packages like libreoffice pulling in their own ICU, which is a challenge from a security standpoint. I have already put ICU 53 in experimental, so most likely, doing this transition is just giving me the okay to upload to experimental and then scheduling binary NMUs of downstream packages. This has been the case in the past. Ben file: title = icu; is_affected = .depends ~ libicu52 | .depends ~ libicu52-dbg | .depends ~ libicu53 | .depends ~ libicu53-dbg; is_good = .depends ~ libicu53 | .depends ~ libicu53-dbg; is_bad = .depends ~ libicu52 | .depends ~ libicu52-dbg; -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140804115950.0234191861.qww314...@soup.appiancorp.com
Re: dropping libtiff4-dev transitional package
Emilio Pozuelo Monfort po...@debian.org wrote: On 23/06/14 21:20, Jay Berkenbilt wrote: There are 27 packages (including 1 pending upload) left that still have build dependencies on libtiff4-dev: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=libtiff4-dev;users=q...@debian.org At this point, I'd like to go ahead and remove libtiff4-dev and change these to serious since they will be FTBFS. I'm thinking most people will probably fix their packages soon after this, and I can work on NMUs for the rest after a little more time. I think we should act soon if we want go get the libtiff4-dev transitional out of the archive before jessie. Any objections? Sounds good to me. Cheers, Emilio Does it need a hint to transition to jessie? tiff-4.0.3-10 is not going because of the (intentional) disappearance of binary package libtiff4-dev. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140708135452.3193645226.qww314...@jberkenbilt-linux.appiancorp.com
dropping libtiff4-dev transitional package
There are 27 packages (including 1 pending upload) left that still have build dependencies on libtiff4-dev: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=libtiff4-dev;users=q...@debian.org At this point, I'd like to go ahead and remove libtiff4-dev and change these to serious since they will be FTBFS. I'm thinking most people will probably fix their packages soon after this, and I can work on NMUs for the rest after a little more time. I think we should act soon if we want go get the libtiff4-dev transitional out of the archive before jessie. Any objections? -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140623152042.0241539363.qww314...@jberkenbilt-linux.appiancorp.com
Bug#717923: tiff transition apparently nearing completion
It looks like there are only two blocking bugs left on the tiff transition and only one of them applies to a package that's in testing (gimp). After these issues are resolved, will it be time for me to request removal of the tiff3 package? If not, what is the trigger that the time has come to request removal? -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140122153512.0235710083.qww314...@jberkenbilt-linux.appiancorp.com
Re: permission to do a vips upload to proposed-updates (bug 714984)
Adam D. Barratt a...@adam-barratt.org.uk wrote: On 2013-12-21 14:49, Adam D. Barratt wrote: On 2013-12-20 22:02, Jay Berkenbilt wrote: Adam D. Barratt a...@adam-barratt.org.uk wrote: Before giving a final ack, please could you provide a source debdiff of the package you're proposing to upload, preferably versioned as 7.28.5-1 +deb7u1? Attached. Thanks! Please go ahead; thanks. For the record, this was uploaded and I've just flagged it for acceptance in to p-u. Thanks. One request: for future updates, please open a suitably-tagged bug report against release.debian.org (e.g. via reportbug). Noted. I think I knew this at one time and forgot. I was going to suggest updating the developer's reference to mention this explicitly, but I see it's already there. I will, instead, update my brain, which appears to have gotten out of date. Unfortunately, there's some problem with the data storage system that my brain uses which causes it to sometimes retrieve old versions of information I have stored there. This happened not long ago when I requested a library transition. Hopefully I can make myself remember that I should always try reportbug against release.debian.org before emailing debian-release@lists.debian.org. Thanks. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131223170828.0401913930.qww314...@soup.q.qbilt.org
permission to do a vips upload to proposed-updates (bug 714984)
Details are in bug 714984. There's a small bug in vips in wheezy that prevents jpeg compression from working right in some cases. This severely impacts the use of vips for certain types of work. The problem seems to be related to the jpeg transition, but upstream provided a small patch. Mathieu Malaterre ma...@debian.org did a great job of reporting the problem upstream, testing it, and having another user test it, so I think this is ready for a stable upload. If you are okay with it, I will prepare an upload, build against wheezy, and upload to proposed-updates. Any objections? Note that the current vips in jessie and sid are not affected by this problem, nor is the version in squeeze. This problem only affects the version in wheezy. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131220101345.3007967710.qww314...@jberkenbilt-linux.appiancorp.com
Re: permission to do a vips upload to proposed-updates (bug 714984)
Adam D. Barratt a...@adam-barratt.org.uk wrote:
Before giving a final ack, please could you provide a source debdiff of
the package you're proposing to upload, preferably versioned as 7.28.5-1
+deb7u1?
Attached. Thanks!
--
Jay Berkenbilt q...@debian.org
diff -Nru vips-7.28.5/debian/changelog vips-7.28.5/debian/changelog
--- vips-7.28.5/debian/changelog 2012-05-29 14:25:06.0 -0400
+++ vips-7.28.5/debian/changelog 2013-12-20 16:53:02.0 -0500
@@ -1,3 +1,11 @@
+vips (7.28.5-1+deb7u1) stable; urgency=low
+
+ * Fix crash on tiff with jpeg compression. Thanks to Mathieu Malaterre
+ma...@debian.org for diagnosing this bug, getting a fix from
+upstream, and preparing a patch. (Closes: #689523, #714984, #731948)
+
+ -- Jay Berkenbilt q...@debian.org Fri, 20 Dec 2013 16:39:12 -0500
+
vips (7.28.5-1) unstable; urgency=low
* New upstream release
diff -Nru vips-7.28.5/debian/patches/bug714984.patch vips-7.28.5/debian/patches/bug714984.patch
--- vips-7.28.5/debian/patches/bug714984.patch 1969-12-31 19:00:00.0 -0500
+++ vips-7.28.5/debian/patches/bug714984.patch 2013-12-20 16:53:02.0 -0500
@@ -0,0 +1,103 @@
+Description: Segmentation Fault: vips 7.28.5-1 with jpeg compression
+ commit 996f26ec7011f6eb1aad4c204100d0f0970e2cad
+ Author: John Cupitt jcup...@gmail.com
+ Date: Fri Dec 13 15:03:16 2013 +
+
+ fix a tiff write crash
+
+ see
+
+ http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714984
+ https://github.com/jcupitt/libvips/issues/88
+Bug-Debian: http://bugs.debian.org/714984
+Reviewed-by: Mathieu Malaterre ma...@debian.org
+
+Index: vips-7.28.5/ChangeLog
+===
+--- vips-7.28.5.orig/ChangeLog 2012-05-06 13:29:26.0 +0200
vips-7.28.5/ChangeLog 2013-12-14 10:47:03.610487401 +0100
+@@ -1,3 +1,6 @@
++13/12/13 started 7.28.5-1
++- fix jpeg tiff write, see https://github.com/jcupitt/libvips/issues/88
++
+ 19/4/12 started 7.28.5
+ - ifthenelse blend mode was broken
+ - small blend speedup
+Index: vips-7.28.5/libvips/foreign/vips2tiff.c
+===
+--- vips-7.28.5.orig/libvips/foreign/vips2tiff.c 2012-05-06 13:29:26.0 +0200
vips-7.28.5/libvips/foreign/vips2tiff.c 2013-12-14 10:47:03.610487401 +0100
+@@ -126,6 +126,8 @@
+ * 2/12/11
+ * - make into a simple function call ready to be wrapped as a new-style
+ * VipsForeign class
++ * 7/8/12
++ * - be more cautious enabling YCbCr mode
+ */
+
+ /*
+@@ -452,15 +454,9 @@
+ TIFFSetField( tif, TIFFTAG_ORIENTATION, ORIENTATION_TOPLEFT );
+ TIFFSetField( tif, TIFFTAG_COMPRESSION, tw-compression );
+
+- if( tw-compression == COMPRESSION_JPEG ) {
++ if( tw-compression == COMPRESSION_JPEG )
+ TIFFSetField( tif, TIFFTAG_JPEGQUALITY, tw-jpqual );
+
+- /* Enable rgb-ycbcr conversion in the jpeg write. See also
+- * the photometric selection below.
+- */
+- TIFFSetField( tif, TIFFTAG_JPEGCOLORMODE, JPEGCOLORMODE_RGB );
+- }
+-
+ if( tw-predictor != -1 )
+ TIFFSetField( tif, TIFFTAG_PREDICTOR, tw-predictor );
+
+@@ -518,12 +514,17 @@
+ TIFFTAG_INKSET, INKSET_CMYK );
+ }
+ else if( tw-compression == COMPRESSION_JPEG
+-tw-im-Bands == 3 )
++tw-im-Bands == 3
++tw-im-BandFmt == VIPS_FORMAT_UCHAR ) {
+ /* This signals to libjpeg that it can do
+ * YCbCr chrominance subsampling from RGB, not
+ * that we will supply the image as YCbCr.
+ */
+ photometric = PHOTOMETRIC_YCBCR;
++TIFFSetField( tif,
++ TIFFTAG_JPEGCOLORMODE,
++ JPEGCOLORMODE_RGB );
++ }
+ else
+ photometric = PHOTOMETRIC_RGB;
+
+@@ -1340,9 +1341,27 @@
+ /* TIFFTAG_JPEGQUALITY is a pesudo-tag, so we can't copy it.
+ * Set explicitly from TiffWrite.
+ */
+- if( tw-compression == COMPRESSION_JPEG )
++ if( tw-compression == COMPRESSION_JPEG ) {
+ TIFFSetField( out, TIFFTAG_JPEGQUALITY, tw-jpqual );
+
++ /* Only for three-band, 8-bit images.
++ */
++ if( tw-im-Bands == 3
++ tw-im-BandFmt == VIPS_FORMAT_UCHAR ) {
++ /* Enable rgb-ycbcr conversion in the jpeg write.
++ */
++ TIFFSetField( out,
++TIFFTAG_JPEGCOLORMODE, JPEGCOLORMODE_RGB );
++
++ /* And we want ycbcr expanded to rgb on read.
++ * Otherwise TIFFTileSize() will give us the size of
++ * a chrominance subsampled tile.
++ */
++ TIFFSetField( in,
++TIFFTAG_JPEGCOLORMODE, JPEGCOLORMODE_RGB );
++ }
++ }
++
+ /* We can't copy profiles :( Set again from TiffWrite.
+ */
+ if( embed_profile( tw, out ) )
diff -Nru vips-7.28.5/debian/patches/series vips-7.28.5/debian/patches/series
--- vips-7.28.5/debian/patches/series 2010-02-06 17:41:01.0 -0500
+++ vips-7.28.5/debian/patches/series 2013-12-20 16:53:02.0 -0500
@@ -0,0 +1 @@
+bug714984.patch
Bug#729531: transition: icu
Julien Cristau jcris...@debian.org wrote: I'd like to upgrade the version of ICU from 4.8 to 52. They changed their version numbering scheme essentially multiplying everything by 10. We skipped a few versions (49, 50, 51) because of the freeze before wheezy. This is the first major version to be released since Wheezy. (A major ICU version is released every six months.) ICU 52 should be source compatible but not binary compile with ICU 4.8. Many bugs have been fixed since ICU 4.8. I have basically done a library transition approximately every other ICU version, and they have all gone smoothly up to this point. The dev package name is versionless (libicu-dev) so this transition should be able to be done with just a forced rebuild of ICU's reverse dependencies. Please go ahead, and let us know when icu 52 is installed on all archs so we can start the rebuilds. ICU 52 is installed on all architectures now. Thanks! -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131204082445.0398451667.qww314...@soup.q.qbilt.org
Bug#717923: transition: tiff 4.x (libtiff5)
Julien Cristau jcris...@debian.org wrote:
On Tue, Dec 3, 2013 at 16:02:17 -0500, Jay Berkenbilt wrote:
If you're good with this plan, give me the word, and I will do the
upload. I can probably take care of the mass bug filing...I can script
it locally unless you have a quick way to do it.
Sounds good to me, I think we can go ahead with this.
I've got it ready to go but with two changes, so I wanted to get
confirmation.
1. Why is it necessary for the transition packages to depend on the
binary libraries and not just the dev package? If libtiff4-dev and
libtiff5-alt-dev depend on libtiff5-dev ( 4.0.3-6~), isn't this
sufficient? Is there some special reason that the dependency on
libtiff5 (and presumably also libtiffxx5) has to be explicit?
2. I think I'm going punt on libtiff4-alt-dev. Fedora switched over
to tiff 4.x a while ago and never provided any way for people to build
against 3.x libraries. There were only something like 3 packages that
had any issues, and by now, fixes are available in all cases. Also,
unlike libtiff5-alt-dev, which was totally transparent because of
pkg-config, tiff 3.x doesn't use pkg-config, so having people use it
would require changes to their builds anyway.
The new package will 4.0.3-6. For libtiff4-dev and libtiff5-alt-dev,
both provided by the tiff source package, I have
Depends: ${misc:Depends}, libtiff5-dev ( 4.0.3-6~)
and for libtiff5-dev, I have
Replaces: libtiff5-alt-dev ( 4.0.3-6~), libtiff4-dev ( 4.0.3-6~)
Conflicts: libtiff5-alt-dev ( 4.0.3-6~), libtiff4-dev ( 4.0.3-6~)
Provides: libtiff-dev
For the tiff3 package, I just dropped the libtiff4-dev package and the
provides of libtiff-dev along with it. There will be no -dev package
for tiff 3.x.
I won't upload today because I want to compose a message to debian-devel
first, but if this sounds okay, I will do the upload tomorrow. I did
various tests including installing libtiff4-dev and libtiff5-alt-dev and
upgrading. The upgrade pulled in libtiff5-dev and libtiff5xx (libtiff5
was already on my system) and autoremoved libtiffxx0c2, and then it was
safe for me to remove the two transitional packages as expected. I also
tested building vips in a chroot with the updated packages. vips has
tons of dependencies including both tiff4 and tiff5 indirectly.
Everything looks good there as well.
--
Jay Berkenbilt q...@debian.org
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20131204165927.0208763127.qww314...@jberkenbilt-linux.appiancorp.com
Bug#717923: transition: tiff 4.x (libtiff5)
Julien Cristau jcris...@debian.org wrote: Hi Jay, first, sorry for not handling this sooner. Apology accepted. I know you guys have too much to do and not enough resources. On Fri, Jul 26, 2013 at 11:33:03 -0400, Jay Berkenbilt wrote: Rationale for not keeping libtiff4-dev: * tiff 3.x does not support pkg-config. We can't install libtiff4 dev files in a standard path since they will then conflict with libtiff-dev. Therefore, source packages that must have libtiff4-dev will have to make changes to their builds anyway to change include and library paths; simple binary NMU for this case is not possible. Forcing them to change the build dependency to libtiff4-alt-dev makes it easier to track which packages need attention and which packages have already been updated. Basically everyone with libtiff4-dev in their build dependency list will either have to replace it with libtiff-dev or replace it with libtiff4-alt-dev and update include and library paths. So I think your plan sounds good, but I would really prefer to have as few packages as possible build-depending on libtiff4-dev before we flip the switch. Either that, or make the libtiff-dev built from the tiff 4.x source package temporarily build a transitional libtiff4-dev package depending on libtiff-dev and libtiff5, do the mass bug filing, and give people a couple months to change their build-deps (or less, if there are volunteers for an aggressive NMU campaign). I count about 70 such source packages right now, and making them all FTBFS would be annoying. Sounds great to me. I think this plan will make for a smoother transition: 1. tiff3: stop providing libtiff-dev, drop libtiff4-dev, add libtiff4-alt-dev as in the original plan. 2. tiff: New plan: keep libtiff5-dev but have it provide libtiff-dev. Don't drop libtiff5-alt-dev, but instead make it a transitional package that depends on libtiff5-dev. Incorporate your suggestion of adding libtiff4-dev to depend on libtiff-dev and libtiff5. 3. Do mass bug filing as described before. Give people some time to adjust. 4. Eventually remove libtiff5-alt-dev and libtiff4-dev from the tiff package and drop the tiff3 package. Deal with anything that's FTBFS at that time. Only step 2 really differs from my original plan, and I agree that it is an improvement. By adding the libtiff4-dev package that you suggest and also making libtiff5-alt-dev a transitional package that depends on libtiff5-dev, very few if any should packages be FTBFS during the transition, right? Note that Ubuntu has had libtiff5-dev providing libtiff-dev for some time now, which bodes well for us. If you're good with this plan, give me the word, and I will do the upload. I can probably take care of the mass bug filing...I can script it locally unless you have a quick way to do it. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131203160217.2981378896.qww314...@jberkenbilt-linux.appiancorp.com
Bug#729531: ICU 52.1 in experimental
I neglected to mention that ICU 5.2 is packaged and in experimental. When I get the green light from the release team to upload, it should be ready to go. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131114103002.0503992294.qww314...@jberkenbilt-linux.appiancorp.com
Bug#729531: transition: icu
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition I'd like to upgrade the version of ICU from 4.8 to 52. They changed their version numbering scheme essentially multiplying everything by 10. We skipped a few versions (49, 50, 51) because of the freeze before wheezy. This is the first major version to be released since Wheezy. (A major ICU version is released every six months.) ICU 52 should be source compatible but not binary compile with ICU 4.8. Many bugs have been fixed since ICU 4.8. I have basically done a library transition approximately every other ICU version, and they have all gone smoothly up to this point. The dev package name is versionless (libicu-dev) so this transition should be able to be done with just a forced rebuild of ICU's reverse dependencies. Ben file: title = icu; is_affected = .depends ~ libicu48 | .depends ~ libicu52; is_good = .depends ~ libicu52; is_bad = .depends ~ libicu48; -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131113164158.0666434927.qww314159@soup
Re: tiff 4.x (libtiff5) transition
Luk Claes l...@debian.org wrote: Your plan looks good except that I think it would be better to have libtiff5-dev provide libtiff-dev and not introduce a proper libtiff-dev. Thanks for the reply. That's fine, I can make that modification. Rereading my plan all the way through, I think having libtiff5-dev provide libtiff-dev instead of renaming it requires small and obvious changes and also means that people who depend on libtiff5-dev don't technically have to change their packages. I'd still rather have people build depend on libtiff-dev. Most of my arguments for not having libtiff5-dev were based on potential future transitions, which are not all that likely to happen. That said, I do use unversioned dev package names for all my other library packages, and if I were packaging tiff from scratch today, I would probably do it that way. But I don't feel strongly, so I can and will go with your modification unless someone tells me not to. I am assuming this is not an invitation to proceed yet, right? I am holding off on doing it until I actually get an explicit go-ahead. If I'm supposed to take this as a green light, please let me know. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130903141817.0222656689.qww314...@jberkenbilt-linux.appiancorp.com
Bug#717922: transition: qpdf
Package: release.debian.org Usertags: transition I have uploaded qpdf 5.0.0-2 to unstable. This is a transition from libqpdf10 to libqpdf13. It's source compatible, and the one package (cups-filters) that build depends on libqpdf-dev just needs a binary NMU. (I'm not even sure I have to tell you about this...I think this has happened automatically in the past, but I can't remember for sure.) -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130726112918.1573207152.qww314...@jberkenbilt-linux.appiancorp.com
Bug#717923: transition: tiff 4.x (libtiff5)
. Rationale for not having libtiff-dev provide libtiff5-dev: * Hardly anything can be depending on libtiff5-dev since it would only be possible currently if you have no packages in your dependency or reverse dependency chain that build depend on libtiff4-dev. * Not having a libtiff5-dev in the archive at all will make it easier for us in dealing with some future hypothetical upgrade to a newer non-binary-compatible version in the future. No such upgrade is planned, and upstream is pretty much just in maintenance mode, but you never know. Rationale for not keeping libtiff4-dev: * tiff 3.x does not support pkg-config. We can't install libtiff4 dev files in a standard path since they will then conflict with libtiff-dev. Therefore, source packages that must have libtiff4-dev will have to make changes to their builds anyway to change include and library paths; simple binary NMU for this case is not possible. Forcing them to change the build dependency to libtiff4-alt-dev makes it easier to track which packages need attention and which packages have already been updated. Basically everyone with libtiff4-dev in their build dependency list will either have to replace it with libtiff-dev or replace it with libtiff4-alt-dev and update include and library paths. Right now, we have a stable state where the default is libtiff4, most packages get libtiff4, those that need libtiff5 can get it with special workarounds, and libtiff4 and libtiff5 can be arbitrarily mixed in the dependency/build dependency chain. This step can get us quickly to a new stable state that reverses the roles of libtiff4 and libtiff5: the default becomes libtiff5, most packages get libtiff5, those that need libtiff4 can get it with special workarounds, and libtiff4 and libtiff5 can be arbitrarily mixed in the dependency/build dependency chain. Though things will admittedly be a little chaotic right after the initial upload, we will quickly reach a point where new versions can transition to jessie, and we can work at our leisure in fixing the packages that need libtiff4-alt-dev. 2. Tell packagers (via mass bug filing?): * If your package depends on libtiff-dev already, no action required; the release team will automatically schedule binary NMUs of your package. * If your package depends on libtiff4-dev but can work fine with tiff 4.x (most packages), replace your dependency on libtiff4-dev with a new dependency on libtiff-dev. * If your package depended on libtiff5-dev, change it to depend on libtiff-dev, or to help future backporters, on libtiff-dev ( 4.0.3-1~). * If your package previously depended on libtiff5-alt-dev, change it to depend on libtiff-dev ( 4.0.3-1~) and remove any special code in your packaging that you had to add to get libtiff5-alt-dev. (If you were finding libtiff5 with pkg-config, no action will be required.) * If your package MUST continue to use tiff 3.x, then replace your build dependency on libtiff4-dev or libtiff-dev with one on libtiff4-alt-dev (which can coexist with libtiff-dev) and change your build to look in /usr/include/libtiff4-alt for headers and libraries in /usr/lib/arch/libtiff4-alt. (There is no pkg-config support in tiff 3.x, unfortunately, so this will have to be manual.) 3. Continue to monitor. Work toward fixing any issues that prevent packages from dropping libtiff4-alt-dev. 4. Before jessie, when all issues are resolved, remove tiff3 source package. As I said, this is disruptive in the short term (basically between the uploads of the new tiff packages and when people fix their build dependencies), but I think it can converge quickly because none of the steps required for developers (or NMU-ers) to follow are hard. Basically no one has to change any source code or fix any bugs at this point. The only thing they have to do is make sure -I and -L are correct in their packages' builds, and this can likely be done pretty easily for most packages. I'm happy to discuss less disruptive ways to do this, but I worry about having this drag on for ages, and I would also can't think of any less disruptive way to do it that doesn't require most packages to be changed twice instead of just once. But someone on the release team with more experience in planning and managing transitions like this may come up with something better that I have overlooked. I'd obviously like to get on this as soon as possible, but I understand that there are many competing priorities and will certainly work with the release team to get this done at the appropriate time and in the appropriate way. -- Jay Berkenbilt q
Re: Why does libgeotiff-dev depend on libtiff5-dev ?
Francesco P. Lovergine fran...@debian.org wrote: On Sat, Jun 15, 2013 at 10:00:26PM +0100, Alastair McKinstry wrote: I'm unfamiliar with the history of libtiff4 / tiff5, but libgd-dev depends on libtiff-dev ; can anyone answer: (1) why does libgeotiff-dev depend on libtiff5-dev? Because it needs a working bigtiff support, which is only provided by libtiff5 (2) why libtiff5-dev not provide the virtual libtiff-dev? Because in wheezy the tiff maintainer would not accept the migration to the current library for all rdeps, which is understandable. The release team would not let me, which is also understandable. The 5 flavor is of primary interest for gis-related programs. Something that definitevely needs to be managed for jessie, because sometimes one could need to link gis-related and other libraries. To support that decision let me remember all of you that tiff5 is compatible at source level with tiff4. Please instead build-depend on libtiff5-alt-dev and use pkg-config to find libtiff. Then you will be all set for the transition when it occurs. For additional details, please see README.Debian in the tiff package and http://lists.debian.org/debian-release/2013/05/msg00127.html. The release team has not yet found the time to reply to my message of May 6 on when they will be ready to think about the tiff transition or whether my plans for the transition are okay. (It is not my intention to be critical of the release team. They do a great job and are volunteers with limited time just like the rest of us.) In the mean time, we will continue to have issues like this popping up as people stumble over the current confusion. If I had known over a year ago when I put the first version of libtiff5-dev into debian that it was going to be this long before the transition could happen, I would have not made a libtiff5-dev and instead only made a libtiff5-alt-dev, but it's too late for that now, I'm afraid. I suppose I could make libtiff5-dev an alias for libtiff5-alt-dev, but that would break any packages that aren't using pkg-config to find -ltiff. Please note that if you build depend on libtiff5-alt-dev, you will get a lintian error about use of a runpath. This is harmless as the runpath points to a location where there will never be a copy of the library. I am going to try to resolve this. Maybe I will ask the release team if I should make libtiff5-dev an alias to libtiff5-alt-dev, assuming they do not reply to that suggestion from this message. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130617101759.0237414693.qww314...@jberkenbilt-linux.appiancorp.com
Re: tiff 4.x (libtiff5) transition
It's been a few weeks since my original post about the libtiff transition, and I haven't heard any responses. While I appreciate that this is not at the top of your long list, I would really appreciate some kind of response if only an indication that you've got it on your list and will prioritize it when you have a chance. Mainly I'm interested to know whether you think my plan is sound and whether you have any idea when we might be able to move forward. In the mean time, I'm going to move forward with uploading new versions, etc., without changing the current packaging scheme since I don't want to make a change that will make things harder than necessary. In my original message, I mentioned the versions that would be part of the transition, so clearly those versions are going to change now. I just don't want anyone to think that I have given up waiting and am going to push forward. Thanks. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130601145540.0542213282.qww314159@soup
Re: tiff 4.x (libtiff5) transition
I'm not sure where the tiff transition falls on your long list, but I thought I'd add a little more information on what issues we may encounter. Jay Berkenbilt q...@debian.org wrote: Wasting no time, I'd like to remind the release team that I'm really hoping Jessie will ship with only one version of the tiff library: . . . The vast majority of packages that use tiff 3.x will transition to tiff 4.x with no changes to their code. Those packages that already build depend on libtiff-dev instead of libtiff4-dev may even get away with just a binary NMU. There are some packages that may require small code changes to take care of places where APIs have changed to support bigtiff. . . . Following up on this, I'm include the following remark from Tom Lane, the person at Red Hat who manages the tiff package and who is active on the upstream mailing list (and who I have talked to many times about coordinating security issues, etc.): libtiff4 is source-compatible but not binary-compatible with libtiff3. The breaks were necessary to support large files. FWIW, my experience with updating the Fedora distro is that 4.0 is only about 99.9% source-compatible either. There were a few packages that required source-code fixes (freeimage, tkimg, xloadimage according to my notes). As an example, the library no longer exposes the contents of struct TIFFFieldInfo. In any case, as Fedora has already made progress in this area, I can mine their patches for any required NMUs. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130514110904.0207178878.qww314...@jberkenbilt-linux.appiancorp.com
tiff 4.x (libtiff5) transition
upgrade to a newer non-binary-compatible version in the future. No such upgrade is planned, and upstream is pretty much just in maintenance mode, but you never know. Rationale for not keeping libtiff4-dev: * tiff 3.x does not support pkg-config. We can't install libtiff4 dev files in a standard path since they will then conflict with libtiff-dev. Therefore, source packages that must have libtiff4-dev will have to make changes to their builds anyway to change include and library paths; simple binary NMU for this case is not possible. Forcing them to change the build dependency to libtiff4-alt-dev makes it easier to track which packages need attention and which packages have already been updated. Basically everyone with libtiff4-dev in their build dependency list will either have to replace it with libtiff-dev or replace it with libtiff4-alt-dev and update include and library paths. Right now, we have a stable state where the default is libtiff4, most packages get libtiff4, those that need libtiff5 can get it with special workarounds, and libtiff4 and libtiff5 can be arbitrarily mixed in the dependency/build dependency chain. This step can get us quickly to a new stable state that reverses the roles of libtiff4 and libtiff5: the default becomes libtiff5, most packages get libtiff5, those that need libtiff4 can get it with special workarounds, and libtiff4 and libtiff5 can be arbitrarily mixed in the dependency/build dependency chain. Though things will admittedly be a little chaotic right after the initial upload, we will quickly reach a point where new versions can transition to jessie, and we can work at our leisure in fixing the packages that need libtiff4-alt-dev. 2. Tell packagers (via mass bug filing?): * If your package depends on libtiff-dev already, no action required; the release team will automatically schedule binary NMUs of your package. * If your package depends on libtiff4-dev but can work fine with tiff 4.x (most packages), replace your dependency on libtiff4-dev with a new dependency on libtiff-dev. * If your package depended on libtiff5-dev, change it to depend on libtiff-dev, or to help future backporters, on libtiff-dev ( 4.0.3-1~). * If your package previously depended on libtiff5-alt-dev, change it to depend on libtiff-dev ( 4.0.3-1~) and remove any special code in your packaging that you had to add to get libtiff5-alt-dev. (If you were finding libtiff5 with pkg-config, no action will be required.) * If your package MUST continue to use tiff 3.x, then replace your build dependency on libtiff4-dev or libtiff-dev with one on libtiff4-alt-dev (which can coexist with libtiff-dev) and change your build to look in /usr/include/libtiff4-alt for headers and libraries in /usr/lib/arch/libtiff4-alt. (There is no pkg-config support in tiff 3.x, unfortunately, so this will have to be manual.) 3. Continue to monitor. Work toward fixing any issues that prevent packages from dropping libtiff4-alt-dev. 4. Before jessie, when all issues are resolved, remove tiff3 source package. As I said, this is disruptive in the short term (basically between the uploads of the new tiff packages and when people fix their build dependencies), but I think it can converge quickly because none of the steps required for developers (or NMU-ers) to follow are hard. Basically no one has to change any source code or fix any bugs at this point. The only thing they have to do is make sure -I and -L are correct in their packages' builds, and this can likely be done pretty easily for most packages. I'm happy to discuss less disruptive ways to do this, but I worry about having this drag on for ages, and I would also can't think of any less disruptive way to do it that doesn't require most packages to be changed twice instead of just once. But someone on the release team with more experience in planning and managing transitions like this may come up with something better that I have overlooked. I'd obviously like to get on this as soon as possible, but I understand that there are many competing priorities and will certainly work with the release team to get this done at the appropriate time and in the appropriate way. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130506102958.0230117954.qww314...@jberkenbilt-linux.appiancorp.com
Bug#703631: unblock: icu/4.8.1.1-12
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package icu
This upload addresses CVE-2013-0900 and closes RC-bug 702346. The
change came from upstream and was backported to ICU 4.8 by people at Red
Hat for Fedora 17. I took their patch, removed the extraneous inclusion
of one of the .orig files from it, and applied it with updated DEP-3
headers. The resulting package passes its own test suite.
The attached debdiff is relative to 4.8.1.1-11 even though 4.8.1.1-10 is
the version in wheezy. This is because 4.8.1.1-11 has already been
unblocked and would have transitioned tomorrow, so I wanted to give you
a diff against the most recently approved package.
unblock icu/4.8.1.1-12
-- System Information:
Debian Release: 7.0
APT prefers unstable
APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru icu-4.8.1.1/debian/changelog icu-4.8.1.1/debian/changelog
--- icu-4.8.1.1/debian/changelog 2013-03-16 14:58:26.0 -0400
+++ icu-4.8.1.1/debian/changelog 2013-03-21 11:29:08.0 -0400
@@ -1,3 +1,10 @@
+icu (4.8.1.1-12) unstable; urgency=high
+
+ * Add patch to address CVE-2013-0900, a threading race condition.
+(Closes: #702346)
+
+ -- Jay Berkenbilt q...@debian.org Thu, 21 Mar 2013 11:29:08 -0400
+
icu (4.8.1.1-11) unstable; urgency=medium
* Fix crash on rendering incremental Malayalam text input. Thanks Colin
diff -Nru icu-4.8.1.1/debian/patches/CVE-2013-0900.patch icu-4.8.1.1/debian/patches/CVE-2013-0900.patch
--- icu-4.8.1.1/debian/patches/CVE-2013-0900.patch 1969-12-31 19:00:00.0 -0500
+++ icu-4.8.1.1/debian/patches/CVE-2013-0900.patch 2013-03-21 11:26:50.0 -0400
@@ -0,0 +1,296 @@
+Description: CVE-2013-0900: Race condition in ICU.
+ Credit to Google Chrome Security Team (Inferno)
+ Patch taken from backport done by Fedora 17
+Origin: upstream, http://www.icu-project.org/trac/changeset/32865, http://www.icu-project.org/trac/changeset/32908
+Bug-Debian: http://bugs.debian.org/702346
+Bug-RedHat: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2013-0900
+
+Index: icu-4.8.1.1/source/common/locid.cpp
+===
+--- icu-4.8.1.1.orig/source/common/locid.cpp 2013-03-21 11:21:45.053153118 -0400
icu-4.8.1.1/source/common/locid.cpp 2013-03-21 11:21:45.029153121 -0400
+@@ -1,6 +1,6 @@
+ /*
+ **
+- * Copyright (C) 1997-2010, International Business Machines
++ * Copyright (C) 1997-2012, International Business Machines
+ * Corporation and others. All Rights Reserved.
+ **
+ *
+@@ -32,6 +32,7 @@
+
+ #include unicode/locid.h
+ #include unicode/uloc.h
++#include mutex.h
+ #include umutex.h
+ #include uassert.h
+ #include cmemory.h
+@@ -41,6 +42,21 @@
+
+ #define LENGTHOF(array) (int32_t)(sizeof(array)/sizeof((array)[0]))
+
++U_CDECL_BEGIN
++static UBool U_CALLCONV locale_cleanup(void);
++U_CDECL_END
++
++U_NAMESPACE_BEGIN
++
++static U_NAMESPACE_QUALIFIER Locale *gLocaleCache = NULL;
++
++// gDefaultLocaleMutex protects all access to gDefaultLocalesHashT and gDefaultLocale.
++static UMTX gDefaultLocaleMutex = 0;
++static UHashtable *gDefaultLocalesHashT = NULL;
++static U_NAMESPACE_QUALIFIER Locale *gDefaultLocale = NULL;
++
++U_NAMESPACE_END
++
+ typedef enum ELocalePos {
+ eENGLISH,
+ eFRENCH,
+@@ -75,10 +91,6 @@
+ UBool valuesToo,
+ UErrorCode *status);
+
+-static U_NAMESPACE_QUALIFIER Locale *gLocaleCache = NULL;
+-static U_NAMESPACE_QUALIFIER Locale *gDefaultLocale = NULL;
+-static UHashtable *gDefaultLocalesHashT = NULL;
+-
+ U_CDECL_BEGIN
+ //
+ // Deleter function for Locales owned by the default Locale hash table/
+@@ -100,24 +112,19 @@
+ if (gDefaultLocalesHashT) {
+ uhash_close(gDefaultLocalesHashT); // Automatically deletes all elements, using deleter func.
+ gDefaultLocalesHashT = NULL;
++gDefaultLocale = NULL;
+ }
+-else if (gDefaultLocale) {
+-// The cache wasn't created, and only one default locale was created.
+-delete gDefaultLocale;
+-}
+-gDefaultLocale = NULL;
+
+ return TRUE;
+ }
+ U_CDECL_END
+
+ U_NAMESPACE_BEGIN
+-//
+-// locale_set_default_internal.
+-//
+-void locale_set_default_internal(const char *id)
+-{
+-UErrorCode status = U_ZERO_ERROR;
++
++Locale *locale_set_default_internal(const char *id, UErrorCode status) {
++// Synchronize this entire function.
++Mutex lock(gDefaultLocaleMutex);
++
+ UBool canonicalize = FALSE;
+
+ // If given a NULL string for the locale id
Bug#703199: unblock: icu/4.8.1.1-11
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package icu
This patch fixes ICU bug 702982, severity important. The bug fix is a
one-line (actually one character) change to a table in ICU that fixes a
potential crash rendering incremental Malayalam text input. This patch
has been applied upstream, and upstream has encouraged distributions to
take it. The Ubuntu version of ICU already includes this patch. Since
this is a bug of priority important (which I set it to because a crash
caused by a particular pattern of characters is a potential DOS attack)
and the package can go into testing through unstable, I hope you will
grant the unblock request. Thanks for considering.
unblock icu/4.8.1.1-11
-- System Information:
Debian Release: 7.0
APT prefers unstable
APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru icu-4.8.1.1/debian/changelog icu-4.8.1.1/debian/changelog
--- icu-4.8.1.1/debian/changelog 2012-11-17 14:37:40.0 -0500
+++ icu-4.8.1.1/debian/changelog 2013-03-16 14:58:26.0 -0400
@@ -1,3 +1,10 @@
+icu (4.8.1.1-11) unstable; urgency=medium
+
+ * Fix crash on rendering incremental Malayalam text input. Thanks Colin
+Watson. (Closes: #702982)
+
+ -- Jay Berkenbilt q...@debian.org Sat, 16 Mar 2013 14:58:15 -0400
+
icu (4.8.1.1-10) unstable; urgency=low
* Include pkg-config files in dev package. Thanks Tommi Vainikainen.
diff -Nru icu-4.8.1.1/debian/patches/mlym-crash.patch icu-4.8.1.1/debian/patches/mlym-crash.patch
--- icu-4.8.1.1/debian/patches/mlym-crash.patch 1969-12-31 19:00:00.0 -0500
+++ icu-4.8.1.1/debian/patches/mlym-crash.patch 2013-03-16 14:56:23.0 -0400
@@ -0,0 +1,19 @@
+Description: Fix crash on rendering incremental Malayalam text input
+Author: Caolán McNamara caol...@redhat.com
+Origin: other, https://ssl.icu-project.org/trac/ticket/9948
+Forwarded: https://ssl.icu-project.org/trac/ticket/9948
+Last-Update: 2013-03-13
+
+Index: b/source/layout/IndicClassTables.cpp
+===
+--- a/source/layout/IndicClassTables.cpp
b/source/layout/IndicClassTables.cpp
+@@ -273,7 +273,7 @@
+
+ static const IndicClassTable kndaClassTable = {0x0C80, 0x0CEF, 4, KNDA_SCRIPT_FLAGS, kndaCharClasses, kndaSplitTable};
+
+-static const IndicClassTable mlymClassTable = {0x0D00, 0x0D6F, 3, MLYM_SCRIPT_FLAGS, mlymCharClasses, mlymSplitTable};
++static const IndicClassTable mlymClassTable = {0x0D00, 0x0D6F, 4, MLYM_SCRIPT_FLAGS, mlymCharClasses, mlymSplitTable};
+
+ static const IndicClassTable sinhClassTable = {0x0D80, 0x0DF4, 4, SINH_SCRIPT_FLAGS, sinhCharClasses, sinhSplitTable};
+
diff -Nru icu-4.8.1.1/debian/patches/series icu-4.8.1.1/debian/patches/series
--- icu-4.8.1.1/debian/patches/series 2012-05-24 13:52:17.0 -0400
+++ icu-4.8.1.1/debian/patches/series 2013-03-16 14:55:46.0 -0400
@@ -8,3 +8,4 @@
pathmax.patch
CVE-2011-4599.patch
indic-ccmp.patch
+mlym-crash.patch
Bug#699044: unblock: tiff/4.0.2-6, tiff3/3.9.6-11
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock packages tiff and tiff3 I hope it's okay that I'm including two unblock requests together in one bug report. The problem applies to both the tiff3 and tiff packages, and it's exactly the same problem exactly the same fix. These versions close RC bugs 699041 (tiff3) and 687645 . They fix a small but important problem: back in 2008, I changed these packages to stop creating symlinks in /usr/share/doc, but the preinst wasn't properly removing old symlinks. This could affect people who were upgrading from etch or people whose systems have been continuously updated since that time who may still have symlinks for those packages. Debdiffs attached. tiff3_3.9.6-10-to-11.debdiff -- diff -Nru tiff3-3.9.6/debian/all-preinst tiff3-3.9.6/debian/all-preinst --- tiff3-3.9.6/debian/all-preinst 2009-06-28 13:10:19.0 -0400 +++ tiff3-3.9.6/debian/all-preinst 2013-01-26 12:22:55.0 -0500 @@ -1,6 +1,5 @@ #!/bin/sh set -e -if [ x$1 = xupgrade -a \ - -d /usr/share/doc/PKG -a ! -h /usr/share/doc/PKG ]; then - rm -rf /usr/share/doc/PKG +if [ -h /usr/share/doc/PKG ]; then + rm -f /usr/share/doc/PKG fi diff -Nru tiff3-3.9.6/debian/changelog tiff3-3.9.6/debian/changelog --- tiff3-3.9.6/debian/changelog2012-12-15 06:13:58.0 -0500 +++ tiff3-3.9.6/debian/changelog2013-01-26 12:32:35.0 -0500 @@ -1,3 +1,11 @@ +tiff3 (3.9.6-11) unstable; urgency=high + + * Fix /usr/share/doc symlink to directory transition. When upgrading +from very old versions (pre 3.8.2-8), /usr/share/doc may contain +symbolic links that should be removed. (Closes: #699041) + + -- Jay Berkenbilt q...@debian.org Sat, 26 Jan 2013 12:27:56 -0500 + tiff3 (3.9.6-10) unstable; urgency=high * Add fix for CVE-2012-5581, reimplementing DOTRANGE handling to make it -- tiff_4.0.2-5-to-6.debdiff -- diff -Nru tiff-4.0.2/debian/all-preinst tiff-4.0.2/debian/all-preinst --- tiff-4.0.2/debian/all-preinst 2009-08-21 13:26:05.0 -0400 +++ tiff-4.0.2/debian/all-preinst 2013-01-26 12:29:19.0 -0500 @@ -1,6 +1,5 @@ #!/bin/sh set -e -if [ x$1 = xupgrade -a \ - -d /usr/share/doc/PKG -a ! -h /usr/share/doc/PKG ]; then - rm -rf /usr/share/doc/PKG +if [ -h /usr/share/doc/PKG ]; then + rm -f /usr/share/doc/PKG fi diff -Nru tiff-4.0.2/debian/changelog tiff-4.0.2/debian/changelog --- tiff-4.0.2/debian/changelog 2012-11-17 12:40:40.0 -0500 +++ tiff-4.0.2/debian/changelog 2013-01-26 12:28:48.0 -0500 @@ -1,3 +1,11 @@ +tiff (4.0.2-6) unstable; urgency=high + + * Fix /usr/share/doc symlink to directory transition. When upgrading +from very old versions (pre 3.8.2-8), /usr/share/doc may contain +symbolic links that should be removed. (Closes: #687645) + + -- Jay Berkenbilt q...@debian.org Sat, 26 Jan 2013 12:28:19 -0500 + tiff (4.0.2-5) unstable; urgency=high * Add fix for CVE-2012-4564, a heap-buffer overflow. Thanks Adrian La -- unblock tiff/4.0.2-6 unblock tiff/3.9.6-11 -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130126124542.0457685504.qww314159@soup
Bug#695988: unblock: tiff3/3.9.6-10
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package tiff3
This version of tiff3 addresses CVE-2012-5581 and closes RC bug 694693.
The only change is the inclusion of the patch, which was prepared by
the Ubuntu security team and was backported from upstream CVS by the Red
Hat Security team.
Debdiff attached.
unblock tiff3/3.9.6-10
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru tiff3-3.9.6/debian/changelog tiff3-3.9.6/debian/changelog
--- tiff3-3.9.6/debian/changelog 2012-10-05 17:32:44.0 -0400
+++ tiff3-3.9.6/debian/changelog 2012-12-15 06:13:58.0 -0500
@@ -1,3 +1,11 @@
+tiff3 (3.9.6-10) unstable; urgency=high
+
+ * Add fix for CVE-2012-5581, reimplementing DOTRANGE handling to make it
+safer. Thanks to Red Hat security team for backporting the fix.
+(Closes: #694693)
+
+ -- Jay Berkenbilt q...@debian.org Sat, 15 Dec 2012 06:04:00 -0500
+
tiff3 (3.9.6-9) unstable; urgency=high
* Previous change was uploaded with the wrong CVE number. I updated the
diff -Nru tiff3-3.9.6/debian/patches/CVE-2012-5581.patch tiff3-3.9.6/debian/patches/CVE-2012-5581.patch
--- tiff3-3.9.6/debian/patches/CVE-2012-5581.patch 1969-12-31 19:00:00.0 -0500
+++ tiff3-3.9.6/debian/patches/CVE-2012-5581.patch 2012-12-15 05:59:34.0 -0500
@@ -0,0 +1,324 @@
+Author: Frank Warmerdam warmer...@google.com
+Description: * libtiff/tif_dir.c, tif_print.c : Remove FIELD_CUSTOM handling
+ for PAGENUMBER, HALFTONEHINTS, and YCBCRSUBSAMPLING. Implement DOTRANGE
+ differently. This is to avoid using special TIFFGetField/TIFFSetField rules
+ for these fields in non-image directories (like EXIF).
+
+Back-ported patch from upstream CVS by Huzaifa S. Sidhpurwala of Red Hat
+Security Response Team.
+
+https://bugzilla.redhat.com/show_bug.cgi?id=867235
+https://bugzilla.redhat.com/attachment.cgi?id=640578
+
+Index: tiff3-3.9.6/libtiff/tif_dir.c
+===
+--- tiff3-3.9.6.orig/libtiff/tif_dir.c 2010-07-08 12:17:59.0 -0400
tiff3-3.9.6/libtiff/tif_dir.c 2012-12-15 05:59:21.869364661 -0500
+@@ -493,94 +493,90 @@
+ status = 0;
+ goto end;
+ }
++ if (fip-field_tag == TIFFTAG_DOTRANGE
++strcmp(fip-field_name,DotRange) == 0) {
++ /* TODO: This is an evil exception and should not have been
++ handled this way ... likely best if we move it into
++ the directory structure with an explicit field in
++ libtiff 4.1 and assign it a FIELD_ value */
++ uint16 v[2];
++ v[0] = (uint16)va_arg(ap, int);
++ v[1] = (uint16)va_arg(ap, int);
++ _TIFFmemcpy(tv-value, v, 4);
++ }
++
++ else if (fip-field_passcount
++ || fip-field_writecount == TIFF_VARIABLE
++ || fip-field_writecount == TIFF_VARIABLE2
++ || fip-field_writecount == TIFF_SPP
++ || tv-count 1) {
+
+- if ((fip-field_passcount
+- || fip-field_writecount == TIFF_VARIABLE
+- || fip-field_writecount == TIFF_VARIABLE2
+- || fip-field_writecount == TIFF_SPP
+- || tv-count 1)
+- fip-field_tag != TIFFTAG_PAGENUMBER
+- fip-field_tag != TIFFTAG_HALFTONEHINTS
+- fip-field_tag != TIFFTAG_YCBCRSUBSAMPLING
+- fip-field_tag != TIFFTAG_DOTRANGE) {
+ _TIFFmemcpy(tv-value, va_arg(ap, void *),
+ tv-count * tv_size);
+ } else {
+- /*
+- * XXX: The following loop required to handle
+- * TIFFTAG_PAGENUMBER, TIFFTAG_HALFTONEHINTS,
+- * TIFFTAG_YCBCRSUBSAMPLING and TIFFTAG_DOTRANGE tags.
+- * These tags are actually arrays and should be passed as
+- * array pointers to TIFFSetField() function, but actually
+- * passed as a list of separate values. This behaviour
+- * must be changed in the future!
+- */
+- int i;
++assert( tv-count == 1 );
+ char *val = (char *)tv-value;
+-
+- for (i = 0; i tv-count; i++, val += tv_size) {
+- switch (fip-field_type) {
+-case TIFF_BYTE:
+-case TIFF_UNDEFINED:
+-{
+- uint8 v = (uint8)va_arg(ap, int);
+- _TIFFmemcpy(val, v, tv_size);
+-}
+-break;
+-case TIFF_SBYTE:
+-{
+- int8 v = (int8)va_arg(ap, int);
+- _TIFFmemcpy(val, v, tv_size
Bug#693541: unblock: tiff/4.0.2-5
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal
Please unblock package tiff 4.0.2-5, which includes a patch to address
CVE-2012-4564 and which closes RC bug #692345.
diff -Nru tiff-4.0.2/debian/changelog tiff-4.0.2/debian/changelog
--- tiff-4.0.2/debian/changelog 2012-10-05 17:39:16.0 -0400
+++ tiff-4.0.2/debian/changelog 2012-11-17 12:40:40.0 -0500
@@ -1,3 +1,10 @@
+tiff (4.0.2-5) unstable; urgency=high
+
+ * Add fix for CVE-2012-4564, a heap-buffer overflow. Thanks Adrian La
+Duca for doing all the work to prepare this upload. (Closes: #692345)
+
+ -- Jay Berkenbilt q...@debian.org Sat, 17 Nov 2012 12:40:25 -0500
+
tiff (4.0.2-4) unstable; urgency=high
* Previous change was uploaded with the wrong CVE number. I updated the
diff -Nru tiff-4.0.2/debian/patches/CVE-2012-4564.patch tiff-4.0.2/debian/patches/CVE-2012-4564.patch
--- tiff-4.0.2/debian/patches/CVE-2012-4564.patch 1969-12-31 19:00:00.0 -0500
+++ tiff-4.0.2/debian/patches/CVE-2012-4564.patch 2012-11-17 12:39:17.0 -0500
@@ -0,0 +1,31 @@
+Index: tiff-4.0.2/tools/ppm2tiff.c
+===
+--- tiff-4.0.2.orig/tools/ppm2tiff.c 2010-04-10 15:22:34.0 -0400
tiff-4.0.2/tools/ppm2tiff.c 2012-11-16 13:00:44.654825029 -0500
+@@ -89,6 +89,7 @@
+ int c;
+ extern int optind;
+ extern char* optarg;
++ tmsize_t scanline_size;
+
+ if (argc 2) {
+ fprintf(stderr, %s: Too few arguments\n, argv[0]);
+@@ -237,8 +238,16 @@
+ }
+ if (TIFFScanlineSize(out) linebytes)
+ buf = (unsigned char *)_TIFFmalloc(linebytes);
+- else
+- buf = (unsigned char *)_TIFFmalloc(TIFFScanlineSize(out));
++ else {
++ scanline_size = TIFFScanlineSize(out);
++ if (scanline_size != 0)
++ buf = (unsigned char *)_TIFFmalloc(TIFFScanlineSize(out));
++ else {
++ fprintf(stderr, %s: scanline size overflow\n,infile);
++ (void) TIFFClose(out);
++ exit(-2);
++ }
++ }
+ if (resolution 0) {
+ TIFFSetField(out, TIFFTAG_XRESOLUTION, resolution);
+ TIFFSetField(out, TIFFTAG_YRESOLUTION, resolution);
diff -Nru tiff-4.0.2/debian/patches/series tiff-4.0.2/debian/patches/series
--- tiff-4.0.2/debian/patches/series 2012-10-05 17:07:54.0 -0400
+++ tiff-4.0.2/debian/patches/series 2012-11-17 12:39:17.0 -0500
@@ -1,3 +1,4 @@
opengl.patch
CVE-2012-3401.patch
CVE-2012-4447.patch
+CVE-2012-4564.patch
Bug#693551: unblock: icu/4.8.1.1-10
Package: release.debian.org User: release.debian@packages.debian.org Usertags: unblock Severity: normal Please unblock package icu 4.8.1.1-10. This fixes severity important bug #687339. The issue is trivial: the libicu-dev package failed to install pkg-config files. I upgraded the priority of the bug to important since, without pkg-config files, there is a potential for a downstream package to work on other distributions that properly include these files but not to work on debian, which accidentally omits them. Since this is a very small, low-risk change on a priority optional package that fixes an important bug and that can go into wheezy through unstable, I believe it should be eligible for an unblock request. The debdiff is attached. Thanks for considering it. -- Jay Berkenbilt q...@debian.org diff -Nru icu-4.8.1.1/debian/changelog icu-4.8.1.1/debian/changelog --- icu-4.8.1.1/debian/changelog 2012-08-11 13:27:24.0 -0400 +++ icu-4.8.1.1/debian/changelog 2012-11-17 14:37:40.0 -0500 @@ -1,3 +1,10 @@ +icu (4.8.1.1-10) unstable; urgency=low + + * Include pkg-config files in dev package. Thanks Tommi Vainikainen. +(Closes: #687339) + + -- Jay Berkenbilt q...@debian.org Sat, 17 Nov 2012 14:37:40 -0500 + icu (4.8.1.1-9) unstable; urgency=low * debian/rules: Use xz compression for binary packages. diff -Nru icu-4.8.1.1/debian/libicu-dev.install icu-4.8.1.1/debian/libicu-dev.install --- icu-4.8.1.1/debian/libicu-dev.install 2012-04-22 08:30:07.0 -0400 +++ icu-4.8.1.1/debian/libicu-dev.install 2012-11-17 14:38:18.0 -0500 @@ -1,6 +1,7 @@ usr/lib/*/lib*.so usr/lib/*/lib*.a usr/lib/*/icu +usr/lib/*/pkgconfig/*.pc usr/include usr/bin usr/sbin
Bug#689752: unblock tiff3-3.9.6-9 and tiff-4.0.2-4
Package: release.debian.org Usertags: unblock Please unblock tiff3-3.9.6-9 and tiff-4.0.2-4, which fix CVE-2012-4447 and address RC security bug #688944. I had uploaded tiff3-3.9.6-8 and tiff-4.0.2-3, which fixed CVE-2012-4447 but claimed to fix non-existent CVE-2012-4777. Ugh. My dcut was a few seconds too late. So those versions only lived a few minutes. The bug was only reported against the tiff package but affects both tiff and tiff3. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121005174346.0433238412.qww314159@soup
Bug#685847: freeze exception for psutils to fix RC bug
Package: release.debian.org Severity: normal I have uploaded psutils_1.17.dfsg-1, which removes some files with unclear or inappropriate copyright. This closes RC bug #682908. No changes were made that were not directly related to this fix. I updated README.source and copyright to describe the repackaging of the upstream source tarball, which was basically just to remove the offending files. Then I added a patch to fix the Makefile to remove references to those files, refreshed the other patches with quilt refresh -p1, and updated the watch file to add dversionmangle. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120825064329.0434567009.qww314159@soup
request unblock for icu 4.8.1.1-9 (bug #683901)
At the request of Ansgar Burchardt, I re-uploaded ICU with xz compression to save space on the first CD. The upload includes no other changes. I'm requesting a freeze exception for this version. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120814084948.1065356132.qww314159@jberkenbilt-linux
Re: request unblock for icu 4.8.1.1-9 (bug #683901)
Adam D. Barratt a...@adam-barratt.org.uk wrote: On Tue, 2012-08-14 at 08:49 -0400, Jay Berkenbilt wrote: At the request of Ansgar Burchardt, I re-uploaded ICU with xz compression to save space on the first CD. The upload includes no other changes. I'm requesting a freeze exception for this version. Unblocked. Thanks. Please could you file any further requests in the BTS? That makes it much less likely that it'll get lost in the flood. Yes, sorry. I had forgotten about that. Most likely I would not have forgotten if the testing migration section of the PTS page mentioned filing a bug report with details (like which pseudopackage to report against, which I would have to go digging for) rather than what it says now: Not touching package due to block request by freeze (contact debian-release if update is needed) -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120814134208.1065349316.qww314159@jberkenbilt-linux
Re: freeze exception qpdf versioned symbols?
Jonathan Nieder jrnie...@gmail.com wrote:
Hi,
Jay Berkenbilt wrote:
Okay, I've attached two files here. The first is a copy of
version-symbols.patch with the real changes, so this excludes the
changes to the regenerated configure file. The second file is a source
debdiff.
I am not on the release team, so please take anything I say with a
grain of salt.
The release team decided that they weren't going to accept this, so this
discussion is now academic. However, you made some interesting points
that I thought were worth responding to.
[...]
--- qpdf-2.3.1/debian/changelog 2012-05-19 09:21:52.0 -0400
+++ qpdf-2.3.1/debian/changelog 2012-07-18 10:20:10.0 -0400
@@ -1,3 +1,9 @@
+qpdf (2.3.1-5) unstable; urgency=low
+
+ * Enable versioned symbols.
Are the symbol versions used shared with upstream, or is this a
Debian-specific thing?
*checks*
Looks like these are Debian-private but the patch is based on 92c94e7d
(Add symbol versioning, 2012-06-20). Ok.
I am upstream for this. I enabled versioned symbols for future releases
of qpdf (I will soon be releasing 3.0.0). This was a debian-specific
backport to 2.3.1 for the old ABI. qpdf does appear in other
distributions that I am not involved in, and they wouldn't have
versioned symbols. So actually this is a pretty decent argument for not
doing it anyway.
++# Check if LD supports linker scripts, and define conditional
++# HAVE_LD_VERSION_SCRIPT if so. This functionality is currently
++# constrained to compilers using GNU ld on ELF systems or systems
++# which provide an adequate emulation thereof.
++AC_ARG_ENABLE([ld-version-script],
++ AS_HELP_STRING([--enable-ld-version-script],
++[enable linker version script (default is disabled)]),
Is the default really --disable?
No, the default is really enable. I copied this code from something
that had a default of disable, and while I changed the default, I didn't
change the help message. Thanks for catching it. I fixed it upstream
now.
+@@ -0,0 +1,4 @@
++LIBQPDF_3 {
++ global:
++*;
++};
It would be more comforting to have a list of symbols intended for
export here, so unintentional ABI changes could be caught more easily.
Do I understand that that would be hard to make because this is a C++
library?
It would be hard but not impossible. qpdf also works on Windows, and
for that, I already have every public API marked, but I don't think the
value for the amount of effort is good enough.
Thanks and hope that helps,
Yes, your comments were helpful and at least resulted in fixing the
configure help message. Thanks!
--
Jay Berkenbilt q...@debian.org
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120722213822.0386649101.qww314159@soup
Re: freeze exception qpdf versioned symbols?
Jay Berkenbilt q...@debian.org wrote: Okay, I've attached two files here. The first is a copy of version-symbols.patch with the real changes, so this excludes the changes to the regenerated configure file. The second file is a source debdiff. . . . If it looks good, I'll proceed with the upload. I haven't heard anything about this. Should I proceed with the upload? -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120721213626.1487195862.qww314159@soup
freeze exception for tiff3 and tiff for security bugs
I've upload tiff3-3.9.6-7 and tiff-4.0.2-2 with fixes to CVE-2012-3401. The patch is as attached to the bug reports, 682195 and 682115. Please unblock so these RC security bug fixes can go in. No other changes were made in these uploads. The bug doesn't actually apply to tiff3, but the patch should work for the version of tiff in stable. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120721214405.1487172600.qww314159@soup
Re: freeze exception qpdf versioned symbols?
Cyril Brulebois k...@debian.org wrote:
I must confess I'm not really fluent with symbol versioning, but I think
a patch enabling it for the current package with no further changes
could be worth an unblock. Feel free to propose a source debdiff (or to
upload it), and we'll review that.
Okay, I've attached two files here. The first is a copy of
version-symbols.patch with the real changes, so this excludes the
changes to the regenerated configure file. The second file is a source
debdiff. The only changes are a shlibs bump and the addition of
versioned-symbols.patch. The patch includes changes from regeneration
of configure, which you can ignore since the relevant changes are to
configure.ac and most of the configure changes are from the change from
autoconf 2.68 to 2.69. The shlibs bump is needed to make sure packages
that built with the versioned library pull in the versioned library.
If it looks good, I'll proceed with the upload.
--
Jay Berkenbilt q...@debian.org
Index: qpdf-2.3.1/autoconf.mk.in
===
--- qpdf-2.3.1.orig/autoconf.mk.in 2011-12-28 17:19:40.0 -0500
+++ qpdf-2.3.1/autoconf.mk.in 2012-07-18 10:08:07.677346374 -0400
@@ -31,3 +31,4 @@
VALIDATE_DOC=@VALIDATE_DOC@
SKIP_TEST_COMPARE_IMAGES=@SKIP_TEST_COMPARE_IMAGES@
BUILDRULES=@BUILDRULES@
+HAVE_LD_VERSION_SCRIPT=@HAVE_LD_VERSION_SCRIPT@
Index: qpdf-2.3.1/configure.ac
===
--- qpdf-2.3.1.orig/configure.ac 2011-12-28 17:19:40.0 -0500
+++ qpdf-2.3.1/configure.ac 2012-07-18 10:08:07.677346374 -0400
@@ -42,6 +42,40 @@
AC_TYPE_UINT32_T
AC_CHECK_FUNCS(random)
+# Check if LD supports linker scripts, and define conditional
+# HAVE_LD_VERSION_SCRIPT if so. This functionality is currently
+# constrained to compilers using GNU ld on ELF systems or systems
+# which provide an adequate emulation thereof.
+AC_ARG_ENABLE([ld-version-script],
+ AS_HELP_STRING([--enable-ld-version-script],
+[enable linker version script (default is disabled)]),
+[have_ld_version_script=$enableval], [have_ld_version_script=yes])
+if test $have_ld_version_script != no; then
+ AC_MSG_CHECKING([if LD -Wl,--version-script works])
+ save_LDFLAGS=$LDFLAGS
+ LDFLAGS=$LDFLAGS -Wl,--version-script=conftest.map
+ cat conftest.map EOF
+VERS_1 {
+global: sym;
+};
+
+VERS_2 {
+global: sym;
+} VERS_1;
+EOF
+ AC_LINK_IFELSE([AC_LANG_PROGRAM([], [])],
+ [have_ld_version_script=yes], [have_ld_version_script=no])
+ rm -f conftest.map
+ LDFLAGS=$save_LDFLAGS
+ AC_MSG_RESULT($have_ld_version_script)
+fi
+if test $have_ld_version_script = yes; then
+ HAVE_LD_VERSION_SCRIPT=1
+else
+ HAVE_LD_VERSION_SCRIPT=0
+fi
+AC_SUBST(HAVE_LD_VERSION_SCRIPT)
+
AC_MSG_CHECKING(for gnu make = 3.81)
make_okay=0
if make --version /dev/null 21; then
Index: qpdf-2.3.1/libqpdf.map
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ qpdf-2.3.1/libqpdf.map 2012-07-18 10:08:07.677346374 -0400
@@ -0,0 +1,4 @@
+LIBQPDF_3 {
+ global:
+*;
+};
Index: qpdf-2.3.1/make/libtool.mk
===
--- qpdf-2.3.1.orig/make/libtool.mk 2011-12-28 17:19:40.0 -0500
+++ qpdf-2.3.1/make/libtool.mk 2012-07-18 10:08:07.677346374 -0400
@@ -15,6 +15,12 @@
# --- Private definitions ---
+ifeq ($(HAVE_LD_VERSION_SCRIPT), 1)
+LD_VERSION_FLAGS=-Wl,--version-script=libqpdf.map
+else
+LD_VERSION_FLAGS=
+endif
+
# Usage: $(call libdepflags,$(basename obj))
# Usage: $(call fixdeps,$(basename obj))
ifeq ($(GENDEPS),1)
@@ -80,7 +86,8 @@
# Usage: $(call makelib,objs,library,ldflags,libs,current,revision,age)
define makelib
$(LIBTOOL) --mode=link \
- $(CXX) $(CXXFLAGS) -o $(2) $(1) $(3) $(4) \
+ $(CXX) $(CXXFLAGS) $(LD_VERSION_FLAGS) \
+ -o $(2) $(1) $(3) $(4) \
-rpath $(libdir) -version-info $(5):$(6):$(7)
endef
diff -Nru qpdf-2.3.1/debian/changelog qpdf-2.3.1/debian/changelog
--- qpdf-2.3.1/debian/changelog 2012-05-19 09:21:52.0 -0400
+++ qpdf-2.3.1/debian/changelog 2012-07-18 10:20:10.0 -0400
@@ -1,3 +1,9 @@
+qpdf (2.3.1-5) unstable; urgency=low
+
+ * Enable versioned symbols.
+
+ -- Jay Berkenbilt q...@debian.org Wed, 18 Jul 2012 10:20:10 -0400
+
qpdf (2.3.1-4) unstable; urgency=low
* Work around portability issues exposed by upgrading to gcc 4.7. The
diff -Nru qpdf-2.3.1/debian/libqpdf3.shlibs qpdf-2.3.1/debian/libqpdf3.shlibs
--- qpdf-2.3.1/debian/libqpdf3.shlibs 2012-04-22 10:25:08.0 -0400
+++ qpdf-2.3.1/debian/libqpdf3.shlibs 2012-07-18 10:20:43.0 -0400
@@ -1 +1 @@
-libqpdf 3 libqpdf3 (= 2.3.0)
+libqpdf 3 libqpdf3 ( 2.3.1-5~)
diff -Nru qpdf-2.3.1/debian/patches/series qpdf-2.3.1/debian/patches/series
--- qpdf-2.3.1/debian/patches/series 2012-05-19 09:18:54.0 -0400
+++ qpdf-2.3.1/debian/patches/series 2012-07-18 10:08:15.0
freeze exception qpdf versioned symbols?
I have added symbol versioning to qpdf (for which I am the maintainer and also upstream) in a not-yet-released upstream version. Sometime soon, I will be releasing a new version of qpdf with a few ABI-breaking changes in preparation for qpdf becoming a dependency of cups-filters, resulting in work being done in a google summer of code project. While there are currently no packages in debian that depend on qpdf, I thought it might be nice to get the symbol versions into debian before wheezy since the next release will not be binary compatible. I have no plans to make any future ABI-breaking changes as I am committed to ABI stability. In this case, however, it was unavoidable as there were functions that took int and needed off_t. As long as I had to break it anyway, I also made one change to significantly simplify one rarely used operation for the user. If you would grant a freeze exception for a patch to the existing version of qpdf to enable symbol versioning, I would prepare an upload and then request a freeze exception on the specific version. If not, it doesn't really matter...the next upload to unstable for version 3.0.0 and libqpdf8 (now libqpdf3) will have symbol versions enabled regardless, and as I said, there are no packages in the archive at all, let alone library packages, that currently depend on qpdf. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120714110026.0385755749.qww314159@soup
Re: short-term plans for libtiff
format. Here is the README.Debian that I intend to include with the new tiff packages: -- Note that tiff 4.x provides libtiff5 and libtiff5-dev, while tiff 3.x provides libtiff4 and libtiff4-dev. This may seem confusing, but it is just because the shared library versions and the software versions don't happen to be the same, nor is there any expectation for them to be the same. Until the libtiff4 - libtiff5 transition occurs after the release of wheezy, a new temporary package called libtiff5-alt-dev is being provided. This package installs include and library files for libtiff5 (tiff 4.x) in an alternative location with pkg-config files that point to it. You should only use this package if you need to depend on libtiff5 development files while also having libtiff4-dev installed on your system. This package will disappear when libtiff4-dev is removed from the archive. The most common use of libtiff5-alt-dev will be as a build dependency for a debian package that has a direct dependency on libtiff5 (for example, to get bigtiff support) and an indirect dependency on libtiff4-dev. In this case, you can have your package specify libtiff5-alt-dev instead of libtiff5-dev as a build dependency. If your package finds the location of libtiff headers and libraries with pkg-config, then all you will have to do when libtiff5-alt-dev disappears is to change your build dependency to libtiff-dev, which will then point to libtiff5-dev. For an example of a package that does this, look at vips. Note that if you link use this package, your executables or shared libraries will include an rpath that points /usr/lib/arch/libtiff5-alt. This is harmless since no actual shared libraries will live in that directory, but it is a side effect of having libdir set in the libtiff.la file there, which is needed for libtool to link with the correct -ltiff. This situation will cause lintian errors, but the problem will go away after the libtiff transition is complete. -- Jay Berkenbilt q...@debian.org, Thu, 24 May 2012 15:50:07 -0400 -- Again, I believe this is harmless. It creates a very small number of cases where a package will have to be changed and re-uploaded during the transition, but there will obviously be several packages like that for other reasons (things that explicitly depend on libtiff4-dev). I suspect that only a very small number of packages will actually do this. I am open to alternative ways of doing this, but without something like this, packages that want bigtiff support and also depend on things that use libtiff4 will have to resort to including tiff 4.x sources in their package as some things were doing prior to the introduction of libtiff5-dev. I tested this by building vips packages. Vips has a ton of dependencies including many that also depend on libtiff4-dev. The only change to the vips packages (aside from lintian overrides) is changing the build dependency from libtiff4-dev to libtiff5-alt-dev and changing the corresponding dependency of the dev package. ldd shows the resulting package to have linked with both libtiff4 and libtiff5. Bigtiff support works as does the rest of the package. May I proceed? If not, can you give me some explanation of what I need to do? -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120527113123.0386049510.qww314159@soup
short-term plans for libtiff
I'm planning on a new upload of tiff where all existing packages are unchanged and there's a new package called libtiff5-alt-dev. This package installed the tiff 4.x headers and libraries in a path that does not conflict with libtiff4-dev, and it installs the libtiff pkg-config files in the usual location. (libtiff4-dev does not provide pkg-config.) libtiff5-alt-dev conflicts with libtiff5-dev (since they both install pkg-config files) but not with libtiff4-dev. It is possible to have both libtiff5-alt-dev and libtiff4-dev installed at the same time, and this makes it possible to build a package that directly requires libtiff5 and indirectly depends on libtiff4-dev, such as vips. This will work easily for packages that use pkg-config to find tiff headers. A few packages do this and then fall back to standard system paths if pkg-config fails. Those packages work with either libtiff4-dev or libtiff5-dev. For packages that declare build dependencies on libtiff5-alt-dev and use pkg-config to find tiff, all they have to do after the transition is change the build dependency to libtiff-dev. Can you think of any reason that this could possibly cause any harm? I don't think it will since it won't have any impact at all on packages that don't explicitly build depend on libtiff5-alt-dev. I'm going to go ahead and do the upload. If it's a bad idea for some reason that I am failing to see, it can always be rejected from NEW. If this is a bad idea for some reason, I would really like to find a solution so that vips and nip2 (among others) can have bigtiff support before wheezy. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120519104227.1611971078.qww314159@soup
Re: short-term plans for libtiff
Cyril Brulebois k...@debian.org wrote: Hi Jay, Jay Berkenbilt q...@debian.org (19/05/2012): Can you think of any reason that this could possibly cause any harm? I don't think it will since it won't have any impact at all on packages that don't explicitly build depend on libtiff5-alt-dev. I'm going to go ahead and do the upload. If it's a bad idea for some reason that I am failing to see, it can always be rejected from NEW. If this is a bad idea for some reason, I would really like to find a solution so that vips and nip2 (among others) can have bigtiff support before wheezy. I'd appreciate if you could give us a few days to get back to you on this. I think Julien is more or less the only one of us who looked into libtiff stuff, so I think it makes sense to wait for his input. Mraw, KiBi. I will wait as you request. For what it's worth, I have (locally) built vips and nip2 with this change, and they work perfectly. No build dependency conflicts, and the software opens and saves bigtiff files properly. There's also ITK packages (medical) where the maintainer has contacted me about not being able to support bigtiff because of this same issue. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120519110804.1611974333.qww314159@soup
Re: versioned tiff uploaded to experimental
Julien Cristau jcris...@debian.org wrote: On Sun, Jan 29, 2012 at 07:05:25 -0500, Jay Berkenbilt wrote: [snip] Any objections to this plan? I would probably wait until after wheezy to work on removal of tiff3, but I guess we could move libtiff-dev to libtiff5-dev sooner than that if lots of packages work fine with it. But we don't necessarily have to. The plan sounds good to me, fwiw. Sorry for the delay in replying. No problem. Coincidentally, I am in the process of preparing uploads for unstable since upstream released this weekend. I guess the next step will be sometime post-wheezy when we try to push to get rid of tiff3 from the archive. Do I have to do anything to ask for all tiff reverse dependencies to be automatically rebuild (other than mentioning it here)? I expect the uploads within half an hour. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120220095658.0204565560.qww314...@jberkenbilt-linux.appiancorp.com
Re: versioned tiff uploaded to experimental
Julien Cristau jcris...@debian.org wrote: On Mon, Feb 20, 2012 at 09:56:58 -0500, Jay Berkenbilt wrote: Do I have to do anything to ask for all tiff reverse dependencies to be automatically rebuild (other than mentioning it here)? I expect the uploads within half an hour. I'll take care of this once the new version is in testing. I set up http://release.debian.org/transitions/html/libtiff4-symbols.html so we can track what's left. Great, thanks. BTW, in version number comparisons '' confusingly means greater or equal (and is deprecated for that reason), so I suspect the shlibs should really say = 3.9.5-3 or = 3.9.6 to also account for the 3.9.5-2+b2 binary NMU on armhf. Doesn't matter much anyway, 3.9.5-2 is greater than the stable version, just thought I'd mention it. Oops, yeah, I knew that at one time and had forgotten. I made the same mistake in the control file, but lintian caught it. I updated my notes for shlibs files to remind myself for the future. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120220111315.0204591992.qww314...@jberkenbilt-linux.appiancorp.com
Re: versioned tiff uploaded to experimental
Jay Berkenbilt q...@debian.org wrote: [please cc me on responses; I am not subscribed to debian-release] I have uploaded tiff3_3.9.5-3 with libtiff4, libtiff4-dev, and libtiffxx0c2 and tiff_4.0.0-1 with libtiff5, libtiff-dev, libtiffxx5, libtiff-tools, libtiff-doc, and libtiff-opengl to experimental as previously discussed. All libraries have versioned symbols. I did a bunch of tests, and everything works as expected. . . . It dawned on me that if I just call the dev package in tiff_4.0.1-1 libtiff5-dev and don't have it provide libtiff-dev, then I don't have to wait, and I can just upload tiff3_3.9.6-1 and tiff_4.0.1-1 to unstable at the same time. So the initial condition would be that tiff3 includes libtiff4-dev which provides libtiff-dev, and tiff includes libtiff5-dev which doesn't provide anything. Nothing will break during the bin NMUs (or regular uploads) since no one is depending on libtiff5-dev, but the packages the specifically need it can get it right away. Later, after all the bin NMUs are done and nothing in the archive is linked against the non-versioned libtiff4, if we want to push toward removal of tiff3 or just to making tiff 4.x the default tiff, I can change it so that tiff includes libtiff-dev which provides libtiff5-dev for compatibility and make tiff3's libtiff4-dev stop providing libtiff-dev. (Or I could keep libtiff5-dev's name as it is and have it provide libtiff-dev...I'm not really sure which is better. jpeg does it one way, png does it the other way.) Any objections to this plan? I would probably wait until after wheezy to work on removal of tiff3, but I guess we could move libtiff-dev to libtiff5-dev sooner than that if lots of packages work fine with it. But we don't necessarily have to. Another advantage is that you won't have to keep hearing from me about tiff. :-) I appreciate the indulgence as you've helped guide me toward a better solution or at least keep me from making things worse. If we do this, I'll do one more tiff upload to experimental since I guess tiff will be NEW with libtiff5-dev as a real package. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120129070525.0289307139.qww314159@soup
versioned tiff uploaded to experimental
[please cc me on responses; I am not subscribed to debian-release]
I have uploaded tiff3_3.9.5-3 with libtiff4, libtiff4-dev, and
libtiffxx0c2 and tiff_4.0.0-1 with libtiff5, libtiff-dev, libtiffxx5,
libtiff-tools, libtiff-doc, and libtiff-opengl to experimental as
previously discussed. All libraries have versioned symbols. I did a
bunch of tests, and everything works as expected. Specifically:
Programs linked with non-versioned libtiff4 still run properly when
libtiff4 is upgraded to the versioned libtiff4. Programs linked with a
versioned copy of libtiff4 do not work with a non-versioned copy.
It works to link a program with one shared library that uses versioned
libtiff4 and another that uses versioned libtiff5. Here's what I did:
--- f.c ---
#include tiffio.h
#include tiff.h
#include stdio.h
void f()
{
uint32 width;
TIFF* t = TIFFOpen(/tmp/a.tif, r);
if (TIFFGetField(t, TIFFTAG_IMAGEWIDTH, width))
{
printf(%d\n, width);
}
}
--
--- g.c ---
#include tiffio.h
#include tiff.h
#include stdio.h
void g()
{
uint32 height;
TIFF* t = TIFFOpen(/tmp/a.tif, r);
if (TIFFGetField(t, TIFFTAG_IMAGELENGTH, height))
{
printf(%d\n, height);
}
}
--
--- main.c ---
void f();
void g();
int main()
{
f();
g();
return 0;
}
--
With libtiff4-dev installed:
% gcc -fPIC -c f.c
% gcc -shared -o libf.so -ltiff f.o
With libtiff-dev (tiff5) installed:
% gcc -fPIC -c c.c
% gcc -shared -o libg.so -ltiff g.o
Then
% gcc -o main main.c -L. -lf -lg
% LD_LIBRARY_PATH=. ldd ./main
linux-vdso.so.1 = (0x7fffd13ff000)
libf.so = ./libf.so (0x7f8aca4a1000)
libg.so = ./libg.so (0x7f8aca2a)
libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f8ac9ef7000)
libtiff.so.5 = /usr/lib/x86_64-linux-gnu/libtiff.so.5
(0x7f8ac9c86000)
libtiff.so.4 = /usr/lib/x86_64-linux-gnu/libtiff.so.4
(0x7f8ac9a21000)
/lib64/ld-linux-x86-64.so.2 (0x7f8aca6a4000)
libjpeg.so.8 = /usr/lib/libjpeg.so.8 (0x7f8ac97e6000)
libz.so.1 = /usr/lib/libz.so.1 (0x7f8ac95cf000)
libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f8ac934d000)
% LD_LIBRARY_PATH=. ./main
170
168
Once tiff3 clears NEW in experimental, unless I hear any objections,
as soon as upstream release 3.9.6, I'll upload that to unstable and let
the release team know that they can start binary NMUs of everything that
links with tiff.
--
Jay Berkenbilt q...@debian.org
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120128130600.0464744872.qww314159@soup
Re: intention for tiff packages
Julien Cristau jcris...@debian.org wrote: On Mon, Jan 23, 2012 at 11:00:53 -0500, Jay Berkenbilt wrote: Upstream has committed symbol versioning for both the 3.9.x branch and the trunk (4.0.0) and is prepared to release 3.9.6 and 4.0.1 with symbol versioning once we sign off that it's what we're looking for. What's the best way to do this? I would hate to make the assessment on my own and then find out it's still not right. Maybe I can prepare versions for experimental built with symbol versioning and someone can look it over? I'll still do my test of an application depending on a library with tiff 3 and another library with tiff 4. An upload to experimental with the option enabled seems reasonable. On the packaging side the addition of versioned symbols means bumping libtiff4's shlibs to avoid warnings from ld.so. I quickly looked over the upstream changes adding the version script, which look fine to me. Okay, thanks. One more question: tiff 4.0.0~beta7 is already in experimental, so I can't upload a new tiff 3.9 version to experimental without an epoch or some funky version numbering. While the next upload of tiff to unstable will be a symbol-versioned 3.9.x, should I go ahead and upload the trial version to experimental with the tiff3 source? That way, experimental would have the pair of source packages, both with versioned symbols, that we ultimately want in unstable. This is what I think I need to do: 1. Upload tiff-4.0.0-1 with versioned symbols to experimental 2. Upload tiff3-3.9.5-3 to experimental with versioned symbols 3. Wait for confirmation that this is good 4. Give upstream the go-ahead to release 3.9.6 and 4.0.1 5. Wait for release team to be ready to do the transition 6. Upload tiff-3.9.6-1 with versioned symbols to unstable 7. Wait for transition (all bin-NMUs finish, tiff-3.9.6-1 migrates to testing) 8. Upload tiff3-3.9.6-2 to unstable and simultaneously upload tiff-4.0.1-1 to unstable If this is right, I'll go ahead and do steps 1 and 2. Then I'll wait for an okay before proceeding. Of course, let me know if I should do this differently. My goal is to help make this as smooth as possible. (Thanks for continuing to include me explicitly me on all response since I'm not subscribed to debian-release.) -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120124140033.0220789135.qww314...@jberkenbilt-linux.appiancorp.com
Re: intention for tiff packages
Jay Berkenbilt q...@debian.org wrote: Julien Cristau jcris...@debian.org wrote: On Sat, Jan 21, 2012 at 19:10:00 -0500, Jay Berkenbilt wrote: Julien Cristau jcris...@debian.org wrote: As I said previously, if versioned symbols don't happen (in both the old and new versions), then the transition is unlikely to happen too. It was done for png and jpeg, so it's not like it'd be a first. I have the skills to do this and understand the concept, but I don't have the specific knowledge of exactly how to do it. I can figure it out by looking at png or jpeg, reading documentation, searching the web, etc., but if you have any specific pointers, email threads, or other references that might save me some time, I would be most grateful. I'll try and have a look asap. Might not be until next week though. Much to my surprise, upstream looks like they are going to take it. I started a thread on the tiff list today, and one of the primary maintainers already introduced a change in their CVS to make this possible. I think the process will be 1. Introduce a symbol-versioned version of tiff 3.x 2. Binary NMU everything so that all existing libraries and programs link with the symbol-versioned tiff 3.x 3. Introduce a symbol-versioned tiff 4.x using something akin to my original plan of having a tiff3 source package with 3.9.x libraries only and upgrading the tiff package to use 4.x Is this right? Many packages will be able to link with tiff 4.x without any changes. Anyway, we can discuss the exact mechanics of the migration after step 2 is done assuming this is more or less right since I imagine that will still take some time. Upstream has committed symbol versioning for both the 3.9.x branch and the trunk (4.0.0) and is prepared to release 3.9.6 and 4.0.1 with symbol versioning once we sign off that it's what we're looking for. What's the best way to do this? I would hate to make the assessment on my own and then find out it's still not right. Maybe I can prepare versions for experimental built with symbol versioning and someone can look it over? I'll still do my test of an application depending on a library with tiff 3 and another library with tiff 4. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120123110053.0292693063.qww314...@jberkenbilt-linux.appiancorp.com
Re: intention for tiff packages
Jay Berkenbilt q...@debian.org wrote: As I said previously, if versioned symbols don't happen (in both the old and new versions), then the transition is unlikely to happen too. It was done for png and jpeg, so it's not like it'd be a first. I have the skills to do this and understand the concept, but I don't have the specific knowledge of exactly how to do it. I can figure it out by looking at png or jpeg, reading documentation, searching the web, etc., but if you have any specific pointers, email threads, or other references that might save me some time, I would be most grateful. I found information in the debian library packaging guide. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120122111828.0289256487.qww314159@soup
Re: intention for tiff packages
Julien Cristau jcris...@debian.org wrote: On Sat, Jan 21, 2012 at 19:10:00 -0500, Jay Berkenbilt wrote: Julien Cristau jcris...@debian.org wrote: As I said previously, if versioned symbols don't happen (in both the old and new versions), then the transition is unlikely to happen too. It was done for png and jpeg, so it's not like it'd be a first. I have the skills to do this and understand the concept, but I don't have the specific knowledge of exactly how to do it. I can figure it out by looking at png or jpeg, reading documentation, searching the web, etc., but if you have any specific pointers, email threads, or other references that might save me some time, I would be most grateful. I'll try and have a look asap. Might not be until next week though. Much to my surprise, upstream looks like they are going to take it. I started a thread on the tiff list today, and one of the primary maintainers already introduced a change in their CVS to make this possible. I think the process will be 1. Introduce a symbol-versioned version of tiff 3.x 2. Binary NMU everything so that all existing libraries and programs link with the symbol-versioned tiff 3.x 3. Introduce a symbol-versioned tiff 4.x using something akin to my original plan of having a tiff3 source package with 3.9.x libraries only and upgrading the tiff package to use 4.x Is this right? Many packages will be able to link with tiff 4.x without any changes. Anyway, we can discuss the exact mechanics of the migration after step 2 is done assuming this is more or less right since I imagine that will still take some time. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120122204611.0289269656.qww314159@soup
intention for tiff packages
Here's what I'd like to do with the tiff packages. I believe this will be relatively non-disruptive. Technically, I don't think I *have* to ask permission for this, but I want to do it as a courtesy to the release team, to give you the chance to suggest a different approach or influence the timing, and to make sure I'm picking the best approach. I hope you will find a few minutes to reply so I can move forward, and I hope I won't have to wait very long. Current state: * The tiff source package in unstable is version 3.9.5-2. It includes binary packages libtiff4, libtiffxx0c2, libtiff4-dev, libtiff-tools, libtiff-opengl, and libtiff-doc. The libtiff4-dev package Provides and Conflicts libtiff-dev. * The tiff source package in experimental is version 4.0.0~beta7-2. It includes binary packages libtiff5, libtiffxx5, libtiff-dev, libtiff-tools, libtiff-opengl, and libtiff-doc. The libtiff-dev package Provides libtiff5-dev (reversing the sense from the older package where libtiff4-dev provided libtiff-dev) and both Conflicts and Replaces libtiff4-dev. This was to set the stage for an eventual tiff transition. * Some packages (not sure which ones) apparently embed tiff 4.x sources because they need BigTIFF support. This is bad from many angles. Proposed new state: * Upgrade the tiff package to 4.0.0-1 and upload to unstable. No other changes would be made to the package. * Create source package tiff3 in section oldlibs at initial version 3.9.5-3. Have it include libtiff4, libtiffxx0c2, and libtiff4-dev, and still have libtiff4-dev provide libtiff-dev for now. Drop libtiff-doc, libtiff-opengl, and libtiff-tools. (The libtiff-doc package from 4.x includes the older documentation as well.) Basically this would just be a copy of the existing package minus the duplicated packages. The libtiff4-dev package and tiff 3.x binary packages will stick around but move to the new source package. Their version numbers will continue in sequence, so upgrades will be seamless and automatic. Packages that build-depend on libtiff4-dev will be unaffected. Packages that depend on libtiff-dev alone (if any) will have to specify libtiff4-dev or libtiff5-dev explicitly. This is the only area that might cause a hiccup, but it should be minor. (Also, the tiff3 package would have to go through NEW, so there could be a very brief time when the libtiff4, libtiff4-dev, and libtiffxx02 packages might be uninstallable.) Packages that require tiff 4.x can explicitly depend on libtiff5-dev (or on libtiff-dev | libtiff5-dev). I believe this is a better alternative than just dropping the older packages entirely and forcing a full transition, but I would also be happy to do it that way if you want, though I think it will be much more difficult. Otherwise, I think we should wait until both versions are in the archive and then plan a more orderly transition that could culminate in the removal of the tiff3 source packages prior to the release of wheezy+1. As a reminder, there are ABI changes between libtiff4 and libtiff5, and there are very few source API changes, and they are clearly documented. The tiff libraries do not use versioned symbols, and there is no one right now how has time time and inclination to tackle this. It's basically not going to happen. Anyway, it's extremely unlikely that there will be any more ABI changes in the next many years. There are some packages out there that require features from tiff 4.x. We can help debian be the leader of getting the world to upgrade to the new version of the tiff packages. Thanks. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120121113810.3089362963.qww314159@soup
Re: intention for tiff packages
Julien Cristau jcris...@debian.org wrote: Okay, I basically have to admit that I agree with everything you said. Proposed new state: * Upgrade the tiff package to 4.0.0-1 and upload to unstable. No other changes would be made to the package. * Create source package tiff3 in section oldlibs at initial version 3.9.5-3. Have it include libtiff4, libtiffxx0c2, and libtiff4-dev, and still have libtiff4-dev provide libtiff-dev for now. Drop libtiff-doc, libtiff-opengl, and libtiff-tools. (The libtiff-doc package from 4.x includes the older documentation as well.) Basically this would just be a copy of the existing package minus the duplicated packages. I think that's a bad plan. There are packages in the archive right now, including shared libraries, that build-depend on the unversioned libtiff-dev package. They'd pick up a dependency on libtiff5 on a rebuild, which is not a good thing if we're not going to move the whole archive to it. Yes, you're right. As a reminder, there are ABI changes between libtiff4 and libtiff5, and there are very few source API changes, and they are clearly documented. The tiff libraries do not use versioned symbols, and there is no one right now how has time time and inclination to tackle this. It's basically not going to happen. Anyway, it's extremely unlikely that there will be any more ABI changes in the next many years. As I said previously, if versioned symbols don't happen (in both the old and new versions), then the transition is unlikely to happen too. It was done for png and jpeg, so it's not like it'd be a first. I have the skills to do this and understand the concept, but I don't have the specific knowledge of exactly how to do it. I can figure it out by looking at png or jpeg, reading documentation, searching the web, etc., but if you have any specific pointers, email threads, or other references that might save me some time, I would be most grateful. I've got my hands full with one-year-old twins, and my debian time is extremely limited. While I acknowledge that the only right answer is going to be to do symbol versioning, and while I will not argue against your insistence on doing the right thing, I just don't know when I can do it. I know that I'm going to have to actually figure out which symbols are part of the public API, etc. Once versioned symbols are done, will the plan be more or less what I outlined: tiff3 package with versioned libtiff4 and tiff package with versioned libtiff5, just with the difference being that it will work for lib1 to link with libtiff4, lib2 to link with libtiff5, and program1 to link with both lib1 and lib2, or will there be some other solution? Thanks for keeping us on the right path, even if it means that getting tiff 4.0 into unstable will take a long time. I wish I had never suggested doing anything else. Just my realization that no one really has time to do this forced me down the dark path of looking for an easy solution. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120121191000.3089338302.qww314159@soup
Re: potential tiff transition, tiff 4.0.0 strategy
Julien Cristau jcris...@debian.org wrote: On Tue, Dec 13, 2011 at 09:02:50 -0500, Jay Berkenbilt wrote: So, what is the recommendation of the release team? If you agree that we should do a transition as soon as possible after the final 4.0.0 is released (so that wheezy can have 4.x), do you have any guesses as to when you would be ready for an upload? FWIW, I think it should be required for such a library to use versioned symbols if it doesn't care to keep its ABI stable. While I agree in principle, this is the first ABI change in the over 10 years since I've been using the library, and no others are planned for the foreseeable future. (There was an accidental ABI change in 2003, but they are much more careful now, and even if upstream messes up, I and others on the upstream mailing list call them on it and it gets fixed.) The ABI change was the result of a revised specification to the TIFF file format (support of bigtiff), and this doesn't happen very often. While the TIFF ABI is not absolutely set in stone, I would hardly say it's not stable. There is very little effort on the tiff libraries upstream right now, and the library is very stable and in wide use, so there's basically no chance that upstream is going to do this. I don't have the bandwidth to do it just for the debian packages, and I also don't think it's worth the effort since no ABI changes are likely for years. I'm planning on uploading the new version to unstable but not having it provide libtiff-dev until I hear from the release time how the transition should be handled. That way at least those packages that are already including their own copies of the tiff 4.x source code can stop doing it, but there won't be any accidental dependencies on multiple versions. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111229110217.0207078936.qww314...@jberkenbilt-linux.appiancorp.com
potential tiff transition, tiff 4.0.0 strategy
(Please CC me on replies; I am not subscribed to debian-release.) After many moons, it appears that a final, non-beta release of libtiff 4.0.0 is imminent. tiff-4.0.0~beta7 is in experimental, and some 4.0 beta has been in experimental since August, 2009. I recently learned that the tiff 4.0.0 sources are embedded in some existing packages, which we know is really bad from a security perspective. While tiff 4 is almost entirely source-compatible with tiff 3, there are ABI changes, and in some cases, a source-full upload may be required. For some packages, especially those who are depending on libtiff-dev instead of libtiff4-dev, it's possible that a binary NMU may be sufficient. As you well know, the tiff library has a very long chain of reverse dependencies, so managing a transition could be involved, but it shouldn't really be all that complicated since there should be few source changes. Many packages will have to change their build dependencies. Also, most of the packages that are downstream from tiff depend on it indirectly through other imaging libraries. As I see it, we have two choices: supporting two versions of libtiff in unstable at the same time for some period of time, or biting the bullet and tackling the transition right off the bat. I don't have any window into how ready the release team would be to swallow a tiff transition right now. That said, having two versions of tiff in unstable at the same time seems like it could cause more problems than it solves. Many packages depend on libtiff indirectly, so it seems potentially easy for a package to end up needing two versions at once, and libtiff does not use versioned symbols. (And I don't have the bandwidth to tackle it, and neither does upstream.) My preference would be to just do a libtiff transition. With the release of tiff 4.0.0, the debian version of tiff will be identical to upstream since they are using 5 as the soname of the library in response to our having moved to 4 as the result of an earlier accidental ABI change. All our patches from 3.x are present in the upstream version, and all security issues reported against the 3.x series have also been fixed in 4.x. The 4.x libraries are already being used in many projects and are already getting external security scrutiny, and there is wide consensus that it is ready for prime time. So, what is the recommendation of the release team? If you agree that we should do a transition as soon as possible after the final 4.0.0 is released (so that wheezy can have 4.x), do you have any guesses as to when you would be ready for an upload? -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111213090250.0813570557.qww314...@jberkenbilt-linux.appiancorp.com
Bug#628529: transition: ICU transition (4.4 - 4.8)
On 11/08/2011 05:46 PM, Julien Cristau wrote:
On Sat, Sep 10, 2011 at 13:04:13 -0400, Jay Berkenbilt wrote:
Julien Cristau jcris...@debian.org wrote:
On 05/29/2011 10:19 PM, Jay Berkenbilt wrote:
I'd like to schedule a transition for ICU from 4.4 to 4.8. . . .
This can't really happen as long as icu itself FTBFS on one of the
release architectures, so marking the corresponding bug as a blocker.
The problem blocking this transition has been fixed, and we've had a
successful build on that platform. Still waiting for builds on some of
the rest of the platforms, but it looks good since it was a one-line
change to ./configure{,.in} to add kfreebsd to a case statement.
Hopefully we can move forward with the transition.
I think we're finally ready for this, so please go ahead with the upload
to unstable. Sorry for the delay.
Cheers,
Julien
I'll be uploading shortly. Thanks.
--Jay
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4eba975c.80...@ql.org
binNMU on tiff
Please see bug 640225. A request is made there to binNMU tiff so it no longer links with libjpeg.so.62. I believe that is the correct solution, rather than having me do a new upload. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110903113514.0293615102.qww314159@soup
ICU transition
I'd like to schedule a transition for ICU from 4.4 to 4.8. In the past several ICU transitions, it has been sufficient to do a binary NMU for each reverse dependency, and there's little reason to believe that this time should be any different. There are a few API changes, but they are mostly for interfaces that have been deprecated for a long time, and this is pretty much comparable to earlier ICU releases. I will wait to upload ICU to unstable until I get an okay from the release team and until I hear from openoffice.org maintainers. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110529161900.3019911685.qww314159@soup
libjpeg-dev dependency (bug 610862)
Where did we eventually land on the correct way to make a dependency on libjpeg's dev package? libtiff4-dev depends on libjpeg-dev (and tiff build-depends on libjpeg-dev), which I believe was explicitly done during the libjpeg62 to libjpeg8 transition, which got confused at some point. Anyway, a user complains in bug 610862 that libtiff4-dev depends on libjpeg-dev and shouldn't, but before I change it, I wanted to find out what I should be doing now. I could change to something like libjpeg-dev | libjpeg8-dev or even to libjpeg8-dev | libjpeg-dev (or the libjpeg62-dev versions of the above), but I thought by using libjpeg-dev, I was protecting my package against having to be re-uploaded in the event of a jpeg transition. I could look at the current state, but that doesn't necessarily tell me what the long-term plans are. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110303180429.1925906716.qww314159@motoko.argon.local
Re: fixing 604471/591615 (Malayalam rendering problem) in squeeze
Attached is a diff between icu-4.4.1-6 and icu-4.4.1-7 which fixes merged RC-critical bugs 604471 and 591615. I can't do this through unstable because unstable already contains 4.4.2, a new upstream release (albeit one with only bug fixes). As you can see, all this does is add a new patch to the debian directory (and update series and changelog). I have built this package in a squeeze chroot and have tested OpenOffice.org (in the squeeze chroot and also on my sid system) with and without the patch and have verified that it fixes the problem as reported. (The Red Hat report contains screen shots.) The patch has been accepted by Red Hat and has now also been reported upstream (http://bugs.icu-project.org/trac/ticket/8198). With the (US) holiday weekend, I will not be around my email quite as often as usual, so I have gone ahead and uploaded this to testing-proposed-updates for you to either accept or reject. I hope that's okay -- I know it requires manual intervention either way, so I'm trying to do what makes it easiest for the release team. I will upload to unstable after you either accept or reject this so I can either include or not include its changelog entry in the unstable package's changelog. My original message is below for reference. --Jay Jay Berkenbilt q...@debian.org wrote: There is a bug in ICU 4.4, for which we have a small and minimally invasive patch, that causes OpenOffice.org rendering of Malayalam to not work. The reporter argues that the bug makes the package unusable for at least one set of users (those who work in Malayalam). I've attached the latest bit of the email trail to this message. As such, I have suggested that the bug should be considered grave. The patch is to revert a particular change set's changes to one file: http://bugs.icu-project.org/trac/changeset/26090/icu/trunk/source/layout/IndicReordering.cpp Red Hat has apparently accepted this solution. Their bug report is here: https://bugzilla.redhat.com/show_bug.cgi?id=654200 I don't see an upstream report on this at this time, but the discussion in the Red Hat bug report seems to indicate a thorough analysis. Unfortunately, the version of ICU in squeeze is 4.4.1-6 and the version in sid is 4.4.2-1. I therefore can't upload to unstable and request a freeze exception unless we were prepared to accept 4.4.2-1's changes in squeeze (which . I would prepare a 4.4.1-7 release for testing-proposed-updates, or this could be handled in a point release of squeeze. I've copied the reporter so he can clarify/correct anything I may have said here. Please advise as to whether I should upload a to t-p-u. I'll upload to unstable either way. --Jay From: Mahesh T. Pai paiva...@gmail.com Subject: Re: Bug#604471: libreoffice: Malayalam Rendering issue (probably icu related) To: Jay Berkenbilt q...@debian.org Cc: Rene Engelhard r...@debian.org, 604...@bugs.debian.org, prav...@gmail.com Date: Mon, 22 Nov 2010 22:07:11 +0530 Jay Berkenbilt said on Mon, Nov 22, 2010 at 11:12:12AM -0500,: the patch and upload, but only the release team can make the decision as to whether the change will get into squeeze. It's very late right now, so they will have to be convinced that it is a release-critical bug. If you upgrade the status of the bug from important to grave and justify this, I will upload a new version with the patch that reverts the change that introduced the problem and will request that the release team allow a freeze exception. They will either grant the freeze exception, or they will disagree with the classification of the bug. In the former It is absolutely essential that this patch squeezes past the Squeeze freeze. OO.o / LibO is one of the critical components for the desktop, and the rendering issues caused by the bug renders OO.o / LibO practically useless for people using Malayalam. This has been working well in previous versions of Debian / OO.o / LibO, and it will be extremely disappointing for users to find the problem arising now. While personally, I can wait till the next version of ICU enters testing, that is because I use Sid, and know reasonably well my way around Debian. I would rather that the Squeeze freeze is freeezed till this is fixed. diff -urN ../icu-4.4.1-6/debian/changelog ./debian/changelog --- ../icu-4.4.1-6/debian/changelog 2010-07-28 18:44:01.0 -0400 +++ ./debian/changelog 2010-11-25 12:07:26.0 -0500 @@ -1,3 +1,9 @@ +icu (4.4.1-7) testing-proposed-updates; urgency=high + + * Apply patch to fix Malayam rendering. (Closes: #591615) + + -- Jay Berkenbilt q...@debian.org Thu, 25 Nov 2010 12:07:26 -0500 + icu (4.4.1-6) unstable; urgency=low * Include patch from Alexander Kurtz to solve failure to build from diff -urN ../icu-4.4.1-6/debian/patches/malayalam-rendering.patch ./debian/patches/malayalam-rendering.patch --- ../icu-4.4.1-6/debian/patches/malayalam-rendering.patch
fixing 604471/591615 (Malayalam rendering problem) in squeeze
There is a bug in ICU 4.4, for which we have a small and minimally invasive patch, that causes OpenOffice.org rendering of Malayalam to not work. The reporter argues that the bug makes the package unusable for at least one set of users (those who work in Malayalam). I've attached the latest bit of the email trail to this message. As such, I have suggested that the bug should be considered grave. The patch is to revert a particular change set's changes to one file: http://bugs.icu-project.org/trac/changeset/26090/icu/trunk/source/layout/IndicReordering.cpp Red Hat has apparently accepted this solution. Their bug report is here: https://bugzilla.redhat.com/show_bug.cgi?id=654200 I don't see an upstream report on this at this time, but the discussion in the Red Hat bug report seems to indicate a thorough analysis. Unfortunately, the version of ICU in squeeze is 4.4.1-6 and the version in sid is 4.4.2-1. I therefore can't upload to unstable and request a freeze exception unless we were prepared to accept 4.4.2-1's changes in squeeze (which . I would prepare a 4.4.1-7 release for testing-proposed-updates, or this could be handled in a point release of squeeze. I've copied the reporter so he can clarify/correct anything I may have said here. Please advise as to whether I should upload a to t-p-u. I'll upload to unstable either way. --Jay ---BeginMessage--- Jay Berkenbilt said on Mon, Nov 22, 2010 at 11:12:12AM -0500,: the patch and upload, but only the release team can make the decision as to whether the change will get into squeeze. It's very late right now, so they will have to be convinced that it is a release-critical bug. If you upgrade the status of the bug from important to grave and justify this, I will upload a new version with the patch that reverts the change that introduced the problem and will request that the release team allow a freeze exception. They will either grant the freeze exception, or they will disagree with the classification of the bug. In the former It is absolutely essential that this patch squeezes past the Squeeze freeze. OO.o / LibO is one of the critical components for the desktop, and the rendering issues caused by the bug renders OO.o / LibO practically useless for people using Malayalam. This has been working well in previous versions of Debian / OO.o / LibO, and it will be extremely disappointing for users to find the problem arising now. While personally, I can wait till the next version of ICU enters testing, that is because I use Sid, and know reasonably well my way around Debian. I would rather that the Squeeze freeze is freeezed till this is fixed. -- Mahesh T. Pai || http://[paivakil|fizzard].blogspot.com Funny how people infriging commercial software licences are called pirates, while huge companies infriging the GPL are called users ---End Message---
tiff-3.9.4-5: fixes RC Bug 600188
I've just uploaded tiff-3.9.4-5, which fixes RC bug 600188, CVE-2010-3087. The change adds a single patch. I uploaded with urgency high and am requesting a freeze exception. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101017165109.0601285123.qww314...@soup
backport of CVE-2010-3364 to vips/nip2 in testing
The bug reported in bug 598296 is the security vulnerability
CVE-2010-3364. The bug was reported against vips 7.22, but it actually
affects both vips and nip2, and it is present in all previous versions.
Its fix is a simple change to some wrapper shell scripts. The versions
currently in unstable include upstream's fix to the bug, but the
unstable versions have no possibility of migrating to testing since they
are new upstream versions and depend on other things that are not going
to transition.
I have backported the fix from the current versions in unstable to the
versions in testing. The patch applied with no modifications other than
the name of the file being changed. I have prepared new versions for
testing, but as per your instructions, I have not uploaded them.
(Anyway, I don't have a clean testing chroot set up at the moment,
though I can always make one.) I'm attaching my diffs to this email.
Feel free to either put these in testing or to ask me to go ahead and
upload. I can set up a testing chroot and build packages to upload
(though it might take me several days to get to it).
I haven't done anything with to mark that the bug appears in older
versions. I will also be contacting the security team about fixing it
in stable.
--
Jay Berkenbilt q...@debian.org
Index: debian/changelog
===
--- debian/changelog (.../tags/7.20.7-1) (revision 1488)
+++ debian/changelog (.../branches/7.20) (revision 1488)
@@ -1,3 +1,10 @@
+vips (7.20.7-2) testing-proposed-updates; urgency=low
+
+ * Backport fix to CVE-2010-3364 (insecure library loading) from 7.22.4
+release.
+
+ -- Jay Berkenbilt q...@debian.org Sun, 10 Oct 2010 15:11:35 -0400
+
vips (7.20.7-1) unstable; urgency=low
* New upstream release
Index: debian/patches/ld-library-path.patch
===
--- debian/patches/ld-library-path.patch (.../tags/7.20.7-1) (revision 0)
+++ debian/patches/ld-library-path.patch (.../branches/7.20) (revision 1488)
@@ -0,0 +1,60 @@
+Description: fix to CVE-2010-3364 backported from upstream
+ Prevent insecure prepend to LD_LIBRARY_PATH
+Origin: upstream, backported from 7.22.4
+
+Index: vips-7.20.7/tools/scripts/vips-7.20
+===
+--- vips-7.20.7.orig/tools/scripts/vips-7.20 2010-10-10 15:07:23.240170610 -0400
vips-7.20.7/tools/scripts/vips-7.20 2010-10-10 15:07:28.867670770 -0400
+@@ -19,6 +19,19 @@
+ exit 1
+ fi
+
++# prepend a path component to an environment variable
++# be careful to avoid trailing : characters if the var is not defined, they
++# can cause security problems
++function prepend_var () {
++ # we have to use eval to do double indirection, I think
++ eval value=\$$1
++ if [ x$value = x ]; then
++ export $1=$2
++ else
++ export $1=$2:$value
++ fi
++}
++
+ # try to extract the prefix from a path to an executable
+ # eg. /home/john/vips/bin/fred - /home/john/vips
+ function find_prefix () {
+@@ -92,25 +105,26 @@
+ export VIPSHOME=$prefix
+
+ # add VIPSHOME to man pages
+-export MANPATH=$VIPSHOME/man:$MANPATH
++prepend_var MANPATH $VIPSHOME/man
+
+ # add the VIPS lib area to the library path
+ case `uname` in
+ HPUX)
+- export SHLIB_PATH=$VIPSHOME/lib:$SHLIB_PATH
++ libvar=SHLIB_PATH
+ ;;
+
+ Darwin)
+- export DYLD_LIBRARY_PATH=$VIPSHOME/lib:$DYLD_LIBRARY_PATH
++ libvar=DYLD_LIBRARY_PATH
+ ;;
+
+ *)
+- export LD_LIBRARY_PATH=$VIPSHOME/lib:$LD_LIBRARY_PATH
++ libvar=LD_LIBRARY_PATH
+ ;;
+ esac
++prepend_var $libvar $VIPSHOME/lib
+
+ # add VIPS bin area to path
+-export PATH=$VIPSHOME/bin:$PATH
++prepend_var PATH $VIPSHOME/bin
+
+ # run, passing in args we were passed
+ exec $*
Index: debian/patches/series
===
--- debian/patches/series (.../tags/7.20.7-1) (revision 1488)
+++ debian/patches/series (.../branches/7.20) (revision 1488)
@@ -0,0 +1 @@
+ld-library-path.patch
Index: debian/changelog
===
--- debian/changelog (.../tags/7.20.7-2) (revision 1487)
+++ debian/changelog (.../branches/7.20) (revision 1487)
@@ -1,3 +1,10 @@
+nip2 (7.20.7-3) testing-proposed-updates; urgency=low
+
+ * Backport fix to CVE-2010-3364 (insecure library loading) from 7.22.3
+release.
+
+ -- Jay Berkenbilt q...@debian.org Sun, 10 Oct 2010 15:17:11 -0400
+
nip2 (7.20.7-2) unstable; urgency=low
* Updated build dependencies: libjpeg62-dev - libjpeg-dev
Index: debian/patches/ld-library-path.patch
===
--- debian/patches/ld-library-path.patch (.../tags/7.20.7-2) (revision 0)
+++ debian/patches/ld-library-path.patch (.../branches/7.20) (revision 1487)
@@ -0,0 +1,51 @@
+Description: fix to CVE-2010-3364 backported from upstream
+ Prevent insecure prepend to LD_LIBRARY_PATH
+Origin: upstream, backported from 7.22.3
+
+Index: nip2
tiff-3.9.4-4 fixes CVE-2010-3364
I had overlooked that bug 595064 was a security bug that fixed CVE-2010-3364. I think perhaps a CVE number had not been assigned when the bug was originally reported. In any case, I upgraded the bug to grave and uploaded tiff-3.9.4-4 with a fix to it. The fix changes one line of code, and I didn't make any other changes to the package. Since this is a security-related fix that should be able to enter testing through unstable, I am requesting a freeze exception. Otherwise, it can be handled through normal security channels. I uploaded it with urgency high and mentioned the CVE number in the changelog. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101002134407.0289400883.qww314...@soup
Re: freeze exceptions: qpdf, tiff
Julien Cristau jcris...@debian.org wrote: On Fri, Aug 20, 2010 at 16:27:13 -0400, Jay Berkenbilt wrote: For qpdf, this is a new upstream version that is binary compatible with the old one. qpdf is isolated in the dependency tree (no other packages depend on it), and I am upstream, so I can definitely vouch for the fact that the changes were relatively minor and should be very safe. I see new API but no shlibs bump? New API doesn't require a shlibs bump. Changed or removed API requires a shlibs bump. 2.2.0 adds several new functions. The only function that changed incompatibly was QPDFWriter::disableIncompatbleEncryption(float), which is a private method in the QPDFWriter object. No external code could call that method, so it can't be an unresolved symbol anywhere, so changing it does not require a shlibs bump. I use libtool to manage the shlibs. CURRENT,REVISION,AGE for 2.2.0 is 4,0,1. For 2.1.5, it was 3,4,0. This is consistent with new API having been added but no callable API having been changed or removed. To be absolutely certain, I built qpdf 2.1.5 from source, swapped its native libqpdf.so.3.0.4 with a copy of libqpdf.so.3.1.0 (renamed to libqpdf.os.3.4), and ran qpdf's very thorough test suite. The 2.1.5 qpdf's test suite passes when run with the 2.2.0 qpdf's shared library with the exception of the fact that the test suite reports incomplete coverage on the new API (which is, of course, not exercised by the 2.1.5 test suite). So (assuming you trust the thoroughness of the qpdf test suite), this also confirms that the ABI has not been broken. Are you seeing something different from this? If so, please let me know. I'm also interested to know what you're using to determine whether there are ABI changes. Thanks for being so thorough. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100821090836.0290813736.qww314...@soup
Re: freeze exceptions: qpdf, tiff
Julien Cristau jcris...@debian.org wrote: I hope you will not take it the wrong way that I'm continuing to argue this point. We share a common goal of ensuring that this change is safe and will not cause problems, and I appreciate that you have to act in a policing role about this issue. I also appreciate that many developers don't understand the subtleties of what constitutes a breaking ABI change. In the case of qpdf, it seems as though we disagree on whether the changes are safe. If I have made a mistake, I will surely correct it, but at this point, I still don't believe that I have introduced an incompatible change to the library's ABI, and I really don't want to artificially and needlessly increase the SONAME as that is disruptive to my users. So I continue the discussion below. I see new API but no shlibs bump? New API doesn't require a shlibs bump. Changed or removed API requires a shlibs bump. Err. New API is what shlibs is for. Changed or removed API requires a SONAME and package name change. How is what you're saying different from what I'm saying? I interpreted shlibs bump to mean changing the SONAME. Do you mean something different? You say Changed or removed API requires SONAME and package name change, and I agree. But I don't believe that I have introduced any changed or removed API. Adding new API is not a reason to increase the SONAME. This happens all the time. The reason for this is that the SONAME needs to change when there's a reason that OLD applications linked originally with the OLD library can't continue to work with the NEW library. In other words, you should be able to upgrade the shared library without breaking existing applications. Having new callable methods appear in the shared library will not interfere with existing applications as long as existing symbols can be resolved in the same way. There's no expectation that executables linked with the new library will work with the old library. That's why adding new API doesn't require changing the SONAME. Do you disagree with my understanding of when the SONAME has to change, or do you disagree with my analysis that none of the things that require an SONAME change have happened? Or have I just done a poor job of explaining why my changes are compatible and have unwitting led you to a false conclusion? If our communication is clear but we disagree on one of these issues, can we get someone else to weigh in? Isn't this what the technical committee is for? A good discussion of this issue can be found here: http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html Fundamentally though, you can usually tell by comparing the header files and the list of exported symbols from the libraries. The only changes that could even possibly be considered worthy of causing an SONAME change are the addition of two new private data members to the end of QPDF_Stream and the change to a private member function of QPDFWriter. However, QPDF_Stream is a private class to the library: its header is not installed, no actual instances of the class are ever exposed to the users of the library, and no classes are derived from QPDF_Stream. Therefore, addition of new data members to the end of the object can't cause breakage of existing applications. And the method that changed in QPDFWriter is private. It can't be called from outside the QPDFWriter class, so this is safe too. If there's any doubt, you can run nm -D --demangle on the old and new shared libraries, observe that the only method that disappeared from the old is QPDFWriter::disableIncompatbleEncryption(float), and then verify by looking at QPDFWriter.hh in 2.1.5 that this was in fact a private method. I designed QPDF's APIs the way they are in significant part to make it possible to make certain types of changes without breaking binary compatibility. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100821105320.0290889916.qww314...@soup
Re: freeze exceptions: qpdf, tiff
Julien Cristau jcris...@debian.org wrote: Seems we're just talking past each other. On Sat, Aug 21, 2010 at 10:53:20 -0400, Jay Berkenbilt wrote: I interpreted shlibs bump to mean changing the SONAME. Do you mean something different? I wasn't talking about the library's SONAME, I was talking about the shlibs control file from your package (as documented in policy §8.6, and used by dpkg-shlibdeps). AH! (*strikes head on forehead*) Oops... Thanks for catching that. My mistake. I so thoroughly missed the point that I interpreted shlibs bump as SONAME change. Of course shlibs makes sure you have a new enough version of the library package. I will fix it, re-upload, and re-request a freeze exception. Thanks for setting me straight, and sorry for the confusion. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100821120054.0290808079.qww314...@soup
freeze exceptions: qpdf, tiff
I'd like to request two freeze exceptions: qpdf 2.2.0-1 and tiff 3.9.4-3. For tiff, there are no code changes from 3.9.4-2. I just fixed up requires, conflicts, etc., to bring it up to standards 3.9.1. (I didn't want to combine that with the security fix that was in 3.9.4-2 and was uploaded with urgency=high.) For qpdf, this is a new upstream version that is binary compatible with the old one. qpdf is isolated in the dependency tree (no other packages depend on it), and I am upstream, so I can definitely vouch for the fact that the changes were relatively minor and should be very safe. Thanks for your consideration. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100820162713.2402820247.qww314...@motoko.argon.local
please unblock tiff
I have uploaded tiff-3.9.4-2 to fix CVE-2010-2233. Please unblock so the security fix can be propagated to testing. I did the upload with urgency=high. Thanks. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100814160125.0277396117.qww314...@soup
icu package RC bug and fix
Someone posted an RC bug against ICU because of an FTBFS. Upon investigating the problem, it turns out to be because of doxygen 1.7.1 having showed up the day after the ICU packages were built. The new doxygen doesn't generate gif files anymore, which caused the install-doc target of ICU to fail. I'm uploading a new icu package today, which will of course reset the 10-day counter (since I'm using urgency=low). There are no other changes to the package. If the ICU transition is imminent, it would be safe to override the transition delay. All I've changed is to add a patch that removes *.gif from the list of installed docs and that changes the build dependency on doxygen to be = 1.7.1. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100728190214.2306552371.qww314...@motoko.argon.local
Re: ICU status check
Adam D. Barratt a...@adam-barratt.org.uk wrote: On Fri, June 25, 2010 22:46, Jay Berkenbilt wrote: So, I don't want to nag since I know the release team is busy managing many conflicting priorities, but I'd like to get some sense of when I can upload ICU 4.4. If it's soon, I'll wait on uploading the 4.6 test releases. If not, then I may just go ahead and start on 4.6 with experimental. However, I will still want to upload 4.4 to unstable. Apologies for not getting back to you sooner; sorting out what we were doing after the python transition took a little longer than expected. Please go ahead with the upload of 4.4 to unstable. Thanks. I will be offline starting in about 5 hours until Sunday early afternoon. As soon as I return, I will upload. That way I will be able to closely monitor for any problems. No problem on the delay. We're all volunteers! --Jay -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100709103457.0280422710.qww314...@soup
ICU status check
Hello again. I know the release team hasn't forgotten about the ICU transition, but I'm now faced with a bit of dilema. Upstream is already starting with testing for 4.6, and debian hasn't even got 4.4 yet. I would like to be able to start using experimental to stage 4.6 milestones, but I've got 4.4 there. So I have two choices...either wait to start testing the 4.6 milestones until after the transition, or go ahead and start with the transition and then just upload 4.4 to unstable whenever you give the okay. The past few ICU transitions have been very smooth because the ICU team is careful about source compatibility and the ICU packages are structured so that binary NMUs are sufficient for most of ICU's reverse dependencies. So, I don't want to nag since I know the release team is busy managing many conflicting priorities, but I'd like to get some sense of when I can upload ICU 4.4. If it's soon, I'll wait on uploading the 4.6 test releases. If not, then I may just go ahead and start on 4.6 with experimental. However, I will still want to upload 4.4 to unstable. Thanks. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100625174638.0306576272.qww314...@soup
Re: permission to upload ICU 4.4 to unstable
Jay Berkenbilt q...@debian.org wrote: ICU 4.4 was released a few weeks ago. There are very few changes from 4.4.rc1. I'm going to do one upload of 4.4 to experimental to make sure it builds properly on all platforms. If all goes well, I'd like to go ahead and upload to unstable. Please let me know when I can proceed with the upgrade. As before, there are no API changes for people who stick to published interfaces, so binary NMUs for reverse dependencies should be adequate, as it has been for the last few ICU transitions. Hello again. I'm still waiting for a response to this. Of course, I understand that the release team is busy and understaffed, and that you have to serialize things sometimes, so I'm not complaining...I'm just asking for an update. :-) I know you know about it because I saw it in your bits from the release team. If you could let me know where this is in the queue, I'd appreciate it. Alternatively, if there's something else I need to do to get this on the queue, I'm not aware of it. I remember some discussion about using the BTS for this kind of request, but I don't remember seeing a resolution to that question. Thanks. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100418100019.0267997463.qww314...@soup
permission to upload ICU 4.4 to unstable
ICU 4.4 was released a few weeks ago. There are very few changes from 4.4.rc1. I'm going to do one upload of 4.4 to experimental to make sure it builds properly on all platforms. If all goes well, I'd like to go ahead and upload to unstable. Please let me know when I can proceed with the upgrade. As before, there are no API changes for people who stick to published interfaces, so binary NMUs for reverse dependencies should be adequate, as it has been for the last few ICU transitions. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100409223507.0270542654.qww314...@soup
ICU transition for squeeze?
In response to your request to debian-devel-announce, I'd like to ask if it's possible to transition ICU to version 4.4 for squeeze. 4.4 is supposed to be released this coming week, and we had several pre-release versions in experimental. The ICU packages are set up so that binary NMU's are usually if not always sufficient, and the ICU upstream has what I believe to be a perfect track record when it comes it maintaining API compatibility. The last few ICU transitions have gone through without incident. The most important package that depends on ICU is openoffice.org. My usual policy with respect to ICU transitions is to make sure openoffice tests with the new version and, if everything is okay, to upload and ask the release team to schedule binary NMUs for its reverse dependencies. A 4.4 release candidate was released last week. I haven't uploaded to experimental yet because of a small problem with installation. There are two possible solutions, both of which are easy, but I'm waiting for upstream to let me know which one they prefer. The most likely progression will be that I upload 4.4-1 to experimental for NEW processing (soname change), openoffice.org tests with it, and then I upload 4.4-2 to unstable, coordinate with the release team, of course. As far as my other packages are concerned, I don't see anything significant coming up. There is likely to be a final release of tiff 4.0 soon, but that's going to be a more significant transition that I plan not to start until after squeeze is released. I'll contact the release team separately about preparing for that. Maybe we can learn from the jpeg8 transition, but I'll save the details for another message. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100314210331.0274750181.qww314...@soup
Re: xerces-c2-2.8.0-3+lenny1: permission to upload to stable
Adam D. Barratt a...@adam-barratt.org.uk wrote:
Please prepare an update (built against stable, either on a stable
system or in a chroot), and send a debdiff against the current stable
package to debian-release for upload approval.
Here it is. I have built the packages in a lenny chroot and have done
light testing to ensure proper functionality. The packages are signed
and ready to upload pending approval.
diff -u xerces-c2-2.8.0/debian/changelog xerces-c2-2.8.0/debian/changelog
--- xerces-c2-2.8.0/debian/changelog
+++ xerces-c2-2.8.0/debian/changelog
@@ -1,3 +1,9 @@
+xerces-c2 (2.8.0-3+lenny1) stable; urgency=low
+
+ * Apply patch to correct CVE-2009-1885: DoS attack from nested DTDs.
+
+ -- Jay Berkenbilt q...@debian.org Sat, 06 Feb 2010 22:01:25 -0500
+
xerces-c2 (2.8.0-3) unstable; urgency=low
* Change priority from extra to optional as priority optional packages
only in patch2:
unchanged:
--- xerces-c2-2.8.0.orig/debian/patches/00-CVE-2009-1885.patch
+++ xerces-c2-2.8.0/debian/patches/00-CVE-2009-1885.patch
@@ -0,0 +1,650 @@
+diff -urN xerces-c-src_2_8_0.orig/src/xercesc/validators/DTD/DTDScanner.cpp xerces-c-src_2_8_0/src/xercesc/validators/DTD/DTDScanner.cpp
+--- xerces-c-src_2_8_0.orig/src/xercesc/validators/DTD/DTDScanner.cpp 2007-08-28 14:43:25.0 -0400
xerces-c-src_2_8_0/src/xercesc/validators/DTD/DTDScanner.cpp 2010-02-06 21:58:25.675927667 -0500
+@@ -27,7 +27,9 @@
+ #include xercesc/util/FlagJanitor.hpp
+ #include xercesc/util/Janitor.hpp
+ #include xercesc/util/XMLUniDefs.hpp
++#include xercesc/util/ValueStackOf.hpp
+ #include xercesc/util/UnexpectedEOFException.hpp
++#include xercesc/util/OutOfMemoryException.hpp
+ #include xercesc/sax/InputSource.hpp
+ #include xercesc/framework/XMLDocumentHandler.hpp
+ #include xercesc/framework/XMLEntityHandler.hpp
+@@ -39,7 +41,6 @@
+ #include xercesc/validators/DTD/DTDEntityDecl.hpp
+ #include xercesc/validators/DTD/DocTypeHandler.hpp
+ #include xercesc/validators/DTD/DTDScanner.hpp
+-#include xercesc/util/OutOfMemoryException.hpp
+
+ XERCES_CPP_NAMESPACE_BEGIN
+
+@@ -1046,338 +1047,354 @@
+ // Check for a PE ref here, but don't require spaces
+ checkForPERef(false, true);
+
+-// We have to check entity nesting here
+-unsigned int curReader;
+-
++ValueStackOfXMLSize_t* arrNestedDecl=NULL;
+ //
+ // We know that the caller just saw an opening parenthesis, so we need
+-// to parse until we hit the end of it, recursing for other nested
+-// parentheses we see.
++// to parse until we hit the end of it; if we find several parenthesis,
++// store them in an array to be processed later.
+ //
+ // We have to check for one up front, since it could be something like
+ // (((a)*)) etc...
+ //
+ ContentSpecNode* curNode = 0;
+-if (fReaderMgr-skippedChar(chOpenParen))
++while(fReaderMgr-skippedChar(chOpenParen))
+ {
+-curReader = fReaderMgr-getCurrentReaderNum();
++// to check entity nesting
++const unsigned int curReader = fReaderMgr-getCurrentReaderNum();
++if(arrNestedDecl==NULL)
++arrNestedDecl=new (fMemoryManager) ValueStackOfXMLSize_t(5, fMemoryManager);
++arrNestedDecl-push(curReader);
+
+-// Lets call ourself and get back the resulting node
+-curNode = scanChildren(elemDecl, bufToUse);
++// Check for a PE ref here, but don't require spaces
++checkForPERef(false, true);
++}
+
+-// If that failed, no need to go further, return failure
+-if (!curNode)
+-return 0;
++// We must find a leaf node here, either standalone or nested in the parenthesis
++if (!fReaderMgr-getName(bufToUse))
++{
++fScanner-emitError(XMLErrs::ExpectedElementName);
++return 0;
++}
+
+-if (curReader != fReaderMgr-getCurrentReaderNum() fScanner-getDoValidation())
+-fScanner-getValidator()-emitError(XMLValid::PartialMarkupInPE);
++//
++// Create a leaf node for it. If we can find the element id for
++// this element, then use it. Else, we have to fault in an element
++// decl, marked as created because of being in a content model.
++//
++XMLElementDecl* decl = fDTDGrammar-getElemDecl(fEmptyNamespaceId, 0, bufToUse.getRawBuffer(), Grammar::TOP_LEVEL_SCOPE);
++if (!decl)
++{
++decl = new (fGrammarPoolMemoryManager) DTDElementDecl
++(
++bufToUse.getRawBuffer()
++, fEmptyNamespaceId
++, DTDElementDecl::Any
++, fGrammarPoolMemoryManager
++);
++decl-setCreateReason(XMLElementDecl::InContentModel);
++decl-setExternalElemDeclaration(isReadingExternalEntity());
++fDTDGrammar-putElemDecl(decl);
+ }
+- else
++curNode = new (fGrammarPoolMemoryManager) ContentSpecNode
++(
++decl-getElementName()
++, fGrammarPoolMemoryManager
++);
++
++// Check for a PE ref
Re: xerces-c2-2.8.0-3+lenny1: permission to upload to stable
Adam D. Barratt a...@adam-barratt.org.uk wrote: On Sun, 2010-02-07 at 13:30 -0500, Jay Berkenbilt wrote: Adam D. Barratt a...@adam-barratt.org.uk wrote: Please prepare an update (built against stable, either on a stable system or in a chroot), and send a debdiff against the current stable package to debian-release for upload approval. Here it is. I have built the packages in a lenny chroot and have done light testing to ensure proper functionality. The packages are signed and ready to upload pending approval. Please go ahead. Done. Thanks. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
xerces-c2-2.8.0-3+lenny1: permission to upload to stable
The current xerces-c2 package, 2.8.0+deb1-2, contains a patch supplied by upstream to address CVE-2009-1885. The security team has deemed that this is not important enough for a DSA, and I agree. From Giuseppe Iuculano: the following CVE (Common Vulnerabilities Exposures) id was published for xerces-c2 and xerces27 some time ago. CVE-2009-1885[0]: | Stack consumption vulnerability in validators/DTD/DTDScanner.cpp in | Apache Xerces C++ 2.7.0 and 2.8.0 allows context-dependent attackers | to cause a denial of service (application crash) via vectors involving | nested parentheses and invalid byte values in simply nested DTD | structures, as demonstrated by the Codenomicon XML fuzzing framework. Unfortunately the vulnerability described above is not important enough to get it fixed via regular security update in Debian stable and oldstable. It does not warrant a DSA. However it would be nice if this could get fixed via a regular point update[1]. Please contact the release team for this. As it happens, the patch from 2.8.0+deb1-2 applies perfectly to the version in stable, so preparing an update to stable is trivial. With the permission of the release team, I will prepare the upload. I'm not sure what the best way to do this is. I can either prepare an upload to stable or I can supply a patch that can be applied to the version of the package in stable. I don't presently have a stable chroot to build in, though I can obviously make one to prepare the package if it would help. My changelog starts with this: xerces-c2 (2.8.0-3+lenny1) stable; urgency=low I also added the patch to the debian/patches directory after regenerating it (just to be sure) and changing its name based on the different packaging of the older version. [note to self: ~/tmp/xerces-c2-2.8.0-3+lenny1.patch] -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
does qpdf need a hint?
It looks like qpdf might need a hint to move to testing. The testing migration status is reporting that it's out of date because of the libqpdf1 binary package, but this package is no longer created by qpdf, which now creates libqpdf3. Funny...I don't remember this type of problem needing a manual push before. In any case, I'd be grateful if someone could look into why this isn't transitioning. I can't see any reason that it shouldn't. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
version screwup: any recourse besides epoch?
I screwed up and released tiff 3.9.0beta+deb1 to experimental earlier this week instead of 3.9.0~beta+deb1. Now I'd like to upload 3.9.0 to unstable. I really don't want to introduce an epoch. Is it possible to make 3.9.0beta+deb1 just disappear? It's never been anywhere but experimental, and it's only been there for two days. Otherwise, I'll have to think about whether to introduce an epoch or to just contort the version for this one release, like 3.9.0+final. I hate to use an epoch to fix a typo instead of to handle a genuine change to the version numbering scheme. Advice welcome. I'll delay my 3.9.0 upload a bit until I get an answer. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: version screwup: any recourse besides epoch?
Jay Berkenbilt q...@debian.org wrote: I screwed up and released tiff 3.9.0beta+deb1 to experimental earlier this week instead of 3.9.0~beta+deb1. Now I'd like to upload 3.9.0 to unstable. I really don't want to introduce an epoch. Is it possible to make 3.9.0beta+deb1 just disappear? It's never been anywhere but experimental, and it's only been there for two days. Otherwise, I'll have to think about whether to introduce an epoch or to just contort the version for this one release, like 3.9.0+final. I hate to use an epoch to fix a typo instead of to handle a genuine change to the version numbering scheme. Advice welcome. I'll delay my 3.9.0 upload a bit until I get an answer. Please disregard. I figured it out. I'm going to upload 3.9.0 to unstable, which will work fine because it's newer than 3.8.2. I'll upload 4.0.0beta3 to experimental which will clear out 3.9.0beta+deb1. Sorry for the noise. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: version screwup: any recourse besides epoch?
Andreas Metzler ametz...@downhill.at.eu.org wrote: On 2009-08-21 Jay Berkenbilt q...@debian.org wrote: Jay Berkenbilt q...@debian.org wVrote: I screwed up and released tiff 3.9.0beta+deb1 to experimental earlier this week instead of 3.9.0~beta+deb1. Now I'd like to upload 3.9.0 to [...] I'll upload 4.0.0beta3 to experimental which will clear out 3.9.0beta+deb1. 4.0.0~beta3 I guess ;-) cu andreas Yes. Of course. ;-) -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: scheduling ICU 4.2 transition
I have uploaded ICU 4.2.1 to unstable. Once it builds, it should be possible to initiate rebuilds of its reverse dependencies. Thanks. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: scheduling ICU 4.2 transition
Luk Claes l...@debian.org wrote: Please upload now. Great, glad we're ready. However, I'm getting ready to be gone without email access for a week, and I have an RC bugfix in ICU 4.0.1 unstable waiting to transition. I wouldn't want to introduce a new problem while I'm not here to deal with it or possibly leave an RC buggy version of 4.0.1 sitting in squeeze for however long the transition takes. Hopefully in one week when I get back, it will still be a good time. I will plan on uploading then unless I hear otherwise. Thanks! --Jay -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
scheduling ICU 4.2 transition
It's now been a full month since my first message about scheduling an ICU 4.2 transition, and I have still not done an upload to unstable because I am still waiting for a response. Again, with the utmost respect and admiration for the hard work being done by the release team, I think the new policy of coordinating library transitions won't work if the response time is so long. Perhaps I'm misunderstanding the policy and I should just upload to unstable? To save you from reading the earlier thread, I'd like to upload ICU 4.2.1 to unstable. It is source-compatible but not binary-compatible with ICU 4.0. The packages are structured so that binary NMUs should be sufficient for the vast majority of reverse dependencies. The most prominent reverse dependency, openoffice.org, is already okay with the upload. The final 4.2.1 release is identical to 4.2.1~rc3 currently in experimental. Thanks. --Jay ---BeginMessage--- I sent the message below to debian-release 11 days ago requesting permission to upload ICU 4.2.1 to unstable. I understand and fully support the new policy of getting advance permission and trying to coordinate transitions, but I'm unsure of how long I should expect to wait before receiving a response one way or the other. The actual 4.2.1 differs from 4.2.1~rc1 in experimental by only one line of code and that line is inside of an #ifdef that only runs on Windows, so for our purposes, 4.2.1~rc1 in experimental is identical to 4.2.1. I'd still like to go ahead and get the transition going, but as per requests to debian-devel-announce, I intend to hold off my upload until I get confirmation from debian-release. Please cc me on any response as I am not subscribed to debian-release. (I did check the archives for responses before reposting.) Thanks for all you do to keep things moving. Please see this message as a gentle tug from someone who wants to cause as little disruption as possible rather than as a complaint or criticism. -- Jay Berkenbilt q...@debian.org Jay Berkenbilt q...@debian.org wrote: I'd like to get a place in line for doing a transition to ICU 4.2. I realize there are other transitions going on right now, but I'd be interested in an ETA. I believe the ICU 4.0 transition worked just with binary NMUs, but I also seem to recall that it was forced into testing early. Also, openoffice.org previously reported that it worked with 4.2. In any case, I won't upload to unstable before I hear back from the release team. I'll be uploading 4.2.1 to experimental in the mean time unless you say, yeah, go ahead and upload to unstable. :-) ---End Message---
Re: scheduling ICU 4.2 transition
Philipp Kern pk...@debian.org wrote: It's now been a full month since my first message about scheduling an ICU 4.2 transition, and I have still not done an upload to unstable because I am still waiting for a response. Again, with the utmost respect and admiration for the hard work being done by the release team, I think the new policy of coordinating library transitions won't work if the response time is so long. Perhaps I'm misunderstanding the policy and I should just upload to unstable? Please hold off if possible. We are currently blocked with britney (the testing migration tool) not coping with the vast amount of to-be-migrated packages. We hope to resolve this issue soon. However I agree that you should've get a reply. We are a bit understaffed and that britney runs in circles currently really doesn't help. Thank you for the response. I will hold off. Should I check in again in a few weeks, or is there something specific I should be monitoring before I check in again? If there is a specific package or group of packages that should migrate before I ask again, I'll just check the status of those and not ask again until they are through. Thanks! --Jay -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: scheduling ICU 4.2 transition
I sent the message below to debian-release 11 days ago requesting permission to upload ICU 4.2.1 to unstable. I understand and fully support the new policy of getting advance permission and trying to coordinate transitions, but I'm unsure of how long I should expect to wait before receiving a response one way or the other. The actual 4.2.1 differs from 4.2.1~rc1 in experimental by only one line of code and that line is inside of an #ifdef that only runs on Windows, so for our purposes, 4.2.1~rc1 in experimental is identical to 4.2.1. I'd still like to go ahead and get the transition going, but as per requests to debian-devel-announce, I intend to hold off my upload until I get confirmation from debian-release. Please cc me on any response as I am not subscribed to debian-release. (I did check the archives for responses before reposting.) Thanks for all you do to keep things moving. Please see this message as a gentle tug from someone who wants to cause as little disruption as possible rather than as a complaint or criticism. -- Jay Berkenbilt q...@debian.org Jay Berkenbilt q...@debian.org wrote: I'd like to get a place in line for doing a transition to ICU 4.2. I realize there are other transitions going on right now, but I'd be interested in an ETA. I believe the ICU 4.0 transition worked just with binary NMUs, but I also seem to recall that it was forced into testing early. Also, openoffice.org previously reported that it worked with 4.2. In any case, I won't upload to unstable before I hear back from the release team. I'll be uploading 4.2.1 to experimental in the mean time unless you say, yeah, go ahead and upload to unstable. :-) -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: scheduling ICU 4.2 transition
Rene Engelhard r...@debian.org wrote: Hi, Jay Berkenbilt wrote: permission to upload ICU 4.2.1 to unstable. I understand and fully support the new policy of getting advance permission and trying to coordinate transitions, but I'm unsure of how long I should expect to wait before receiving a response one way or the other. I am not from the RT.. The actual 4.2.1 differs from 4.2.1~rc1 in experimental by only one line of code and that line is inside of an #ifdef that only runs on Windows, so for our purposes, 4.2.1~rc1 in experimental is identical to 4.2.1. I'd still like to go ahead and get the transition going, but as per requests to debian-devel-announce, I intend to hold off my upload until I get confirmation from debian-release. ... but a transition to ICU 4.2 involcing bin-NMUs would disrupt the suitesparse transition which afaics is nearly ready and just needs some hinting/forcing by the RT. After this, *in my opinion* there shouldn't be a problem, but that of course is no official statement by the RT :() Grüße/Regards, René Regardless, I consider renewed input from openoffice maintainers essential before any potentially disruptive upload, so your input is useful to me and hopefully also to the release team. I'll be on pseudo-vacation from 7/17 until maybe 7/24 or so, so I probably would want to wait until after then anyway. I'll of course still wait for the release team before acting. Thanks. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
excuses.php is confused about ICU
(Release team: ICU 4.0.1-3 might need a hint to transition to testing once its 10 days are up...see below for details.) Whatever excuses.php calls (update-excuses?) is confused about RC bug 530568, reported against the experimental version of ICU. It now seems to think that transitioning ICU to testing will introduce this bug, but this bug does not apply to the unstable version. Maybe the confusion is because the unstable version is newer in time than the experimental version, but I haven't looked at the code. Here is an abbreviated chronology: 1. 2009-05-25: RC bug 530568 was reported against ICU 4.2-1 (experimental) 2. 2009-06-27: Version 4.0.1-3 uploaded to unstable 3. 2009-06-28: bug 530568 closed for version 4.2.1~rc1-3 (experimental) and also explicitly marked notfound in 4.0.1-3 http://qa.debian.org/excuses.php?package=icu reports Excuse for icu * Too young, only 4 of 10 days old * icu (source) has new bugs! * Updating icu introduces new bugs: #530568 * Not considered In fact, updating ICU does not introduce new RC bugs. I imagine that there is either a problem in the excuses code or that I have done something wrong with respect to telling the BTS which versions of the package contain this bug. It seems to me that the logic should be that, if a bug applies to version X, it should apply automatically to version Y if Y X, not if Y was uploaded more recently than X. But I'm only guessing about the age anyway since I haven't looked at the code. If it makes a difference, I closed the bug manually with a -done message that contained a Version: pseudo header because I accidentally put the wrong bug number in the ChangeLog. But I think I sent my done message correctly, and the BTS seems to have an accurate idea of which versions contain the bug. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
scheduling ICU 4.2 transition
I'd like to get a place in line for doing a transition to ICU 4.2. I realize there are other transitions going on right now, but I'd be interested in an ETA. I believe the ICU 4.0 transition worked just with binary NMUs, but I also seem to recall that it was forced into testing early. Also, openoffice.org previously reported that it worked with 4.2. In any case, I won't upload to unstable before I hear back from the release team. I'll be uploading 4.2.1 to experimental in the mean time unless you say, yeah, go ahead and upload to unstable. :-) -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: excuses.php is confused about ICU
Adam D. Barratt a...@adam-barratt.org.uk wrote: The BTS's version tracking is based on upload history as laid out in the package's changelog, not version nor date comparisons. The changelog for icu 4.0.1-3 (unstable) included the entries for the 4.2-1 upload to experimental . . . Okay, thanks for the explanation. When I have interleaved versions between unstable and experimental, I always put things in chronological order in the newer version's ChangeLog so I eventually have an unabridged, chronological history. My habit of doing this was based on a discussion on debian-devel years ago (maybe 2004 or 2005). Perhaps I'll switch to doing it based on version ordering instead if it will make the right thing more likely to happen. The full version diagram suggests that BTS is aware of the branches created at stable releases but not necessarily unstable vs. experimental. Adam D. Barratt a...@adam-barratt.org.uk wrote: The simplest solution in this case is to mark the bug as fixed in 4.0.1-3 as well and then as found in 4.2.1~rc1-1. It's not correct but will convince the BTS that 4.2.1 and 4.2.1~rc1-[12] contain the bug but 4.0.1-3 does not. Makes sense, given the explanation. I'll go ahead and do this. (For reference, notfound does not indicate to the BTS that a particular package version does not contain a bug; it removes the version from the explicit list of versions known to be affected, but the rules mentioned above regarding changelog ordering still apply). Yes, I see that now. Thanks! --Jay -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
xerces-c2 out of date on mips for no apparent reason?
PTS (http://packages.qa.debian.org/x/xerces-c2.html) reports that the xerces-c2 package is out of date on mips. However, the build logs (https://buildd.debian.org/pkg.cgi?pkg=xerces-c2) indicate that the package was successfully built on June 12 but was never installed. Starting today, this will prevent xerces-c2 from transitioning. Hopefully someone can poke this to resolve the problem. Thanks. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ICU 4.2 in experimental
Rene Engelhard r...@debian.org wrote: Rene Engelhard wrote: Jay Berkenbilt wrote: I have just uploaded ICU 4.2 in experimental. As is generally the case, this release of ICU is expected to be source-compatible with earlier versions, including 4.0 which is currently in unstable. It will have to clear NEW, but once it does, you may wish to test your packages against the new version of ICU. Once it does clear NEW, I will send email to debian-devel mentioning that it is there. I will work with debian-release to schedule a transition to ICU 4.2 once I have received confirmation from the Open Office people that they are ready. Most likely, everyone else will get by with just an binary NMU. Well, assuming OOo builds (which it seems it does, it at least passed the place where it does heavy stuff with icu at build time) it can be bin-NMUed, too.. Need to check whether it works, though... Needed a fix in the Lotus Word Pro filter nevertheless, no idea why it broke right now with icu 4.2 and not before but the file does include unicode/timezone.h. Anyway, fixed. (LONG_MAX self-defined as const instead of using limits.h Means: we'll need OOo = 3.0.1-5 to build against ICU 4.2 Thanks for the quick turnaround on testing. I have no problem with ICU 4.2 being behind OOo 3.1.0 if that's what you and the release team decide. At the moment, ICU 4.2 is failing to build on most architectures because of a library on which ranlib was not run. Some architectures, like i386, don't care, but most do. I've already reported to upstream. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
