Re: Bits from the Release Team: ride like the wind, Bullseye!
Le 07/07/2019 à 03:47, Jonathan Wiltshire a écrit : > No binary maintainer uploads for bullseye > = > > The release of buster also means the bullseye release cycle is about to begin. > From now on, we will no longer allow binaries uploaded by maintainers to > migrate to testing. This means that you will need to do source-only uploads if > you want them to reach bullseye. > > > Q: I already did a binary upload, do I need to do a new (source-only) > upload? > A: Yes (preferably with other changes, not just a version bump). > > Q: I needed to do a binary upload because my upload went to the NEW queue, > do I need to do a new (source-only) upload for it to reach bullseye? > A: Yes. We also suggest going through NEW in experimental instead of > unstable > where possible, to avoid disruption in unstable. > > Q: Does this also apply to contrib and non-free? > A: No. Not all packages in contrib and non-free can be built on the buildds, > so maintainer uploads will still be allowed to migrate for packages > outside main. Q: BinNMUs of packages uploaded before this new policy that have arch:all binaries can no longer migrate to testing. Is that intentional? See for example ocaml-migrate-parsetree/amd64 (there are others). This will make transitions that involve lots of binNMUs (such as OCaml-related ones) much harder. For example, there is one such ongoing (mini-)transition involving ocaml-migrate-parsetree, 26 other binNMUed packages, and 7 updated packages. It will be delayed by the time to upload all these binNMUed package and their aging. Meanwhile, this transition may become bigger and longer as people unaware of this update their OCaml-related packages. Is there a public API to query the built-on-buildd flag for a given binary package? Cheers, -- Stéphane Please CC: me or debian-ocaml-maint on reply
Bug#933685: transition: http-parser
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hello, following the procedures as written in the Debian wiki, I am requesting a transition slot for the http-parser library 2.9.2, accepted in experimental earlier today. A test rebuild of all the the packages listed at the transition page¹ result in one failure: * python-httptools 0.0.11-1 Bug report with upstream fix filed as #933684 All other packages passed: * jabberd2 2.7.0-1 * libgit2 0.27.7+dfsg.1-0.2 * ocserv 0.12.2-3 * purple-matrix 0.0.0+git20180325-1 * ruby-http-parser.rb 0.6.0-4 * tang 7-1 * tcpflow 1.5.2+repack1-1 Kind regards, Christoph ¹ https://release.debian.org/transitions/html/auto-http-parser.html Ben file: title = "http-parser"; is_affected = .depends ~ /\b(libhttp\-parser2\.8)\b/ | .depends ~ /\b(libhttp\-parser2\.9)\b/; is_good = .depends ~ /\b(libhttp\-parser2\.9)\b/; is_bad = .depends ~ /\b(libhttp\-parser2\.8)\b/; signature.asc Description: PGP signature
Bug#933672: transition: cfitsio
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition I would like to request a transition slot for cfitsio, changing the library name from libcfitsio7 to libcfitsio8. The API has only been extended, not changed, so I don't expect any big issue. Due to a mistake on my side with sbuild, I wrongly uploaded the package to sid instead of experimental. The distribution in the changelog is experimental, but the one in the changes file is sid... Sorry about that. If it is not possible to proceed with the transition in the next days, I'll just reupload the previous version with +really to sid. Ben file: title = "cfitsio"; is_affected = .depends ~ "libcfitsio7" | .depends ~ "libcfitsio8"; is_good = .depends ~ "libcfitsio8"; is_bad = .depends ~ "libcfitsio7"; -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64)
Bug#933653: stretch-pu: package libconvert-units-perl/0.43-11~deb9u1
Package: release.debian.org Severity: normal Tags: stretch User: release.debian@packages.debian.org Usertags: pu This is a no-change rebuild to bump the version number in order to avoid reusing a pre-epoch version number. Andreas diff -Nru libconvert-units-perl-0.43/debian/changelog libconvert-units-perl-0.43/debian/changelog --- libconvert-units-perl-0.43/debian/changelog 2015-07-21 22:16:26.0 +0200 +++ libconvert-units-perl-0.43/debian/changelog 2019-08-01 14:50:24.0 +0200 @@ -1,3 +1,20 @@ +libconvert-units-perl (1:0.43-11~deb9u1) stretch; urgency=medium + + * Non-maintainer upload. + * Rebuild for stretch. + + -- Andreas Beckmann Thu, 01 Aug 2019 14:50:24 +0200 + +libconvert-units-perl (1:0.43-11) unstable; urgency=medium + + * Team upload. + * Re-upload with version bumped to 1:0.43-11 in order to avoid filename +clashes between 1:0.43-2 and the pre-epoch 0.43-2 version. +Thanks: Andreas Beckmann for the bug report. +Closes: #929615 + + -- gregor herrmann Tue, 28 May 2019 23:00:33 +0200 + libconvert-units-perl (1:0.43-2) unstable; urgency=low [ Damyan Ivanov ]
Bug#933651: stretch-pu: package t-digest/3.0-1+deb9u1
Package: release.debian.org Severity: normal Tags: stretch User: release.debian@packages.debian.org Usertags: pu This is a no-change rebuild to bump the version number in order to avoid reusing a pre-epoch version number. Andreas diff -Nru t-digest-3.0/debian/changelog t-digest-3.0/debian/changelog --- t-digest-3.0/debian/changelog 2015-05-11 04:13:48.0 +0200 +++ t-digest-3.0/debian/changelog 2019-08-01 14:26:46.0 +0200 @@ -1,3 +1,11 @@ +t-digest (1:3.0-1+deb9u1) stretch; urgency=medium + + * Non-maintainer upload. + * No-change rebuild to avoid reuse of pre-epoch version 3.0-1 +(Closes: #929618) + + -- Andreas Beckmann Thu, 01 Aug 2019 14:26:46 +0200 + t-digest (1:3.0-1) unstable; urgency=medium * Reverted to t-digest 3.0 because 3.1 had introduced grave API/ABI
Bug#933645: transition: libvpx
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, libvpx6 is ABI incompatible with libvpx5. libvpx6 is ready in experimental. Thanks for transition. Ben file: title = "libvpx"; is_affected = .depends ~ "libvpx5" | .depends ~ "libvpx6"; is_good = .depends ~ "libvpx6"; is_bad = .depends ~ "libvpx5"; -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE=cs_CZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#933636: stretch-pu: package pdfresurrect/0.12-6
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
I'd like to fix a buffer overflow in the pdfresurrect version that's in
stretch.
See https://security-tracker.debian.org/tracker/CVE-2019-14267.
Attached is the debdiff.
Francois
diff -Nru pdfresurrect-0.12/debian/changelog pdfresurrect-0.12/debian/changelog
--- pdfresurrect-0.12/debian/changelog 2015-09-13 18:30:02.0 -0700
+++ pdfresurrect-0.12/debian/changelog 2019-07-30 08:54:01.0 -0700
@@ -1,3 +1,9 @@
+pdfresurrect (0.12-6+deb9u1) stretch; urgency=high
+
+ * Fix buffer overflow (CVE-2019-14267).
+
+ -- Francois Marier Tue, 30 Jul 2019 08:54:01 -0700
+
pdfresurrect (0.12-6) unstable; urgency=medium
* Run wrap-and-sort
diff -Nru pdfresurrect-0.12/debian/patches/CVE-2019-14267.patch pdfresurrect-0.12/debian/patches/CVE-2019-14267.patch
--- pdfresurrect-0.12/debian/patches/CVE-2019-14267.patch 1969-12-31 16:00:00.0 -0800
+++ pdfresurrect-0.12/debian/patches/CVE-2019-14267.patch 2019-07-30 08:54:01.0 -0700
@@ -0,0 +1,47 @@
+commit 4ea7a6f4f51d0440da651d099247e2273f811dbc
+Author: Matt Davis
+Date: Thu Jul 25 20:30:04 2019 -0700
+Last-Update: 2019-07-30
+
+Prevent a buffer overflow in possibly corrupt PDFs.
+
+The startxref identification logic assumed a worse case of having to
+inspect 256 bytes. However, that is not always the case (e.g.,
+corrupted PDFs). This patch prevents that situation.
+
+This bug was identified by j0lamma. Thanks!
+
+CVE-2019-14267
+
+diff --git a/main.c b/main.c
+index d274acc..18ba696 100644
+--- a/main.c
b/main.c
+@@ -230,7 +230,10 @@ static pdf_t *init_pdf(FILE *fp, const char *name)
+
+ pdf = pdf_new(name);
+ pdf_get_version(fp, pdf);
+-pdf_load_xrefs(fp, pdf);
++if (pdf_load_xrefs(fp, pdf) == -1) {
++ pdf_delete(pdf);
++ return NULL;
++}
+ pdf_load_pages_kids(fp, pdf);
+
+ return pdf;
+diff --git a/pdf.c b/pdf.c
+index 27b09a1..b671537 100644
+--- a/pdf.c
b/pdf.c
+@@ -210,6 +210,11 @@ int pdf_load_xrefs(FILE *fp, pdf_t *pdf)
+ fseek(fp, pos - (++pos_count), SEEK_SET);
+
+ /* Suck in end of "startxref" to start of %%EOF */
++if (pos_count >= sizeof(buf)) {
++ ERR("Failed to locate the startxref token. "
++ "This might be a corrupt PDF.\n");
++ return -1;
++}
+ memset(buf, 0, sizeof(buf));
+ fread(buf, 1, pos_count, fp);
+ c = buf;
diff -Nru pdfresurrect-0.12/debian/patches/series pdfresurrect-0.12/debian/patches/series
--- pdfresurrect-0.12/debian/patches/series 2015-09-13 18:30:02.0 -0700
+++ pdfresurrect-0.12/debian/patches/series 2019-07-30 08:54:01.0 -0700
@@ -1 +1,2 @@
fix_manpage_path.patch
+CVE-2019-14267.patch
Bug#933637: buster-pu: package pdfresurrect/0.15-2
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
I'd like to fix a buffer overflow in the pdfresurrect version that's in
buster.
See https://security-tracker.debian.org/tracker/CVE-2019-14267.
Attached is the debdiff.
Francois
diff -Nru pdfresurrect-0.15/debian/changelog pdfresurrect-0.15/debian/changelog
--- pdfresurrect-0.15/debian/changelog 2019-03-01 23:12:55.0 -0800
+++ pdfresurrect-0.15/debian/changelog 2019-07-30 08:41:35.0 -0700
@@ -1,3 +1,9 @@
+pdfresurrect (0.15-2+deb10u1) buster; urgency=high
+
+ * Fix buffer overflow (CVE-2019-14267).
+
+ -- Francois Marier Tue, 30 Jul 2019 08:41:35 -0700
+
pdfresurrect (0.15-2) unstable; urgency=medium
* Bump Standars-Version up to 4.3.0
diff -Nru pdfresurrect-0.15/debian/patches/CVE-2019-14267.patch pdfresurrect-0.15/debian/patches/CVE-2019-14267.patch
--- pdfresurrect-0.15/debian/patches/CVE-2019-14267.patch 1969-12-31 16:00:00.0 -0800
+++ pdfresurrect-0.15/debian/patches/CVE-2019-14267.patch 2019-07-30 08:41:35.0 -0700
@@ -0,0 +1,46 @@
+commit 4ea7a6f4f51d0440da651d099247e2273f811dbc
+Author: Matt Davis
+Date: Thu Jul 25 20:30:04 2019 -0700
+
+Prevent a buffer overflow in possibly corrupt PDFs.
+
+The startxref identification logic assumed a worse case of having to
+inspect 256 bytes. However, that is not always the case (e.g.,
+corrupted PDFs). This patch prevents that situation.
+
+This bug was identified by j0lamma. Thanks!
+
+CVE-2019-14267
+
+diff --git a/main.c b/main.c
+index d604613..de2f8e9 100644
+--- a/main.c
b/main.c
+@@ -203,7 +203,10 @@ static pdf_t *init_pdf(FILE *fp, const char *name)
+
+ pdf = pdf_new(name);
+ pdf_get_version(fp, pdf);
+-pdf_load_xrefs(fp, pdf);
++if (pdf_load_xrefs(fp, pdf) == -1) {
++ pdf_delete(pdf);
++ return NULL;
++}
+ pdf_load_pages_kids(fp, pdf);
+
+ return pdf;
+diff --git a/pdf.c b/pdf.c
+index 4cd7f12..b23b50a 100644
+--- a/pdf.c
b/pdf.c
+@@ -233,6 +233,11 @@ int pdf_load_xrefs(FILE *fp, pdf_t *pdf)
+ fseek(fp, pos - (++pos_count), SEEK_SET);
+
+ /* Suck in end of "startxref" to start of %%EOF */
++if (pos_count >= sizeof(buf)) {
++ ERR("Failed to locate the startxref token. "
++ "This might be a corrupt PDF.\n");
++ return -1;
++}
+ memset(buf, 0, sizeof(buf));
+ SAFE_E(fread(buf, 1, pos_count, fp), pos_count,
+"Failed to read startxref.\n");
diff -Nru pdfresurrect-0.15/debian/patches/series pdfresurrect-0.15/debian/patches/series
--- pdfresurrect-0.15/debian/patches/series 1969-12-31 16:00:00.0 -0800
+++ pdfresurrect-0.15/debian/patches/series 2019-07-30 08:41:35.0 -0700
@@ -0,0 +1 @@
+CVE-2019-14267.patch
Parking Euratechnologies
View this email in your browser / VERSION FRANÇAISE Tijdelijke actie: Zomerpromotie! Waarom is investeren in parkings interessant? Weinig onderhoud - Gegarandeerde huurinkomsten! Investeren in parkeerplaatsen onderscheidt zich van het investeren in andere onroerende goederen doordat betalingsproblemen, huurachterstand, schade en leegstand niet voorkomen. Een parkeerplaats, dat is immers slechts enkele lijnen op de grond en een slagboom. **Makkelijk toch?** * Profiteer van de stijgende parkeertarieven * Geen zorgen dankzij de professionele uitbating * 38.2% winststijging behaald in 2018! * Gegarandeerde huurinkomsten Wilt u meegenieten van deze unieke opportuniteit? VRAAG HIER VRIJBLIJVEND MEER INFORMATIE Geldig tot 31/08/2019 http://creadomus.acemlnc.com/lt.php?s=aad4c2688298a7ecdef3a2dcd95ba996=63A145A41A275 http://creadomus.acemlnc.com/lt.php?s=aad4c2688298a7ecdef3a2dcd95ba996=63A145A41A276 http://creadomus.acemlnc.com/lt.php?s=aad4c2688298a7ecdef3a2dcd95ba996=63A145A41A274 mailto:market...@creadomus.be If you would like to be removed from our mailing list, click here to unsubscribe Creadomus , Kortrijksesteenweg 1041, 9051 Gent, Belgium
Bug#903211: Checking for removal of BD [was Re: release.debian.org: How to handle unbuildable packages in buster]
Paul Gevers: > Hi all, > > On Thu, 09 Aug 2018 09:32:00 + Niels Thykier wrote: >> 3) Build-Depends are not enforced on removal. That is packages >> /can/ be removed while packages are build depending on them. >> >> Limitation 2+3 are slightly more involved and may take quite a while for >> us to implement. > > Seems like this is really in need of attention. [...] > Ack. > I may be saying something stupid, but shouldn't the build-depends not > *just* be added to the depends in the migration phase? Or is that still > quite involved due to -arch/-indep? > > Paul > The migration phase never concerned itself with source packages (if you are thinking of the is_installable check). And adding Build-Depends(-Indep|-Arch) to a random binary of the source would have its own issues - notably, a binary is not required to be co-installable with its source's build-depends. It is not that it is impossible, it is just a question of spoons, time and test cases. If you have any trivial test cases, please by all means begin to collect/commit them (it makes life so much easier later). Thanks, ~Niels
