Bug#1036811: bullseye-pu: package ncurses/6.2+20201114-2+deb11u2
On 2023-07-24 18:37 +0100, Jonathan Wiltshire wrote: > Control: tag -1 confirmed > > On Fri, May 26, 2023 at 08:51:55PM +0200, Sven Joachim wrote: >> I would like to address CVE-2023-29491[1] aka bug #1034372[2] in >> Bullseye. The changes are the same as in version 6.4-3 (see >> #1035351[3]), except that there is no need to patch configure.in this >> time. > > Please go ahead. Thanks, uploaded. Cheers, Sven
Bug#1036811: bullseye-pu: package ncurses/6.2+20201114-2+deb11u2
On 2023-07-23 14:12 +0100, Jonathan Wiltshire wrote:
> Control: tag -1 moreinfo
>
> On Fri, May 26, 2023 at 08:51:55PM +0200, Sven Joachim wrote:
>> [ Risks ]
>> Users who are relying on their own terminfo files under
>> ${HOME}/.terminfo can no longer use them in setuid/setgid programs and
>> will have to work around that, e.g. by changing their TERM environment
>> variable, using a different terminal emulator or asking their sysadmin
>> for help.
>>
>> On my systems I did not find any setuid binaries linked to the tinfo
>> library, but some setgid games in the bsdgames package.
>
> Would a news entry highlighting this be appropriate?
Probably not, since the vast majority of users (at least 99%, more
likely 99.9%) will not be affected. The Bookworm version of ncurses
does not contain such a news entry either, and I have not heard of any
bug reports (just checked the bsdgames package) or support questions.
Cheers,
Sven
Bug#1036811: bullseye-pu: package ncurses/6.2+20201114-2+deb11u2
Package: release.debian.org
Severity: normal
Tags: bullseye d-i
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: ncur...@packages.debian.org, debian-b...@lists.debian.org
Control: affects -1 + src:ncurses
I would like to address CVE-2023-29491[1] aka bug #1034372[2] in
Bullseye. The changes are the same as in version 6.4-3 (see
#1035351[3]), except that there is no need to patch configure.in this
time.
[ Reason ]
Various memory corruption bugs exist when loading specifically crafted
terminfo database files. This is a security problem in programs running
with elevated privileges, as users are allowed to provide their own
terminfo files under ${HOME}/.terminfo or via the TERMINFO or
TERMINFO_DIRS environment variables.
Backporting the upstream fixes would be too intrusive (and has not been
attempted in Bookworm either), but via a configure option it is possible
to prevent setuid/setgid programs from loading custom terminfo files
supplied by the user, after which the bugs are no longer security
relevant.
[ Impact ]
Local users could try privilege escalations in setuid/setgid programs
linked to the tinfo library. How easily those can be achieved probably
depends on the program.
[ Tests ]
No automatic tests exist. I have manually verified that programs can no
longer use custom terminfo files if their effective UID or GID differs
from the real one. Also I have verified that the terminfo database in
the ncurses-{base,term} packages is unchanged from 6.2+20201114-2+deb11u2.
[ Risks ]
Users who are relying on their own terminfo files under
${HOME}/.terminfo can no longer use them in setuid/setgid programs and
will have to work around that, e.g. by changing their TERM environment
variable, using a different terminal emulator or asking their sysadmin
for help.
On my systems I did not find any setuid binaries linked to the tinfo
library, but some setgid games in the bsdgames package.
[ 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
I have slightly edited the debdiff to exclude spurious changes to the
debian/lib{32,64}tinfo6.symbols files, as these are just symlinks to
libtinfo6.symbols. See devscripts bug #773762[4].
[ Other info ]
Since ncurses produces a udeb I have CC'ed debian-boot and tagged the
bug accordingly. The screen binary in the screen-udeb package is
actually affected by the change, as it is installed setgid utmp. This
should not really matter though, since the terminfo files in the
di-utils-terminfo package are installed in the standard place under
/lib/terminfo.
Thanks for consideration.
Cheers,
Sven
1. https://security-tracker.debian.org/tracker/CVE-2023-29491
2. https://bugs.debian.org/1034372
3. https://bugs.debian.org/1035351
4. https://bugs.debian.org/773762
diff -Nru ncurses-6.2+20201114/debian/changelog ncurses-6.2+20201114/debian/changelog
--- ncurses-6.2+20201114/debian/changelog 2023-02-08 20:16:03.0 +0100
+++ ncurses-6.2+20201114/debian/changelog 2023-05-26 20:31:08.0 +0200
@@ -1,3 +1,17 @@
+ncurses (6.2+20201114-2+deb11u2) bullseye; urgency=medium
+
+ * Configure with "--disable-root-environ" to disallow loading of
+custom terminfo entries in setuid/setgid programs, mitigating the
+impact of CVE-2023-29491 (see #1034372).
+- Update the symbols files for the newly exported symbol
+ _nc_env_access.
+- New patch debian-env-access.diff, changing the behavior of the
+ "--disable-root-environ" configure option to not restrict programs
+ run by the superuser, equivalent to the "--disable-setuid-environ"
+ option introduced in the 20230423 patchlevel.
+
+ -- Sven Joachim Fri, 26 May 2023 20:31:08 +0200
+
ncurses (6.2+20201114-2+deb11u1) bullseye; urgency=medium
* New patch CVE-2022-29458.diff: add a limit-check to guard against
diff -Nru ncurses-6.2+20201114/debian/libtinfo5.symbols ncurses-6.2+20201114/debian/libtinfo5.symbols
--- ncurses-6.2+20201114/debian/libtinfo5.symbols 2021-01-01 10:31:15.0 +0100
+++ ncurses-6.2+20201114/debian/libtinfo5.symbols 2023-05-26 19:46:17.0 +0200
@@ -95,6 +95,7 @@
_nc_curr_col@NCURSES_TINFO_5.0.19991023 6
_nc_curr_line@NCURSES_TINFO_5.0.19991023 6
_nc_doalloc@NCURSES_TINFO_5.0.19991023 6
+ _nc_env_access@NCURSES_TINFO_5.2.20001021 6.2+20201114-2+deb11u2~
_nc_err_abort@NCURSES_TINFO_5.0.19991023 6
_nc_fallback@NCURSES_TINFO_5.0.19991023 6
_nc_find_entry@NCURSES_TINFO_5.0.19991023 6
diff -Nru ncurses-6.2+20201114/debian/libtinfo6.symbols ncurses-6.2+20201114/debian/libtinfo6.symbols
--- ncurses-6.2+20201114/debian/libtinfo6.symbols 2021-01-01 10:31:15.0 +0100
+++ ncurses-6.2+20201114/debian/libtinfo6.symbols 2023-05-26 19:46:17.0 +0200
@@ -94,6 +94,7 @@
_nc_curr_col@NCURSES6_TINFO_5.0.19991023 6
_nc_curr_li
Bug#1035351: [pre-approval] unblock: ncurses/6.4-3
Control: reopen -1 Control: tags -1 - confirmed moreinfo Control: retitle -1 unblock: ncurses/6.4-4 On 2023-05-07 15:28 +0200, Paul Gevers wrote: > Hi, > > On 01-05-2023 18:32, Sven Joachim wrote: >> I would like to address CVE-2023-29491[1] aka bug #1034372[2] in >> Bookworm. > > unblocked and aged. Thanks, unfortunately this upload uncovered an old but hitherto hidden bug in the build system that would lead to random build failures after patching configure.in, see #1035621. It is only by chance that none of the three arches where ncurses 6.4-3 FTBFS is a release architecture. To fix that problem I have uploaded ncurses 6.4-4, see the attached debdiff against 6.4-3. The good news is that the files in the binary packages should be identical, except for changelog.Debian.gz of course. Cheers, Sven diff -Nru ncurses-6.4/debian/autoconf.sh ncurses-6.4/debian/autoconf.sh --- ncurses-6.4/debian/autoconf.sh 1970-01-01 01:00:00.0 +0100 +++ ncurses-6.4/debian/autoconf.sh 2023-05-07 13:55:21.0 +0200 @@ -0,0 +1,5 @@ +#!/bin/sh +set -e + +autoconf-dickey +cd test && autoconf-dickey diff -Nru ncurses-6.4/debian/changelog ncurses-6.4/debian/changelog --- ncurses-6.4/debian/changelog 2023-05-06 17:16:54.0 +0200 +++ ncurses-6.4/debian/changelog 2023-05-07 16:33:47.0 +0200 @@ -1,3 +1,12 @@ +ncurses (6.4-4) unstable; urgency=medium + + * Run autoconf-dickey in the toplevel and test/ directories rather +than autoreconf-dickey, as the latter picks up the backup file of +configure.in below the .pc/ directory, which is unwanted and does +not work (Closes: #1035621). + + -- Sven Joachim Sun, 07 May 2023 16:33:47 +0200 + ncurses (6.4-3) unstable; urgency=medium * Configure with "--disable-root-environ" to disallow loading of diff -Nru ncurses-6.4/debian/rules ncurses-6.4/debian/rules --- ncurses-6.4/debian/rules 2023-05-01 11:36:38.0 +0200 +++ ncurses-6.4/debian/rules 2023-05-07 13:55:21.0 +0200 @@ -211,7 +211,7 @@ config.guess-stamp: dh_update_autotools_config - dh_autoreconf autoreconf-dickey -- -f -i + dh_autoreconf debian/autoconf.sh touch $@ $(objdir)/config.status: config.guess-stamp
Bug#1035473: nmu: logol_1.7.9+dfsg-6
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: lo...@packages.debian.org, swi-pro...@packages.debian.org, svenj...@gmx.de Control: affects -1 + src:logol The logol package should be rebuilt so that logol-bin picks up a dependency on the virtual libswipl9 package. Otherwise it might break during the trixie release cycle if libswipl9 is split off from swi-prolog-core into its own package, or if the libswipl SONAME changes again. See #1033636 for the reasons why swi-prolog-core provides the libswipl9 package. nmu logol_1.7.9+dfsg-6 . ANY . unstable . -m "Rebuild against swi-prolog 9.0.4+dfsg-2" Cheers, Sven
Bug#1035351: [pre-approval] unblock: ncurses/6.4-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Tags: d-i
X-Debbugs-Cc: ncur...@packages.debian.org, debian-b...@lists.debian.org
Control: affects -1 + src:ncurses
I would like to address CVE-2023-29491[1] aka bug #1034372[2] in
Bookworm.
[ Reason ]
Various memory corruption bugs exist when loading specifically crafted
terminfo database files. This is a security problem in programs running
with elevated privileges, as users are allowed to provide their own
terminfo files under ${HOME}/.terminfo or via the TERMINFO or
TERMINFO_DIRS environment variables.
Backporting the upstream fixes seems to be too risky this late in the
release process, but via a configure option it is possible to prevent
setuid/setgid programs from loading custom terminfo files supplied by
the user, after which the bugs are no longer security relevant.
[ Impact ]
Local users could try privilege escalations in setuid/setgid programs
linked to the tinfo library. How easily those can be achieved probably
depends on the program.
[ Tests ]
No automatic tests exist. I have manually verified that programs can no
longer use custom terminfo files if their effective UID or GID differs
from the real one. Also I have verified that the terminfo database in
the ncurses-{base,term} packages is unchanged from 6.4-2.
[ Risks ]
Users who are relying on their own terminfo files under
${HOME}/.terminfo can no longer use them in setuid/setgid programs and
will have to work around that, e.g. by changing their TERM variable,
using a different terminal emulator or asking their sysadmin for help.
On my systems I did not find any setuid binaries linked to the tinfo
library, but some setgid games in the bsdgames package.
[ 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 testing
I have slightly edited the debdiff to exclude spurious changes to the
debian/lib{32,64}tinfo6.symbols files, as these are just symlinks to
libtinfo6.symbols. See devscripts bug #773762[3].
[ Other info ]
Since ncurses produces udebs, I have CC'ed debian-boot and tagged the
bug accordingly. There should be no effect on the installer, as I would
expect it to run all programs as root.
Thanks for consideration.
Cheers,
Sven
1. https://security-tracker.debian.org/tracker/CVE-2023-29491
2. https://bugs.debian.org/1034372
3. https://bugs.debian.org/773762
diff -Nru ncurses-6.4/debian/changelog ncurses-6.4/debian/changelog
--- ncurses-6.4/debian/changelog 2023-01-25 21:21:49.0 +0100
+++ ncurses-6.4/debian/changelog 2023-05-01 17:57:51.0 +0200
@@ -1,3 +1,21 @@
+ncurses (6.4-3) unstable; urgency=medium
+
+ * Configure with "--disable-root-environ" to disallow loading of
+custom terminfo entries in setuid/setgid programs, mitigating the
+impact of CVE-2023-29491 (see #1034372).
+- Update the symbols files for the newly exported symbol
+ _nc_env_access.
+- New patch fix-configure-root-args-option.diff cherry-picked from
+ the 20230415 patchlevel, fixing a copy/paste error which caused
+ the "--disable-root-environ" configure option to pick up code
+ meant to be used by the "--disable-root-args" option instead.
+- New patch debian-env-access.diff, changing the behavior of the
+ "--disable-root-environ" configure option to not restrict programs
+ run by the superuser, equivalent to the "--disable-setuid-environ"
+ option introduced in the 20230423 patchlevel.
+
+ -- Sven Joachim Mon, 01 May 2023 17:57:51 +0200
+
ncurses (6.4-2) unstable; urgency=medium
* Add Breaks against vim-common (<< 2:9.0.1000-2) to ncurses-base
diff -Nru ncurses-6.4/debian/libtinfo5.symbols ncurses-6.4/debian/libtinfo5.symbols
--- ncurses-6.4/debian/libtinfo5.symbols 2023-01-22 17:54:52.0 +0100
+++ ncurses-6.4/debian/libtinfo5.symbols 2023-05-01 11:36:38.0 +0200
@@ -95,6 +95,7 @@
_nc_curr_col@NCURSES_TINFO_5.0.19991023 6
_nc_curr_line@NCURSES_TINFO_5.0.19991023 6
_nc_doalloc@NCURSES_TINFO_5.0.19991023 6
+ _nc_env_access@NCURSES_TINFO_5.2.20001021 6.4-3~
_nc_err_abort@NCURSES_TINFO_5.0.19991023 6
_nc_fallback@NCURSES_TINFO_5.0.19991023 6
_nc_find_entry@NCURSES_TINFO_5.0.19991023 6
diff -Nru ncurses-6.4/debian/libtinfo6.symbols ncurses-6.4/debian/libtinfo6.symbols
--- ncurses-6.4/debian/libtinfo6.symbols 2023-01-22 17:54:52.0 +0100
+++ ncurses-6.4/debian/libtinfo6.symbols 2023-05-01 11:36:38.0 +0200
@@ -94,6 +94,7 @@
_nc_curr_col@NCURSES6_TINFO_5.0.19991023 6
_nc_curr_line@NCURSES6_TINFO_5.0.19991023 6
_nc_doalloc@NCURSES6_TINFO_5.0.19991023 6
+ _nc_env_access@NCURSES6_TINFO_5.2.20001021 6.4-3~
_nc_err_abort@NCURSES6_TINFO_5.0.19991023 6
_nc_export_termtype2@NCURSES6_TINFO_6.1.20171230 6.1
_nc_fallback2@NCURSES6_TINFO_6.1.20171230 6.1
diff -Nru ncurs
Bug#1030888: bullseye-pu: package ncurses/6.2+20201114-2+deb11u1
On 2023-02-19 18:52 +, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Wed, 2023-02-08 at 20:30 +0100, Sven Joachim wrote: >> I would like to fix two crash bugs in tic(1) & friends for Bullseye. >> There have been various similar issues in the previous years which we >> usually fixed in point releases. >> >> [ Reason ] >> 1. Bug #10098701[1] aka CVE-2022-29458[2] >> 2. Bug #1029399[3] >> >> [ Impact ] >> 1. Out-of-bounds read in the tinfo library could lead to crashes and >>potential code execution on crafted input. This usually requires >>the victim's assistance. >> >> 2. Stack buffer overflow can lead to a crash in tic on crafted input. >>This usually requires the victim's assistance. >> > > Please go ahead. Thanks, uploaded. Cheers, Sven
Bug#1030888: bullseye-pu: package ncurses/6.2+20201114-2+deb11u1
On 2023-02-10 08:34 +0100, Cyril Brulebois wrote: > Sven Joachim (2023-02-08): >> Since ncurses builds a udeb, I have put debian-boot in X-Debbugs-Cc. >> The changes should not affect the installer. > > ACK on principle; I'll try and make sure to test nano at some point. You probably want to test screen rather than nano, because nano-udeb is still linked with slang in Bullseye. Cheers, Sven
Bug#1030888: bullseye-pu: package ncurses/6.2+20201114-2+deb11u1
Package: release.debian.org Severity: normal Tags: bullseye d-i User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: ncur...@packages.debian.org, debian-b...@lists.debian.org Control: affects -1 + src:ncurses I would like to fix two crash bugs in tic(1) & friends for Bullseye. There have been various similar issues in the previous years which we usually fixed in point releases. [ Reason ] 1. Bug #10098701[1] aka CVE-2022-29458[2] 2. Bug #1029399[3] [ Impact ] 1. Out-of-bounds read in the tinfo library could lead to crashes and potential code execution on crafted input. This usually requires the victim's assistance. 2. Stack buffer overflow can lead to a crash in tic on crafted input. This usually requires the victim's assistance. [ Tests ] 1. The upstream bug report contains a reproducer[4]. It requires building ncurses with -fsanitize=address which I did. This confirmed that the original code has the bug, and the patch seems to fix it. 2. The upstream bug report contains a reproducer[5]. It crashes Bullseye's tic version, but not the patched one. Additionally, I verified that the terminfo database in the ncurses-base and ncurses-term packages is identical to the one in version 6.2+20201114-2. [ Risks ] 1. The upstream fixes in the 20220416 patchlevel do not apply cleanly and needed to be backported, which Thorsten Alteholz did in DLA-3167-1[6] for Bullseye LTS. This obviously increases the risk of something going wrong, however the same change has been in Buster LTS for over three months, and I have not heard of any complaints. While this fix touches the tinfo library, the code in question is, to the best of my knowledge, only used by tic and its aliases as it deals with terminfo source files. 2. The upstream fix from the 20230121 applies cleanly and is fairly small, so I think the risk is low. This issue only affects the tic program, not the library. [ 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 stable [x] the issues are verified as fixed in unstable [ Changes ] 1. Backport fixes from the 20220416 patchlevel. This has been done by Thorsten Alteholz in 6.1+20181013-2+deb10u3 for Buster LTS, and his patch applys cleanly to the Bullseye version. I have reviewed and fixed up mior issues with the patch such as trailing leading spaces followed by tabs. 2. Cherry-pick bug fix from the 20230121 upstream patchlevel. This is identical to the patch that went into ncurses 6.4-2. 3. Two small changes that help with CI and do not affect the binary packages: Set the release to bullseye in the Salsa CI, and add a lintian override for false-positive errors triggered by lintian 2.115 and newer. [ Other info ] Since ncurses builds a udeb, I have put debian-boot in X-Debbugs-Cc. The changes should not affect the installer. Cheers, Sven 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009870 2. https://security-tracker.debian.org/tracker/CVE-2022-29458 3. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029399 4. https://lists.gnu.org/archive/html/bug-ncurses/2022-04/msg00014.html 5. https://lists.gnu.org/archive/html/bug-ncurses/2023-01/msg00035.html 6. https://security-tracker.debian.org/tracker/DLA-3167-1 diff -Nru ncurses-6.2+20201114/debian/changelog ncurses-6.2+20201114/debian/changelog --- ncurses-6.2+20201114/debian/changelog 2021-01-01 16:02:10.0 +0100 +++ ncurses-6.2+20201114/debian/changelog 2023-02-08 20:16:03.0 +0100 @@ -1,3 +1,18 @@ +ncurses (6.2+20201114-2+deb11u1) bullseye; urgency=medium + + * New patch CVE-2022-29458.diff: add a limit-check to guard against +corrupt terminfo data (report/testcase by NCNIPC of China, +CVE-2022-29458), fix backported from the 20220416 upstream patchlevel +(Closes: #1009870). Thanks to Thorsten Alteholz for the patch. + * New patch fix_crash_on_very_long_tc-use_clause.diff, cherry-picked +from the 20230121 patchlevel: correct limit-check when dumping tc/use +clause via tic -I (report by Gabriel Ravier, Closes: #1029399). + * Use bullseye as the release in the Salsa CI pipeline. + * Add a lintian override for source-is-missing in the Ada documentation +(see #1019980). + + -- Sven Joachim Wed, 08 Feb 2023 20:16:03 +0100 + ncurses (6.2+20201114-2) unstable; urgency=medium * New patch 02-fix-mlterm.diff, cherry-picked from the 20201205 upstream diff -Nru ncurses-6.2+20201114/debian/gitlab-ci.yml ncurses-6.2+20201114/debian/gitlab-ci.yml --- ncurses-6.2+20201114/debian/gitlab-ci.yml 2021-01-01 10:31:15.0 +0100 +++ ncurses-6.2+20201114/debian/gitlab-ci.yml 2023-01-28 12:24:41.0 +0100 @@ -1,3 +1,6 @@ include: - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs
Re: Upload of TeX Info 7.0.x to unstable?
Am 01.02.2023 um 23:32 schrieb Hilmar Preuße: > Am 25.01.2023 um 22:08 teilte Sebastian Ramacher mit: >> On 2023-01-24 09:23:26 +0100, Hilmar Preuße wrote: > > Dear release managers, > >>> TeX Info version 7.0 was released last year at beginning of November and >>> was uploaded to experimental. We got a few bug reports, which were >>> addressed by upstream authors promptly. >>> Since then two bugfix releases appeared (currently 7.0.2) and we could >>> think about uploading to unstable. According to [1] we are neither in >>> the tool chain nor would this be a transition. Nevertheless we know that >>> a few(?) packages use makeinfo and texi2* to convert documents, so >>> uploading could cause breakage and FTBFS bugs when building docs. >> >> Did you perform a test rebuild of the reverse build dependencies? That >> would make it every easy to answer the question whether its safe or not. >> > I got a response from Lucas: > > > At http://qa-logs.debian.net/2023/01/31/ you will find build logs for > packages: > 1) currently in testing > 2) that failed with the new texinfo but succeeded in vanilla unstable > > In addition to those, octave's build hang but I don't have the build > log, so this would need to be retried. > > > This is a list of 15 (+1) packages, which likely disqualifies for an > upload of TeX Info 7.0. I'll try to look into these issues in the next > days, but I have doubt that I'm even able to evaluate if these are bugs > in makeinfo or bugs in the packages. I had a look at some of these logs, and all cases appear to be tripping over the following change mentioned in texinfo's NEWS file. , | 7.0 (7 November 2022) | * texi2any | . HTML output: | . use manual_name_html as output directory for split HTML instead of |manual_name or manual_name.html ` Which seems to rather gratuitously break existing Makefiles left and right. Actually it surprises me that only 15 packages FTBFS due to that incompatible change, there will likely be other cases where HTML documentation silently goes missing. :-( Cheers, Sven
Bug#1029525: [pre-approval] unblock: ncurses/6.4-2
On 2023-01-23 20:57 +0100, Paul Gevers wrote:
> Control: tags -1 moreinfo
>
> On 23-01-2023 20:02, Sven Joachim wrote:
>> [ Reason ]
>> 1. Pasting in vim is broken on some terminal emulators[1]
>> Remedy: Declare versioned Breaks against vim-common in
>> ncurses-{base,term}
>> 2. Stack buffer overflow in "tic -I" on crafted input[2]
>> Remedy: Cherry-pick upstream fix
>
> Ack.
>
>> [ Risks ]
>
> [...]
>
>> 3. Although the workaround for debhelper bug #875780[6] is not exactly
>> pretty, it should not pose any risks.
>
> Can you ease my slight worry by pointing out where you got the
> STRIP_OPTIONS from? In other words, can we confirm these are the same
> options that debhelper would apply?
I copied them from the dh_strip source[1].
Cheers,
Sven
1. https://sources.debian.org/src/debhelper/13.11.4/dh_strip/#L376
Bug#1029525: [pre-approval] unblock: ncurses/6.4-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: ncur...@packages.debian.org
Control: affects -1 + src:ncurses
I would like to fix three bugs[1,2,3] in ncurses for Bookworm. While
none of them is RC, they have some impact on users, and the changes are
fairly small.
[ Reason ]
1. Pasting in vim is broken on some terminal emulators[1]
Remedy: Declare versioned Breaks against vim-common in ncurses-{base,term}
2. Stack buffer overflow in "tic -I" on crafted input[2]
Remedy: Cherry-pick upstream fix
3. On i386 and mips64el, libncurses++w.a is not stripped[3]
Remedy: Strip the file by hand in debian/rules
[ Impact ]
1. On upgrades from Bullseye to Bookworm, if ncurses-base is upgraded
before vim (which is rather likely without the Breaks), pasting in
vim is severely broken for some terminal emulators and values of
$TERM. One rather popular combination is using tmux and TERM=tmux
or TERM=tmux-256color.
For the gory details see #1027435, #1027674[4] and upstream issue
11766[5] in vim.
2. Potentially a security issue, although it requires some cooperation
by the victim, and the stack protection should prevent worse things
than a crash. Several cases of such crash bugs in tic have been
fixed via point releases in the past.
3. On the affected architectures, several hundred kilobytes are used,
and the size of libncurses-dev.deb also increases, wasting bandwith.
Perhaps more importantly, the build becomes unreproducible, a sad
regression compared to previous Debian releases.
[ Tests ]
1. No tests have been performed yet. Once ncurses 6.4-2 is in unstable
I intend to test upgrades from Bullseye in a chroot, but real world
examples with 1000+ installed packages will have to be tested by
users.
2. The reproducer test given by the upstream bug submitter no longer
crashes. The terminfo database in the ncurses-{base,term} packages
is identical with the 6.4-1 version.
3. The offending file is stripped on i386, and two test builds produced
identical packages.
[ Risks ]
1. On upgrades from Bullseye, the upgrade of ncurses-base and
ncurses-term will be delayed. All reverse dependencies in the archive
are satisfied with the Bullseye versions, so I do not expect problems.
2. Although the fix is small, it might still contain bugs. Any damage
will be limited to the usage of "infocmp -u", "tic -I" and "tic -C"
(or their aliases infotocap and captoinfo), which are not used very
often.
3. Although the workaround for debhelper bug #875780[6] is not exactly
pretty, it should not pose any risks.
[ Checklist ]
[x] all changes are documented in debian/changelog
[x] I reviewed all changes and I approve them
[x] attach the patches applied in git, rather than a debdiff
Thanks for your consideration.
Cheers,
Sven
1. https://bugs.debian.org/1027435
2. https://bugs.debian.org/1029399
3. https://bugs.debian.org/1029404
4. https://bugs.debian.org/1027674
5. https://github.com/vim/vim/issues/11766
6. https://bugs.debian.org/875780
From 12bb87e58cf0ad787b90281452404a9ee1240244 Mon Sep 17 00:00:00 2001
From: Sven Joachim
Date: Sun, 22 Jan 2023 18:02:59 +0100
Subject: [PATCH 1/3] Add versioned Breaks against vim-common to
ncurses-{base,term}
Pasting text is broken in older vim versions for some rather popular
terminals and values of $TERM, e.g. in tmux if TERM is set to "tmux"
or "tmux-256color". To avoid nasty surprises on partial upgrades,
ensure that a fixed vim version is installed along the new terminfo
database.
Closes: #1027435
---
debian/changelog | 7 +++
debian/control | 4 ++--
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index 3af8f1e5..fdd6f828 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+ncurses (6.4-2) UNRELEASED; urgency=medium
+
+ * Add Breaks against vim-common (<< 2:9.0.1000-2) to ncurses-base
+and ncurses-term (Closes: #1027435).
+
+ -- Sven Joachim Sun, 22 Jan 2023 17:59:41 +0100
+
ncurses (6.4-1) unstable; urgency=medium
* New upstream release.
diff --git a/debian/control b/debian/control
index 0d2f7af0..fc151b97 100644
--- a/debian/control
+++ b/debian/control
@@ -24,7 +24,7 @@ Provides: ncurses-runtime
Breaks: libtinfo5 (<< 6.1), libslang2 (<< 2.3.1a-3), libunibilium0 (<< 2),
libunibilium4 (<< 2.0.0-3), bash-static (<< 4.4.18-1.1),
zsh-static (<< 5.4.2-4), libmono-corlib4.5-cil (<< 4.6.2.7+dfsg-2),
-neovim (<< 0.6.0)
+neovim (<< 0.6.0), vim-common (<< 2:9.0.1000-2)
Description: basic terminal type definitions
The ncurses library routines are a terminal-independent method of
updating character screens with reasonable optimization.
@@ -44,7 +44,7 @@ Replaces: dvtm
Bug#1005233: buster-pu: package xterm/344-1+deb10u2
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
I have uploaded xterm 344-1+deb10u2 to fix #1004689 aka CVE-2022-24130
in buster.
This is the same problem and the same fix as the one for bullseye, see
#1005232 for details. The patch is six lines longer because two minor
changes from xterm 357 had to be applied first.
Cheers,
Sven
diff -Nru xterm-344/debian/changelog xterm-344/debian/changelog
--- xterm-344/debian/changelog 2021-03-07 17:53:16.0 +0100
+++ xterm-344/debian/changelog 2022-02-07 20:05:11.0 +0100
@@ -1,3 +1,12 @@
+xterm (344-1+deb10u2) buster; urgency=medium
+
+ * Cherry-pick sixel graphics fixes from xterm 370d and 370f.
+- Check for out-of-bounds condition while drawing sixels, and quit
+ that operation (report by Nick Black (CVE-2022-24130),
+ Closes: #1004689).
+
+ -- Sven Joachim Mon, 07 Feb 2022 20:05:11 +0100
+
xterm (344-1+deb10u1) buster; urgency=medium
* Apply upstream fix from xterm 366 for CVE-2021-27135.
diff -Nru xterm-344/debian/patches/CVE-2022-24130.diff xterm-344/debian/patches/CVE-2022-24130.diff
--- xterm-344/debian/patches/CVE-2022-24130.diff 1970-01-01 01:00:00.0 +0100
+++ xterm-344/debian/patches/CVE-2022-24130.diff 2022-02-02 18:26:45.0 +0100
@@ -0,0 +1,79 @@
+Description: Cherry-pick sixel graphics fixes from xterm 370d and 370f
+ Check for out-of-bounds condition while drawing sixels, and quit that
+ operation (report by Nick Black, CVE-2022-24130).
+Bug-Debian: https://bugs.debian.org/1004689
+
+---
+ graphics_sixel.c | 31 +--
+ 1 file changed, 25 insertions(+), 6 deletions(-)
+
+--- a/graphics_sixel.c
b/graphics_sixel.c
+@@ -141,7 +141,7 @@ init_sixel_background(Graphic *graphic,
+ graphic->color_registers_used[context->background] = 1;
+ }
+
+-static void
++static Boolean
+ set_sixel(Graphic *graphic, SixelContext const *context, int sixel)
+ {
+ const int mh = graphic->max_height;
+@@ -162,7 +162,10 @@ set_sixel(Graphic *graphic, SixelContext
+ ((color != COLOR_HOLE)
+ ? (unsigned) graphic->color_registers[color].b : 0U)));
+ for (pix = 0; pix < 6; pix++) {
+- if (context->col < mw && context->row + pix < mh) {
++ if (context->col >= 0 &&
++ context->col < mw &&
++ context->row + pix >= 0 &&
++ context->row + pix < mh) {
+ if (sixel & (1 << pix)) {
+ if (context->col + 1 > graphic->actual_width) {
+ graphic->actual_width = context->col + 1;
+@@ -175,8 +178,10 @@ set_sixel(Graphic *graphic, SixelContext
+ }
+ } else {
+ TRACE(("sixel pixel %d out of bounds\n", pix));
++ return False;
+ }
+ }
++return True;
+ }
+
+ static void
+@@ -451,7 +456,12 @@ parse_sixel(XtermWidget xw, ANSI *params
+ init_sixel_background(graphic, );
+ graphic->valid = 1;
+ }
+- set_sixel(graphic, , sixel);
++ if (sixel) {
++ if (!set_sixel(graphic, , sixel)) {
++ context.col = 0;
++ break;
++ }
++ }
+ context.col++;
+ } else if (ch == '$') { /* DECGCR */
+ /* ignore DECCRNLM in sixel mode */
+@@ -528,9 +538,18 @@ parse_sixel(XtermWidget xw, ANSI *params
+ init_sixel_background(graphic, );
+ graphic->valid = 1;
+ }
+- for (i = 0; i < Pcount; i++) {
+- set_sixel(graphic, , sixel);
+- context.col++;
++ if (sixel) {
++ int i;
++ for (i = 0; i < Pcount; i++) {
++ if (set_sixel(graphic, , sixel)) {
++ context.col++;
++ } else {
++ context.col = 0;
++ break;
++ }
++ }
++ } else {
++ context.col += Pcount;
+ }
+ } else if (ch == '#') { /* DECGCI */
+ ANSI color_params;
diff -Nru xterm-344/debian/patches/series xterm-344/debian/patches/series
--- xterm-344/debian/patches/series 2021-03-05 22:10:42.0 +0100
+++ xterm-344/debian/patches/series 2022-02-02 17:42:37.0 +0100
@@ -2,3 +2,4 @@
902_windowops.diff
904_fontops.diff
CVE-2021-27135.diff
+CVE-2022-24130.diff
signature.asc
Description: PGP signature
Bug#1005232: bullseye-pu: package xterm/366-1+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
I have uploaded xterm 366-1+deb11u1 to fix #1004689 aka CVE-2022-24130
in bullseye.
[ Reason ]
CVE-2022-24130: xterm through Patch 370, when Sixel support is enabled,
allows attackers to trigger a buffer overflow in set_sixel in
graphics_sixel.c via crafted text.
[ Impact ]
An attacker could cause xterm to crash or possibly do worse things,
e.g. by luring the victim to cat(1) a specially crafted file. In its
default configuration xterm does not interpret Sixel graphics, the user
needs to set the decTerminalID resource to a non-standard value or
invoke xterm with the -ti switch to enable Sixel support and become
vulnerable.
[ Tests ]
I have verified that the testcase at [1] no longer causes a crash with
the attached patch.
[ Risks ]
No official upstream release has been made yet, but the issue has been
addressed in current snapshots at [2]. The patch has been taken from
there and is identical to the one that went into xterm 370-2, currently
in unstable and testing.
[ 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
Cheers,
Sven
1. https://www.openwall.com/lists/oss-security/2022/01/30/3
2. https://github.com/ThomasDickey/xterm-snapshots/
diff -Nru xterm-366/debian/changelog xterm-366/debian/changelog
--- xterm-366/debian/changelog 2021-02-11 10:31:09.0 +0100
+++ xterm-366/debian/changelog 2022-02-07 20:14:01.0 +0100
@@ -1,3 +1,12 @@
+xterm (366-1+deb11u1) bullseye; urgency=medium
+
+ * Cherry-pick sixel graphics fixes from xterm 370d and 370f.
+- Check for out-of-bounds condition while drawing sixels, and quit
+ that operation (report by Nick Black (CVE-2022-24130),
+ Closes: #1004689).
+
+ -- Sven Joachim Mon, 07 Feb 2022 20:14:01 +0100
+
xterm (366-1) unstable; urgency=medium
* New upstream release
diff -Nru xterm-366/debian/patches/CVE-2022-24130.diff xterm-366/debian/patches/CVE-2022-24130.diff
--- xterm-366/debian/patches/CVE-2022-24130.diff 1970-01-01 01:00:00.0 +0100
+++ xterm-366/debian/patches/CVE-2022-24130.diff 2022-02-07 20:12:57.0 +0100
@@ -0,0 +1,73 @@
+Description: Cherry-pick sixel graphics fixes from xterm 370d and 370f
+ Check for out-of-bounds condition while drawing sixels, and quit that
+ operation (report by Nick Black, CVE-2022-24130).
+Bug-Debian: https://bugs.debian.org/1004689
+
+---
+ graphics_sixel.c | 25 +++--
+ 1 file changed, 19 insertions(+), 6 deletions(-)
+
+--- a/graphics_sixel.c
b/graphics_sixel.c
+@@ -149,7 +149,7 @@ init_sixel_background(Graphic *graphic,
+ graphic->color_registers_used[context->background] = 1;
+ }
+
+-static void
++static Boolean
+ set_sixel(Graphic *graphic, SixelContext const *context, int sixel)
+ {
+ const int mh = graphic->max_height;
+@@ -170,7 +170,10 @@ set_sixel(Graphic *graphic, SixelContext
+ ((color != COLOR_HOLE)
+ ? (unsigned) graphic->color_registers[color].b : 0U)));
+ for (pix = 0; pix < 6; pix++) {
+- if (context->col < mw && context->row + pix < mh) {
++ if (context->col >= 0 &&
++ context->col < mw &&
++ context->row + pix >= 0 &&
++ context->row + pix < mh) {
+ if (sixel & (1 << pix)) {
+ if (context->col + 1 > graphic->actual_width) {
+ graphic->actual_width = context->col + 1;
+@@ -183,8 +186,10 @@ set_sixel(Graphic *graphic, SixelContext
+ }
+ } else {
+ TRACE(("sixel pixel %d out of bounds\n", pix));
++ return False;
+ }
+ }
++return True;
+ }
+
+ static void
+@@ -462,8 +467,12 @@ parse_sixel(XtermWidget xw, ANSI *params
+ init_sixel_background(graphic, );
+ graphic->valid = 1;
+ }
+- if (sixel)
+- set_sixel(graphic, , sixel);
++ if (sixel) {
++ if (!set_sixel(graphic, , sixel)) {
++ context.col = 0;
++ break;
++ }
++ }
+ context.col++;
+ } else if (ch == '$') { /* DECGCR */
+ /* ignore DECCRNLM in sixel mode */
+@@ -531,8 +540,12 @@ parse_sixel(XtermWidget xw, ANSI *params
+ if (sixel) {
+ int i;
+ for (i = 0; i < Pcount; i++) {
+- set_sixel(graphic, , sixel);
+- context.col++;
++ if (set_sixel(graphic, , sixel)) {
++ context.col++;
++ } else {
++ context.col = 0;
++ break;
++ }
+ }
+ } else {
+ context.col += Pcount;
diff -Nru xterm-366/debian/patches/series xterm-366/debian/patches/series
--- xterm-366/debian/patches/series 2021-02-11 10:28:06.0 +0100
+++ xterm-366/debian/patches/series 2022-02-07 20:12:57.0 +0100
@@ -1,3 +1,4 @@
900_debian_xterm.diff
902_windowops.diff
904_fontops.diff
+CVE-2022-24130.diff
signature.asc
Description: PGP signature
Bug#983051: buster-pu: package xterm/344-1+deb10u1
On 2021-03-13 17:27 +, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Sun, 2021-03-07 at 18:21 +0100, Sven Joachim wrote: >> On 2021-02-18 17:54 +0100, Sven Joachim wrote: > [...] >> > I would like to fix bug #982439/CVE-2021-27135[1] in Buster, a >> > potential >> > DoS against xterm when the user selects specially crafted >> > text. The fix >> > is already in testing and applies unmodified to the version in >> > Buster, >> > the code in question had not seen any changes since then. The >> > xterm >> > package in Stretch-LTS has also already been patched. >> >> It turned out that the patch was insufficient and introduced new >> problems reported in bug #984615. Fortunately, upstream had already >> fixed it in xterm 365e/366. >> >> Please find an updated debdiff attached, with it the SaltTextAway() >> function in question is identical to the one in xterm 366 >> (bullseye/sid). Apologies for not having tested the initial patch >> thoroughly enough. >> > > Please go ahead. Thanks, uploaded. Cheers, Sven signature.asc Description: PGP signature
Bug#983051: buster-pu: package xterm/344-1+deb10u1
On 2021-02-18 17:54 +0100, Sven Joachim wrote:
> Package: release.debian.org
> Severity: normal
> Tags: buster
> User: release.debian@packages.debian.org
> Usertags: pu
> X-Debbugs-Cc: Salvatore Bonaccorso , Julien Cristau
> , Sven Joachim
>
> I would like to fix bug #982439/CVE-2021-27135[1] in Buster, a potential
> DoS against xterm when the user selects specially crafted text. The fix
> is already in testing and applies unmodified to the version in Buster,
> the code in question had not seen any changes since then. The xterm
> package in Stretch-LTS has also already been patched.
It turned out that the patch was insufficient and introduced new
problems reported in bug #984615. Fortunately, upstream had already
fixed it in xterm 365e/366.
Please find an updated debdiff attached, with it the SaltTextAway()
function in question is identical to the one in xterm 366
(bullseye/sid). Apologies for not having tested the initial patch
thoroughly enough.
Cheers,
Sven
diff -Nru xterm-344/debian/changelog xterm-344/debian/changelog
--- xterm-344/debian/changelog 2019-02-14 18:04:18.0 +0100
+++ xterm-344/debian/changelog 2021-03-07 17:53:16.0 +0100
@@ -1,3 +1,11 @@
+xterm (344-1+deb10u1) buster; urgency=medium
+
+ * Apply upstream fix from xterm 366 for CVE-2021-27135.
+- Correct upper-limit for selection buffer, accounting for combining
+ characters (Closes: #982439).
+
+ -- Sven Joachim Sun, 07 Mar 2021 17:53:16 +0100
+
xterm (344-1) unstable; urgency=medium
* New upstream release.
diff -Nru xterm-344/debian/patches/CVE-2021-27135.diff xterm-344/debian/patches/CVE-2021-27135.diff
--- xterm-344/debian/patches/CVE-2021-27135.diff 1970-01-01 01:00:00.0 +0100
+++ xterm-344/debian/patches/CVE-2021-27135.diff 2021-03-07 17:36:55.0 +0100
@@ -0,0 +1,61 @@
+Description: Fix for CVE-2021-27135 from xterm 366
+ Correct upper-limit for selection buffer, accounting for
+ combining characters (report by Tavis Ormandy).
+
+---
+ button.c | 29 +
+ 1 file changed, 25 insertions(+), 4 deletions(-)
+
+--- a/button.c
b/button.c
+@@ -3914,6 +3914,7 @@ SaltTextAway(XtermWidget xw,
+ int i;
+ int eol;
+ int need = 0;
++size_t have = 0;
+ Char *line;
+ Char *lp;
+ CELL first = *cellc;
+@@ -3948,7 +3949,11 @@ SaltTextAway(XtermWidget xw,
+
+ /* UTF-8 may require more space */
+ if_OPT_WIDE_CHARS(screen, {
+- need *= 4;
++ if (need > 0) {
++ if (screen->max_combining > 0)
++ need += screen->max_combining;
++ need *= 6;
++ }
+ });
+
+ /* now get some memory to save it in */
+@@ -3986,10 +3991,26 @@ SaltTextAway(XtermWidget xw,
+ }
+ *lp = '\0'; /* make sure we have end marked */
+
+-TRACE(("Salted TEXT:%u:%s\n", (unsigned) (lp - line),
+- visibleChars(line, (unsigned) (lp - line;
++have = (size_t) (lp - line);
++/*
++ * Scanning the buffer twice is unnecessary. Discard unwanted memory if
++ * the estimate is too-far off.
++ */
++if ((have * 2) < (size_t) need) {
++ Char *next;
++ scp->data_limit = have + 1;
++ next = realloc(line, scp->data_limit);
++ if (next == NULL) {
++ free(line);
++ scp->data_length = 0;
++ scp->data_limit = 0;
++ }
++ scp->data_buffer = next;
++}
++scp->data_length = have;
+
+-scp->data_length = (size_t) (lp - line);
++TRACE(("Salted TEXT:%u:%s\n", (unsigned) have,
++ visibleChars(scp->data_buffer, (unsigned) have)));
+ }
+
+ #if OPT_PASTE64
diff -Nru xterm-344/debian/patches/series xterm-344/debian/patches/series
--- xterm-344/debian/patches/series 2019-02-13 17:54:29.0 +0100
+++ xterm-344/debian/patches/series 2021-03-05 22:10:42.0 +0100
@@ -1,3 +1,4 @@
900_debian_xterm.diff
902_windowops.diff
904_fontops.diff
+CVE-2021-27135.diff
signature.asc
Description: PGP signature
Bug#983051: buster-pu: package xterm/344-1+deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: Salvatore Bonaccorso , Julien Cristau
, Sven Joachim
I would like to fix bug #982439/CVE-2021-27135[1] in Buster, a potential
DoS against xterm when the user selects specially crafted text. The fix
is already in testing and applies unmodified to the version in Buster,
the code in question had not seen any changes since then. The xterm
package in Stretch-LTS has also already been patched. At [2] there is
the upstream source of the patch.
Thanks for considering.
1. https://bugs.debian.org/982439
2.
https://github.com/ThomasDickey/xterm-snapshots/commit/82ba55b8f994ab30ff561a347b82ea340ba7075c#diff-1316a8dc8f904428cd95f29accdea9fff33e680f9f30216391d8df33d2f9f806
diff -Nru xterm-344/debian/changelog xterm-344/debian/changelog
--- xterm-344/debian/changelog 2019-02-14 18:04:18.0 +0100
+++ xterm-344/debian/changelog 2021-02-18 17:39:44.0 +0100
@@ -1,3 +1,11 @@
+xterm (344-1+deb10u1) buster; urgency=medium
+
+ * Apply upstream fix from xterm 365d for CVE-2021-27135.
+- Correct upper-limit for selection buffer, accounting for combining
+ characters (Closes: #982439).
+
+ -- Sven Joachim Thu, 18 Feb 2021 17:39:44 +0100
+
xterm (344-1) unstable; urgency=medium
* New upstream release.
diff -Nru xterm-344/debian/patches/CVE-2021-27135.diff xterm-344/debian/patches/CVE-2021-27135.diff
--- xterm-344/debian/patches/CVE-2021-27135.diff 1970-01-01 01:00:00.0 +0100
+++ xterm-344/debian/patches/CVE-2021-27135.diff 2021-02-17 19:28:55.0 +0100
@@ -0,0 +1,55 @@
+Description: Fix for CVE-2021-27135 from xterm 365d
+ Correct upper-limit for selection buffer, accounting for
+ combining characters (report by Tavis Ormandy).
+
+---
+ button.c | 23 +++
+ 1 file changed, 19 insertions(+), 4 deletions(-)
+
+--- a/button.c
b/button.c
+@@ -3914,6 +3914,7 @@ SaltTextAway(XtermWidget xw,
+ int i;
+ int eol;
+ int need = 0;
++size_t have = 0;
+ Char *line;
+ Char *lp;
+ CELL first = *cellc;
+@@ -3948,7 +3949,11 @@ SaltTextAway(XtermWidget xw,
+
+ /* UTF-8 may require more space */
+ if_OPT_WIDE_CHARS(screen, {
+- need *= 4;
++ if (need > 0) {
++ if (screen->max_combining > 0)
++ need += screen->max_combining;
++ need *= 6;
++ }
+ });
+
+ /* now get some memory to save it in */
+@@ -3986,10 +3991,20 @@ SaltTextAway(XtermWidget xw,
+ }
+ *lp = '\0'; /* make sure we have end marked */
+
+-TRACE(("Salted TEXT:%u:%s\n", (unsigned) (lp - line),
+- visibleChars(line, (unsigned) (lp - line;
++have = (size_t) (lp - line);
++/*
++ * Scanning the buffer twice is unnecessary. Discard unwanted memory if
++ * the estimate is too-far off.
++ */
++if ((have * 2) < (size_t) need) {
++ scp->data_limit = have + 1;
++ line = realloc(line, scp->data_limit);
++}
++
++TRACE(("Salted TEXT:%u:%s\n", (unsigned) have,
++ visibleChars(line, (unsigned) have)));
+
+-scp->data_length = (size_t) (lp - line);
++scp->data_length = have;
+ }
+
+ #if OPT_PASTE64
diff -Nru xterm-344/debian/patches/series xterm-344/debian/patches/series
--- xterm-344/debian/patches/series 2019-02-13 17:54:29.0 +0100
+++ xterm-344/debian/patches/series 2021-02-17 18:51:05.0 +0100
@@ -1,3 +1,4 @@
900_debian_xterm.diff
902_windowops.diff
904_fontops.diff
+CVE-2021-27135.diff
signature.asc
Description: PGP signature
Bug#944009: buster-pu: package ncurses/6.1+20181013-2+deb10u2
On 2019-11-08 19:52 +, Adam D. Barratt wrote: > On Wed, 2019-11-06 at 11:54 +, Adam D. Barratt wrote: >> Control: tags -1 + confirmed d-i >> >> On 2019-11-02 19:10, Sven Joachim wrote: >> > I would like to upload ncurses 6.1+20181013-2+deb10u2 to buster, >> > fixing >> > several bugs in tic's parser which have been reported last >> > month. Two >> > of them are heap buffer overflows that have been assigned CVE >> > numbers >> > and a Debian bug[1], two others are out-of-bound-reads and one an >> > infinite loop. >> > >> > I have verified that the reported crashes and the infinite loop >> > which I >> > could reproduce in ncurses 6.1+20181013-2+deb10u1 appear to be >> > fixed, >> > at >> > least with the submitted corrupt input files. Also, the compiled >> > terminfo files in ncurses-base and ncurses-term are identical to >> > the >> > ones currently in buster. >> > >> > This upload touches the tinfo library which is used in the >> > installer, >> > however to the best of my knowledge the changed functions are only >> > used >> > by tic and not by any other packages. >> >> Nevertheless I'd appreciate a formal ACK there. > > Given that the window for getting fixes into the 10.2 point release > closes this weekend, feel free to upload and we'll wait for the d-i ack > before deciding whether to include it in 10.2. Thanks, uploaded. Cheers, Sven
Bug#944009: buster-pu: package ncurses/6.1+20181013-2+deb10u2
Package: release.debian.org
Severity: normal
Tags: buster d-i
User: release.debian@packages.debian.org
Usertags: pu
I would like to upload ncurses 6.1+20181013-2+deb10u2 to buster, fixing
several bugs in tic's parser which have been reported last month. Two
of them are heap buffer overflows that have been assigned CVE numbers
and a Debian bug[1], two others are out-of-bound-reads and one an
infinite loop.
I have verified that the reported crashes and the infinite loop which I
could reproduce in ncurses 6.1+20181013-2+deb10u1 appear to be fixed, at
least with the submitted corrupt input files. Also, the compiled
terminfo files in ncurses-base and ncurses-term are identical to the
ones currently in buster.
This upload touches the tinfo library which is used in the installer,
however to the best of my knowledge the changed functions are only used
by tic and not by any other packages.
Thanks for your consideration.
1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942401
diff -Nru ncurses-6.1+20181013/debian/changelog ncurses-6.1+20181013/debian/changelog
--- ncurses-6.1+20181013/debian/changelog 2019-08-05 20:03:21.0 +0200
+++ ncurses-6.1+20181013/debian/changelog 2019-11-02 19:16:19.0 +0100
@@ -1,3 +1,20 @@
+ncurses (6.1+20181013-2+deb10u2) buster; urgency=medium
+
+ * Cherry-pick tic fixes from upstream patchlevels 20191012,
+20191015 and 20191019 (Closes: #942401).
+- Check for invalid hashcode in _nc_find_type_entry and
+ nc_find_entry (CVE-2019-17594).
+- Check for missing character after backslash in fmt_entry
+ (CVE-2019-17595).
+- Check for acsc with odd length in dump_entry in check for
+ one-one mapping.
+- Check for missing character after backslash in write_it.
+- Modify tic to exit if it cannot remove a conflicting name, because
+ treating that as a partial success can cause an infinite loop in
+ use-resolution.
+
+ -- Sven Joachim Sat, 02 Nov 2019 19:16:19 +0100
+
ncurses (6.1+20181013-2+deb10u1) buster; urgency=medium
* Drop "rep" from xterm-new and derived terminfo descriptions
diff -Nru ncurses-6.1+20181013/debian/patches/CVE-2019-17594.diff ncurses-6.1+20181013/debian/patches/CVE-2019-17594.diff
--- ncurses-6.1+20181013/debian/patches/CVE-2019-17594.diff 1970-01-01 01:00:00.0 +0100
+++ ncurses-6.1+20181013/debian/patches/CVE-2019-17594.diff 2019-11-02 17:21:09.0 +0100
@@ -0,0 +1,37 @@
+Author: Sven Joachim
+Description: Fix for CVE-2019-17594
+ Check for invalid hashcode in _nc_find_type_entry and nc_find_entry,
+ fix cherry-picked from upstream patchlevel 20191012.
+Bug-Debian: https://bugs.debian.org/942401
+Bug: https://lists.gnu.org/archive/html/bug-ncurses/2019-10/msg00017.html
+Forwarded: not-needed
+Last-Update: 2019-11-02
+
+---
+ ncurses/tinfo/comp_hash.c |8 ++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/ncurses/tinfo/comp_hash.c
b/ncurses/tinfo/comp_hash.c
+@@ -63,7 +63,9 @@ _nc_find_entry(const char *string,
+
+ hashvalue = data->hash_of(string);
+
+-if (data->table_data[hashvalue] >= 0) {
++if (hashvalue >= 0
++ && (unsigned) hashvalue < data->table_size
++ && data->table_data[hashvalue] >= 0) {
+
+ real_table = _nc_get_table(termcap);
+ ptr = real_table + data->table_data[hashvalue];
+@@ -96,7 +98,9 @@ _nc_find_type_entry(const char *string,
+ const HashData *data = _nc_get_hash_info(termcap);
+ int hashvalue = data->hash_of(string);
+
+-if (data->table_data[hashvalue] >= 0) {
++if (hashvalue >= 0
++ && (unsigned) hashvalue < data->table_size
++ && data->table_data[hashvalue] >= 0) {
+ const struct name_table_entry *const table = _nc_get_table(termcap);
+
+ ptr = table + data->table_data[hashvalue];
diff -Nru ncurses-6.1+20181013/debian/patches/CVE-2019-17595.diff ncurses-6.1+20181013/debian/patches/CVE-2019-17595.diff
--- ncurses-6.1+20181013/debian/patches/CVE-2019-17595.diff 1970-01-01 01:00:00.0 +0100
+++ ncurses-6.1+20181013/debian/patches/CVE-2019-17595.diff 2019-11-02 17:22:34.0 +0100
@@ -0,0 +1,36 @@
+Author: Sven Joachim
+Description: Fix for CVE-2019-17595
+ Fix for CVE-2019-17595 cherry-picked from upstream patchlevel
+ 20191012. Additionally to the CVE fix, this contains a check for
+ acsc with odd length in dump_entry in check for one-one mapping.
+Bug-Debian: https://bugs.debian.org/942401
+Bug: https://lists.gnu.org/archive/html/bug-ncurses/2019-10/msg00013.html
+Bug: https://lists.gnu.org/archive/html/bug-ncurses/2019-10/msg00018.html
+Forwarded: not-needed
+Last-Update: 2019-11-02
+
+---
+ progs/dump_entry.c |5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/progs/dump_entry.c
b/progs/dump_entry.c
+@@ -1110,7 +1110,8 @@ fmt_entry(TERMTYPE2 *tterm,
+ *d++ = '\\';
+ *d = ':';
+ } else if (*d == '\\') {
+-*++d = *s++;
++if ((*++d =
Bug#934163: buster-pu: package ncurses/6.1+20181013-2+deb10u1
Package: release.debian.org Severity: normal Tags: buster d-i User: release.debian@packages.debian.org Usertags: pu I have just uploaded ncurses 6.1+20181013-2+deb10u1 to Buster which contains a one-line fix for bug #933053[1], the same as in version 6.1+20190713-2 which is now in testing. Some background: for about 20 years, xterm has support for a special escape sequence which causes characters to be repeated. In ncurses 6.1-1 and later, an entry was added to the xterm* terminfo descriptions announcing this feature. The ncurses library makes use of it for line drawing characters. Now there are many terminal emulators out there who set TERM to xterm or xterm-256color, and they did generally not actually support this escape sequence, leading to the line drawing characters not repeated which looks then very bad. You can see a few screenshots in bug #933053. Most popular terminal emulators in Buster have already been fixed, so desktop systems are largely unaffected. However, if people connect to a Buster server from an older system, say Debian 9 or Ubuntu 16.04, they may experience this issue. The solution is to drop the particular entry from the xterm* terminfo entries, so that the ncurses library no longer uses it. I have tested the fix with the Stretch versions of konsole and gnome-terminal and a Buster chroot. Since ncurses builds a udeb I need a d-i ack, debian-boot@ and kibi@ are already in X-Debbugs-CC. The libraries are not touched by the patch and are identical with and without it. The xterm terminfo file is used by src:debian-installer-utils to build di-utils-terminfo.udeb, but only on kfreebsd. 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933053 diff -Nru ncurses-6.1+20181013/debian/changelog ncurses-6.1+20181013/debian/changelog --- ncurses-6.1+20181013/debian/changelog 2019-02-11 18:17:20.0 +0100 +++ ncurses-6.1+20181013/debian/changelog 2019-08-05 20:03:21.0 +0200 @@ -1,3 +1,10 @@ +ncurses (6.1+20181013-2+deb10u1) buster; urgency=medium + + * Drop "rep" from xterm-new and derived terminfo descriptions +(Closes: #933053). + + -- Sven Joachim Mon, 05 Aug 2019 20:03:21 +0200 + ncurses (6.1+20181013-2) unstable; urgency=medium * Add Breaks against libmono-corlib4.5-cil (<< 4.6.2.7+dfsg-2) diff -Nru ncurses-6.1+20181013/debian/xterm.ti ncurses-6.1+20181013/debian/xterm.ti --- ncurses-6.1+20181013/debian/xterm.ti 2019-02-11 18:16:04.0 +0100 +++ ncurses-6.1+20181013/debian/xterm.ti 2019-08-05 20:02:15.0 +0200 @@ -136,7 +136,7 @@ kcbt=\E[Z, kent=\EOM, rin=\E[%p1%dT, - use=ansi+rep, +# use=ansi+rep, use=ecma+strikeout, use=xterm+pcfkeys, use=xterm+tmux, signature.asc Description: PGP signature
Bug#932616: nmu: tcptraceroute_1.5beta7+debian-4.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Bug #932240 in debhelper 12.2 has caused missing dependencies in packages with setuid/setgid binaries. At least the tcptraceroute package is affected by this bug, see #932603. But there could well be others. :-( nmu tcptraceroute_1.5beta7+debian-4.1 . ANY . unstable . -m "Rebuild with fixed debhelper."
Bug#930951: nmu: libapt-pkg-perl_0.1.36
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Please binnmu libapt-pkg-perl on amd64. The package uploaded by the maintainer depends on libapt-pkg5.90, which is only available in experimental. nmu libapt-pkg-perl_0.1.36 . amd64 . unstable . -m "Rebuild in a clean sid environment."
Bug#918706: nmu: multiple imagemagick reverse dependencies
Control: reopen -1 On 2019-01-08 20:25 +0700, Balint Reczey wrote: > Package: release.debian.org > User: release.debian@packages.debian.org > Usertags: binnmu > Severity: normal > > Dear Release Team, > > Imagemagick upstream temporarily broke ABI (#916839) and the following > packages may need a binNMU as the current packages were built and > linked with the broken imagemagick libraries while they were present > in the archive: > > nmu aiscm_0.18.1-1 . ANY . -m 'Rebuild against imagemagick that > fixed ABI breakage.' > nmu chafa_1.0.1-2 . ANY . -m 'Rebuild against imagemagick that fixed > ABI breakage.' > nmu emacs_1:25.2+1-11 . ANY . -m 'Rebuild against imagemagick that > fixed ABI breakage.' > nmu gem_1:0.94~pre1-1 . ANY . -m 'Rebuild against imagemagick that > fixed ABI breakage.' > nmu graphicsmagick_1.4~hg15873-1 . ANY . -m 'Rebuild against > imagemagick that fixed ABI breakage.' > nmu inkscape_0.92.3-7 . ANY . -m 'Rebuild against imagemagick that > fixed ABI breakage.' > nmu pqiv_2.11-1 . ANY . -m 'Rebuild against imagemagick that fixed > ABI breakage.' > nmu vips_8.7.2-1 . ANY . -m 'Rebuild against imagemagick that fixed > ABI breakage.' The version number for emacs is too low, so it has not been rebuilt. This appears to have caused #918979, so can you please schedule a rebuild for it? nmu emacs_1:26.1+1-3 . ANY . -m 'Rebuild against imagemagick that fixed ABI breakage.' Cheers, Sven
Bug#918131: nmu: gnushogi_1.5~git20140725-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Please rebuild gnushogi in experimental, it still depends on libncurses5 rather than libncurses6. nmu gnushogi_1.5~git20140725-1 . ANY . experimental . -m "Rebuild against libncurses6." There are two more packages in experimental which depend on libncurses5, but they cannot be rebuilt due to #832330 and #915072. Please see #894049 for the libncurses6 transition.
Bug#885584: jessie-pu: package ncurses/5.9+20140913-1+deb8u3
On 2018-06-08 21:26 +0100, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Thu, 2017-12-28 at 11:43 +0100, Sven Joachim wrote: >> > The same problem with the same fix as in #885582 for stretch. > > Please go ahead. Apologies for the very long delay. Uploaded, thanks. Cheers, Sven
Bug#900514: nmu: gnucobol_2.2-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Another case of a package which was uploaded before the ncurses transition and got stuck in NEW for too long. nmu gnucobol_2.2-1 . amd64 . unstable . -m "Rebuild against libncurses6."
Bug#899064: nmu: smenu_0.9.12-1
Package: release.debian.org Severity: normal On amd64 only, the smenu package depends on libncurses5. Not the maintainer's fault, since the package is new and has been uploaded before the libncurses6 transition started. nmu smenu_0.9.12-1 . amd64 . unstable . -m "Rebuild against libncurses6."
Bug#894049: transition: ncurses
On 2018-05-12 21:15 +0200, Emilio Pozuelo Monfort wrote: > On 12/05/18 21:07, Sven Joachim wrote: >> My goal with that "! .package" part was to prevent the ncurses source >> package from being listed as "partial" which would have happened >> otherwise, because the binary packages libncursesw5 and libncurses5 >> still depend on libtinfo5. And this has apparently even worked. > > Ah, you are right. I was thinking of .source, which might have been easier > here > with & ! .source ~ /^ncurses$/. I don't use .source or .package much as I > don't > mind partial results (usually fixed by a decruft, though not in this case), > so I > had forgotten that we had both .source and .package, and assumed that .package > matched sources (which obviously makes little sense). So thanks for > instructing > me about that! Can you please update the transition tracker, replacing the is_bad regex with my last suggestion, i.e. the following? is_bad = .depends ~ /\b(lib32ncurses5|lib32ncursesw5|lib32tinfo5|lib64ncurses5|lib64tinfo5|libncurses5|libncursesw5|libtinfo5|libtinfo5\-udeb)([^-]|$)/ & ! .package ~ /\b(libncursesw5|libncurses5)\b/; > PS: I will continue with the binNMUs soon, once the libicu ones are done. Thanks! In related news, I have requested a binNMU for bash (#898500), since it was missing on the transition tracker. I didn't want to fight with ben to add pre-depends matches to the regexes. Cheers, Sven
Bug#898500: nmu: bash_4.4.18-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu The bash package is missing on the ncurses transition tracker[1] since it Pre-Depends rather than Depends on libtinfo5. Rather than fight with the ben syntax to add it there, I prefer to file a separate binNMU request which is easier for me to get right. nmu bash_4.4.18-2 . ANY . unstable . -m "Rebuild against libtinfo6." 1. https://release.debian.org/transitions/html/libncurses6.html
Bug#894049: transition: ncurses
On 2018-05-12 20:29 +0200, Emilio Pozuelo Monfort wrote: > On 12/05/18 10:59, Sven Joachim wrote: >> On 2018-05-12 09:46 +0200, Emilio Pozuelo Monfort wrote: >> >>> On 10/05/18 15:56, Sven Joachim wrote: >>>> On 2018-03-25 21:51 +0200, Sven Joachim wrote: >>>> >>>> This has turned out to be rather suboptimal, because the regexes match >>>> on libncurses5-dev etc, and so some packages are listed as partial or >>>> bad in the tracker[1] which should be good or unaffected. The ones >>>> below seem to be better, filtering out the -dev packages while still >>>> catching hardcoded dependencies such as #804579. >>>> >>>> title = "libncurses6"; >>>> is_affected = .depends ~ >>>> /\b(lib32ncurses6|lib32ncursesw6|lib32tinfo6|lib64ncurses6|lib64ncursesw6|lib64tinfo6|libncurses6|libncursesw6|libtinfo6|libtinfo6\-udeb|lib32ncurses5|lib32ncursesw5|lib32tinfo5|lib64ncurses5|lib64tinfo5|libncurses5|libncursesw5|libtinfo5|libtinfo5\-udeb)([^-]|$)/; >>>> is_good = .depends ~ >>>> /\b(lib32ncurses6|lib32ncursesw6|lib32tinfo6|lib64ncurses6|lib64ncursesw6|lib64tinfo6|libncurses6|libncursesw6|libtinfo6|libtinfo6\-udeb)\b/; >>>> is_bad = .depends ~ >>>> /\b(lib32ncurses5|lib32ncursesw5|lib32tinfo5|lib64ncurses5|lib64tinfo5|libncurses5|libncursesw5|libtinfo5|libtinfo5\-udeb)\b/ >>>> & ! .package ~ /\b(libncursesw5|libncurses5)([^-]|$)/; >>> >>> What do you want to achieve with this? >> >> Filter out packages which depend on libncurses5-dev or >> libncursesw5-dev, since changing their dependencies is out of the scope >> for this transition. For instance, cwidget is listed as "partial" in >> the tracker, and I think this is because libcwidget-dev depends on >> libncursesw5-dev. >> >> The trailing '$' is there to match cases like logol where there is a >> hardcoded dependency on libncursesw5. > > Sorry, I meant with the .package line that I quoted after the question. I > should > have made it clearer. The above change makes sense and I committed it to the > transition tracker. I have seen that, but the is_bad regex is still very much suboptimal because with it dependencies on libncursesw?5-dev are considered "bad". >>> & ! .package ~ /\b(libncursesw5|libncurses5)([^-]|$)/; >>> >>> I don't think that's doing what you want. >> >> Indeed not, thanks for checking. The line below is what I meant. >> >> is_bad = .depends ~ >> /\b(lib32ncurses5|lib32ncursesw5|lib32tinfo5|lib64ncurses5|lib64tinfo5|libncurses5|libncursesw5|libtinfo5|libtinfo5\-udeb)([^-]|$)/ >> & ! .package ~ /\b(libncursesw5|libncurses5)\b/; That "is_bad" regex was better, I think. >> Pardon my ignorance, but this is only the second time in my life where I >> worked^Wstruggled with ben files. And "ben monitor" only gives a list >> of affected packages, I can't really check what is "good" or "bad" wrt >> the state of the archive. :-( > > Maybe my question wasn't clear. Your " ! .package" part of the match is > basically a no-op (unless I'm misremembering the ben syntax). Basically that > full is_bad is doing something like "give me all packages that depend on one > of > these, but exclude src:libncursesw5 and src:libncurses5 from the is_bad set. > Since there are no such source packages, that part is basically doing nothing. According to the ben reference manual it matches _binary_ packages: , | * `is_bad`: matches binary packages that are considered to be broken | (not fixed) for this transition. ` > Since I don't know what you want to achieve with that, I can't suggest > something > that may work. :-) My goal with that "! .package" part was to prevent the ncurses source package from being listed as "partial" which would have happened otherwise, because the binary packages libncursesw5 and libncurses5 still depend on libtinfo5. And this has apparently even worked. Cheers, Sven
Bug#894049: transition: ncurses
On 2018-05-12 09:46 +0200, Emilio Pozuelo Monfort wrote: > On 10/05/18 15:56, Sven Joachim wrote: >> On 2018-03-25 21:51 +0200, Sven Joachim wrote: >> >> This has turned out to be rather suboptimal, because the regexes match >> on libncurses5-dev etc, and so some packages are listed as partial or >> bad in the tracker[1] which should be good or unaffected. The ones >> below seem to be better, filtering out the -dev packages while still >> catching hardcoded dependencies such as #804579. >> >> title = "libncurses6"; >> is_affected = .depends ~ >> /\b(lib32ncurses6|lib32ncursesw6|lib32tinfo6|lib64ncurses6|lib64ncursesw6|lib64tinfo6|libncurses6|libncursesw6|libtinfo6|libtinfo6\-udeb|lib32ncurses5|lib32ncursesw5|lib32tinfo5|lib64ncurses5|lib64tinfo5|libncurses5|libncursesw5|libtinfo5|libtinfo5\-udeb)([^-]|$)/; >> is_good = .depends ~ >> /\b(lib32ncurses6|lib32ncursesw6|lib32tinfo6|lib64ncurses6|lib64ncursesw6|lib64tinfo6|libncurses6|libncursesw6|libtinfo6|libtinfo6\-udeb)\b/; >> is_bad = .depends ~ >> /\b(lib32ncurses5|lib32ncursesw5|lib32tinfo5|lib64ncurses5|lib64tinfo5|libncurses5|libncursesw5|libtinfo5|libtinfo5\-udeb)\b/ >> & ! .package ~ /\b(libncursesw5|libncurses5)([^-]|$)/; > > What do you want to achieve with this? Filter out packages which depend on libncurses5-dev or libncursesw5-dev, since changing their dependencies is out of the scope for this transition. For instance, cwidget is listed as "partial" in the tracker, and I think this is because libcwidget-dev depends on libncursesw5-dev. The trailing '$' is there to match cases like logol where there is a hardcoded dependency on libncursesw5. > & ! .package ~ /\b(libncursesw5|libncurses5)([^-]|$)/; > > I don't think that's doing what you want. Indeed not, thanks for checking. The line below is what I meant. is_bad = .depends ~ /\b(lib32ncurses5|lib32ncursesw5|lib32tinfo5|lib64ncurses5|lib64tinfo5|libncurses5|libncursesw5|libtinfo5|libtinfo5\-udeb)([^-]|$)/ & ! .package ~ /\b(libncursesw5|libncurses5)\b/; Pardon my ignorance, but this is only the second time in my life where I worked^Wstruggled with ben files. And "ben monitor" only gives a list of affected packages, I can't really check what is "good" or "bad" wrt the state of the archive. :-( Cheers, Sven
Bug#894049: transition: ncurses
On 2018-03-25 21:51 +0200, Sven Joachim wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > I would like to start a transition for ncurses, changing the soname of > the libraries from 5 to 6. The results thus far look quite good, although a few bugs still need to ironed out, e.g. #898131. > Suggested ben file (please check if it is correct): > > title = "ncurses"; > is_affected = .depends ~ > /\b(lib32ncurses6|lib32ncursesw6|lib32tinfo6|lib64ncurses6|lib64ncursesw6|lib64tinfo6|libncurses6|libncursesw6|libtinfo6|libtinfo6\-udeb|lib32ncurses5|lib32ncursesw5|lib32tinfo5|lib64ncurses5|lib64tinfo5|libncurses5|libncursesw5|libtinfo5|libtinfo5\-udeb)\b/; > is_good = .depends ~ > /\b(lib32ncurses6|lib32ncursesw6|lib32tinfo6|lib64ncurses6|lib64ncursesw6|lib64tinfo6|libncurses6|libncursesw6|libtinfo6|libtinfo6\-udeb)\b/; > is_bad = .depends ~ > /\b(lib32ncurses5|lib32ncursesw5|lib32tinfo5|lib64ncurses5|lib64tinfo5|libncurses5|libncursesw5|libtinfo5|libtinfo5\-udeb)\b/ > & ! .package ~ /\b(libncursesw5|libncurses5)\b/; This has turned out to be rather suboptimal, because the regexes match on libncurses5-dev etc, and so some packages are listed as partial or bad in the tracker[1] which should be good or unaffected. The ones below seem to be better, filtering out the -dev packages while still catching hardcoded dependencies such as #804579. title = "libncurses6"; is_affected = .depends ~ /\b(lib32ncurses6|lib32ncursesw6|lib32tinfo6|lib64ncurses6|lib64ncursesw6|lib64tinfo6|libncurses6|libncursesw6|libtinfo6|libtinfo6\-udeb|lib32ncurses5|lib32ncursesw5|lib32tinfo5|lib64ncurses5|lib64tinfo5|libncurses5|libncursesw5|libtinfo5|libtinfo5\-udeb)([^-]|$)/; is_good = .depends ~ /\b(lib32ncurses6|lib32ncursesw6|lib32tinfo6|lib64ncurses6|lib64ncursesw6|lib64tinfo6|libncurses6|libncursesw6|libtinfo6|libtinfo6\-udeb)\b/; is_bad = .depends ~ /\b(lib32ncurses5|lib32ncursesw5|lib32tinfo5|lib64ncurses5|lib64tinfo5|libncurses5|libncursesw5|libtinfo5|libtinfo5\-udeb)\b/ & ! .package ~ /\b(libncursesw5|libncurses5)([^-]|$)/; Another small problem is that bash is missing on the tracker since it uses Pre-Depends rather than Depends. Should I try to fiddle more with the ben syntax, or file a separate binNMU request for bash? The latter would definitely be easier for me. Cheers, Sven 1. https://release.debian.org/transitions/html/libncurses6.html
Bug#894049: transition: ncurses
On 2018-05-06 08:32 +0200, Emilio Pozuelo Monfort wrote:
> On 06/05/18 02:05, peter green wrote:
>> I suspect fpc will also need a sourceful upload for the new ncurses. I would
>> recommend not binnmuing it until the maintainers have had chance to take a
>> look.
>
> It's not on https://release.debian.org/transitions/html/libncurses6.html so I
> wasn't planning on binNMUing it.
>
>> Is there a full list of differences between the version 5 and 6 ABIs
>> anywhere?
>> chtype has already been mentioned, are there any others?
>
> Cc'ing Sven for that.
The chtype and mmask_t types have both changed from unsigned long to
unsigned int in the new ncurses ABI, and NCURSES_MOUSE_VERSION has been
bumped from 1 to 2. AFAIK these are the only incompatible changes.
The fpc package should probably apply the attached patch and
build-depend on libncurses-dev (>= 6.1+20180210) to ensure that it gets
built against the new ABI.
That being said, ncurses.pp is based on ncurses 5.6 which is over eleven
years old. Somebody ought to update it upstream for ncurses 6.0 or
newer, I guess.
Cheers,
Sven
--- a/fpcsrc/packages/ncurses/src/ncurses.pp 2015-06-18 10:59:10.0 +0200
+++ b/fpcsrc/packages/ncurses/src/ncurses.pp 2018-05-06 08:46:48.731837657 +0200
@@ -69,13 +69,13 @@ const
NCURSES_VERSION_MINOR = 6;
NCURSES_VERSION_PATCH = 20061217;
NCURSES_VERSION = '5.6';
- NCURSES_MOUSE_VERSION = 1;
+ NCURSES_MOUSE_VERSION = 2;
type
pchtype = ^chtype;
- chtype = culong;
+ chtype = cuint;
pmmask_t = ^mmask_t;
- mmask_t = culong;
+ mmask_t = cuint;
{ colors }
var
Bug#894049: transition: ncurses
On 2018-04-30 19:00 +0200, Emilio Pozuelo Monfort wrote: > On 25/03/18 21:51, Sven Joachim wrote: >> Package: release.debian.org >> Severity: normal >> User: release.debian@packages.debian.org >> Usertags: transition >> >> I would like to start a transition for ncurses, changing the soname of >> the libraries from 5 to 6. > > You dropped lib32tinfo-dev but lib32readline-dev depends on it. Yes, but lib32ncurses-dev Provides/Replaces/Conflicts lib32tinfo-dev. > Can you advise on what to do there? Decrufting the binary packages no longer built from src:ncurses should help, I think. Thanks for managing the ncurses transition! Cheers, Sven
Bug#894049: transition: ncurses
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition I would like to start a transition for ncurses, changing the soname of the libraries from 5 to 6. This affects a large number of packages (about 600 of them), but should be doable almost exclusively via binNMUs, with two exceptions: - libcdk5 needs a sourceful upload and a rename of the library package, neither this package nor its three reverse dependencies should be rebuilt before that. Please see https://bugs.debian.org/892280 and https://release.debian.org/transitions/html/auto-libcdk5.html. - cwidget also needs a sourceful upload and either a package rename or a shlibs bump + versioned Breaks against aptitude, please see https://bugs.debian.org/891161 for details. Fortunately both cwidget and aptitude currently FTBFS with libncursesw6, so there is no danger of incompatible combinations after binNMUs. The packages libtinfo5, libncurses5 and libncursesw5 are still built, so only packages depending on the multilib packages and the udeb become uninstallable and need to be rebuilt right away: grub, readline and screen. Apart from cwidget/aptitude, I have not noticed any ncurses related FTBFS bugs, and the API is unchanged. However, there will certainly be quite a few unrelated FTBFS problems, such as the recent switch to openjdk-9 and the python3.6/python3-distutils breakage. Suggested ben file (please check if it is correct): title = "ncurses"; is_affected = .depends ~ /\b(lib32ncurses6|lib32ncursesw6|lib32tinfo6|lib64ncurses6|lib64ncursesw6|lib64tinfo6|libncurses6|libncursesw6|libtinfo6|libtinfo6\-udeb|lib32ncurses5|lib32ncursesw5|lib32tinfo5|lib64ncurses5|lib64tinfo5|libncurses5|libncursesw5|libtinfo5|libtinfo5\-udeb)\b/; is_good = .depends ~ /\b(lib32ncurses6|lib32ncursesw6|lib32tinfo6|lib64ncurses6|lib64ncursesw6|lib64tinfo6|libncurses6|libncursesw6|libtinfo6|libtinfo6\-udeb)\b/; is_bad = .depends ~ /\b(lib32ncurses5|lib32ncursesw5|lib32tinfo5|lib64ncurses5|lib64tinfo5|libncurses5|libncursesw5|libtinfo5|libtinfo5\-udeb)\b/ & ! .package ~ /\b(libncursesw5|libncurses5)\b/; Thanks for your consideration, Sven signature.asc Description: PGP signature
Bug#893828: nmu: unintended ruby dependencies
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Some packages built from the libprelude and redland-bindings sources have gained spurious dependencies on ruby due to #892131. They should be rebuilt with gem2deb 0.38.1, which on some architectures is not yet available. nmu libprelude_4.1.0-4 . ANY . unstable . -m "Rebuild with fixed gem2deb (see #892131)." dw libprelude_4.1.0-4 . ANY . -m 'gem2deb (>= 0.38.1)' nmu redland-bindings_1.0.17.1+dfsg-1.3 . ANY -alpha -hppa -hurd-i386 -kfreebsd-amd64 -kfreebsd-i386 -mipsel -powerpcspe . unstable . -m "Rebuild with fixed gem2deb (see #892131)." dw redland-bindings_1.0.17.1+dfsg-1.3 . ANY . -m 'gem2deb (>= 0.38.1)'
Bug#885582: stretch-pu: package ncurses/6.0+20161126-1+deb9u2
On 2018-02-11 09:45 +0100, Julien Cristau wrote: > Control: tag -1 - moreinfo > Control: tag -1 confirmed > > On Sat, Feb 10, 2018 at 11:08:37 +0100, Julien Cristau wrote: > >> Control: tag -1 moreinfo >> > Got that one wrong, sorry. Thanks, uploaded. Cheers, Sven
Bug#885582: stretch-pu: package ncurses/6.0+20161126-1+deb9u2
On 2018-02-10 11:08 +0100, Julien Cristau wrote:
> Control: tag -1 moreinfo
> [...]
> Thanks, go ahead.
This is contradictory. Did you meant to tag the bug "confirmed" rather
than "moreinfo"?
>> +--- a/ncurses/tinfo/write_entry.c
>> b/ncurses/tinfo/write_entry.c
>> +@@ -267,6 +267,9 @@ _nc_write_entry(TERMTYPE *const tp)
>> + #endif
>> + #endif /* USE_SYMLINKS */
>> +
>> ++unsigned limit2 = sizeof(filename) - (2 + LEAF_LEN);
>> ++char saved = '\0';
>> ++
>> + static int call_count;
>> + static time_t start_time; /* time at start of writes */
>> +
>> +@@ -365,12 +368,18 @@ _nc_write_entry(TERMTYPE *const tp)
>> +start_time = 0;
>> + }
>> +
>> +-if (strlen(first_name) >= sizeof(filename) - (2 + LEAF_LEN))
>> ++if (strlen(first_name) >= sizeof(filename) - (2 + LEAF_LEN)) {
>
> kind of curious that limit2 wasn't used here...
Good point, I reported this upstream:
https://lists.gnu.org/archive/html/bug-ncurses/2018-02/msg00016.html.
Cheers,
Sven
Bug#885584: jessie-pu: package ncurses/5.9+20140913-1+deb8u3
Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu
The same problem with the same fix as in #885582 for stretch.
Cheers,
Sven
diff -Nru ncurses-5.9+20140913/debian/changelog ncurses-5.9+20140913/debian/changelog
--- ncurses-5.9+20140913/debian/changelog 2017-12-03 11:20:45.0 +0100
+++ ncurses-5.9+20140913/debian/changelog 2017-12-28 11:14:57.0 +0100
@@ -1,3 +1,11 @@
+ncurses (5.9+20140913-1+deb8u3) jessie; urgency=medium
+
+ * Cherry-pick upstream fix from the 20171125 patchlevel to fix
+a buffer overflow in the _nc_write_entry function
+(CVE-2017-16879, Closes: #882620).
+
+ -- Sven Joachim <svenj...@gmx.de> Thu, 28 Dec 2017 11:14:57 +0100
+
ncurses (5.9+20140913-1+deb8u2) jessie; urgency=medium
* Re-upload with no changes to work around #826161.
diff -Nru ncurses-5.9+20140913/debian/patches/cve-2017-16879.diff ncurses-5.9+20140913/debian/patches/cve-2017-16879.diff
--- ncurses-5.9+20140913/debian/patches/cve-2017-16879.diff 1970-01-01 01:00:00.0 +0100
+++ ncurses-5.9+20140913/debian/patches/cve-2017-16879.diff 2017-12-28 10:53:47.0 +0100
@@ -0,0 +1,44 @@
+Author: Sven Joachim <svenj...@gmx.de>
+Description: Fix for CVE-2017-16879 in the _nc_write_entry function
+ Fix for CVE-2017-16879 cherry-picked from upstream patchlevel
+ 20171125.
+Bug-Debian: https://bugs.debian.org/882620
+Forwarded: not-needed
+Last-Update: 2017-11-27
+
+---
+ ncurses/tinfo/write_entry.c | 11 ++-
+ 1 file changed, 10 insertions(+), 1 deletion(-)
+
+--- a/ncurses/tinfo/write_entry.c
b/ncurses/tinfo/write_entry.c
+@@ -268,6 +268,9 @@ _nc_write_entry(TERMTYPE *const tp)
+ #endif
+ #endif /* USE_SYMLINKS */
+
++unsigned limit2 = sizeof(filename) - (2 + LEAF_LEN);
++char saved = '\0';
++
+ static int call_count;
+ static time_t start_time; /* time at start of writes */
+
+@@ -366,12 +369,18 @@ _nc_write_entry(TERMTYPE *const tp)
+ start_time = 0;
+ }
+
+-if (strlen(first_name) >= sizeof(filename) - (2 + LEAF_LEN))
++if (strlen(first_name) >= sizeof(filename) - (2 + LEAF_LEN)) {
+ _nc_warning("terminal name too long.");
++ saved = first_name[limit2];
++ first_name[limit2] = '\0';
++}
+
+ _nc_SPRINTF(filename, _nc_SLIMIT(sizeof(filename))
+ LEAF_FMT "/%s", first_name[0], first_name);
+
++if (saved)
++ first_name[limit2] = saved;
++
+ /*
+ * Has this primary name been written since the first call to
+ * write_entry()? If so, the newer write will step on the older,
diff -Nru ncurses-5.9+20140913/debian/patches/series ncurses-5.9+20140913/debian/patches/series
--- ncurses-5.9+20140913/debian/patches/series 2017-12-01 10:17:11.0 +0100
+++ ncurses-5.9+20140913/debian/patches/series 2017-12-28 10:53:47.0 +0100
@@ -5,3 +5,4 @@
termcap-fix.diff
more-cve-fixes.diff
cve-2017-13733.diff
+cve-2017-16879.diff
Bug#885582: stretch-pu: package ncurses/6.0+20161126-1+deb9u2
Package: release.debian.org
Severity: normal
Tags: stretch d-i
User: release.debian@packages.debian.org
Usertags: pu
I would like to fix bug #882620 aka CVE-2017-16879 in stretch, a buffer
overflow in the _nc_write_entry function.
While this touches the tinfo library used in the installer,
_nc_write_entry() is only used by tic as far as I am aware.
Cheers,
Sven
diff -Nru ncurses-6.0+20161126/debian/changelog ncurses-6.0+20161126/debian/changelog
--- ncurses-6.0+20161126/debian/changelog 2017-09-07 19:05:43.0 +0200
+++ ncurses-6.0+20161126/debian/changelog 2017-12-28 10:47:33.0 +0100
@@ -1,3 +1,11 @@
+ncurses (6.0+20161126-1+deb9u2) stretch; urgency=medium
+
+ * Cherry-pick upstream fix from the 20171125 patchlevel to fix
+a buffer overflow in the _nc_write_entry function
+(CVE-2017-16879, Closes: #882620).
+
+ -- Sven Joachim <svenj...@gmx.de> Thu, 28 Dec 2017 10:47:33 +0100
+
ncurses (6.0+20161126-1+deb9u1) stretch; urgency=medium
* Cherry-pick upstream fixes from the 20170701 and 20170708 patchlevels
diff -Nru ncurses-6.0+20161126/debian/patches/cve-2017-16879.diff ncurses-6.0+20161126/debian/patches/cve-2017-16879.diff
--- ncurses-6.0+20161126/debian/patches/cve-2017-16879.diff 1970-01-01 01:00:00.0 +0100
+++ ncurses-6.0+20161126/debian/patches/cve-2017-16879.diff 2017-12-28 10:32:23.0 +0100
@@ -0,0 +1,44 @@
+Author: Sven Joachim <svenj...@gmx.de>
+Description: Fix for CVE-2017-16879 in the _nc_write_entry function
+ Fix for CVE-2017-16879 cherry-picked from upstream patchlevel
+ 20171125.
+Bug-Debian: https://bugs.debian.org/882620
+Forwarded: not-needed
+Last-Update: 2017-11-27
+
+---
+ ncurses/tinfo/write_entry.c | 11 ++-
+ 1 file changed, 10 insertions(+), 1 deletion(-)
+
+--- a/ncurses/tinfo/write_entry.c
b/ncurses/tinfo/write_entry.c
+@@ -267,6 +267,9 @@ _nc_write_entry(TERMTYPE *const tp)
+ #endif
+ #endif /* USE_SYMLINKS */
+
++unsigned limit2 = sizeof(filename) - (2 + LEAF_LEN);
++char saved = '\0';
++
+ static int call_count;
+ static time_t start_time; /* time at start of writes */
+
+@@ -365,12 +368,18 @@ _nc_write_entry(TERMTYPE *const tp)
+ start_time = 0;
+ }
+
+-if (strlen(first_name) >= sizeof(filename) - (2 + LEAF_LEN))
++if (strlen(first_name) >= sizeof(filename) - (2 + LEAF_LEN)) {
+ _nc_warning("terminal name too long.");
++ saved = first_name[limit2];
++ first_name[limit2] = '\0';
++}
+
+ _nc_SPRINTF(filename, _nc_SLIMIT(sizeof(filename))
+ LEAF_FMT "/%s", first_name[0], first_name);
+
++if (saved)
++ first_name[limit2] = saved;
++
+ /*
+ * Has this primary name been written since the first call to
+ * write_entry()? If so, the newer write will step on the older,
diff -Nru ncurses-6.0+20161126/debian/patches/series ncurses-6.0+20161126/debian/patches/series
--- ncurses-6.0+20161126/debian/patches/series 2017-09-07 19:05:43.0 +0200
+++ ncurses-6.0+20161126/debian/patches/series 2017-12-28 10:32:23.0 +0100
@@ -5,3 +5,4 @@
termcap-fix.diff
more-cve-fixes.diff
cve-2017-13733.diff
+cve-2017-16879.diff
Bug#879529: transition: perl 5.26.1
On 2017-10-26 10:18 +0200, Emilio Pozuelo Monfort wrote: > On 26/10/17 09:13, Niko Tyni wrote: >> On Mon, Oct 23, 2017 at 09:15:35PM +0200, Emilio Pozuelo Monfort wrote: >>> Control: tags -1 confirmed perl 5.26.1-1 is in experimental. It is binary compatible with 5.26.0 and therefore Provides both perlapi-5.26.0 and perlapi-5.26.1. However, four binNMUs will be needed once it enters unstable due to their strict versioned dependencies on the current perl version: libpar-packer-perl libdevel-cover-perl libclass-xsaccessor-perl libcommon-sense-perl Please let us know if/when it's OK to upload. >>> >>> Please go ahead. >> >> Thanks, now uploaded and built on all architectures. >> Could you please schedule the binNMUs. > > Scheduled. It seems that something went wrong here and perl was not upgraded to 5.26.1 on the buildd chroots, meaning the binNMUs were wasted. :-( Cheers, Sven
Bug#867814: stretch-pu: package ncurses/6.0+20161126-1+deb9u1
On 2017-09-23 19:59 +0100, Adam D. Barratt wrote:
> Control: tags -1 -moreinfo +confirmed
>
> On Thu, 2017-09-07 at 19:06 +0200, Cyril Brulebois wrote:
>> Sven Joachim <svenj...@gmx.de> (2017-09-06):
>> > Meanwhile seven new CVEs in the tic library and programs have been
>> > reported, and I would like to fix those as well, see the attached
>> > new
>> > debdiff. It contains all the library changes from the 20170826
>> > upstream
>> > patchlevel and the program fixes of the 20170902 patchlevel. I
>> > have
>> > also attached the test cases for the 13 bugs reported in the Red
>> > Hat
>> > bugtracker.
>> >
>> > > > > 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.
>> >
>> > This is unfortunately no longer the case, since strings.c and
>> > trim_sgr0.c are compiled into the tinfo library. However, the
>> > changes
>> > to these files are small.
>>
>> I have no straightforward way to double check things still run
>> smoothly
>> with stretch's d-i, so I'll follow whatever decision the release team
>> makes; if regressions pop up, we'll figure out how to fix them.
>>
>
> Let's go with it and keep our fingers crossed that any issues show up
> quickly.
Thanks, uploaded.
Cheers,
Sven
Bug#867814: stretch-pu: package ncurses/6.0+20161126-1+deb9u1
On 2017-09-09 15:08 +0200, Julien Cristau wrote: > Do you know what the reverse dependencies of the tic program or library > are in Debian, Short answer: I don't know. Long answer: The tic library is used by tack and a few programs in ncurses-bin (tic and its aliases infotocap/captoinfo, infocmp and toe). I am not aware of any others, but there might be one or two. For the programs, infocmp is commonly used by Perl's Term::Cap module which in turn is used by other Perl modules, so by quite a few packages. It only runs infocmp on the terminfo description pointed to by the TERM variable. There are 40+ other hits for infocmp on codesearch.debian.net, I have not really checked them. Apparently captoinfo and infotocap have no reverse dependencies. For tic and toe, it is impossible to check due to their short names. :-( If you run tic with common arguments as a normal user, it will write to the ~/.terminfo directory, creating it if necessary. I don't have this directory which indicates that third parties don't run tic behind my back, but then again I have only a fraction of all packages installed. > and whether any of them commonly process untrusted > terminfo data (though I know that's not an easy thing to paint as > black/white)? If I had known such a program, I would have asked for a DSA after all. So I don't know, but my knowledge is limited and Debian is large. Cheers, Sven
Bug#867814: stretch-pu: package ncurses/6.0+20161126-1+deb9u1
On 2017-09-07 05:32 +0200, Salvatore Bonaccorso wrote: > Not a must, and note that is just a comment on my side, I'm not a SRM: > if possible add a bug closer as well to the changelog entry so that > when the point release happends, the correct fixed version is as well > propagated to the BTS bugs. Heh, it was you who had marked these bugs as found in 6.0+20170715-2 in the first place. ;-) Anyway, I have updated the changelog and also fixed a typo in it. diff --git a/debian/changelog b/debian/changelog index 160b2cb1..a75f99e6 100644 --- a/debian/changelog +++ b/debian/changelog @@ -7,11 +7,12 @@ ncurses (6.0+20161126-1+deb9u1) stretch; urgency=medium regression from the above security fixes (see #868266). * Cherry-pick upstream fixes from the 20170826 patchlevel for more crash bugs in the tic library (CVE-2017-13728, CVE-2017-13729, -CVE-2017-13730, CVE-2017-13731, CVE-2017-13732, CVE-2017-13734). - * Cerry-pick upstream fixes from the 20170902 patchlevel to fix -another crash bug in the tic program (CVE-2017-13733). +CVE-2017-13730, CVE-2017-13731, CVE-2017-13732, CVE-2017-13734, +Closes: #873723). + * Cherry-pick upstream fixes from the 20170902 patchlevel to fix +another crash bug in the tic program (CVE-2017-13733, Closes: #873746). - -- Sven Joachim <svenj...@gmx.de> Mon, 04 Sep 2017 22:04:15 +0200 + -- Sven Joachim <svenj...@gmx.de> Thu, 07 Sep 2017 19:05:43 +0200 ncurses (6.0+20161126-1) unstable; urgency=low If a new full debdiff is wanted, please say so. Cheers, Sven
Bug#867817: jessie-pu: package ncurses/5.9+20140913-1+deb8u1
On 2017-08-12 19:24 +0200, Sven Joachim wrote:
> Control: tags -1 - moreinfo
>
> On 2017-07-15 12:54 +0200, Sven Joachim wrote:
>
>> On 2017-07-15 11:38 +0100, Adam D. Barratt wrote:
>>
>>> Control: tags -1 + confirmed
>>>
>>> On Sun, 2017-07-09 at 19:40 +0200, Sven Joachim wrote:
>>>> The same problem as in #867814 for stretch and almost the same fix,
>>>> except that one inapplicable hunk has been removed from the patch.
>>>
>>> Please go ahead.
>>
>> Same answer as in #867814, the fallout from #868266 needs to be sorted
>> out first → no upload this weekend, defer for 8.10.
>
> Unfortunately the fixes from the 20170715 patchlevel were rather large
> and not easily backportable to jessie, but finally openSUSE[1] has come
> up with a patch that I have stolen. The output of "infocmp -C" slightly
> differs from the one in currently in jessie, but I think there are no
> functional differences. At least perldoc works fine.
As in #867814, I would like to fix the seven new CVEs 2017-137{28..34}
as well. The two additional patches are the same as the ones for
stretch (modulo line numbers, since I ran "quilt refresh").
Cheers,
Sven
diff -Nru ncurses-5.9+20140913/debian/changelog ncurses-5.9+20140913/debian/changelog
--- ncurses-5.9+20140913/debian/changelog 2014-09-17 19:00:57.0 +0200
+++ ncurses-5.9+20140913/debian/changelog 2017-09-06 17:11:59.0 +0200
@@ -1,3 +1,18 @@
+ncurses (5.9+20140913-1+deb8u1) jessie; 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).
+ * Apply termcap-format fix from openSUSE's ncurses-5.9-55.6.1 package,
+repairing a regression from the above security fixes (see #868266).
+ * Cherry-pick upstream fixes from the 20170826 patchlevel for more
+crash bugs in the tic library (CVE-2017-13728, CVE-2017-13729,
+CVE-2017-13730, CVE-2017-13731, CVE-2017-13732, CVE-2017-13734).
+ * Cerry-pick upstream fixes from the 20170902 patchlevel to fix
+another crash bug in the tic program (CVE-2017-13733).
+
+ -- Sven Joachim <svenj...@gmx.de> Wed, 06 Sep 2017 17:11:59 +0200
+
ncurses (5.9+20140913-1) unstable; urgency=low
* New upstream patchlevel.
diff -Nru ncurses-5.9+20140913/debian/patches/cve-2017-13733.diff ncurses-5.9+20140913/debian/patches/cve-2017-13733.diff
--- ncurses-5.9+20140913/debian/patches/cve-2017-13733.diff 1970-01-01 01:00:00.0 +0100
+++ ncurses-5.9+20140913/debian/patches/cve-2017-13733.diff 2017-09-06 17:11:59.0 +0200
@@ -0,0 +1,91 @@
+Author: Sven Joachim <svenj...@gmx.de>
+Description: Fix for CVE-2017-13733 in the tic program
+ Fix for CVE-2017-13733 cherry-picked from upstream patchlevel
+ 20170902.
+Bug-Debian: https://bugs.debian.org/873746
+Bug-RedHat: https://bugzilla.redhat.com/show_bug.cgi?id=1484290
+Forwarded: not-needed
+Last-Update: 2017-09-06
+
+---
+ progs/dump_entry.c | 19 ++-
+ progs/tput.c |2 +-
+ 2 files changed, 11 insertions(+), 10 deletions(-)
+
+--- a/progs/dump_entry.c
b/progs/dump_entry.c
+@@ -722,12 +722,12 @@ fmt_entry(TERMTYPE *tterm,
+ #undef CUR
+ #define CUR tterm->
+ if (outform == F_TERMCAP) {
+- if (termcap_reset != ABSENT_STRING) {
+- if (init_3string != ABSENT_STRING
++ if (VALID_STRING(termcap_reset)) {
++ if (VALID_STRING(init_3string)
+ && !strcmp(init_3string, termcap_reset))
+ DISCARD(init_3string);
+
+- if (reset_2string != ABSENT_STRING
++ if (VALID_STRING(reset_2string)
+ && !strcmp(reset_2string, termcap_reset))
+ DISCARD(reset_2string);
+ }
+@@ -799,7 +799,7 @@ fmt_entry(TERMTYPE *tterm,
+ buffer[0] = '\0';
+
+ if (predval != FAIL) {
+- if (capability != ABSENT_STRING
++ if (VALID_STRING(capability)
+ && i + 1 > num_strings)
+ num_strings = i + 1;
+
+@@ -877,8 +877,7 @@ fmt_entry(TERMTYPE *tterm,
+ }
+ }
+ /* e.g., trimmed_sgr0 */
+- if (capability != ABSENT_STRING &&
+- capability != CANCELLED_STRING &&
++ if (VALID_STRING(capability) &&
+ capability != tterm->Strings[i])
+ free(capability);
+ }
+@@ -1047,7 +1046,8 @@ kill_labels(TERMTYPE *tterm, int target)
+
+ for (n = 0; n <= 10; ++n) {
+ _nc_SPRINTF(name, _nc_SLIMIT(sizeof(name)) "lf%d", n);
+- if ((cap = find_string(tterm, name)) != ABSENT_STRING
++ cap = find_string(tterm, name);
++ if (VALID_STRING(cap)
+ && kill_string(tterm, cap)) {
+ target -= (int) (strlen(cap) + 5);
+ ++result;
+@@ -1072,7 +1072,8 @@ kill_fkeys(TERMTYPE *tterm, int target)
+
+ for (n = 60; n >= 0; --n) {
+ _nc_SPRINTF(name, _nc_SLIMIT(sizeof(name)) "kf%d", n);
+- if ((cap = find_
Bug#867814: stretch-pu: package ncurses/6.0+20161126-1+deb9u1
On 2017-07-19 20:30 +0200, Sven Joachim wrote:
> 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.
Meanwhile seven new CVEs in the tic library and programs have been
reported, and I would like to fix those as well, see the attached new
debdiff. It contains all the library changes from the 20170826 upstream
patchlevel and the program fixes of the 20170902 patchlevel. I have
also attached the test cases for the 13 bugs reported in the Red Hat
bugtracker.
>>> 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.
This is unfortunately no longer the case, since strings.c and
trim_sgr0.c are compiled into the tinfo library. However, the changes
to these files are small.
Cheers,
Sven
diff -Nru ncurses-6.0+20161126/debian/changelog ncurses-6.0+20161126/debian/changelog
--- ncurses-6.0+20161126/debian/changelog 2016-11-29 21:19:08.0 +0100
+++ ncurses-6.0+20161126/debian/changelog 2017-09-04 22:04:15.0 +0200
@@ -1,3 +1,18 @@
+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).
+ * Cherry-pick upstream fixes from the 20170826 patchlevel for more
+crash bugs in the tic library (CVE-2017-13728, CVE-2017-13729,
+CVE-2017-13730, CVE-2017-13731, CVE-2017-13732, CVE-2017-13734).
+ * Cerry-pick upstream fixes from the 20170902 patchlevel to fix
+another crash bug in the tic program (CVE-2017-13733).
+
+ -- Sven Joachim <svenj...@gmx.de> Mon, 04 Sep 2017 22:04:15 +0200
+
ncurses (6.0+20161126-1) unstable; urgency=low
* New upstream patchlevel.
diff -Nru ncurses-6.0+20161126/debian/patches/cve-2017-13733.diff ncurses-6.0+20161126/debian/patches/cve-2017-13733.diff
--- ncurses-6.0+20161126/debian/patches/cve-2017-13733.diff 1970-01-01 01:00:00.0 +0100
+++ ncurses-6.0+20161126/debian/patches/cve-2017-13733.diff 2017-09-04 22:04:15.0 +0200
@@ -0,0 +1,91 @@
+Author: Sven Joachim <svenj...@gmx.de>
+Description: Fix for CVE-2017-13733 in the tic program
+ Fix for CVE-2017-13733 cherry-picked from upstream patchlevel
+ 20170902.
+Bug-Debian: https://bugs.debian.org/873746
+Bug-RedHat: https://bugzilla.redhat.com/show_bug.cgi?id=1484290
+Forwarded: not-needed
+Last-Update: 2017-09-04
+
+---
+ progs/dump_entry.c | 19 ++-
+ progs/tput.c |2 +-
+ 2 files changed, 11 insertions(+), 10 deletions(-)
+
+--- a/progs/dump_entry.c
b/progs/dump_entry.c
+@@ -957,12 +957,12 @@ fmt_entry(TERMTYPE *tterm,
+ #undef CUR
+ #define CUR tterm->
+ if (outform == F_TERMCAP) {
+- if (termcap_reset != ABSENT_STRING) {
+- if (init_3string != ABSENT_STRING
++ if (VALID_STRING(termcap_reset)) {
++ if (VALID_STRING(init_3string)
+ && !strcmp(init_3string, termcap_reset))
+ DISCARD(init_3string);
+
+- if (reset_2string != ABSENT_STRING
++ if (VALID_STRING(reset_2string)
+
Bug#867817: jessie-pu: package ncurses/5.9+20140913-1+deb8u1
Control: tags -1 - moreinfo
On 2017-07-15 12:54 +0200, Sven Joachim wrote:
> On 2017-07-15 11:38 +0100, Adam D. Barratt wrote:
>
>> Control: tags -1 + confirmed
>>
>> On Sun, 2017-07-09 at 19:40 +0200, Sven Joachim wrote:
>>> The same problem as in #867814 for stretch and almost the same fix,
>>> except that one inapplicable hunk has been removed from the patch.
>>
>> Please go ahead.
>
> Same answer as in #867814, the fallout from #868266 needs to be sorted
> out first → no upload this weekend, defer for 8.10.
Unfortunately the fixes from the 20170715 patchlevel were rather large
and not easily backportable to jessie, but finally openSUSE[1] has come
up with a patch that I have stolen. The output of "infocmp -C" slightly
differs from the one in currently in jessie, but I think there are no
functional differences. At least perldoc works fine.
Cheers,
Sven
1. https://bugzilla.opensuse.org/show_bug.cgi?id=1049344
diff -Nru ncurses-5.9+20140913/debian/changelog ncurses-5.9+20140913/debian/changelog
--- ncurses-5.9+20140913/debian/changelog 2014-09-17 19:00:57.0 +0200
+++ ncurses-5.9+20140913/debian/changelog 2017-07-09 16:26:16.0 +0200
@@ -1,3 +1,13 @@
+ncurses (5.9+20140913-1+deb8u1) UNRELEASED; 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).
+ * Apply termcap-format fix from openSUSE's ncurses-5.9-55.6.1 package,
+repairing a regression from the above security fixes (see #868266).
+
+ -- Sven Joachim <svenj...@gmx.de> Sun, 09 Jul 2017 16:26:16 +0200
+
ncurses (5.9+20140913-1) unstable; urgency=low
* New upstream patchlevel.
diff -Nru ncurses-5.9+20140913/debian/patches/cve-fixes.diff ncurses-5.9+20140913/debian/patches/cve-fixes.diff
--- ncurses-5.9+20140913/debian/patches/cve-fixes.diff 1970-01-01 01:00:00.0 +0100
+++ ncurses-5.9+20140913/debian/patches/cve-fixes.diff 2017-07-09 16:26:16.0 +0200
@@ -0,0 +1,173 @@
+Author: Sven Joachim <svenj...@gmx.de>
+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 | 30 +++---
+ 3 files changed, 36 insertions(+), 22 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 (entryp->nuses > 1 && is_tc) {
++ BAD_TC_USAGE
++ }
+ }
+ } else {
+ /* normal token lookup */
+@@ -571,7 +574,7 @@ append_acs0(string_desc * dst, int code,
+ static void
+ append_acs(string_desc * dst, int code, char *src)
+ {
+-if (src != 0 && strlen(src) == 1) {
++if (VALID_STRING(src) && strlen(src) == 1) {
+ append_acs0(dst, code, *src);
+ }
+ }
+@@ -829,1
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 <svenj...@gmx.de> 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.00000 +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 <svenj...@gmx.de>
+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);
Bug#867817: jessie-pu: package ncurses/5.9+20140913-1+deb8u1
Control: tags -1 = moreinfo On 2017-07-15 11:38 +0100, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Sun, 2017-07-09 at 19:40 +0200, Sven Joachim wrote: >> The same problem as in #867814 for stretch and almost the same fix, >> except that one inapplicable hunk has been removed from the patch. > > Please go ahead. Same answer as in #867814, the fallout from #868266 needs to be sorted out first → no upload this weekend, defer for 8.10. Cheers, Sven
Bug#867814: stretch-pu: package ncurses/6.0+20161126-1+deb9u1
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. > 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. Cheers, Sven
Bug#867817: jessie-pu: package ncurses/5.9+20140913-1+deb8u1
Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu
The same problem as in #867814 for stretch and almost the same fix,
except that one inapplicable hunk has been removed from the patch.
Cheers,
Sven
diff -Nru ncurses-5.9+20140913/debian/changelog ncurses-5.9+20140913/debian/changelog
--- ncurses-5.9+20140913/debian/changelog 2014-09-17 19:00:57.0 +0200
+++ ncurses-5.9+20140913/debian/changelog 2017-07-09 16:26:16.0 +0200
@@ -1,3 +1,11 @@
+ncurses (5.9+20140913-1+deb8u1) jessie; 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).
+
+ -- Sven Joachim <svenj...@gmx.de> Sun, 09 Jul 2017 16:26:16 +0200
+
ncurses (5.9+20140913-1) unstable; urgency=low
* New upstream patchlevel.
diff -Nru ncurses-5.9+20140913/debian/patches/cve-fixes.diff ncurses-5.9+20140913/debian/patches/cve-fixes.diff
--- ncurses-5.9+20140913/debian/patches/cve-fixes.diff 1970-01-01 01:00:00.0 +0100
+++ ncurses-5.9+20140913/debian/patches/cve-fixes.diff 2017-07-09 16:26:16.0 +0200
@@ -0,0 +1,173 @@
+Author: Sven Joachim <svenj...@gmx.de>
+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 | 30 +++---
+ 3 files changed, 36 insertions(+), 22 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 (entryp->nuses > 1 && is_tc) {
++ BAD_TC_USAGE
++ }
+ }
+ } else {
+ /* normal token lookup */
+@@ -571,7 +574,7 @@ append_acs0(string_desc * dst, int code,
+ static void
+ append_acs(string_desc * dst, int code, char *src)
+ {
+-if (src != 0 && strlen(src) == 1) {
++if (VALID_STRING(src) && strlen(src) == 1) {
+ append_acs0(dst, code, *src);
+ }
+ }
+@@ -829,15 +832,14 @@ postprocess_termcap(TERMTYPE *tp, bool h
+ }
+
+ if (tp->Strings[to_ptr->nte_index]) {
++ const char *s = tp->Strings[from_ptr->nte_index];
++ const char *t = tp->Strings[to_ptr->nte_index];
+ /* There's no point in warning about it if it's the same
+ * string; that's just an inefficiency.
+ */
+- if (strcmp(
+- tp->Strings[from_ptr->nte_index],
+- tp->Strings[to_ptr->nte_index]) != 0)
++ if (VALID_STRING(s) && VALID_STRING(t) && strcmp(s, t) != 0)
+ _nc_warning("%s (%s) already has an explicit value %s, ignoring ko",
+-ap->to, ap->from,
+-_nc_visbuf(tp->Strings[to_ptr->nte_index]));
++ap->to, ap->from, t);
+ continue;
+ }
+
+--- a/progs/dump_entry.c
b/progs/dump_entry.c
+@@ -609,9 +609,10 @@ fmt_entry(TERMTYPE *tterm,
+ Pre
Bug#867814: stretch-pu: package ncurses/6.0+20161126-1+deb9u1
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
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.
Upstream has fixed these problems in the latest patchlevels (already in
sid), and I would like to address them in a stable upload. I have
verified that the testcases in the reported Red Hat bugs no longer cause
crashes (if anybody wants to verify that, I can send them).
Cheers,
Sven
diff -Nru ncurses-6.0+20161126/debian/changelog ncurses-6.0+20161126/debian/changelog
--- ncurses-6.0+20161126/debian/changelog 2016-11-29 21:19:08.0 +0100
+++ ncurses-6.0+20161126/debian/changelog 2017-07-09 15:32:26.0 +0200
@@ -1,3 +1,11 @@
+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).
+
+ -- Sven Joachim <svenj...@gmx.de> Sun, 09 Jul 2017 15:32:26 +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-09 15:32:26.0 +0200
@@ -0,0 +1,185 @@
+Author: Sven Joachim <svenj...@gmx.de>
+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 (entryp->nuses > 1 && is_tc) {
++ BAD_TC_USAGE
++ }
+ }
+ } else {
+ /* normal token lookup */
+@@ -572,7 +575,7 @@ append_acs0(string_desc * dst, int code,
+ static void
+ append_acs(string_desc * dst, int code, char *src)
+ {
+-if (src != 0 && strlen(src) == 1) {
++if (VALID_STRING(src) && strlen(src) == 1) {
+ append_acs0(dst, code, *src);
+ }
+ }
+@@ -833,15 +836,14 @@ postprocess_termcap(TERMTYPE *tp, bool h
+ }
+
+ if (tp->Strings[to_ptr->nte_index]) {
++ const char *s = tp->Strings[from_ptr->nte_index];
++ const char *t = tp->Strings[to_ptr->nte_index];
+ /* There's no point in warning about it if it's the same
+ * string; that's just an inefficiency.
+ */
+- if (strcmp(
+-
Bug#858190: unblock: manpages/4.10-1
On 2017-04-04 14:36 +0200, Dr. Tobias Quathamer wrote: > Am 03.04.2017 um 17:56 schrieb Niels Thykier: >> Control: tags -1 confirmed >> >>> unblock manpages/4.10-1 >>> >>> The package has not been uploaded to unstable, I'll wait for your >>> approval before doing so. >>> >>> Regards, >>> Tobias >> >> Ack, please go ahead. >> >> Thanks, >> ~Niels > > Hi Niels, > > thanks a lot, the package has just been accepted into unstable. Unfortunately it introduced at least two file conflicts, #859511 and #859514. Can you please drop the offending files for now and check whether there are other clashes in newly added manpages? Cheers, Sven
Bug#857489: unblock: xserver-xorg-video-nouveau/1:1.0.13-2
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock the package xserver-xorg-video-nouveau, it fixes a bug
leading to a black screen when the monitor returns from powersave mode.
The problem only becomes visible with atomic modesetting in Linux 4.10
and later, but as quite a few people will install a newer kernel than
4.9 in stretch, I think it's important to fix it in the next release.
No bug report in the BTS, but it has been reported upstream at
https://bugs.freedesktop.org/show_bug.cgi?id=99922, and I could both
reproduce the bug and that the fix works.
unblock xserver-xorg-video-nouveau/1:1.0.13-2
diff -u xserver-xorg-video-nouveau-1.0.13/debian/changelog xserver-xorg-video-nouveau-1.0.13/debian/changelog
--- xserver-xorg-video-nouveau-1.0.13/debian/changelog
+++ xserver-xorg-video-nouveau-1.0.13/debian/changelog
@@ -1,3 +1,11 @@
+xserver-xorg-video-nouveau (1:1.0.13-2) unstable; urgency=medium
+
+ * Team upload.
+ * Cherry-pick commit 924083938c ("Consider CRTCs disabled when DPMS is
+off") from upstream.
+
+ -- Sven Joachim <svenj...@gmx.de> Sat, 11 Mar 2017 09:00:49 +0100
+
xserver-xorg-video-nouveau (1:1.0.13-1) unstable; urgency=medium
* Team upload.
only in patch2:
unchanged:
--- xserver-xorg-video-nouveau-1.0.13.orig/src/drmmode_display.c
+++ xserver-xorg-video-nouveau-1.0.13/src/drmmode_display.c
@@ -65,6 +65,7 @@
uint32_t rotate_fb_id;
Bool cursor_visible;
int scanout_pixmap_x;
+int dpms_mode;
} drmmode_crtc_private_rec, *drmmode_crtc_private_ptr;
typedef struct {
@@ -114,6 +115,14 @@
return drmmode_crtc->mode_crtc->crtc_id;
}
+Bool
+drmmode_crtc_on(xf86CrtcPtr crtc)
+{
+drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
+
+return crtc->enabled && drmmode_crtc->dpms_mode == DPMSModeOn;
+}
+
int
drmmode_head(xf86CrtcPtr crtc)
{
@@ -313,9 +322,10 @@
}
static void
-drmmode_crtc_dpms(xf86CrtcPtr drmmode_crtc, int mode)
+drmmode_crtc_dpms(xf86CrtcPtr crtc, int mode)
{
-
+ drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
+ drmmode_crtc->dpms_mode = mode;
}
void
only in patch2:
unchanged:
--- xserver-xorg-video-nouveau-1.0.13.orig/src/nouveau_dri2.c
+++ xserver-xorg-video-nouveau-1.0.13/src/nouveau_dri2.c
@@ -279,23 +279,27 @@
ScrnInfoPtr scrn = xf86ScreenToScrn(draw->pScreen);
xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(scrn);
NVPtr pNv = NVPTR(scrn);
- int i;
+ int i, active_crtc_count = 0;
if (!xf86_config->num_crtc)
return FALSE;
for (i = 0; i < xf86_config->num_crtc; i++) {
xf86CrtcPtr crtc = xf86_config->crtc[i];
- if (crtc->enabled && crtc->rotatedData)
- return FALSE;
+ if (drmmode_crtc_on(crtc)) {
+ if (crtc->rotatedData)
+return FALSE;
+ active_crtc_count++;
+ }
}
return ((DRI2CanFlip(draw) && pNv->has_pageflip)) &&
dst_pix->drawable.width == src_pix->drawable.width &&
dst_pix->drawable.height == src_pix->drawable.height &&
dst_pix->drawable.bitsPerPixel == src_pix->drawable.bitsPerPixel &&
- dst_pix->devKind == src_pix->devKind;
+ dst_pix->devKind == src_pix->devKind &&
+ active_crtc_count;
}
static Bool
@@ -475,7 +479,7 @@
int head = drmmode_crtc(config->crtc[i]);
void *token;
- if (!config->crtc[i]->enabled)
+ if (!drmmode_crtc_on(config->crtc[i]))
continue;
flipdata->flip_count++;
only in patch2:
unchanged:
--- xserver-xorg-video-nouveau-1.0.13.orig/src/nouveau_present.c
+++ xserver-xorg-video-nouveau-1.0.13/src/nouveau_present.c
@@ -152,7 +152,7 @@
ScrnInfoPtr scrn = xf86ScreenToScrn(window->drawable.pScreen);
xf86CrtcPtr crtc = rrcrtc->devPrivate;
- if (!scrn->vtSema || !crtc->enabled)
+ if (!scrn->vtSema || !drmmode_crtc_on(crtc))
return FALSE;
return TRUE;
@@ -199,7 +199,7 @@
flip->msc = target_msc;
for (i = 0; i < config->num_crtc; i++) {
-if (config->crtc[i]->enabled)
+if (drmmode_crtc_on(config->crtc[i]))
last = i;
}
@@ -208,7 +208,7 @@
int crtc = drmmode_crtc(config->crtc[i]);
void *user = NULL;
-if (!config->crtc[i]->enabled)
+if (!drmmode_crtc_on(config->crtc[i]))
continue;
if (token && ((crtc == sync) || (i == last))) {
only in patch2:
unchanged:
--- xserver-xorg-video-nouveau-1.0.13.orig/src/nouveau_xv.c
+++ xserver-xorg-video-nouveau-1.0.13/src/nouveau_xv.c
@@ -299,7 +299,7 @@
for (i = 0; i < xf86_config->num_crtc; i++) {
xf86CrtcPtr crtc = xf86_config->crtc[i];
- if (!crtc->enabled)
+ if (!drmmode_crtc_on(crtc))
continue;
if ((x < (crtc->x + crtc->mode.HDisplay)) &&
only in patch2:
unchanged:
--- xserver-xorg-video-nouveau-1.0.13.orig/src/nv_proto.h
+++ xserver-xorg-video-nouveau-1.0.13/src/nv_proto.h
@@ -13,6 +13,7 @@
void drmmode_screen_fini(ScreenPtr pScreen);
int drmmode_crtc(xf86CrtcPtr crtc);
+Bool drmmode_crtc_on(xf86CrtcPtr crtc);
int drmmode_head(xf86CrtcPtr crtc);
void drmmode_swap(ScrnInfoPtr, uint32_t, uint32_t *);
Bug#830997: release.debian.org: Permission to consider dpkg-buildpackage -A bugs as RC
On 2016-07-21 16:18 +0200, Santiago Vila wrote: > On Thu, Jul 21, 2016 at 02:21:02AM +0200, Santiago Vila wrote: > >> Some of the new bugs are like this: >> >> make: *** No rule to make target 'build-indep'. Stop. >> >> Targets build-arch and build-indep are mandatory, and this was already >> decided by dpkg author. This is not new, so I would raise those bugs >> to serious now. > > A small clarification: What was decided by dpkg author is to drop a > hack which enabled those packages to build successfully. > > The mass bug filing was announced by Niels here: > > https://lists.debian.org/debian-devel/2016/04/msg00023.html > > Quoting Niels: > >> We intend to do another round of MBF for this problem once we have >> located a way to break down the remaining packages into smaller and more >> manageable sets. > > I think the second round of MBF did not take place yet. It did, albeit a bit later than planned. See Guillem's followup this month[1] and the list of bugs Niels has filed[2]. Cheers, Sven 1. https://lists.debian.org/debian-devel/2016/07/msg00130.html 2. https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=arch-all-and-any-missing-targets;users=ni...@thykier.net
Bug#827842: release.debian.org: nmu: ncurses_6.0+20160319-2
On 2016-06-22 08:11 +0200, Julien Cristau wrote: > On Tue, Jun 21, 2016 at 17:53:40 +0200, Sven Joachim wrote: > >> Package: release.debian.org >> Severity: normal >> User: release.debian@packages.debian.org >> Usertags: binnmu >> >> Due to findutils bug #827724, ncurses-bin ended up empty on various >> architectures, see #827797. Rebuilding with non-broken findutils should >> fix that. >> >> nmu ncurses_6.0+20160319-2 . amd64 i386 mips powerpc kfreebsd-i386 >> . unstable . -m "Rebuild with findutils 4.6.0+git+20160517-4" >> >> The amd64 package is not actually affected, but having amd64 and i386 >> out of sync is going to cause a lot of complaints from multiarch users >> that I'd rather not deal with. >> > jcristau@wuiet:~$ wb nmu ncurses . ANY -x32 . -m 'Rebuild with fixed > findutils (#827724)' --extra-depends 'findutils (>= > 4.6.0+git+20160517-4)' > > Scheduled. Thanks. Unfortunately, ncurses is now in BD-Uninstallable state on alpha and hurd-i386, because findutils FTBFS there (the broken findutils versions also did not build on these arches). Could you please take out the findutils Extra-Depends? Cheers, Sven
Bug#827842: release.debian.org: nmu: ncurses_6.0+20160319-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Due to findutils bug #827724, ncurses-bin ended up empty on various architectures, see #827797. Rebuilding with non-broken findutils should fix that. nmu ncurses_6.0+20160319-2 . amd64 i386 mips powerpc kfreebsd-i386 . unstable . -m "Rebuild with findutils 4.6.0+git+20160517-4" The amd64 package is not actually affected, but having amd64 and i386 out of sync is going to cause a lot of complaints from multiarch users that I'd rather not deal with.
Bug#807867: nmu: all packages built without GCC 5 and hardening-wrapper
On 2015-12-14 18:37 +0100, Emilio Pozuelo Monfort wrote: > On 13/12/15 22:52, Matthias Klose wrote: >> hardening-wrapper 1.28+nmu1 is supposed to fix hardening-wrapper, however >> binNMUs for all packages build-depending on hardening-wrapper, which got >> built >> (either uploaded or binNMUed) after GCC 5 became the default have to be >> successfully done. > > A list would be useful. This evening I skimmed through the build logs of packages build-depending on hardening-wrapper. Judging by the build dates, the following 39 packages have apparently been built with hardening-wrapper 2.7 and gcc 5. animals bind9 bogl brltty cdcover cluster-glue crmsh espeakedit grap gsmartcontrol hwloc ldns libjna-java liblouis liblouisutdml liblouisxml libmsn libpam-mount libprelude libtritonus-java libvoikko opari openafs openjdk-7-jre-dcevm openlayer passwordmaker-cli pidgin postfix postgresql-9.4 qt-at-spi quisk shadow siege softhsm sonic vite vzctl witty xmahjongg Sadly, hardening-wrapper 2.8+nmu1 had a bug (#807949) affecting the architectures i386, kfreebsd-i386 and hurd-i386. The following four packages built with this version need a rebuild on these architectures to regain linker hardening flags. nmon ploop splitvt zoem Cheers, Sven
Bug#796835: release.debian.org: Transition: ncurses-6.0
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-CC: ncur...@packages.debian.org Control: block 230990 by -1 For quite some time, ncurses had the option to be built with a new ABI that enables applications to use mouse wheels, among other good things (see #230990). Switching to this ABI had been stalled due to the lack of symbol versioning and the rather large number of ncurses' reverse dependencies, with quite a few libraries among them. In the latest ncurses release (6.0), symbol versioning was added to the libraries, and we would like to see ncurses' reverse dependencies to be rebuilt during the Stretch release cycle so that the long requested ABI change becomes possible after the Debian 9 release. The new ncurses version has already migrated to testing, and there is no hurry to rebuild reverse dependencies right away, but I would like to see a mass rebuild some time before the Stretch freeze and set up a tracker in the meantime. Suggested ben file (only lightly tested, please check): title = ncurses-6.0; is_affected = .depends ~ /libncursesw?5|libtinfo5/; is_good = .depends ~ /libncursesw?5 \(= 6|libtinfo5 \(= 6/; is_bad = .depends ~ /libncursesw?5 \(= 5|libtinfo5(,|$)|libtinfo5\(= 5/; Cheers, Sven
Bug#774688: unblock: pbbuttonsd/0.7.9-3
On 2015-01-06 10:24 +0100, Mathieu Malaterre wrote: diff -Nru pbbuttonsd-0.7.9/debian/changelog pbbuttonsd-0.7.9/debian/changelog --- pbbuttonsd-0.7.9/debian/changelog 2014-01-22 13:08:34.0 +0100 +++ pbbuttonsd-0.7.9/debian/changelog 2015-01-06 10:12:42.0 +0100 @@ -1,3 +1,10 @@ +pbbuttonsd (0.7.9-4) unstable; urgency=low + + * Adopt package. Closes: #422162 + * Fix for linux kernel 3.x. Closes: #711685 How about future 4.x kernels? It seems quite possible that those will be released during jessie's lifetime. Cheers, Sven -- 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/87sifn68dz@turtle.gmx.de
Re: Bug#721115: linux-base: Depends on libuuid-perl then perlapi-5.14.2, however perlapi-5.14.2 was removed in perl (5.18.1-2)
On 2013-08-28 11:49 +0200, Ben Hutchings wrote: On Wed, 2013-08-28 at 14:28 +0800, Steven Shiau wrote: Package: linux-base Version: 3.5 Severity: normal Dear Maintainer, linux-base depends on libuuid-perl then perlapi-5.14.2, however perlapi was removed in perl (5.18.1-2). This will cause the running linux-image package to be removed. It looks like linux-base needs to be re-uploaded (it's arch:all, so binNMUs won't help). No, why should it? http://release.debian.org/transitions/html/perl5.18.html apparently only covers dependencies on 'perl' not 'perlapi-5.14.2' so it seems to be understating the size of this transition. Does this make sense? Not to me, linux-base does not depend on perl nor perl-api-5.14.2. All that's needed is a rebuild of libuuid-perl against the newer perl, and libuuid-perl is listed on the above page. Cheers, Sven -- 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/87haeaxgsq@turtle.gmx.de
Bug#698555: unblock: systemd/44-8
On 2013-01-20 13:53 +0100, Michael Biebl wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package systemd It contains the following two fixes: systemd (44-8) unstable; urgency=low * Team upload. * Use comment=systemd.* syntax in systemd.mount man page. The mount/util-linux version in wheezy is not recent enough to support the new x-systemd* syntax. Closes: #697141 * Don't enable persistent storage of journal log files. The journal in v44 is not yet mature enough. -- Michael Biebl bi...@debian.org Sat, 19 Jan 2013 20:05:05 +0100 The journal related changes probably deserve a couple of words: The journal in v44 is still pretty new and not yet very robust. Under certain circumstances (e.g. system crash) the journal can become corrupted. While newer versions are much more likely to recover from such a situation, in v44 one needs to remove the journal files in /var/log/journal manually. By not making the journal files persistent, after a reboot the journal will be working again in any case. We also still ship a syslog by default in Debian, so we do have long-term logs. So we decided to not ship /var/log/journal in the package for wheezy. In that case systemd-journald will not store any log files on disk. Are current users of systemd advised to remove /var/log/journal themselves? Having used systemd exclusively for a few weeks, I discovered a 23 Megabyte system.journal file which apparently never got rotated or truncated. Cheers, Sven -- 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/871udghra2@turtle.gmx.de
Bug#685218: unblock: xserver-xorg-video-nouveau/1:1.0.1-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock xserver-xorg-video-nouveau, it fixes bug #675161 which has made the version in testing unusable for the past three months. The version in unstable had been blocked from migrating by bug #679566 which only got solved in testing today. unblock xserver-xorg-video-nouveau/1:1.0.1-3 That was the good part, now to the bad and the ugly: upstream rewrote the nouveau parts of libdrm and large parts of the driver between the versions in testing and unstable, resulting in a *huge* diff: , | ChangeLog | 405 + | configure.ac |4 +- | debian/NEWS.Debian |9 + | debian/changelog | 47 ++ | debian/patches/02-drm-nouveau-newabi.patch | 2285 | debian/patches/series |1 + | debian/rules |2 +- | debian/watch |4 + | src/Makefile.am| 47 +- | src/compat-api.h | 96 +++ | src/drmmode_display.c | 48 +- | src/nouveau_dri2.c | 59 +- | src/nouveau_exa.c | 143 +++-- | src/nouveau_local.h| 186 -- | src/nouveau_wfb.c |4 +- | src/nouveau_xv.c | 90 ++- | src/nv04_accel.h | 93 +++ | src/nv04_exa.c | 525 - | src/nv04_xv_blit.c | 262 - | src/nv10_exa.c | 863 +-- | src/nv30_exa.c | 979 --- | src/nv30_shaders.c | 347 --- | src/nv30_shaders.h | 72 --- | src/nv30_xv_tex.c | 302 -- | src/nv40_exa.c | 998 | src/nv40_xv_tex.c | 293 -- | src/nv50_accel.c | 695 -- | src/nv50_accel.h | 69 ++- | src/nv50_exa.c | 954 +++--- | src/nv50_xv.c | 381 +--- | src/nv_accel_common.c | 588 ++- | src/nv_const.h |2 + | src/nv_dma.c | 119 +++- | src/nv_dma.h |4 +- | src/nv_driver.c| 135 ++--- | src/nv_include.h | 13 +- | src/nv_proto.h | 17 +- | src/nv_shadow.c|3 +- | src/nv_type.h | 66 ++- | src/nvc0_accel.c | 876 +++- | src/nvc0_accel.h | 124 ++-- | src/nvc0_exa.c | 1033 + | src/nvc0_shader.h | 444 ++ | src/nvc0_xv.c | 374 +--- | src/nve0_shader.h | 440 ++ | src/vl_hwmc.c |6 +- | 46 files changed, 8833 insertions(+), 5674 deletions(-) ` The patch 02-drm-nouveau-newabi.patch pulls in the new libdrm_nouveau into the driver source, since upgrading the system libdrm is not possible due to mesa and plymouth still needing the old API. Definitely nothing to be proud of, but it seems to work. I very much wish this unblock request were not necessary; if somebody comes up with a miraculous fix for #666468, it can be ignored, but I do not expect this to happen anytime soon. Cheers, Sven -- 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/871uj4e84a@turtle.gmx.de
Re: Bug#679671: ia32-libs-i386: depends on removed package libdb4.8
Am 01.07.2012 um 11:13 schrieb Goswin von Brederlow: Sven Joachim svenj...@gmx.de writes: Package: ia32-libs-i386 Version: 20120616 Severity: serious Your package depends on libdb4.8 which is no longer available in unstable. It is still in wheezy. Not anymore. I assume it is going to be removed there as well? It was removed yesterday when libdb4.8 4.8.30-12 migrated. Cheers, Sven -- 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/878vf3kazj.fsf...@turtle.gmx.de
Bug#614345: pu: package libpng/1.2.44-2
On 2011-02-27 20:30 +0100, Steve Langasek wrote: On Sun, Feb 27, 2011 at 08:03:12PM +0100, Julien Cristau wrote: (Incidentally, for some reason my system seems to still have a /usr/lib/libpng12.so.0, unknown to dpkg. Not sure where that comes from.) That seems to be courtesy of ldconfig. If you have libpng-dev installed, ldconfig finds .so files in the directory with an soname of 'libpng12.so.0', doesn't find a file of that name in the directory, so creates a symlink... even though this was already available in /lib. I'd say this is misbehavior on the part of ldconfig since there's no need for this symlink and no way to get around its creation AFAICS. Yes, this is bug #249122. Cheers, Sven -- 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/87mxlhp7bz@turtle.gmx.de
Re: Pre-approval request for dpkg sync() changes for squeeze
On 2010-11-15 08:21 +0100, Raphael Hertzog wrote: On Wed, 10 Nov 2010, Philipp Kern wrote: On Tue, Nov 09, 2010 at 07:50:23PM +0100, Philipp Kern wrote: On Fri, Oct 22, 2010 at 11:35:54AM +0200, Guillem Jover wrote: 1) Switch back from sync() to fsync() before rename() (while keeping the sync() code around for the benefit of other distributions that might not want to switch just yet). So to avoid unrelated I/O when there's background work being done for example. This hack also only works on Linux where sync() is synchronous, so it would unify that code path for all dpkg supported platforms. Bug: #588339 http://git.hadrons.org/?p=debian/dpkg/dpkg.git;a=commitdiff;h=87740373 I'm still not sure we have all needed information. Would you mind doing a matrix what this change would cause? I.e. if we get performance regressions on ext4, btrfs or even ext3 with the squeeze kernel (we're really only interested in that one, not some random other revision) or if we even get data safety regressions. I also forgot to throw nfs into the picture. I'm sorry, I won't have the time to do new benchmarks on this. The only benchmarks we have have been made by Sven Joachim: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578635#20 (asyncsync is the switch to sync() instead of fsync() so the opposite of the above patch) He mentionned that without the sync() trick it takes 3 to 5 times longer to unpack a package. Even longer actually, see the figures below. Sven, would you have time to provide some of the stats asked by the release team? I can only test ext4, here are some samples of dpkg unpacking a large package (dpkg --unpack --no-triggers emacs23-common_23.2+1-5.1_all.deb), leaving out user and sys times since those do not vary much (~ 0.5 seconds in every case): dpkg versionCache mount options unpack time ̅̅̅ 1.15.8.5colddefaults7.803s 1.15.8.5warmdefaults5.283s 1.15.8.5coldnodelalloc 7.608s 1.15.8.5warmnodelalloc 3.783s 1.15.7 colddefaults 40.429s 1.15.7 warmdefaults 37.848s 1.15.7 coldnodelalloc 7.945s 1.15.7 warmnodelalloc 3.524s All this is with a standard squeeze kernel on an otherwise idle system. It should be noted that with lots of other disk activity such as writing to USB disks, the figures in dpkg 1.15.8.5 can become much worse and dpkg might even stall because of the many sync() calls: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595927. As far as ext4 is concerned, switching back to fsync() seems to be acceptable only if the filesystem is mounted with the nodelalloc option. Maybe the installer should set this up. Regards, Sven -- 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/87tyjjufnc@turtle.gmx.de
Re: Pre-approval request for dpkg sync() changes for squeeze
On 2010-11-08 16:40 +0100, Phillip Susi wrote: On 11/6/2010 5:41 AM, Sven Joachim wrote: For ext4, mounting with the nodelalloc option helps a lot, although this option allegedly slows down ext4 in the general case. How does that help? Doesn't it just disable the delayed allocator, forcing the blocks to be allocated when they hit the cache, rather than when flushed? Wouldn't that make sure you don't get zero byte files, but instead get files full of trash? I just meant that fsync() seems to be a lot faster in ext4 with that mount option, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588339#50. I have no idea why this is so, though. Sven -- 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/87tyjrhl0t@turtle.gmx.de
Bug#598882: release.debian.org: unblock: ncurses/5.7+20100313-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Sorry to bother you again with ncurses, but I would like to get
5.7+20100313-4 into squeeze to fix bug #597175. This is effectively a
one line change to the previous version cherry-picked from upstream.
Full debdiff is attached for reference, the relevant commit in our git
repository can be found at [1].
unblock ncurses/5.7+20100313-4
1.
http://git.debian.org/?p=collab-maint/ncurses.git;a=commit;h=824d808291ae3071ea7e66cd9be62e17a2eb0e30
reverted:
--- ncurses-5.7+20100313/debian/lib64ncurses5.debhelper.log
+++ ncurses-5.7+20100313.orig/debian/lib64ncurses5.debhelper.log
@@ -1 +0,0 @@
-dh_prep
reverted:
--- ncurses-5.7+20100313/debian/lib64ncurses5-dev.debhelper.log
+++ ncurses-5.7+20100313.orig/debian/lib64ncurses5-dev.debhelper.log
@@ -1 +0,0 @@
-dh_prep
diff -u ncurses-5.7+20100313/debian/changelog
ncurses-5.7+20100313/debian/changelog
--- ncurses-5.7+20100313/debian/changelog
+++ ncurses-5.7+20100313/debian/changelog
@@ -1,3 +1,11 @@
+ncurses (5.7+20100313-4) unstable; urgency=low
+
+ * New patch 09-fix-delscreen-segfault.diff taken from upstream
+patchlevel 20100501, fixes a segfault or infinite loop in applications
+using multiple screens (Closes: #597175).
+
+ -- Sven Joachim svenj...@gmx.de Tue, 28 Sep 2010 07:08:17 +0200
+
ncurses (5.7+20100313-3) unstable; urgency=low
* Fix dangling symlinks in ncurses-term that were introduced by the
diff -u ncurses-5.7+20100313/debian/patches/series
ncurses-5.7+20100313/debian/patches/series
--- ncurses-5.7+20100313/debian/patches/series
+++ ncurses-5.7+20100313/debian/patches/series
@@ -6,0 +7 @@
+09-fix-delscreen-segfault.diff
only in patch2:
unchanged:
--- ncurses-5.7+20100313.orig/debian/patches/09-fix-delscreen-segfault.diff
+++ ncurses-5.7+20100313/debian/patches/09-fix-delscreen-segfault.diff
@@ -0,0 +1,20 @@
+Description: Fix segfault or infinite loop in delscreen()
+ Patch taken from upstream patchlevel 20100501.
+Bug-Debian: http://bugs.debian.org/597175
+Author: Thomas Dickey dic...@his.com
+Last-Update: 2010-09-17
+---
+ ncurses/base/lib_set_term.c |2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/ncurses/base/lib_set_term.c
b/ncurses/base/lib_set_term.c
+@@ -117,7 +117,7 @@
+ for (each_screen(temp)) {
+ if (temp == sp) {
+ if (last)
+- last = sp-_next_screen;
++ last-_next_screen = sp-_next_screen;
+ else
+ _nc_screen_chain = sp-_next_screen;
+ result = TRUE;
pgpXhzNQy5id5.pgp
Description: PGP signature
Re: Freeze exception: shadow / possible cron update?
On 2010-09-21 11:49 +0200, Julien Cristau wrote: On Sun, Sep 19, 2010 at 19:10:50 +0200, Christian Kastner wrote: On 09/19/2010 06:21 PM, Julien Cristau wrote: On Sun, Sep 19, 2010 at 17:21:38 +0200, Christian Kastner wrote: Assuming that #596283 will be fixed by a -2 release of shadow, I was wondering whether the Release Team would like a cron -115 as well, with this feature removed from /etc/cron.daily/standard. Sounds reasonable. I'm not sure introducing yet more 'Breaks' is necessary though. The worst case if you're using new cron and old shadow is your stuff isn't backed up, right? That is correct. However, that worst case -- however unlikely -- might be severe enough to warrant the Breaks:. I'm therefore tending towards the latter, but will leave the final call up to you. I guess the other option is to leave both backups in place for squeeze, and remove the one from cron later. A bit confusing to have those files backed up from 2 places, but no harm other than that. I think I'd like that more than Breaks... How about letting cron depend on the new passwd package instead of breaking the old? ISTM this would have been the better action for #541415 as well. Sven -- 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/874odj8isj@turtle.gmx.de
Re: The NVIDIA packages and squeeze
On 2010-09-21 19:22 +0200, Julien Cristau wrote: On Tue, Sep 21, 2010 at 18:23:40 +0200, Andreas Beckmann wrote: On 2010-09-21 15:59, Julien Cristau wrote: Do the nvidia packages do anything to prevent nouveau.ko from being loaded? nvidia-kernel-common (all binary module packages and the dkms packages depend on this package) installs a blacklist entry in /etc/modprobe.d/ That kind of sucks because it means that package has to be purged before nouveau can work again. Oh well. I don't think this is the case, because the X server (unlike udev) does not invoke modprobe with the -b switch, so nouveau should still work if you don't have an xorg.conf. But people may wonder where their gettys went (when KMS kicks in, it erases the screen contents leaving only the blank cursor, and you have to press enter to see the login prompt). Sven -- 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/87wrqf6kno@turtle.gmx.de
Re: Permission to fix bug #576127 in ncurses
On 2010-09-11 20:28 +0200, Julien Cristau wrote: On Sat, Sep 11, 2010 at 20:20:25 +0200, Sven Joachim wrote: I would like to get a freeze exception for ncurses to fix bug #576127[0] for squeeze. While this bug only affects a minority of our users, those will be hit rather hard, and this bug is a regression from Lenny. The commits in our git repository can be found at [1] and [2]. Another bug I would like to fix is #595484[3]. This is not as important, but the patch is a one-liner (exactly three characters long). The commit would be [4]. Please go ahead, let us know when the package is accepted. Craig uploaded it, and it has already been built on all release architectures. Cheers, Sven pgpuUkjnlBA9a.pgp Description: PGP signature
Re: Permission to fix bug #576127 in ncurses
On 2010-09-13 16:32 +0200, Sven Joachim wrote: On 2010-09-11 20:28 +0200, Julien Cristau wrote: On Sat, Sep 11, 2010 at 20:20:25 +0200, Sven Joachim wrote: I would like to get a freeze exception for ncurses to fix bug #576127[0] for squeeze. While this bug only affects a minority of our users, those will be hit rather hard, and this bug is a regression from Lenny. The commits in our git repository can be found at [1] and [2]. Another bug I would like to fix is #595484[3]. This is not as important, but the patch is a one-liner (exactly three characters long). The commit would be [4]. Please go ahead, let us know when the package is accepted. Craig uploaded it, and it has already been built on all release architectures. I just noticed that the source package contains two spurious *.debhelper.log files, which is probably due to - Craig having worked on i386 at some point, but uploading on amd64 - dh_clean only removing log files for packages in the architecture list (cf. debhelper 4.1.52 changelog entry) - lintian being silent about the files that should not be there Otherwise it is identical to our new 'sid' branch in git[1], please unblock. Cheers, Sven 1. http://git.debian.org/?p=collab-maint/ncurses.git;a=shortlog;h=refs/heads/sid pgpW9mJpyNKhU.pgp Description: PGP signature
Permission to fix bug #576127 in ncurses
I would like to get a freeze exception for ncurses to fix bug #576127[0]
for squeeze. While this bug only affects a minority of our users, those
will be hit rather hard, and this bug is a regression from Lenny. The
commits in our git repository can be found at [1] and [2].
Another bug I would like to fix is #595484[3]. This is not as
important, but the patch is a one-liner (exactly three characters long).
The commit would be [4].
Sorry for not coming up with this sooner, the main maintainer had been
busy with his fatherhood[5].
Full diff against the version in squeeze with the three cherry-picked
commits is attached.
0. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=576127
1.
http://git.debian.org/?p=collab-maint/ncurses.git;a=commit;h=03e938257f20da054de985d2bc6fad48161e2bbb
2.
http://git.debian.org/?p=collab-maint/ncurses.git;a=commit;h=451a1f8cce791cda6847695730f49477970d2655
3. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595484
4.
http://git.debian.org/?p=collab-maint/ncurses.git;a=commit;h=2958576a9cb767ce5e472bf8fc4e859ab464d677
5.
http://www.enc.com.au/sees-blog/2010/09/psmisc-2213-gjay-031-2-and-son-20.html
diff --git a/debian/changelog b/debian/changelog
index 76eeb13..4b473e8 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+ncurses (5.7+20100313-3) UNRELEASED; urgency=low
+
+ * Fix dangling symlinks in ncurses-term that were introduced by the
+removal of the ncurses-base compatibility symlinks in version
+5.7+20100313-1 (Closes: #576127). Add versioned Breaks against older
+ncurses-term versions in ncurses-base.
+ * Correct rxvt-unicode sgr0 terminfo entry (Closes: #595484).
+
+ -- Sven Joachim svenj...@gmx.de Tue, 07 Sep 2010 20:35:26 +0200
+
ncurses (5.7+20100313-2) unstable; urgency=medium
[ Sven Joachim ]
diff --git a/debian/control b/debian/control
index 91cc769..e4c7e47 100644
--- a/debian/control
+++ b/debian/control
@@ -172,6 +172,7 @@ Essential: yes
Depends: ${misc:Depends}
Conflicts: ncurses, ncurses-runtime
Provides: ncurses-runtime
+Breaks: ncurses-term ( 5.7+20100313-3)
Description: basic terminal type definitions
This package contains terminfo data files to support the most common types of
terminal, including ansi, dumb, linux, rxvt, screen, sun, vt100, vt102, vt220,
@@ -182,6 +183,7 @@ Architecture: all
Section: admin
Priority: standard
Depends: ${misc:Depends}
+Replaces: ncurses-base ( 5.7+20100313-1)
Description: additional terminal type definitions
This package contains all of the numerous terminal definitions not found in
the ncurses-base package.
diff --git a/debian/ncurses-term.links b/debian/ncurses-term.links
new file mode 100644
index 000..5eaca09
--- /dev/null
+++ b/debian/ncurses-term.links
@@ -0,0 +1,6 @@
+/lib/terminfo/c/cons25 /usr/share/terminfo/c/cons25
+/lib/terminfo/s/sun /usr/share/terminfo/s/sun
+/lib/terminfo/v/vt100 /usr/share/terminfo/v/vt100
+/lib/terminfo/v/vt220 /usr/share/terminfo/v/vt220
+/lib/terminfo/x/xterm-color /usr/share/terminfo/x/xterm-color
+/lib/terminfo/x/xterm-r6/usr/share/terminfo/x/xterm-r6
diff --git a/debian/rules b/debian/rules
index 1c5727b..8bf61e9 100755
--- a/debian/rules
+++ b/debian/rules
@@ -447,6 +447,7 @@ binary-indep: build install
dh_lintian -i
dh_compress -i
dh_fixperms -i
+ dh_link -i
dh_gencontrol -i
dh_installdeb -i
dh_md5sums -i
diff --git a/debian/rxvt-unicode.ti b/debian/rxvt-unicode.ti
index 18dd772..d64f1de 100644
--- a/debian/rxvt-unicode.ti
+++ b/debian/rxvt-unicode.ti
@@ -40,7 +40,7 @@ rxvt-unicode|rxvt-unicode terminal (X Window System),
rmso=\E[27m, rmul=\E[24m,
rs1=\Ec,
rs2=\E[r\E[m\E[2J\E[H\E[?7h\E[?1;3;4;6l\E[4l\E,
- sgr0=\E[m\017,
+ sgr0=\E[m\E(B,
enacs=, smacs=\E(0, rmacs=\E(B,
smso=\E[7m, smul=\E[4m, tbc=\E[3g,
vpa=\E[%i%p1%dd,
pgp1Y26x0fFnK.pgp
Description: PGP signature
Re: chromium not in Squeeze: a bit of communication needed?
On 2010-09-08 16:10 +0200, Michael Gilbert wrote: On Wed, 8 Sep 2010 13:48:49 +0200, Stefano Zacchiroli wrote: I've been following the chromium-browser saga a bit, who has ended up with the removal of the package from testing [1,2]. While I'm a chromium-browser user myself, and hence I'm saddened of seeing it go, I'm not here to question the choice as I'm sure it's been made as the right one and that it hasn't been an easy one to make. [1] http://lists.debian.org/debian-release/2010/09/msg00582.html [2] http://www.iuculano.it/en/linux/debian/chromium-browser-removed-from-testing/ Still I think we need, as Debian, to communicate about that choice. As you can imagine, I particularly care about that as sooner or later someone will ask me « why Debian doesn't ship Chromium? », and I'd like to know the right answer to that question, so that I can provide it, rather than offering my personal view only :-) That's all I care about. [3] I think that this need is justification to declare backports officially supported by the debian project. Thus when asked this question, you can point to the fact that chromium is indeed supported on stable, just via a different model than folks are used to. That is of course assuming someone is willing to support the backport. It also means that users need to be taught how to change the apt pinning priority for backports, because in the default configuration backported packages are never updated automatically. Which is very bad from a security point of view. Sven -- 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/87fwxkmgib@turtle.gmx.de
Re: freeze exception for gcc-4.5 (i386, amd64 only)
On 2010-08-18 19:49 +0200, Julien Cristau wrote: On Wed, Aug 18, 2010 at 19:12:37 +0200, Ludovic Brenta wrote: Personally, I'd be comfortable with gcc-4.5 in Squeeze except for this part: - the upload will build several runtime libraries from the 4.5 sources. Regression tests did pass for the runtime libs built from the 4.5 sources and for 4.4 using the runtime libs from 4.5. This really gives me the creeps. I would propose that gcc-4.5 be allowed in testing, with priority extra, but not that the several runtime libraries (which ones are they?) be built from the gcc-4.5 sources. Would that be acceptable to everyone? I assume gcc-4.5 needs libgcc1 from gcc-4.5. As well as libgomp1, and g++-4.5 needs libstdc++6 from gcc-4.5. Sven -- 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/87aaojiyqs@turtle.gmx.de
Re: simplesamlphp not migrating to testing
On 2010-06-27 19:36 +0200, Thijs Kinkhorst wrote: On snein 27 Juny 2010, Julien Cristau wrote: My package simplesamlphp is not migrating to testing: Excuse for simplesamlphp * 23 days old (needed 10 days) * simplesamlphp/i386 unsatisfiable Depends: php5-mhash (= 5.2.0) * Valid candidate In squeeze php5-mhash is provided by php5, in Lenny this is a separate package. I want to Depend on php5-mhash to also keep the dependencies correct in a Lenny context. What can I do to have the package migrate? Change the Depends to php5 (= $whatever) | php5-mhash? OK, I will do that but I'm just checking to avoid trial-and-error, as it was a surprise to me in the first place that testing migration doesn't consider Provides. Huh? Versioned Provides have never been supported, so simplesamlphp is simply not installable in sid. Sven -- 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/87bpawpdx8@turtle.gmx.de
Re: gettext, autopoint and cvs
On 2010-05-18 15:52 +0200, Santiago Vila wrote: Sorry, I missed your mail (I don't read -release very often, please feel free to Cc me). I am reading it after uploading gettext 0.18-1 today. This is from the changelog: * Changed autopoint so that it uses git instead of cvs. As the autopoint package was created to avoid gettext to depend on cvs, we are not going to make gettext to depend on git now. Moreover, as packages using autopoint and still having cvs in their build-depends would not work anymore even if autopoint is still kept in the gettext package, this effectively puts an end to the transition period: packages using autopoint must build-depend on autopoint now. However, as I was asking for permission to make those bugs RC, and I believed there was no reply, I've made a random bug against gettext (#581637 seemed appropriate) to be of serious severity to prevent it from entering testing. This means if we were to release squeeze as stable today, everything would work. I think this allows us to not consider the bugs as RC. This seems wrong to me. The packages will FTBFS in unstable now, right? If so, IMO the bugs should be raised to serious and tagged sid. However, gettext 0.18 will not enter testing until the remaining bugs are fixed. You want to block #581637 by these bugs. Cheers, Sven -- 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/87ljbhxmzk@turtle.gmx.de
Bug#573486: RM: emacs22/22.3+1-1.2
On 2010-05-17 21:06 +0200, Adam D. Barratt wrote: On Thu, 2010-03-11 at 21:09 +0100, Moritz Muehlenhoff wrote: Please remove emacs22 from testing. It's superseded by emacs23 and the last remaining dep in Squeeze (python2.5-doc) should transition to testing in three days. I added a removal hint, which succeeded in last night's britney run. However, as emacs22 is still in unstable and does not have any RC bugs, it migrated back in to testing this morning. One or other of those things should probably be fixed. :-) I just filed #582156 to prevent re-migration, so you can try again. Removal from unstable will probably have to wait because hyperlatex still depends on emacs22, and that bug (#571122) appears to be non-trivial to fix; at least I have no idea what is going on there. Cheers, Sven -- 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/87sk5p3u4k@turtle.gmx.de
Bug#573486: RM: emacs22/22.3+1-1.2
On 2010-04-18 22:49 +0200, Moritz Muehlenhoff wrote: Indeed, emacs22 can be removed now. dak rm -Rn -s testing emacs22 still shows a blocking dep, but that seems to be a bug, python2.5-doc is built from the source package python2.5 now, which build-depends on emacs23: Checking reverse dependencies... # Broken Build-Depends: python2.5-doc/contrib: emacs22 Dependency problem found. This is not a bug, the python2.5 version that builds python2.5-doc did FTBFS on mips and thus is not yet in testing. Sven -- 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/87aat0jwwd@turtle.gmx.de
Re: RM: knights/testing -- RM; RC-buggy, Does not build, not ported to KDE4
On 2010-04-13 07:55 +0200, Jari Aalto wrote: Consider removing knights: SERIOUS knights: build depends kdebase-kio-plugins no longer exists (need porting to KDE4) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528348 IMPORTANT knights: obsolete build-dep on x-dev http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515376 The application does not build. Needs porting to KDE4 which hasn't been done since the bug #528348 was reported 2009-05-14. Err, this package has not been in testing for almost 11 months. Sven -- 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/87fx2z6g33@turtle.gmx.de
Bug#576538: Please binNMU slang2_2.2.2-4 on hppa against fixed ncurses
Package: release.debian.org X-Debbugs-CC: sla...@packages.debian.org User: release.debian@packages.debian.org Usertags: binnmu Please rebuild slang2 on hppa with libncurses5-dev 5.7+20100313-2 to solve a problem with unresolved symbols (see #575220). See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575284#52 for further details. nmu slang2_2.2.2-4 . hppa . -m Rebuild with libncurses5-dev 5.7+20100313-2 dw slang2_2.2.2-4 . hppa . -m libncurses5-dev (= 5.7+20100313-2) -- 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/87vdc656nd@turtle.gmx.de
Re: [pkg-nvidia-devel] X stack for squeeze
On 2010-03-17 09:37 +0100, Philipp Kern wrote: On Tue, Mar 16, 2010 at 04:23:11PM -0700, Randall Donald wrote: We generally go with the latest version at the time of freeze and then build a kernel module package that is compatible. Other than that is there something else you are asking about? You mean regardless of 9 RC bugs opened against the package? That even sounds like please force the newest upstream versions into squeeze regardless of any packaging bugs, or do you want to release with the current version in testing? Regarding the version in testing, could it please be removed? It has unfulfilled dependencies (needs kernel from Lenny) and does not work with current xserver-xorg-core (support for xserver 1.7 was added in 190.36, according to /usr/share/doc/nvidia-glx/NVIDIA_Changelog.gz). Sven -- 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/87y6hrl41k@turtle.gmx.de
Bug#573486: RM: emacs22/22.3+1-1.2
On 2010-03-11 21:09 +0100, Moritz Muehlenhoff wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Please remove emacs22 from testing. It's superseded by emacs23 and the last remaining dep in Squeeze (python2.5-doc) should transition to testing in three days. It's not so easy since there are a few packages which would be broken: wnn7egg (contrib) ecasound-el elserv gnus hyperlatex wysihtml-el yc-el The hyperlatex problem is tracked in #571122, and the gnus package can probably be removed from testing without harming anyone (emacs23 has a newer version). I think that bugs should be filed against the others (which severity?). Note that this comes from xemacs21 not being in testing; the xemacs21 maintainer's lack of response to RC bugs suggests that maybe it will not be released with squeeze. Sven -- 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/87k4tiinud@turtle.gmx.de
Re: BinNMU for libjpeg8 transition
On 2010-02-11 19:38 +0100, Luk Claes wrote: Bill Allombert wrote: libjpeg62-dev need to be kept for LSB compatibility. Can you point me to the section that points to that need? http://refspecs.freestandards.org/LSB_3.2.0/LSB-Desktop-generic/LSB-Desktop-generic/libjpeg62.html#LIBJPEG It's the same in LSB 4.0. Sven -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: BinNMU for libjpeg8 transition
On 2010-02-11 20:21 +0100, Julien Cristau wrote: On Thu, Feb 11, 2010 at 19:44:58 +0100, Sven Joachim wrote: On 2010-02-11 19:38 +0100, Luk Claes wrote: Bill Allombert wrote: libjpeg62-dev need to be kept for LSB compatibility. Can you point me to the section that points to that need? http://refspecs.freestandards.org/LSB_3.2.0/LSB-Desktop-generic/LSB-Desktop-generic/libjpeg62.html#LIBJPEG It's the same in LSB 4.0. Doesn't that allow us to keep libjpeg62 but get rid of libjpeg62-dev? If Debian has no interest of being a platform for building LSB packages, surely. I don't know if this is a concern or not. Sven -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: BinNMU for libjpeg8 transition
On 2010-02-09 23:39 +0100, Bill Allombert wrote: On Fri, Feb 05, 2010 at 09:40:22PM +0100, Bill Allombert wrote: On Mon, Feb 01, 2010 at 03:27:06PM +0100, Bill Allombert wrote: jpeg8 is now in testing and libterralib and sdop has been fixed already, so I would like to start the transition by uploading a version of libjpeg8-dev that provides libjpeg-dev. Accordingly, and unless directed otherwise, I will upload a version of libjpeg8-dev that provides libjpeg-dev on Sunday. Done in version libjpeg8-dev 8-2. Please trigger binNMU for the following packages that build-depends on libjpeg-dev (and not libjpeg62-dev|libjpeg-dev) for rebuilding against libjpeg8-dev 8-2: imagemagick 7:6.5.8.3-1 inventor 2.1.5-10-14 kwwidgets 1.0.0~cvs20090825-4 libphash 0.8.1-1 libsfml 1.5+repack1-3 libterralib 3.3.1-8 mathgl 1.9-2 nxcomp 3.2.0-7-1.1 openscenegraph 2.8.2-2 ossim 1.7.21-1 pike7.6 7.6.112-dfsg-1 poppler 0.12.2-2.1 prima 1.28-1 shoes 0.r396-5 slicer 3.4.0~svn10438-4 steghide 0.5.1-9 tipptrainer 0.6.0-16 vino 2.28.1-2.1 vtk 5.4.2-4 vxl 1.13.0-2 xen-3 3.4.2-2 xjig 2.4-13 xnc 5.0.4-4 Are any of these packages actually buildable now? For instance, anything that depends on libtiff4?-dev is not, because libtiff4-dev depends on libjpeg62-dev. Neither is anything that depends on libgtk2.0-dev, because of the dependency chain libgtk2.0-dev - libcairo2-dev - libdirectfb-dev - libjpeg62-dev. Sven -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
stable update for backup-manager
Dear release team, I would like to upload a new version of the backup-manager to stable in order to fix a (relatively minor) security issue. The fix is trivial, just transposing to lines and thus ensuring that a password is not written to a file until the world is denied read access. Full debdiff is attached. There is certainly no need for a DSA, since the problem is similar to CVE-2007-2766 (to be fixed in oldstable, no DSA), but even harder to exploit. Regards, Sven diff -u backup-manager-0.7.7/debian/control backup-manager-0.7.7/debian/control --- backup-manager-0.7.7/debian/control +++ backup-manager-0.7.7/debian/control @@ -3,7 +3,7 @@ Priority: optional Build-Depends-Indep: debiandoc-sgml, tetex-bin, tetex-extra Build-Depends: po-debconf, debhelper (= 5), dpatch -Maintainer: Alexis Sukrieh suk...@debian.org +Maintainer: Sven Joachim svenj...@gmx.de Standards-Version: 3.7.3 XS-Vcs-Svn: svn://svn.debian.org/svn/pkg-backup-mngr/trunk/ diff -u backup-manager-0.7.7/debian/changelog backup-manager-0.7.7/debian/changelog --- backup-manager-0.7.7/debian/changelog +++ backup-manager-0.7.7/debian/changelog @@ -1,3 +1,12 @@ +backup-manager (0.7.7-2) stable; urgency=high + + * Fix possible MYSQL password leaking to local users by making the +.my.cnf file world-unreadable before writing the password to it. + * Set myself as maintainer in debian/control. + * Remove spurious debian/patches/00list.diff and update 00list. + + -- Sven Joachim svenj...@gmx.de Fri, 22 Jan 2010 12:47:43 +0100 + backup-manager (0.7.7-1.1) unstable; urgency=low * Non-maintainer upload. diff -u backup-manager-0.7.7/debian/patches/00list backup-manager-0.7.7/debian/patches/00list --- backup-manager-0.7.7/debian/patches/00list +++ backup-manager-0.7.7/debian/patches/00list @@ -4,0 +5,2 @@ +05_German_transation_update.dpatch +06_no_password_leak.dpatch reverted: --- backup-manager-0.7.7/debian/patches/00list.diff +++ backup-manager-0.7.7.orig/debian/patches/00list.diff @@ -1,7 +0,0 @@ 00list~ 2008-09-21 09:03:58.0 +0200 -+++ 00list 2008-09-21 08:20:06.0 +0200 -@@ -2,3 +2,4 @@ - 02_cdrecord_to_wodim.dpatch - 03_VERSION.dpatch - 04_Makefile.dpatch -+05_German_transation_update.dpatch only in patch2: unchanged: --- backup-manager-0.7.7.orig/debian/patches/06_no_password_leak.dpatch +++ backup-manager-0.7.7/debian/patches/06_no_password_leak.dpatch @@ -0,0 +1,20 @@ +#! /bin/sh /usr/share/dpatch/dpatch-run +## 06_no_password_leak.dpatch by Sven Joachim svenj...@gmx.de +## +## All lines beginning with `## DP:' are a description of the patch. +## DP: Fix possible leaking of MYSQL passwords to local users. + +...@dpatch@ +diff -urNad backup-manager-0.7.7~/lib/backup-methods.sh backup-manager-0.7.7/lib/backup-methods.sh +--- backup-manager-0.7.7~/lib/backup-methods.sh 2008-04-14 19:58:43.0 +0200 backup-manager-0.7.7/lib/backup-methods.sh 2010-01-22 12:40:04.787321885 +0100 +@@ -852,8 +852,8 @@ + warning Creating a default MySQL client configuration file: \$HOME/.my.cnf + echo [client] $HOME/.my.cnf + echo # The following password will be sent to all standard MySQL clients $HOME/.my.cnf +-echo password=\$BM_MYSQL_ADMINPASS\ $HOME/.my.cnf + chmod 600 $HOME/.my.cnf ++echo password=\$BM_MYSQL_ADMINPASS\ $HOME/.my.cnf + fi + base_command=$mysqldump $opt -u$BM_MYSQL_ADMINLOGIN -h$BM_MYSQL_HOST -P$BM_MYSQL_PORT + compress=$BM_MYSQL_FILETYPE pgpHPFqdkCLKq.pgp Description: PGP signature
oldstable update for backup-manager
Dear release team, I would like to upload a new version of the backup-manager to oldstable in order to fix CVE-2007-2766¹. The patch is taken from a commit in upstream's git repository², removing unrelated changes. Full debdiff is attached. Regards, Sven ¹ http://security-tracker.debian.org/tracker/CVE-2007-2766 ² http://github.com/sukria/Backup-Manager/commit/a4e57ad01d89bd0dcae1d19689ce442bfc4f118d diff -u backup-manager-0.7.5/debian/changelog backup-manager-0.7.5/debian/changelog --- backup-manager-0.7.5/debian/changelog +++ backup-manager-0.7.5/debian/changelog @@ -1,3 +1,12 @@ +backup-manager (0.7.5-5) oldstable; urgency=high + + * Fix leaking of MYSQL passwords to local users (CVE-2007-2766). +Note that the password is now taken from $HOME/.my.cnf if it exists, +overriding the BM_MYSQL_ADMINPASS variable in backup-manager.conf. + * Set myself as maintainer. + + -- Sven Joachim svenj...@gmx.de Fri, 22 Jan 2010 13:20:44 +0100 + backup-manager (0.7.5-4) stable-security; urgency=high * Backport from unstable (version 0.7.6-4) for closing a security issue: diff -u backup-manager-0.7.5/debian/control backup-manager-0.7.5/debian/control --- backup-manager-0.7.5/debian/control +++ backup-manager-0.7.5/debian/control @@ -3,7 +3,7 @@ Priority: optional Build-Depends-Indep: debiandoc-sgml, tetex-bin, tetex-extra Build-Depends: po-debconf, debhelper (= 5), dpatch -Maintainer: Alexis Sukrieh suk...@debian.org +Maintainer: Sven Joachim svenj...@gmx.de Standards-Version: 3.7.2 XS-Vcs-Svn: svn://svn.debian.org/svn/pkg-backup-mngr/trunk/ diff -u backup-manager-0.7.5/debian/patches/00list backup-manager-0.7.5/debian/patches/00list --- backup-manager-0.7.5/debian/patches/00list +++ backup-manager-0.7.5/debian/patches/00list @@ -6,0 +7 @@ +08_CVE-2007-2766.dpatch only in patch2: unchanged: --- backup-manager-0.7.5.orig/debian/patches/08_CVE-2007-2766.dpatch +++ backup-manager-0.7.5/debian/patches/08_CVE-2007-2766.dpatch @@ -0,0 +1,69 @@ +#! /bin/sh /usr/share/dpatch/dpatch-run +## 08_CVE-2007-2766.dpatch by Sven Joachim svenj...@gmx.de +## +## All lines beginning with `## DP:' are a description of the patch. +## DP: Fix leaking of MYSQL passwords to local users (CVE 2007-2766). + +...@dpatch@ +diff -urNad backup-manager-0.7.5~/doc/user-guide.sgml backup-manager-0.7.5/doc/user-guide.sgml +--- backup-manager-0.7.5~/doc/user-guide.sgml 2006-09-16 18:48:17.0 +0200 backup-manager-0.7.5/doc/user-guide.sgml 2010-01-22 13:12:10.327128967 +0100 +@@ -662,6 +662,21 @@ + This method provides a way to archive MySQL databases, the archives are made with + mysqldump (SQL text files) and can be compressed. + ++p ++In versions prior to 0.8, bmngr; used to pass the MySQL client's password through ++the command line. As explained by the MySQL manual, that's a security issue as ++the password is then readable for a short time in the /proc directory (or using ++the ps command). ++ ++p ++To close that vulnerability, the MySQL client password is not passed through ++the command line anymore, it is written in a configuration file located in the ++home directory of the user running bmngr; : tt~/.my.cnf/tt. ++ ++p ++If that file doesn't exist at runtime, bmngr; will create it and will then ++write the password provided in ttBM_MYSQL_ADMINPASS/tt inside. ++ + sect2 id=BM_MYSQL_DATABASESttBM_MYSQL_DATABASES/tt + + p +diff -urNad backup-manager-0.7.5~/lib/backup-methods.sh backup-manager-0.7.5/lib/backup-methods.sh +--- backup-manager-0.7.5~/lib/backup-methods.sh 2006-09-16 18:48:17.0 +0200 backup-manager-0.7.5/lib/backup-methods.sh 2010-01-22 13:13:45.147119826 +0100 +@@ -680,7 +680,21 @@ + opt=--opt + fi + +-base_command=$mysqldump $opt -u$BM_MYSQL_ADMINLOGIN -p$BM_MYSQL_ADMINPASS -h$BM_MYSQL_HOST -P$BM_MYSQL_PORT ++# if a MySQL Client conffile exists, the password must be inside ++if [ -f $HOME/.my.cnf ]; then ++info Using existing MySQL client configuration file: \$HOME/.my.cnf ++# we create a default one, just with the password ++else ++if [ -z $BM_MYSQL_ADMINPASS ]; then ++error You have to set BM_MYSQL_ADMINPASS in order to use the mysql method. ++fi ++warning Creating a default MySQL client configuration file: \$HOME/.my.cnf ++echo [client] $HOME/.my.cnf ++echo # The following password will be sent to all standard MySQL clients $HOME/.my.cnf ++chmod 600 $HOME/.my.cnf ++echo password=\$BM_MYSQL_ADMINPASS\ $HOME/.my.cnf ++fi ++base_command=$mysqldump $opt -u$BM_MYSQL_ADMINLOGIN -h$BM_MYSQL_HOST -P$BM_MYSQL_PORT + compress=$BM_MYSQL_FILETYPE + + for database in $BM_MYSQL_DATABASES +diff -urNad backup-manager-0.7.5~/lib/sanitize.sh backup-manager-0.7.5/lib/sanitize.sh +--- backup-manager-0.7.5~/lib/sanitize.sh 2006-09-16 18:48:17.0 +0200 backup-manager-0.7.5/lib/sanitize.sh 2010-01-22 13:12:10.327128967 +0100 +@@ -198,7 +198,6
Bug#559753: emacs21 still not removed
reopen 559753 thanks Unfortunately, emacs21 still has not been removed from testing. It seems that another removal hint is needed for prime (reverse dependency of libsuikyo-ruby1.8) to get rid of suikyo and thus emacs21. Sven -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: libjpeg62-dev - libjpeg-dev transition
On 2009-09-19 19:20 +0200, Pierre Habouzit wrote: On Sat, Sep 19, 2009 at 02:32:51PM +0200, Andreas Barth wrote: * Pierre Habouzit (madco...@madism.org) [090919 01:08]: I'll put blocks in my hint file to be sure that both those packages will migrate in testing together (I'm unsure if britney is clever enough to block them until all the binNMUs are done, I don't think it is). Then please ask for binNMUs of all the package that B-D on libjpeg-dev. Then we will let that migrate. The question is: Are libjpeg62 and libjepg7 co-useable? (This only works if symbol versioning is turned on.) Huh, libjpeg62 and libjpet7 have different so-name so they are co-installable. I don't get what you mean with co-useable and it certainly has nothing to do with symbol versioning. It has. If the symbols are not versioned, bad things may happen if both libraries are loaded into a process' address space. Sven -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: breaking the xserver-xorg-* circular dependency?
On 2008-12-04 21:54 +0100, Sven Joachim wrote:
On 2008-12-04 21:17 +0100, Julien Cristau wrote:
Hi,
for some reason, the etch-lenny upgrade results in epic fail when using
aptitude, because random X driver packages get removed.
At least if one accepts the first solution offered by aptitude, the
subsequent ones are usually better.
I'm not quite sure why it does that, but one candidate explanation is
the circular dependency between xserver-xorg, xserver-xorg-core and all
X drivers. Does someone have time to test such an upgrade, first with
the packages currently in lenny, and then with a modified
xserver-xorg-core that doesn't depend on xserver-xorg?
Short summary: no success, forget about the idea. For details, read on.
I volunteer for such a task (probably not tomorrow, but I should have
time over the weekend).
Did this today:
- debootstrapped an etch chroot
- aptitude install xserver-xorg-core
- change sources.list to lenny
- aptitude install aptitude
- aptitude -s full-upgrade
As had been confirmed several times before, aptitude wants to remove
xserver-xorg-video-all in this situation.
Do you have an apt-gettable repository for the
modified xserver-xorg-core?
Apparently not, so I built my own. The results were less than
satisfactory:
,
| # aptitude -s full-upgrade
| Reading package lists... Done
| Building dependency tree
| Reading state information... Done
| Reading extended state information
| Initializing package states... Done
| Reading task descriptions... Done
| The following packages are BROKEN:
| libsasl2
| The following NEW packages will be installed:
| bash-completion{a} dbus{a} dbus-x11{a} libdbus-1-3{a} libgnutls26{a}
libhal1{a}
| libldap-2.4-2{a} libpixman-1-0{a} libxcb-xlib0{a} libxcb1{a} lzma{a}
netcat-traditional{a}
| uuid-runtime{a}
| The following packages will be REMOVED:
| debconf-utils{u} defoma{u} discover1{u} discover1-data{u} file{u}
fontconfig-config{u}
| libcap1{u} libdb4.2{u} libdb4.3{u} libdb4.4{u} libdiscover1{a}
libfontconfig1{u} libfs6{u}
| libmagic1{u} libopencdk8{u} libsm6{u} libttf2{u} libxaw7{u} libxcursor1{u}
libxext6{u}
| libxfixes3{u} libxft2{u} libxi6{u} libxkbfile1{u} libxmu6{u} libxmuu1{u}
libxpm4{u}
| libxrandr2{u} libxrender1{u} libxss1{u} libxt6{u} libxtrap6{u} libxtst6{u}
libxv1{u}
| libxxf86dga1{u} libxxf86vm1{u} mdetect{u} perl{u} perl-doc{u}
perl-modules{u} ttf-dejavu{u}
| ucf{u} xbase-clients{u} xresprobe{u} xserver-xorg{u}
xserver-xorg-input-all{u}
| xserver-xorg-input-evdev{u} xserver-xorg-input-kbd{u}
xserver-xorg-input-mouse{u}
| xserver-xorg-input-synaptics{u} xserver-xorg-input-wacom{u}
xserver-xorg-video-all{u}
| xserver-xorg-video-apm{a} xserver-xorg-video-ark{a}
xserver-xorg-video-ati{a}
| xserver-xorg-video-chips{u} xserver-xorg-video-cirrus{u}
xserver-xorg-video-cyrix{u}
| xserver-xorg-video-dummy{u} xserver-xorg-video-fbdev{a}
xserver-xorg-video-glint{a}
| xserver-xorg-video-i128{u} xserver-xorg-video-i740{u}
xserver-xorg-video-i810{u}
| xserver-xorg-video-imstt{u} xserver-xorg-video-mga{a}
xserver-xorg-video-neomagic{u}
| xserver-xorg-video-newport{a} xserver-xorg-video-nsc{a}
xserver-xorg-video-nv{a}
| xserver-xorg-video-rendition{a} xserver-xorg-video-s3{a}
xserver-xorg-video-s3virge{a}
| xserver-xorg-video-savage{u} xserver-xorg-video-siliconmotion{a}
xserver-xorg-video-sis{a}
| xserver-xorg-video-sisusb{u} xserver-xorg-video-tdfx{a}
xserver-xorg-video-tga{a}
| xserver-xorg-video-trident{a} xserver-xorg-video-tseng{u}
xserver-xorg-video-v4l{a}
| xserver-xorg-video-vesa{a} xserver-xorg-video-vga{a}
xserver-xorg-video-via{a}
| xserver-xorg-video-vmware{u} xserver-xorg-video-voodoo{u}
| The following packages will be upgraded:
| adduser base-files base-passwd bash bsdmainutils bsdutils coreutils cpio
cron debconf
| debconf-i18n debian-archive-keyring debianutils dhcp3-client dhcp3-common
diff dmidecode dpkg
| dselect e2fslibs e2fsprogs ed findutils gcc-4.1-base gnupg gpgv grep
groff-base gzip hostname
| ifupdown info initscripts iptables iputils-ping klogd laptop-detect libacl1
libattr1
| libblkid1 libbz2-1.0 libcomerr2 libdrm2 libexpat1 libfontenc1 libfreetype6
libgcc1
| libgcrypt11 libgpg-error0 liblocale-gettext-perl libncurses5 libnewt0.52
libpam-modules
| libpam-runtime libpam0g libpng12-0 libpopt0 libreadline5 libsasl2-2
libselinux1 libsepol1
| libsigc++-2.0-0c2a libslang2 libss2 libssl0.9.8 libtasn1-3
libtext-charwidth-perl
| libtext-iconv-perl libtext-wrapi18n-perl libusb-0.1-4 libuuid1 libwrap0
libx11-6 libx11-data
| libxau6 libxdmcp6 libxfont1 login logrotate lsb-base makedev man-db
manpages mawk mktemp
| module-init-tools mount nano ncurses-base ncurses-bin net-tools netbase
netcat openbsd-inetd
| passwd perl-base procps readline-common sed sysklogd sysv-rc sysvinit
sysvinit-utils tar
| tasksel tasksel-data tcpd traceroute update-inetd
Re: breaking the xserver-xorg-* circular dependency?
On 2008-12-04 21:17 +0100, Julien Cristau wrote: Hi, for some reason, the etch-lenny upgrade results in epic fail when using aptitude, because random X driver packages get removed. At least if one accepts the first solution offered by aptitude, the subsequent ones are usually better. I'm not quite sure why it does that, but one candidate explanation is the circular dependency between xserver-xorg, xserver-xorg-core and all X drivers. Does someone have time to test such an upgrade, first with the packages currently in lenny, and then with a modified xserver-xorg-core that doesn't depend on xserver-xorg? I volunteer for such a task (probably not tomorrow, but I should have time over the weekend). Do you have an apt-gettable repository for the modified xserver-xorg-core? Cheers, Sven -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#507631: libghc6-happs-server-dev: uninstallable with unstable's hslogger
On 2008-12-03 12:59 +0100, Mark Purcell wrote: On Wednesday 03 December 2008 17:35:04 Chip Salzenberg wrote: Now that unstable's libghc6-hslogger-dev is updated, the happs packages are uninstallable. Quoting dselect: libghc6-happs-util-dev depends on libghc6-hslogger-dev ( 1.0.5.0+) This bug only effects sid, as libghc6-hslogger-dev hasn't migrated to lenny and from the looks it isn't planned for migration. John, Is it your intention for libghc6-hslogger-dev to migrate to lenny? If not are you aware that uploading to unstable, during freeze causes issues for your rdepends as they must now target fixes for lenny through tpu and not unstable. You can safely upload to experimental for new upstream releases without causing lenny issues for your rdepends. Release-Managers, I would recommend tagging this bug lenny-ignore if the intention is not to migrate libghc6-hslogger-dev. It should be tagged sid instead. Since Lenny is not affected by this bug, there is nothing to ignore. :-) Sven -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#507631: libghc6-happs-server-dev: uninstallable with unstable's hslogger
On 2008-12-03 14:01 +0100, Mark Purcell wrote: On Wednesday 03 December 2008 23:17:55 Sven Joachim wrote: Since Lenny is not affected by this bug, there is nothing to ignore. :-) Except the bug is filed against libghc6-happs-server-dev/0.9.2.1-3 which is currently in lenny (and sid) And? Tagging it sid should get it off the radar for lenny-relevant bugs, AIUI. For instance, #507189 is also tagged sid and not mentioned in http://bugs.debian.org/release-critical/other/testing.html. Sven -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Some unblock requests, again
On 2008-11-18 09:23 +0100, Josselin Mouette wrote: Le dimanche 16 novembre 2008 à 21:23 +0100, Josselin Mouette a écrit : fontconfig (2.6.0-2) unstable; urgency=low * Do not enable bitmap fonts by default. Closes: #496716. + rules: ship an empty 70-yes-bitmaps.conf and rename the original to 70-force-bitmaps.conf. + fontconfig-config.postinst: install the symbolic link to 70-yes-bitmaps.conf if asked to do so. + fontconfig-config.config: always assume bitmap fonts are not wanted if no symbolic link is present. There were some issues with this attempt, so I have uploaded a hopefully better version: fontconfig (2.6.0-3) unstable; urgency=low * Remove doc/Makefile and doc/version.sgml in the clean target. * Ship a minimal 70-yes-bitmaps.conf to avoid spurious warnings. Closes: #505969. * fontconfig-config.config: don’t force the bitmap fonts to be off, rather re-ask when we find no existing symbolic link, since in this case the intent of the user is unknown. Closes: #505970. Alas, this upload does not fix #505994. And apparently I'm not the only one who sorely misses the fixed font, see #506124. Regards, Sven -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Some unblock requests, again
On 2008-11-18 17:36 +0100, Josselin Mouette wrote: Le mardi 18 novembre 2008 à 17:13 +0100, Sven Joachim a écrit : fontconfig (2.6.0-3) unstable; urgency=low * Remove doc/Makefile and doc/version.sgml in the clean target. * Ship a minimal 70-yes-bitmaps.conf to avoid spurious warnings. Closes: #505969. * fontconfig-config.config: don’t force the bitmap fonts to be off, rather re-ask when we find no existing symbolic link, since in this case the intent of the user is unknown. Closes: #505970. Alas, this upload does not fix #505994. I really can’t reproduce #505994. Maybe you should check the symbolic links and files in /etc/fonts; with enabled_bitmaps=true, the configuration should be exactly the same between 2.6.0-1 and -3. Well, here is the listing of /etc/fonts with 2.6.0-1: % ls -lR /etc/fonts/ /etc/fonts/: total 21 drwxr-xr-x 2 root root 2048 Nov 18 11:48 conf.avail drwxr-xr-x 2 root root 2048 Nov 18 11:48 conf.d -rw-r--r-- 1 root root 5287 Nov 14 2007 fonts.conf -rw-r--r-- 1 root root 6961 Nov 14 2007 fonts.dtd /etc/fonts/conf.avail: total 91 -rw-r--r-- 1 root root 220 Nov 14 2007 10-autohint.conf -rw-r--r-- 1 root root 226 Nov 14 2007 10-no-sub-pixel.conf -rw-r--r-- 1 root root 225 Nov 14 2007 10-sub-pixel-bgr.conf -rw-r--r-- 1 root root 225 Nov 14 2007 10-sub-pixel-rgb.conf -rw-r--r-- 1 root root 226 Nov 14 2007 10-sub-pixel-vbgr.conf -rw-r--r-- 1 root root 226 Nov 14 2007 10-sub-pixel-vrgb.conf -rw-r--r-- 1 root root 217 Nov 14 2007 10-unhinted.conf -rw-r--r-- 1 root root 912 Nov 14 2007 20-fix-globaladvance.conf -rw-r--r-- 1 root root 301 Sep 15 2006 20-lohit-gujarati.conf -rw-r--r-- 1 root root 1157 Nov 14 2007 20-unhint-small-vera.conf -rw-r--r-- 1 root root 3165 May 25 05:30 25-unhint-nonlatin.conf -rw-r--r-- 1 root root 514 Sep 15 2006 30-amt-aliases.conf -rw-r--r-- 1 root root 4107 Nov 14 2007 30-metric-aliases.conf -rw-r--r-- 1 root root 1290 Nov 14 2007 30-urw-aliases.conf -rw-r--r-- 1 root root 1723 Sep 15 2006 40-generic.conf -rw-r--r-- 1 root root 2069 May 25 05:30 40-nonlatin.conf -rw-r--r-- 1 root root 1806 May 25 05:30 45-latin.conf -rw-r--r-- 1 root root 545 Sep 15 2006 49-sansserif.conf -rw-r--r-- 1 root root 188 Nov 14 2007 50-user.conf -rw-r--r-- 1 root root 189 Nov 14 2007 51-local.conf -rw-r--r-- 1 root root 1669 May 25 05:30 60-latin.conf -rw-r--r-- 1 root root 10524 May 25 05:30 65-fonts-persian.conf -rw-r--r-- 1 root root 289 May 25 05:30 65-khmer.conf -rw-r--r-- 1 root root 6552 May 25 05:30 65-nonlatin.conf -rw-r--r-- 1 root root 672 May 25 05:30 69-unifont.conf -rw-r--r-- 1 root root 263 Nov 16 17:39 70-force-bitmaps.conf -rw-r--r-- 1 root root 263 Nov 14 2007 70-no-bitmaps.conf -rw-r--r-- 1 root root 263 Jun 1 05:03 70-yes-bitmaps.conf -rw-r--r-- 1 root root 388 Nov 14 2007 80-delicious.conf -rw-r--r-- 1 root root 1754 Sep 15 2006 90-synthetic.conf -rw-r--r-- 1 root root 959 Nov 14 2007 README /etc/fonts/conf.d: total 16 lrwxrwxrwx 1 root root 39 Nov 18 11:47 20-fix-globaladvance.conf - ../conf.avail/20-fix-globaladvance.conf lrwxrwxrwx 1 root root 39 Nov 18 11:47 20-unhint-small-vera.conf - ../conf.avail/20-unhint-small-vera.conf lrwxrwxrwx 1 root root 39 Nov 18 11:48 30-defoma.conf - /var/lib/defoma/fontconfig.d/fonts.conf lrwxrwxrwx 1 root root 36 Nov 18 11:47 30-metric-aliases.conf - ../conf.avail/30-metric-aliases.conf lrwxrwxrwx 1 root root 33 Nov 18 11:47 30-urw-aliases.conf - ../conf.avail/30-urw-aliases.conf lrwxrwxrwx 1 root root 30 Nov 18 11:47 40-nonlatin.conf - ../conf.avail/40-nonlatin.conf lrwxrwxrwx 1 root root 27 Nov 18 11:47 45-latin.conf - ../conf.avail/45-latin.conf lrwxrwxrwx 1 root root 31 Nov 18 11:47 49-sansserif.conf - ../conf.avail/49-sansserif.conf -rw-r--r-- 1 root root 254 Jan 2 2006 50-enable-terminus.conf lrwxrwxrwx 1 root root 26 Nov 18 11:47 50-user.conf - ../conf.avail/50-user.conf lrwxrwxrwx 1 root root 27 Nov 18 11:47 51-local.conf - ../conf.avail/51-local.conf lrwxrwxrwx 1 root root 27 Nov 18 11:47 60-latin.conf - ../conf.avail/60-latin.conf lrwxrwxrwx 1 root root 35 Nov 18 11:47 65-fonts-persian.conf - ../conf.avail/65-fonts-persian.conf lrwxrwxrwx 1 root root 30 Nov 18 11:47 65-nonlatin.conf - ../conf.avail/65-nonlatin.conf lrwxrwxrwx 1 root root 29 Nov 18 11:47 69-unifont.conf - ../conf.avail/69-unifont.conf lrwxrwxrwx 1 root root 31 Nov 18 11:47 80-delicious.conf - ../conf.avail/80-delicious.conf lrwxrwxrwx 1 root root 31 Nov 18 11:47 90-synthetic.conf - ../conf.avail/90-synthetic.conf -rw-r--r-- 1 root root 959 May 25 05:30 README -rw-r--r-- 1 root root 250 Feb 1 2006 autohint.conf -rw-r--r-- 1 root root 306 Feb 1 2006 no-bitmaps.conf -rw-r--r-- 1 root root 257 Feb 1 2006 no-sub-pixel.conf -rw-r--r-- 1 root root 256 Feb 1 2006 sub-pixel.conf -rw-r--r-- 1 root root 247 Feb 1 2006 unhinted.conf -rw-r--r-- 1 root root 296 Feb 1 2006 yes-bitmaps.conf After
Re: Some unblock requests, again
On 2008-11-18 21:51 +0100, Josselin Mouette wrote: Le mardi 18 novembre 2008 à 20:01 +0100, Sven Joachim a écrit : Apart from /etc/fonts/conf.avail/70-yes-bitmaps.conf and the new symlink in /etc/fonts/conf.d to it there seems to be no difference. Indeed; which means the configuration should be exactly the same. Apparently this is caused by the missing cache for bitmap fonts after running dpkg-reconfigure. So this means we need to re-run fc-cache -fs after a reconfigure in fontconfig-config - a bug that was already here before that change. Correct, after fc-cache -fs the bitmap fonts are there again. :-) Unfortunately I don’t know of a means to reliably detect whether we’re reconfiguring. Maybe by checking if fontconfig is in installed state, but I feel this would be hackish. Maybe a dpkg trigger in the fontconfig package could be used? This has already been suggested in #498948. Cheers, Sven -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Unsmooth transition libungif4g - libgif4
Today a version of imlib11¹ built against libgif4 was uploaded to unstable, and I noticed that it can't be installed because emacs21, emacs22-gtk and icewm all depend on libungif4g (= 4.1.4) which conflicts against libgif4. Although libgif4 provides libungif4g, this does not help much, since dpkg does not support versioned `provides', see #24934 and friends. :-( So it seems that all packages currently build-depending on libungif4-dev need to be rebuilt against libgif-dev to resolve the issue; binNMUs will not be enough, sourceful uploads are necessary. If I got it right, the following 40 source packages build-depend on libungif-dev: afterstep camlimages cheops-ng driftnet emacs21 emacs22 fbi fenix fontforge fsviewer gdal gnome-libs gnucash gnustep-gui imlib2 kaffe kde4libs ktoon libgdiplus libimager-perl metapixel mgp ming mplayer mtpaint openscenegraph paintlib paul pslib shoes simage spamprobe swftools ted wdm wine wmaker xkbsel xplanet pgplot5 [non-free] Regards, Sven ¹ http://packages.debian.org/sid/imlib11 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unsmooth transition libungif4g - libgif4
On 2008-02-05 17:50 +0100, Sune Vuorela wrote: On 2008-02-05, Sven Joachim [EMAIL PROTECTED] wrote: Today a version of imlib11¹ built against libgif4 was uploaded to unstable, and I noticed that it can't be installed because emacs21, woops. My fault I guess. didn't put that much into the change. I can also revert imlib11 if preferred by release team at this stage. But it would be nice to unify on one giflib thingy. Indeed, libungif4 is scheduled for removal. So it seems that all packages currently build-depending on libungif4-dev need to be rebuilt against libgif-dev to resolve the issue; binNMUs will not be enough, sourceful uploads are necessary. Having libungif4-dev shlib file say libungif4g (=something) | libgif4 and binNMU all rdepends could be a smoother way, but maybe not preferred. I have another idea: let giflib build a dummy package libungif4g that depends on libgif4 and version the `Conflicts' and `Replaces' of libgif4 on libungif4g. That way libgif4 could work around the lack of versioned `Provides' in dpkg, and there's no hurry to update all packages build-depending on libungif4-dev immediately. Does that sound reasonable? Sven -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
