Bug#866389: transition: perl 5.26
On Thu, Jul 20, 2017 at 5:04 AM, gregor herrmann wrote: > #867213: syslog-ng-incubator: one rdep (syslog-ng). No reaction on > the bug report, unrelated build failure; I guess syslog-ng* > can be removed from testing if noone fixes the problem in > time. I'd like to point out that DSA relies on syslog-ng on debian.org hosts, so it would be appreciated if the issues could be fixed or worked around rather than removing syslog-ng from buster. Of course buster is not in use on any debian.org hosts yet. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#868722: transition: notmuch
Emilio Pozuelo Monfort writes: > > Up to you what happens with notmuch-addrlookup, as long as it gets fixed. With > that said, you can go ahead. > I have uploaded an NMU of notmuch-addrlookup to delayed/5
Bug#866389: transition: perl 5.26
On Fri, 14 Jul 2017 22:52:49 +0300, Niko Tyni wrote: > On Fri, Jul 14, 2017 at 10:50:16AM +0200, Emilio Pozuelo Monfort wrote: > > > > Thanks. Please go ahead and bump them to severity:serious as we are close to > > doing this. > > Thanks, done. Update re blocking bugs: In a couple of hours the last 4 NMUs will leave DELAYED. The remaining buggy packages, already targetted for auto-removal, then are: #826473: kdesrc-build: no rdepends, can be removed from testing (or maybe even from the archive, according to the bug log). #867213: syslog-ng-incubator: one rdep (syslog-ng). No reaction on the bug report, unrelated build failure; I guess syslog-ng* can be removed from testing if noone fixes the problem in time. So I think from the point of view of blockers we are basically ready. Cheers, gregor -- .''`. https://info.comodo.priv.at/ - Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- signature.asc Description: Digital Signature
Bug#867814: stretch-pu: package ncurses/6.0+20161126-1+deb9u1
Control: tags -1 - moreinfo On 2017-07-15 12:50 +0200, Sven Joachim wrote: > Control: tags -1 - confirmed > Control: tags -1 + moreinfo > > On 2017-07-15 11:04 +0100, Adam D. Barratt wrote: > >> Control: tags -1 + confirmed d-i >> >> On Sun, 2017-07-09 at 19:30 +0200, Sven Joachim wrote: >>> Recently a few flaws in the tic program and the tic library have been >>> detected: null pointer dereference, buffer overflow, stack smashing, you >>> name it. Six bugs have been reported in the Red Hat bugtracker and four >>> CVEs assigned. Fortunately there are rather few users who would run >>> affected programs at all, so it was decided that no DSA would be >>> necessary. > > Unfortunately the fixes have caused a regression in infocmp, see > #868266. I expect an upstream fix this night, but to properly test it > and prepare new packages taking a bit more time seems advisable. So I > guess we'll have to defer that for 9.2. The changes from the 20170715 patchlevel were a bit larger than I would have liked, but applied with minimal tweaking to the stretch version. Running "infocmp -C" on all the terminfo files in ncurses-{base,term} showed no difference compared to the infocmp version currently in stretch. >> I'd be okay with this, but it will need a kibi-ack due to the udeb. > > The changes do not touch the tinfo library which is all that shipped in > the udeb. To elaborate on that, ncurses/tinfo/{alloc,parse}_entry.c are compiled into the tic library while progs/dump_entry.c is for the infocmp and tic programs. Building 6.0+20161126-1 and 6.0+20161126-1+deb9u1 in a stretch chroot produced identical libtinfo.so.5.9 files. Cheers, Sven --- ncurses-6.0+20161126/debian/changelog 2016-11-29 21:19:08.0 +0100 +++ ncurses-6.0+20161126/debian/changelog 2017-07-17 20:47:58.0 +0200 @@ -1,3 +1,13 @@ +ncurses (6.0+20161126-1+deb9u1) stretch; urgency=medium + + * Cherry-pick upstream fixes from the 20170701 and 20170708 patchlevels +for various crash bugs in the tic library and the tic binary +(CVE-2017-10684, CVE-2017-10685, CVE-2017-2, CVE-2017-3). + * Backport termcap-format fix from the 20170715 patchlevel, repairing a +regression from the above security fixes (see #868266). + + -- Sven Joachim Mon, 17 Jul 2017 20:47:58 +0200 + ncurses (6.0+20161126-1) unstable; urgency=low * New upstream patchlevel. diff -Nru ncurses-6.0+20161126/debian/patches/cve-fixes.diff ncurses-6.0+20161126/debian/patches/cve-fixes.diff --- ncurses-6.0+20161126/debian/patches/cve-fixes.diff 1970-01-01 01:00:00.0 +0100 +++ ncurses-6.0+20161126/debian/patches/cve-fixes.diff 2017-07-17 20:47:58.0 +0200 @@ -0,0 +1,185 @@ +Author: Sven Joachim +Description: Fixes for four CVEs + Fixes for CVE 2017-10684, CVE-2017-10685, CVE-2017-2, + CVE-2017-3 cherry-picked from upstream patchlevels 20170701 and + 20170708. +Bug-RedHat: https://bugzilla.redhat.com/show_bug.cgi?id=1464684 +Bug-RedHat: https://bugzilla.redhat.com/show_bug.cgi?id=1464685 +Bug-RedHat: https://bugzilla.redhat.com/show_bug.cgi?id=1464686 +Bug-RedHat: https://bugzilla.redhat.com/show_bug.cgi?id=1464687 +Bug-RedHat: https://bugzilla.redhat.com/show_bug.cgi?id=1464691 +Bug-RedHat: https://bugzilla.redhat.com/show_bug.cgi?id=1464692 +Forwarded: not-needed +Last-Update: 2017-07-09 + +--- + ncurses/tinfo/alloc_entry.c |6 +- + ncurses/tinfo/parse_entry.c | 22 -- + progs/dump_entry.c | 34 +- + 3 files changed, 38 insertions(+), 24 deletions(-) + +--- a/ncurses/tinfo/alloc_entry.c b/ncurses/tinfo/alloc_entry.c +@@ -96,7 +96,11 @@ _nc_save_str(const char *const string) + { + char *result = 0; + size_t old_next_free = next_free; +-size_t len = strlen(string) + 1; ++size_t len; ++ ++if (string == 0) ++ return _nc_save_str(""); ++len = strlen(string) + 1; + + if (len == 1 && next_free != 0) { + /* +--- a/ncurses/tinfo/parse_entry.c b/ncurses/tinfo/parse_entry.c +@@ -236,13 +236,14 @@ _nc_parse_entry(struct entry *entryp, in + * implemented it. Note that the resulting terminal type was never the + * 2-character name, but was instead the first alias after that. + */ ++#define ok_TC2(s) (isgraph(UChar(s)) && (s) != '|') + ptr = _nc_curr_token.tk_name; + if (_nc_syntax == SYN_TERMCAP + #if NCURSES_XNAMES + && !_nc_user_definable + #endif + ) { +- if (ptr[2] == '|') { ++ if (ok_TC2(ptr[0]) && ok_TC2(ptr[1]) && (ptr[2] == '|')) { + ptr += 3; + _nc_curr_token.tk_name[2] = '\0'; + } +@@ -284,9 +285,11 @@ _nc_parse_entry(struct entry *entryp, in + if (is_use || is_tc) { + entryp->uses[entryp->nuses].name = _nc_save_str(_nc_curr_token.tk_valstring); + entryp->uses[entryp->nuses].line = _nc_curr_line; +- entryp->nuses++; +- if (entryp->nuses > 1 && is_tc) { +- BAD_TC_USAGE ++ if (VALID_STRING(entryp->uses[entryp->nuses].name)) { ++ entryp->nuses++; ++ if (en
Processed: Re: Bug#867814: stretch-pu: package ncurses/6.0+20161126-1+deb9u1
Processing control commands: > tags -1 - moreinfo Bug #867814 [release.debian.org] stretch-pu: package ncurses/6.0+20161126-1+deb9u1 Removed tag(s) moreinfo. -- 867814: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867814 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#867461: Bug#858539: should ca-certificates certdata.txt synchronize across all suites?
On 2017-07-19 11:35:56, Michael Shuler wrote: > On 07/06/2017 11:13 PM, Paul Wise wrote: >> On Fri, Jul 7, 2017 at 2:01 AM, Antoine Beaupré wrote: >> >>> For what it's worth, my opinion is that we should attempt to synchronize >>> certdata.txt (and blacklist.txt, for that matter) across all suites (but >>> not other changes to the packaging). This would remove another decision >>> point in our infrastructure and ensure harmonious X509 processing across >>> suites. >> >> I would like to see that happen too. > > I spent a few sessions over the past few days getting the mozilla bundle > 2.14 committed to all the suite branches wheezy and newer. I have some > more verification to work on and I'll get some packages rolled up and > tested for all the suites. > > I appreciate the notes here! Thanks! let us know if you need help with the LTS bits. a. -- On reconnait la grandeur et la valeur d'une nation à la façon dont celle-ci traite ses animaux. - Mahatma Gandhi
Bug#867461: Bug#858539: should ca-certificates certdata.txt synchronize across all suites?
On 07/06/2017 11:13 PM, Paul Wise wrote: > On Fri, Jul 7, 2017 at 2:01 AM, Antoine Beaupré wrote: > >> For what it's worth, my opinion is that we should attempt to synchronize >> certdata.txt (and blacklist.txt, for that matter) across all suites (but >> not other changes to the packaging). This would remove another decision >> point in our infrastructure and ensure harmonious X509 processing across >> suites. > > I would like to see that happen too. I spent a few sessions over the past few days getting the mozilla bundle 2.14 committed to all the suite branches wheezy and newer. I have some more verification to work on and I'll get some packages rolled up and tested for all the suites. I appreciate the notes here! -- Kind regards, Michael
Bug#868355: nmu: ceres-solver_1.12.0+dfsg0-1+b3
Hi all, well, I would prefer to rebuild all reverse dependencies after each new eigen3 (and probably any other header-only lib) upload [1] and be ready to request it. But it looks like it is not a common case to do such BinNMUs. [1] https://bugs.debian.org/845819 Regards Anton 2017-07-19 8:35 GMT+02:00 Philipp Huebner : > Hi, > > until I find the time to package the new release of Ceres Solver, > please go ahead with the BinNMU. > > With Eigen3 being a header-only library and numeric math libraries > making use of derivatives and templating like crazy, I believe this > strict Eigen3 check to be well reasoned. > > I'll ask upstream about this, but expect them to confirm it. > > > Regards, > -- > .''`. Philipp Huebner > : :' : pgp fp: 6719 25C5 B8CD E74A 5225 3DF9 E5CA 8C49 25E4 205F > `. `'` > `- >