Re: Re-evaluating architecture inclusion in unstable/experimental
On Sat, 2018-09-29 at 17:05 +0200, John Paul Adrian Glaubitz wrote: > On 9/29/18 8:48 AM, Ben Hutchings wrote: > > On Fri, 2018-09-28 at 14:16 +0200, John Paul Adrian Glaubitz wrote: > > [...] > > > Furthermore, several of the ports are in very healthy condition and > > > even surpass some release architectures. The powerpc and ppc64 ports, > > > for example, build more packages than any of the mips* ports. > > > > I would be very happy to never have to wait for MIPS builds again. > > I don't have a problem with waiting for slow machines. I just think this > shows that the decisions what becomes a release architecture and what > doesn't isn't purely meritocratic. It's been a long time since Debian could run infrastructure on donated hardware. We need hardware that is reliable and that can be quickly replaced when (not if) it fails. So commercial availability is, and should continue to be, a release qualification. It is also unacceptable that the release of an urgent security update should have to wait a long time for builds. So speed matters. [...] > I think the problem that I have is that the release qualifications are > not practical in the sense that they don't necessarily meet our users > expectations. As I said, I think a tier-based system would be more > practical as it would allow ports to be degraded more gracefully instead > of just kicking them out like it was done with 32-Bit PowerPC. [...] Could you be more specific? Ben. -- Ben Hutchings For every action, there is an equal and opposite criticism. - Harrison signature.asc Description: This is a digitally signed message part
Re: Re-evaluating architecture inclusion in unstable/experimental
On 9/29/18 8:48 AM, Ben Hutchings wrote: > On Fri, 2018-09-28 at 14:16 +0200, John Paul Adrian Glaubitz wrote: > [...] >> Furthermore, several of the ports are in very healthy condition and >> even surpass some release architectures. The powerpc and ppc64 ports, >> for example, build more packages than any of the mips* ports. > > I would be very happy to never have to wait for MIPS builds again. I don't have a problem with waiting for slow machines. I just think this shows that the decisions what becomes a release architecture and what doesn't isn't purely meritocratic. >> As for the kernel maintenance, except for Alpha, all the ports have >> at least one kernel maintainer: >> >> * hppa: actively maintained by two people who also maintain the toolchain > > But the hardware is EOL since 2008. Well, the hardware is usually build like tanks and if people keep using it and others keep maintaining it, why throw something out when it's still working? SAP is still maintaining and supporting JDK on PA-RISC and IA64 for paying customers, FWIW. >> * ia64: maintained by one paid developer at Intel > > To the extent of 2 whole commits this year! I'm pretty sure this is > not actually his job any more. Jason Duerstock talked to him and he said, he's still doing this as a job at Intel because basically no one told him to stop doing it. >> * m68k: maintained by multiple independent kernel maintainers, at least >> five people involved upstream; port is also getting new drivers > > But the available hardware is either too slow to be useful, or only > available through crowdfunding (maybe, eventually). Yes, this is being worked on. There are FPGA-based implementations which allow to boost Amiga and Atari hardware to considerably higher speeds. It's not done on a large commercial scale, so things take longer to develop. But people are working on it and bugs get fixed, code maintained and drivers added. >> * powerpc/ppc64: maintained mostly by IBM people > > IBM looks after 64-bit configurations, so ppc64 is covered but not > powerpc. Well, I have had people from IBM fix 32-bit PowerPC code. There is naturally more involvement behind the 64-bit stuff because that's where the commercial interests are. >> * sh4: maintained by two kernel maintainers > > That may be, but the Debian port isn't stable enough to *build* a > kernel: https://buildd.debian.org/status/logs.php?pkg=linux=sh4 That's a compiler bug, I know. >> * sparc64: used to be maintained by a team at Oracle but Oracle recently >> changed their mind about Linux on SPARC; now it's back to >> David Miller and some additional volunteers > > Oracle laid off their SPARC team. Fujitsu has another SPARC processor > in development, but only for supercomputers (and they seem to be > switching to Aarch64 later). So we can expect this architecture to > slowly fade away now. What Oracle is really doing and planning isn't really clear. I have talked to multiple people at Oracle directly and the consensus is that there isn't a consensus what is going to happen next. But again, this just supports my point that the decisions which ports become release architectures is mostly driven by commercial interests and not whether there are users in the community. Or is there actually a large community of POWER8 and z-Series Debian users? >> * x32: maintained by the people who maintain the x86 port of the kernel > > H. Peter Anvin did the original port in 2012, but so far as I can see > none of the x86 maintainers have done any development on it since then. > And yes, development work has been needed: > > - x32 has 64-bit time_t and that never worked quite right. This may > have finally been fixed this year by Arnd Bergmann's work, but I'm > not sure. > - syscall restart was broken until 2015 when someone actually tested > it. > - There have been several regressions specific to x32, some of which > stuck around for a year or so before someone and fixed them. > > [...] > > So, by all means have fun working on these ports, but aside from ppc64 > I don't see any prospect of them meeting release qualifications. I think the problem that I have is that the release qualifications are not practical in the sense that they don't necessarily meet our users expectations. As I said, I think a tier-based system would be more practical as it would allow ports to be degraded more gracefully instead of just kicking them out like it was done with 32-Bit PowerPC. I don't have a proper concept yet, but I think the OBS approach is more versatile, for example. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#909842: stretch-pu: package libx11/2:1.6.4-3
Package: release.debian.org Severity: normal Tags: stretch User: release.debian@packages.debian.org Usertags: pu Dear release team, I would like to update libx11 in Stretch because it is currently affected by CVE-2018-14598, CVE-2018-14599 and CVE-2018-14600. The security team marked all issues as no-dsa. Please find attached the debdiff. I had to refresh one unrelated patch because it did not apply correctly. No other changes were made. Regards, Markus diff -u libx11-1.6.4/debian/changelog libx11-1.6.4/debian/changelog --- libx11-1.6.4/debian/changelog +++ libx11-1.6.4/debian/changelog @@ -1,3 +1,23 @@ +libx11 (2:1.6.4-3+deb9u1) stretch; urgency=high + + * Non-maintainer upload. + * Fix CVE-2018-14598, CVE-2018-14599 and CVE-2018-14600: + * CVE-2018-14599: +The functions XGetFontPath, XListExtensions, and XListFonts are vulnerable +to an off-by-one override on malicious server responses. + * CVE-2018-14600: +The length value is interpreted as signed char on many systems (depending +on default signedness of char), which can lead to an out of boundary write +up to 128 bytes in front of the allocated storage, but limited to NUL +byte(s). + * CVE-2018-14598: +If the server sends a reply in which even the first string would overflow +the transmitted bytes, list[0] (or flist[0]) will be set to NULL and a +count of 0 is returned. This may trigger a segmentation fault leading to a +Denial of Service. + + -- Markus Koschany Sat, 29 Sep 2018 14:05:05 +0200 + libx11 (2:1.6.4-3) unstable; urgency=high [ Emilio Pozuelo Monfort ] diff -u libx11-1.6.4/debian/patches/003_recognize_glibc_2.3.2_locale_names.diff libx11-1.6.4/debian/patches/003_recognize_glibc_2.3.2_locale_names.diff --- libx11-1.6.4/debian/patches/003_recognize_glibc_2.3.2_locale_names.diff +++ libx11-1.6.4/debian/patches/003_recognize_glibc_2.3.2_locale_names.diff @@ -49,10 +49,8 @@ Partially submitted upstream. This is so large I don't expect it to all go in at once, but any bit would help. --Nathanael -Index: libx11/nls/compose.dir.pre -=== libx11.orig/nls/compose.dir.pre -+++ libx11/nls/compose.dir.pre +--- a/nls/compose.dir.pre b/nls/compose.dir.pre @@ -4,8 +4,13 @@ XCOMM The first word is the compose tabl XCOMM and the second word is the full locale name. XCOMM @@ -234,7 +232,7 @@ en_US.UTF-8/Compose: ph_PH.UTF-8 en_US.UTF-8/Compose: pl_PL.UTF-8 en_US.UTF-8/Compose: pp_AN.UTF-8 -@@ -433,9 +466,11 @@ en_US.UTF-8/Compose: sd_IN@devanagari.U +@@ -433,9 +466,11 @@ en_US.UTF-8/Compose: sd_IN.UTF-8@devana en_US.UTF-8/Compose: se_NO.UTF-8 en_US.UTF-8/Compose: sh_BA.UTF-8 en_US.UTF-8/Compose: sh_YU.UTF-8 @@ -254,10 +252,8 @@ en_US.UTF-8/Compose: tl_PH.UTF-8 en_US.UTF-8/Compose: tn_ZA.UTF-8 en_US.UTF-8/Compose: tr_TR.UTF-8 -Index: libx11/nls/locale.alias.pre -=== libx11.orig/nls/locale.alias.pre -+++ libx11/nls/locale.alias.pre +--- a/nls/locale.alias.pre b/nls/locale.alias.pre @@ -311,6 +311,12 @@ en_CA.iso88591: en_CA.ISO8859-1 en_CA.ISO-8859-1: en_CA.ISO8859-1 en_CA.ISO_8859-1: en_CA.ISO8859-1 @@ -332,10 +328,8 @@ french: fr_FR.ISO8859-1 french.iso88591: fr_CH.ISO8859-1 galego: gl_ES.ISO8859-1 -Index: libx11/nls/locale.dir.pre -=== libx11.orig/nls/locale.dir.pre -+++ libx11/nls/locale.dir.pre +--- a/nls/locale.dir.pre b/nls/locale.dir.pre @@ -6,8 +6,11 @@ XCOMM XCOMM @@ -458,7 +452,7 @@ en_US.UTF-8/XLC_LOCALE: af_ZA.UTF-8 en_US.UTF-8/XLC_LOCALE: am_ET.UTF-8 en_US.UTF-8/XLC_LOCALE: ar_AA.UTF-8 -@@ -297,6 +319,7 @@ en_US.UTF-8/XLC_LOCALE:bn_BD.UTF-8 +@@ -298,6 +320,7 @@ en_US.UTF-8/XLC_LOCALE:bn_BD.UTF-8 en_US.UTF-8/XLC_LOCALE: bn_IN.UTF-8 en_US.UTF-8/XLC_LOCALE: bo_IN.UTF-8 en_US.UTF-8/XLC_LOCALE: br_FR.UTF-8 @@ -538,7 +532,7 @@ en_US.UTF-8/XLC_LOCALE: pp_AN.UTF-8 @@ -431,11 +467,13 @@ en_US.UTF-8/XLC_LOCALE: en_US.UTF-8/XLC_LOCALE: sd_IN.UTF-8 - en_US.UTF-8/XLC_LOCALE: sd...@devanagari.utf-8 + en_US.UTF-8/XLC_LOCALE: sd_IN.UTF-8@devanagari en_US.UTF-8/XLC_LOCALE: se_NO.UTF-8 +en_US.UTF-8/XLC_LOCALE:sid_ET.UTF-8 en_US.UTF-8/XLC_LOCALE: sh_BA.UTF-8 @@ -550,7 +544,7 @@ en_US.UTF-8/XLC_LOCALE:
Re: Upload every package every release cycle
Lars Wirzenius: > Should we require each source package in Debian to be uploaded at > least once per release cycle? > > Lintian[0] reports that there are currently over 7000 packages with an > ancient Standards-Version. That's a lot of packages. Some of those > haven't been uploaded in years. That means that the packages haven't > had attention by their maintainer (or an NMUer) in years. Sometimes > that's OK: there's nothing that needs changing in the package, and > upstream is dormant. > > However, it seems to me that without inspecting each package manually, > we can't know if fixes are needed. It would seems to me that having an > automated way of verifying that a package gets at least minimal > attention would be good for Debian. > > I propose we implement that by requiring that each package gets > uploaded at least once per release cycle, and that the upload updates > the package to match current policy, indicated by updating the > Standards-Version field to one that is not ancient. > > In more detail, I propose the following: > > * When the release freeze begins, every package in testing must have a > Standards-Version that is less than 24 months old (the threshold for > the ancient-standards-version warning in lintian), and will be > removed from testing. > > * Six months before the freeze, RC bugs get filed for any packages > that have the ancient-standards-version lintian warning. This would > leave ample time to fix the problem for any one package. > > [0]: https://lintian.debian.org/tags/ancient-standards-version.html > Hi Lars, Thanks for the proposal. I am not certain this is a proposal that should be driven by the release team. Given its wide-spread affect on how volunteers will have to allocate their Debian time and how many packages it affect, I think it should have consensus among the Debian developer body rather than just the release team. In particular, I am concerned that a significant amount of people will oppose this as a QA check worthy of gating packaging from the release. Along those lines, it might be interesting to start off less ambitious and limit it to several releases out of date. I have pulled the numbers grouped by the date of the policy used in [1]. Note these numbers are from unstable + experimental; we do not have the numbers from testing (as lintian only check unstable + experimental). Thanks, ~Niels [1] $ grep ancient-standards /srv/lintian.debian.org/logs/lintian.log | \ perl -p -E 's/.*\(released (\d+-\d+-\d+)\).*/$1/' | sort | uniq -c 1 1999-07-15 2 1999-11-16 3 2000-08-24 1 2001-01-29 1 2001-02-15 10 2001-02-18 1 2001-06-01 10 2001-07-25 4 2002-08-31 6 2002-11-15 2 2003-03-07 2 2003-05-10 6 2003-07-09 33 2003-08-19 39 2005-06-17 179 2006-05-03 109 2007-12-03 131 2008-06-04 78 2009-03-12 62 2009-06-16 199 2009-08-16 205 2010-01-27 23 2010-06-28 230 2010-07-26 568 2011-04-07 669 2012-02-23 820 2012-09-19 1251 2013-10-28 2812 2014-09-17
Re: Re-evaluating architecture inclusion in unstable/experimental
On Fri, 2018-09-28 at 14:16 +0200, John Paul Adrian Glaubitz wrote: [...] > Furthermore, several of the ports are in very healthy condition and > even surpass some release architectures. The powerpc and ppc64 ports, > for example, build more packages than any of the mips* ports. I would be very happy to never have to wait for MIPS builds again. > As for the kernel maintenance, except for Alpha, all the ports have > at least one kernel maintainer: > > * hppa: actively maintained by two people who also maintain the toolchain But the hardware is EOL since 2008. > * ia64: maintained by one paid developer at Intel To the extent of 2 whole commits this year! I'm pretty sure this is not actually his job any more. > * m68k: maintained by multiple independent kernel maintainers, at least > five people involved upstream; port is also getting new drivers But the available hardware is either too slow to be useful, or only available through crowdfunding (maybe, eventually). > * powerpc/ppc64: maintained mostly by IBM people IBM looks after 64-bit configurations, so ppc64 is covered but not powerpc. > * sh4: maintained by two kernel maintainers That may be, but the Debian port isn't stable enough to *build* a kernel: https://buildd.debian.org/status/logs.php?pkg=linux=sh4 > * sparc64: used to be maintained by a team at Oracle but Oracle recently > changed their mind about Linux on SPARC; now it's back to > David Miller and some additional volunteers Oracle laid off their SPARC team. Fujitsu has another SPARC processor in development, but only for supercomputers (and they seem to be switching to Aarch64 later). So we can expect this architecture to slowly fade away now. > * x32: maintained by the people who maintain the x86 port of the kernel H. Peter Anvin did the original port in 2012, but so far as I can see none of the x86 maintainers have done any development on it since then. And yes, development work has been needed: - x32 has 64-bit time_t and that never worked quite right. This may have finally been fixed this year by Arnd Bergmann's work, but I'm not sure. - syscall restart was broken until 2015 when someone actually tested it. - There have been several regressions specific to x32, some of which stuck around for a year or so before someone and fixed them. [...] So, by all means have fun working on these ports, but aside from ppc64 I don't see any prospect of them meeting release qualifications. Ben. -- Ben Hutchings For every action, there is an equal and opposite criticism. - Harrison signature.asc Description: This is a digitally signed message part
