Bug#935481: stretch-pu: package basez/1.6-3
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
Hi Stable Release Managers,
The basez version released in stretch is affected by bug #931041 and is
consequently not properly decoding base64url stream. This bug has been
fixed in sid, testing and buster-pu. I'm about to upload fixed
basez/1.6-3+deb9u1 package for stretch. See attached debdiff.
Milan
diff -Nru basez-1.6/debian/changelog basez-1.6/debian/changelog
--- basez-1.6/debian/changelog 2016-10-27 09:33:37.0 -0400
+++ basez-1.6/debian/changelog 2019-08-22 22:07:39.0 -0400
@@ -1,3 +1,9 @@
+basez (1.6-3+deb9u1) stretch; urgency=medium
+
+ * Properly decode base64url encoded strings (closes: #931041)
+
+ -- Milan Kupcevic Thu, 22 Aug 2019 22:07:39 -0400
+
basez (1.6-3) unstable; urgency=medium
* Remove configure getconf libs.
diff -Nru basez-1.6/debian/patches/base64url-decode-bug-931041
basez-1.6/debian/patches/base64url-decode-bug-931041
--- basez-1.6/debian/patches/base64url-decode-bug-9310411969-12-31
19:00:00.0 -0500
+++ basez-1.6/debian/patches/base64url-decode-bug-9310412019-08-03
23:29:13.0 -0400
@@ -0,0 +1,16 @@
+Description: properly decode base64url encoded strings
+Author: Milan Kupcevic
+Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931041
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/base64.c
b/base64.c
+@@ -188,7 +188,7 @@
+ bout[0] = bout[0] | c[bin[1]] >> 4;
+ }
+
+- switch(c64d[bin[2]])
++ switch(c[bin[2]])
+ {
+ case 0xfe:
+ if(bin[3] == '=')
diff -Nru basez-1.6/debian/patches/series basez-1.6/debian/patches/series
--- basez-1.6/debian/patches/series 1969-12-31 19:00:00.0 -0500
+++ basez-1.6/debian/patches/series 2019-08-03 22:15:31.0 -0400
@@ -0,0 +1 @@
+base64url-decode-bug-931041
Bug#934537: buster-pu: package basez/1.6-3+deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Hi Stable Release Managers,
The basez version released in buster is affected by bug #931041 and is
consequently not properly decoding base64url stream. This bug has been
fixed in sid and testing. I've prepared fixed basez/1.6-3+deb10u1 package
for buster. See attached debdiff.
Milan
diff -Nru basez-1.6/debian/changelog basez-1.6/debian/changelog
--- basez-1.6/debian/changelog 2016-10-27 09:33:37.0 -0400
+++ basez-1.6/debian/changelog 2019-08-11 18:59:28.0 -0400
@@ -1,3 +1,9 @@
+basez (1.6-3+deb10u1) buster; urgency=medium
+
+ * Properly decode base64url encoded strings (closes: #931041)
+
+ -- Milan Kupcevic Sun, 11 Aug 2019 18:59:28 -0400
+
basez (1.6-3) unstable; urgency=medium
* Remove configure getconf libs.
diff -Nru basez-1.6/debian/patches/base64url-decode-bug-931041
basez-1.6/debian/patches/base64url-decode-bug-931041
--- basez-1.6/debian/patches/base64url-decode-bug-9310411969-12-31
19:00:00.0 -0500
+++ basez-1.6/debian/patches/base64url-decode-bug-9310412019-08-03
23:29:13.0 -0400
@@ -0,0 +1,16 @@
+Description: properly decode base64url encoded strings
+Author: Milan Kupcevic
+Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931041
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/base64.c
b/base64.c
+@@ -188,7 +188,7 @@
+ bout[0] = bout[0] | c[bin[1]] >> 4;
+ }
+
+- switch(c64d[bin[2]])
++ switch(c[bin[2]])
+ {
+ case 0xfe:
+ if(bin[3] == '=')
diff -Nru basez-1.6/debian/patches/series basez-1.6/debian/patches/series
--- basez-1.6/debian/patches/series 1969-12-31 19:00:00.0 -0500
+++ basez-1.6/debian/patches/series 2019-08-03 22:15:31.0 -0400
@@ -0,0 +1 @@
+base64url-decode-bug-931041
Re: Proposal: Repository for fast-paced package backports
On 12/25/18 3:46 PM, Dominik George wrote: [...] > > Name of the new repository > == > > In the past, the name “volatile” was used for a similar repository, but > with a different scope (limited to data packages for things like virus > scanners). I will thus use the working title volatile throughout this > proposal, although this may change. > > Other ideas: fastlane, unsupported > "rolling" sounds like a good fit [...] > > Building packages and package dependencies > == > > Packages for volatile are built the same way as formal backports, only > that the source is taken from unstable rather than testing. In > particular: > > - Changes shall be kept as small as possible. > - The package is rebuilt against stable. > - The package may depend on packages in stable, stable-backports or > stable-volatile. > stable-rolling sounds more appropriate than stable-volatile. > Dependencies on other packages in volatile should be avoided if > possible. How to handle upgrades from stable to stable+1. Packages from backports upgrade with no issues as stable+1 contains the same packages already compiled for the stable+1. How about LTS? As stable-rolling repository would be usable in conjunction with stable-backports and stable, would then oldstable-rolling continue to roll or just freeze in place at the moment when the stable becomes oldstable? [...] > > > Implications for the situation at hand (gitlab) > === > > As there were quite a few concerns raised (some of which I share, and > some I don’t): Of course, if a software intended for volatile has a ton > of dependencies (intended to go into backports), all backports rules and > powers of the ftp-masters apply. Repeating myself: volatile is not meant > to ease the life of maintainers. > Continuous delivery development model based upstream applications are not quite a good fit for a stable release distribution. Milan signature.asc Description: OpenPGP digital signature
Re: Porter roll call for Debian Stretch
On 09/20/2016 05:46 PM, John Paul Adrian Glaubitz wrote: > On 09/20/2016 11:16 PM, Niels Thykier wrote: >>- powerpc: No porter (RM blocker) > > I'd be happy to pick up powerpc to keep it for Stretch. I'm already > maintaining powerpcspe which is very similar to powerpc. > Thank you Adrian for stepping up. You will have my support in this endeavor for the Stretch release. Milan signature.asc Description: OpenPGP digital signature
Bug#793556: jessie-pu: package mkvmlinuz/37+deb8u1
Hi Adam, We've got third party confirmations and requests[0][1] for this fix. Should I upload mkvmlinuz/37+deb8u1 to s-p-u? Milan [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793556#28 [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741642#56 signature.asc Description: OpenPGP digital signature
Bug#793556: jessie-pu: package mkvmlinuz/37+deb8u1
On 12/13/2015 05:21 PM, Adam D. Barratt wrote: > Control: tags -1 -moreinfo +confirmed > > On Sun, 2015-12-13 at 13:01 -0500, Milan Kupcevic wrote: >> Hi Adam, >> >> We've got third party confirmations and requests[0][1] for this fix. >> Should I upload mkvmlinuz/37+deb8u1 to s-p-u? > > I was rather hoping that your poking of debian-kernel might elicit some > response, but apparently not. Please go ahead. > Thanks. Uploaded. Milan signature.asc Description: OpenPGP digital signature
Bug#793556: jessie-pu: package mkvmlinuz/37+deb8u1
On 12/08/2015 01:10 PM, Gerhard Pircher wrote: [ ... ] > It has been verified that the bugfix in version mkvmlinuz/37+deb8u1 > fixes this problem. Thus I would to ask, if this new mkvmlinuz > version will be available anytime soon in Debian stable? > I'm waiting for release managers decision at this point. Milan signature.asc Description: OpenPGP digital signature
Bug#793556: jessie-pu: package mkvmlinuz/37+deb8u1
On 07/25/2015 06:38 AM, Adam D. Barratt wrote: Control: tags -1 + moreinfo On Fri, 2015-07-24 at 22:32 -0400, Milan Kupcevic wrote: mkvmlinuz/37+deb8u1 is fixing bug #741642 already fixed in sid/testing to allow for smooth upgrade from wheezy to jessie. See attached diff. changelog |6 ++ kernel-image/postinst |2 ++ kernel-image/postrm |2 ++ --- mkvmlinuz-37/debian/kernel-image/postinst 2012-06-28 21:01:13.0 -0400 +++ mkvmlinuz-37+deb8u1/debian/kernel-image/postinst2015-07-23 22:45:48.0 -0400 @@ -1,5 +1,7 @@ #!/bin/sh +echo 2 Will the mkvmlinuz invocation later in the postinst ever possibly produce output on stdout? The db_get debconf call does communicate with debconf through stdin/stdout by design. That is why nothing else should use stdin nor stdout at stake for not to interfere with such communication. The violation actually comes from 'run-parts --report' itself, not from the hook. Wheezy kernel package has been using 'run-parts --verbose' to run the hooks. This worked fine as run-parts printed out to stderr only. Jessie kernel package is using 'run-parts --report' instead where output depends on the behavior of the hook in question. See run-parts manual for the exact --report run-parts option description. I'm dealing with this problem by printing out a newline character to stderr from the hook itself, therefore pushing run-parts to output the hook's name to stderr, thus causing run-parts to leave the debconf communication alone. This fix is as minimalist as you possibly could get for a bug fix in a stable release. CC: debian-kernel to get possible input from there While I can see the intent behind the above (forcing run-parts --report to output the script name to stderr rather than stdout), it wasn't immediately obvious. The kernel handbook (in https://kernel-handbook.alioth.debian.org/ch-update-hooks.html ), suggests exec /dev/null 2, which seems much more idiomatic. The kernel-handbook suggestion won't fix this issue because run-parts interprets debconf communication as hook output and decides that it has to print out the hook script name to the same place, thus interfering with debconf communication and causing the error described in bug reports #791868 and #741642. Milan signature.asc Description: OpenPGP digital signature
Bug#793556: jessie-pu: package mkvmlinuz/37+deb8u1
Package: release.debian.org Severity: normal Tags: jessie User: release.debian@packages.debian.org Usertags: pu mkvmlinuz/37+deb8u1 is fixing bug #741642 already fixed in sid/testing to allow for smooth upgrade from wheezy to jessie. See attached diff. changelog |6 ++ kernel-image/postinst |2 ++ kernel-image/postrm |2 ++ 3 files changed, 10 insertions(+) -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: powerpc (ppc64) Kernel: Linux 3.16.0-4-powerpc64 (SMP w/4 CPU core) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) diff -Nru mkvmlinuz-37/debian/changelog mkvmlinuz-37+deb8u1/debian/changelog --- mkvmlinuz-37/debian/changelog 2015-04-10 07:14:08.0 -0400 +++ mkvmlinuz-37+deb8u1/debian/changelog 2015-07-23 23:40:49.0 -0400 @@ -1,3 +1,9 @@ +mkvmlinuz (37+deb8u1) stable; urgency=medium + + * Push run-parts output to stderr. (Closes: #741642) + + -- Milan Kupcevic mi...@physics.harvard.edu Thu, 23 Jul 2015 23:00:46 -0400 + mkvmlinuz (37) unstable; urgency=medium * Include only necessary modules to further reduce vmlinuz size on Pegasos. diff -Nru mkvmlinuz-37/debian/kernel-image/postinst mkvmlinuz-37+deb8u1/debian/kernel-image/postinst --- mkvmlinuz-37/debian/kernel-image/postinst 2012-06-28 21:01:13.0 -0400 +++ mkvmlinuz-37+deb8u1/debian/kernel-image/postinst 2015-07-23 22:45:48.0 -0400 @@ -1,5 +1,7 @@ #!/bin/sh +echo 2 + set -e . /usr/share/debconf/confmodule diff -Nru mkvmlinuz-37/debian/kernel-image/postrm mkvmlinuz-37+deb8u1/debian/kernel-image/postrm --- mkvmlinuz-37/debian/kernel-image/postrm 2012-06-28 21:01:13.0 -0400 +++ mkvmlinuz-37+deb8u1/debian/kernel-image/postrm 2015-07-23 22:45:48.0 -0400 @@ -1,5 +1,7 @@ #!/bin/sh +echo 2 + set -e . /usr/share/debconf/confmodule
Bug#782352: unblock: mkvmlinuz/37
Control: tags -1 - moreinfo Hi, On 04/12/2015 04:19 PM, Ivo De Decker wrote: Control: tags -1 confirmed moreinfo Hi, On Fri, Apr 10, 2015 at 02:09:16PM -0400, Milan Kupcevic wrote: About to upload mkvmlinuz/37 fixing bug #782278 Pegasos II won't boot after kernel upgrade Please go ahead and remove the moreinfo tag from this bug once the upload is in unstable. The mkvmlinuz/37 has landed in sid. Milan signature.asc Description: OpenPGP digital signature
Bug#782352: unblock: mkvmlinuz/37 (pre-approval)
Control: retitle -1 Bug#782352: unblock: mkvmlinuz/37 (pre-approval) Should we go ahead with upload of mkvmlinuz/37? -- 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/55294357.2040...@physics.harvard.edu
Bug#606441: unblock: yaboot/1.3.13a-1squeeze1
On 12/10/2010 06:21 PM, Lennart Sorensen wrote: On Fri, Dec 10, 2010 at 11:42:49PM +0100, Mehdi Dogguy wrote: Well, Gaudenz and Milan worked on fixing the reported RC bugs against yaboot. And, I'd rather thank them for that. sid's version doesn't look like fixing the critical problems experienced by our users. Besides, I don't see any bugreport of yours explaining your issue. Having found the bug reported upstream, fixed in 1.3.14 years ago, and seeing how many people had made attemps at getting 1.3.14 into Debian, there seemed to be no point filling another bug report. So I didn't bother. I usually file bug reports, but yaboot seemed obviously futile. I am rather surprised to see there now is a new version in unstable. A few months too late to really help anyone wanting to run Squeeze though, but at least in a couple of years there will be a Debian version that might be useful for those machines. Well, the whole situation you are describing actually motivated me to do something about it. And I did what was possible to do in short period of time. Any bugreport I could read? Well given I don't even know if an IBM p520 power6+ machine is expected to work with Debian, I haven't filled one. I pointed out a few drivers and other issues I hit, although they seemed to get no interest from anyone. There is a bug report in grub2 (upstream) about the issues left to solve for the IBM pseries servers. You have hands on that machine, I do not. Fix the issue, produce patch, we are eager to see the solution. Also take a look at this thread, we discuss about IBM p520 power6+ machine: http://lists.debian.org/debian-powerpc/2010/12/msg00032.html grub2 does work once you manually generate the image and install it on a boot partition, and it supports software raid (something yaboot didn't, although it appears the 1.3.16 version now in unstable might), so it worked out OK for me. Please provide fully working and tested yaboot 1.3.16 Debian package and propose its upload, I'm sure it will override this one. Or even better, provide fully functional grub2 package for power platform. I'm sure it will get approved quickly. The grub developers helped fix some endianess bugs in the md raid 1.x format handling (as well as in mdadm, which has been fixed upstream now). To make life easier, grub needs working handling of devices without aliases (which IBM machines don't create, unlike apple and sun and most other openfirmware machines). I don't know if that has been completed yet, although some work was being done on it. I have created aliases myself for now which made grub happy. The bug report in grub is: http://savannah.gnu.org/bugs/?30576 If we do not get yaboot 1.3.13a-1squeeze1 and fixed yaboot-installer bug #605932 into squeeze, it will be uninstallable, without manual tweaking, on all machines with SATA, SAS, and SCSI controllers (this includes all Mac G5 machines). All Mac G5 machines also need fixed initramfs-tools bug #603981. I sent a question about the missing network driver and console entries in securetty to debian-boot and heard nothing: http://www.mail-archive.com/debian-b...@lists.debian.org/msg118643.html FYI: a bug report #605774 regarding ehea network driver was submitted on December 03, 2010 by Xavier Grave and was fixed in SVN promptly. It will get to squeeze install CD soon. And finally we should get back to the subject of this message. Do you advocate for or against getting yaboot/1.3.13a-1squeeze1 into squeeze? Why, or why not? Milan signature.asc Description: OpenPGP digital signature
