Bug#1051563: Backporting mutt patches to Debian Buster
Hi Chris, On Fri, Sep 15, 2023 at 8:09 PM Chris Frey wrote: > Attached is a patch that applies to the unpackaged sources of Debian Buster's > version of mutt 1.10. > > It includes 3 patches: > > upstream/Fix-rfc2047-base64-decoding-to-abort-on-illegal-char.patch > debian-specific/Check-for-NULL-userhdrs.patch > debian-specific/Fix-write_one_header-illegal-header-check.patch > > First one applied from Bullseye. The other two I modified slightly > to match the older sources. Many thanks, as usual. I'll look into it and let you know if we hit a bump backporting it. - u
Bug#1037178: puppet does not sync files anymore after recent ruby2.5 security upload
Hi Bernhard, Kees, On Wed, Jun 7, 2023 at 6:58 PM Schmidt, Bernhard wrote: > > I've prepared a fix for the regression and uploaded the binaries at: > > https://people.debian.org/~utkarsh/lts/ruby2.5/ > > > > Can you please give these a try and see if that fixes the regression > > you're seeing? > > Looking good! Many thanks for testing, too! I've actually managed to prepare a final update that I'm ready to upload - this has quite some fixes plus 2 new CVE fixes. Would you please test the new resulting binaries and make sure they look sane enough? :) The binaries can be found at https://people.debian.org/~utkarsh/lts/ruby2.5/. Many thanks! - u
Bug#1037178: puppet does not sync files anymore after recent ruby2.5 security upload
Hi Chris, On Wed, Jun 7, 2023 at 9:01 PM Chris Lamb wrote: > I see your 2.5.5-3+deb10u6 update on the debian/buster branch which > fixes the broken +deb10u5 upload, but I don't see it in the archive > yet. > > Although you mentioned you were going to wait a bit more, I'm just > 100%-checking you aren't waiting on anything from me to upload that? Oh yeah, I wanted to sneak in some fixes and enable the tests and fix the failing ones with the last upload. So I'll take care of the upload and the announcement unless you prefer doing that since you did the original upload? - u
Bug#1037178: puppet does not sync files anymore after recent ruby2.5 security upload
Hi Kees, On Wed, Jun 7, 2023 at 6:53 PM Kees Meijs | Nefos wrote: > I know you were asking Bernhard, but I downloaded and installed as well. > Our Puppet agent seems to be happy again. I had missed your comment in the bug but super, many thanks for testing this out! I'll wait a bit more before I roll this out. There's also CVE-2021-33621 and CVE-2022-28739 open for ruby2.5 in buster, I'll try to include the fixes in this update, too. - u
Bug#1037178: puppet does not sync files anymore after recent ruby2.5 security upload
Hi Bernhard, On Wed, Jun 7, 2023 at 4:16 PM Utkarsh Gupta wrote: > Yep, I'm taking a look to prep something for 2.5. I've prepared a fix for the regression and uploaded the binaries at: https://people.debian.org/~utkarsh/lts/ruby2.5/ Can you please give these a try and see if that fixes the regression you're seeing? - u
Bug#1037178: puppet does not sync files anymore after recent ruby2.5 security upload
Hiya, On Wed, Jun 7, 2023 at 2:39 PM Moritz Muehlenhoff wrote: > Specifically > https://www.ruby-lang.org/en/news/2023/03/28/redos-in-uri-cve-2023-28755/ > states: > > | For Ruby 2.7: Update to uri 0.10.0.1 > | For Ruby 3.0: Update to uri 0.10.2 > | For Ruby 3.1: Update to uri 0.11.1 > | For Ruby 3.2: Update to uri 0.12.1 > > And the 0.10 change > (https://github.com/ruby/uri/commit/17861a53e499a2eabf7ba83d63914d0f01921d70) > is different from the 0.12 one > (https://github.com/ruby/uri/commit/eaf89cc31619d49e67c64d0b58ea9dc38892d175) > > There might be other changes needed for 2.5, not sure. Yep, I'm taking a look to prep something for 2.5. - u
Bug#1037178: puppet does not sync files anymore after recent ruby2.5 security upload
Hi Chris, On Wed, Jun 7, 2023 at 12:56 PM Salvatore Bonaccorso wrote: > Can you please have a look, as this seems to be caused by the DLA > issued as DLA-3447-1. This has been caused by the ruby2.5 update. Can you please TAL? This is perhaps because of the URI version in buster v/s URI version upstream. The upstream patch was supposed to be for 3.2 and was not 2.5 compliant. Let me know if you'd like me to help. - u
Bug#1032998: imagemagick: font issue since 8:6.9.10.23+dfsg-2.1+deb10u2
Hi Bastien, Did you look at the following bug report? - u On Wed, Mar 15, 2023 at 8:09 PM Maxime Besson wrote: > > Package: imagemagick > Version: 8:6.9.10.23+dfsg-2.1+deb10u2 > Severity: normal > > Dear Maintainer, > > After updating to 8:6.9.10.23+dfsg-2.1+deb10u2, libgd-securityimage-perl > does not work anymore because of the CVE-2022-44267 and CVE-2022-44268 > mitigation: > > > > Removing this line from /etc/ImageMagick-6/policy.xml restores correct > hebavior. > > Here is a test script that tries to generate a Captcha > > use GD::SecurityImage use_magick => 1; > > my $image = GD::SecurityImage->new( > width=> 200, > height => 100, > lines=> 4, > gd_font => 'Giant', > scramble => 1, > rndmax => 10, > ); > $image->random; > $image->create( 'normal', 'default', "#403030", "#FF644B"); > print $image->out( force => 'png' ); > > The update breaks usage of fonts, and causes warnings to be printed, and > the image to be missing any text (which is bad for a Captcha) > , likely due to the fact that font configuration files for ImageMagick > are in /etc > > -- Package-specific info: > ImageMagick program version > --- > > -- System Information: > Debian Release: 10.13 > APT prefers oldstable-updates > APT policy: (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, > 'oldstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 6.0.0-0.deb11.6-amd64 (SMP w/6 CPU cores; PREEMPT) > Kernel taint flags: TAINT_WARN > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > LANGUAGE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > > -- Configuration Files: > /etc/ImageMagick-6/policy.xml changed [not included] > > -- no debconf information >
Bug#1032693: RM: puppet-beaker -- ROM; RC buggy, no rdeps, umaintained and blocks transitions
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: s...@debian.org Hello, The package was already orphaned (#1001000) back in December 2021 and it has been unmaintained since then. The package is not in testing either because of 2 RC bugs - #1025979 and #1026491. Since this is not being looked after and often blocks Ruby transitions in one way or the other, I'd like to request its removal from the archive. $ reverse-depends src:puppet-beaker No reverse dependencies found $ reverse-depends -b src:puppet-beaker No reverse dependencies found puppet-beaker suggests and recommends no packages either. Should you have any questions or concerns, please let me know. TIA.
Bug#1028468: bullseye-pu: package tomcat9/9.0.43-2~deb11u5
Package: release.debian.org User: release.debian@packages.debian.org Tags: bullseye Severity: normal Hello, src:tomcat9 has been affected by debbug #1020948 which was fixed in sid and thus would want to backport the fix to bullseye in the next point release. It was noticed that the tomcat-locate-java.sh script which seems to be in charge of identifying the Java version to use doesn't have version 17 listed. This is a trivial (and thus a low regression) fix. Debdiff is duly attached. Let me know if you any more information. TIA! \o/ - u tomcat9_bullseye.debdiff Description: Binary data
Bug#1024055: Upload MariaDB 1:10.3.37-0+deb10u1 ?
Hi Otto, On Mon, Dec 5, 2022 at 5:33 AM Otto Kekäläinen wrote: > I didn't get a reply to this, so asking again. I could take care of the upload but if you'd like to do that, please feel free to do so and I can take care of the paperwork. One quick thing I spotted in the target in d/ch is "buster". Could you please change that to "buster-security" instead? Let me know if you'd like to upload yourself or want me to take care of it. Thanks. - u
Bug#1022818: Update redmine to 5.0.3
Source: redmine Version: 5.0.2-2 Severity: wishlist Hello, Please consider updating src:redmine to 5.0.3. TIA. - u -- System Information: Debian Release: bullseye/sid APT prefers focal-updates APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-50-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1022817: Unnecessary recursive chown'ing?
Source: redmine Version: 5.0.2-2 Severity: normal Hello, The package update performs a recursive chown, unnecessarily increasing the update time (for instance, the recursive chown is unnecessarily applied to ~60 000 files in an instance). Please TAL and fix this if possible. Thanks! - u -- System Information: Debian Release: bullseye/sid APT prefers focal-updates APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-50-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1022816: chown'ing Gemfil makes UID approach incompatible
Source: redmine Version: 5.0.2-2 Severity: normal Hello, Activating cert-based authentication on PostgreSQL requires having redmine on its own UID. However the current Debian package tries to chown a Gemfile, making this UID approach incompatible with the current package. Please TAL and fix this if possible. Thanks! - u -- System Information: Debian Release: bullseye/sid APT prefers focal-updates APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-50-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1022815: REDMINE_INSTANCE_OWNERSHIP option not supported
Source: redmine Version: 5.0.2-2 Severity: normal Hello, Redmine installed from its Debian package should be able to run from its own (Linux) user. The REDMINE_INSTANCE_OWNERSHIP option in the default configuration file (/etc/default/redmine/) seems to indicate that such an execution mode is possible, but the current postinst scripts don’t support it yet. Please TAL and add support to this if possible. Thanks! - u -- System Information: Debian Release: bullseye/sid APT prefers focal-updates APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-50-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1020948: tomcat9 not referenceing openJDK 17
Package: tomcat9 Version: 9.0.67-1 Hi Emmanuel, Thanks for taking care of src:tomcat9. However, it was noticed that the tomcat-locate-java.sh script which seems to be in charge of identifying the Java version to use doesn't have version 17 listed; cf: https://salsa.debian.org/java-team/tomcat9/-/blob/master/debian/libexec/tomcat-locate-java.sh#L16. I believe we should add 17 to the list unless that was intentionally left behind for reasons I'm not aware of. What do you think? This is also affecting Bullseye. If you agree, I can prepare fixes for sid and stable. TIA! \o/ - u
Bug#1014813: reverse dependencies
Control: tags -1 - moreinfo Hi Thorsten, I've addressed the issue at hand and src:redmine/5.0.2-2 is in good shape now. Can you please process the removal of ruby-deckar01-task-list so that ruby-task-list and redmine can migrate to testing? TIA! \o/ - u
Bug#985314: asterisk spams console output to syslog due to systemd misconfiguration
Hello again, On Fri, Jan 21, 2022 at 1:02 AM Utkarsh Gupta wrote: > I don't think this was a problem in the patch that I attached to the > bug but somehow it got introduced when some applied that and uploaded, > maybe? I could be very wrong but I am trying to understand where did > things go wrong. Thanks, Sergio, for explaining me what'd I miss. Clearly my fault. Thanks for the fix! :) - u
Bug#985314: asterisk spams console output to syslog due to systemd misconfiguration
Hi Sergio, On Wed, Jan 19, 2022 at 10:26 PM Sergio Durigan Junior wrote: > "Editing patches by hand considered evil" :-). > > This upload introduced a problem: the asterisk.service file doesn't > contain the [Install] section anymore, which makes it be treated as a > static unit by systemd. This means that the service cannot be > enabled/disabled, so when a reboot happens the service doesn't > automatically start. > > This has been reported in > https://bugs.launchpad.net/ubuntu/+source/asterisk/+bug/1958259, btw. > > The problem happened because the file d/p/systemd.patch was likely > edited by hand, but the diff header was not updated to reflect the new > lines that have been added. Because of this, 'patch' silently drops the > last 6 lines of the diff when applying it. I don't think this was a problem in the patch that I attached to the bug but somehow it got introduced when some applied that and uploaded, maybe? I could be very wrong but I am trying to understand where did things go wrong. - u
Bug#1002837: tiledb: diff for NMU version 1.7.7-1.2
Hi Dirk, On Wed, Dec 29, 2021 at 10:59 PM Dirk Eddelbuettel wrote: > Thanks for the *very* prompt response. I may still wait a day or two to also > hear from Utkarsh who last NMUed. +1 to what Adam said. Please upload directly, thanks for asking. :D For the backstory, I was just a sponsor-er to Adam for src:tiledb and did an NMU for a source-only upload to help it migrate but it got blocked later. :/ - u
Bug#993618: RFS: openldap/2.4.59+dfsg-1~bpo11+1
Hi Ryan, On Fri, Sep 3, 2021 at 11:33 PM Ryan Tandy wrote: > As with previous releases, I am looking for a sponsor to perform the > initial upload of openldap to bullseye-backports since it will be NEW. I > am DM for the package and can take care of future uploads myself. Uploaded, will coordinate other things via IRC. Thank you! - u
Bug#991886: buster-pu: package libpam-tacplus/1.3.8-2+deb10u1
Package: release.debian.org User: release.debian@packages.debian.org Tags: buster Severity: normal Hello, src:libpam-tacplus has been affected by CVE-2020-13881 which is fixed in sid & stretch. Thus this -pu update for buster. This update also helps in fixing the versioning problem because as of now, the version in stretch is greater than that in stable. So this update will help fix things for buster. The debdiff is duly attached. Let me know if you any more information. TIA! \o/ - u libpam-tacplus_buster.debdiff Description: Binary data
Bug#991843: unblock: libjdom2-java/2.0.6-1.1
Hi Sebastian, On Tue, Aug 3, 2021 at 10:35 PM Sebastian Ramacher wrote: > Unstable and bullseye contain the same version of libjdom2-java. Are you > sure that the upload reached unstable? There was a bit of a fiasco and processing delay from dak (see my mail at -devel for more information) but the new version of libjdom2-java should now be available in sid. $ rmadison libjdom2-java libjdom2-java | 2.0.6-1 | oldoldstable| source, all libjdom2-java | 2.0.6-1 | oldstable | source, all libjdom2-java | 2.0.6-1 | stable | source, all libjdom2-java | 2.0.6-1.1 | unstable| source libjdom2-java | 2.0.6-2 | testing | source, all libjdom2-java | 2.0.6-2 | unstable| source, all libjdom2-java | 2.0.6-2.1 | buildd-unstable | source, all libjdom2-java | 2.0.6-2.1 | unstable| source, all Please let me know if you need any more information. Thank you! - u
Bug#991844: unblock: libpam-tacplus/1.3.8-2.1
Hi Paul, On Tue, Aug 3, 2021 at 9:46 PM Paul Gevers wrote: > On 03-08-2021 10:46, Utkarsh Gupta wrote: > > src:libpam-tacplus > > ... is not in testing. > > closing this bug as there's nothing to do (no, we're not going to let it > in now). Ugh, my bad for not checking that. Thanks and of course not letting it go to bullseye absolutely makes sense! Thank you and sorry for the noise! - u
Bug#991844: unblock: libpam-tacplus/1.3.8-2.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hey, src:libpam-tacplus has been affected by CVE-2020-13881 which is fixed in sid & stretch. -pu update for buster is also being filed. This update also helps in fixing the versioning problem because as of now, the version in stretch is greater than that in stable and sid. So this update will help fix things for sid and bullseye, at least. Since this is just a CVE fix, I'd request you to unblock this and let it go to bullseye, please? (I am sorry for doing this on the eleventh hour :/) The debdiff is duly attached. Let me know if you any more information. TIA! \o/ - u libpam-tacplus_sid.debdiff Description: Binary data
Bug#991843: unblock: libjdom2-java/2.0.6-1.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hey, src:libjdom2-java has been affected by CVE-2021-33813 which is fixed in sid & stretch. -pu update for buster is also being filed. Since this is just a CVE fix, I'd request you to unblock this and let it go to bullseye, please? (I am sorry for doing this on the eleventh hour :/) The debdiff is duly attached. Let me know if you any more information. TIA! \o/ - u libjdom2-java_sid.debdiff Description: Binary data
Bug#991842: unblock: libjdom1-java/1.1.3-2.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hey, src:libjdom1-java has been affected by CVE-2021-33813 which is fixed in sid & stretch. -pu update for buster is also being filed. Since this is just a CVE fix, I'd request you to unblock this and let it go to bullseye, please? (I am sorry for doing this on the eleventh hour :/) The debdiff is duly attached. Let me know if you any more information. TIA! \o/ - u libjdom1-java_sid.debdiff Description: Binary data
Bug#989037: Bug#988214: fixed in rails 2:6.0.3.7+dfsg-1
Hi Paul, [CC'ed team@s.d.o] On Sat, Jul 10, 2021 at 1:34 AM Paul Gevers wrote: > Unblocked the latest version in unstable. Awesome, thank you so much! Just as a heads up, I'll be also filing unblock requests for ruby2.7 (already uploaded) and libjdom1-java & libjdom2-java (yet to upload). All three are CVE fixes and hopefully should be trivial for the release team to evaluate. Let me know if you've any questions, thank you! - u
Bug#990752: Local configuration adds 2 dots on hostname, blocking package upgrades
Source: postfix Version: 3.5.6-1 Severity: important Hello, This bug was originally reported in Ubuntu here[1]. The reporter had a valid hostname, "saturn", but due to another bug (also reported in Ubuntu here[2]), the hostname is changed to "saturn.." (that is, 2 dots are added) and this causes the hostname to be invalid, thereby blocking package upgrades, et al. I was wondering if this is known or can we do something about this, please? Thank you! [1]: https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1934381 [2]: https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1929786 - u
Bug#989041: eterm: CVE-2021-33477
Hi Jose, On Thu, Jun 10, 2021 at 11:08 PM Jose Antonio Jimenez Madrid wrote: > Thank you so much Utkarsh for the patch, Of course, no problem! :) > Please, upload it to unstable, as I have to upload it by Debian Mentors > so it will reach testing faster if you upload it to fix this security bug. > Also, you can upload it to buster-pu, the package version is the same > than in Stretch, so it just to upload the same that you have already > upload for Stretch. Okay, uploaded to unstable; filed an unblock request via #989703. Subsequently, uploaded to buster and opened the -pu bug, #989702. Let me know if you have any questions or concerns. Thanks! \o/ - u
Bug#989703: unblock: eterm/0.9.6-6.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hey, src:eterm has been affected by CVE-2021-33477 which is fixed in sid & stretch. -pu update for buster has also been filed. Since this is just a CVE fix, I'd request you to unblock this and let it go to bullseye. :) The debdiff is duly attached. Let me know if you any more information. TIA! \o/ - u eterm_sid.debdiff Description: Binary data
Bug#989702: buster-pu: package eterm/0.9.6-5+deb10u1
Package: release.debian.org User: release.debian@packages.debian.org Tags: buster Severity: normal Hello, src:eterm has been affected by CVE-2021-33477 which is fixed in sid & stretch. Since the version in stretch & buster is the same, I'd like to get this update into -pu in the next release so as to avoid upgrade problems. The debdiff is duly attached. Let me know if you any more information. TIA! \o/ - u eterm_buster.debdiff Description: Binary data
Bug#989041: eterm: CVE-2021-33477
Hi Jose,
Patch attached. Please let me know if I can upload to unstable
directly? This also needs to go to buster-pu.
Let me know if you have questions or concerns.
- u
--- a/src/term.c
+++ b/src/term.c
@@ -1176,6 +1176,11 @@
case 'E':
scr_add_lines((unsigned char *) "\n\r", 1, 2);
break;
+/*
+ disabled because embedded newlines can make exploits easier
+ https://github.com/exg/rxvt-unicode/commit/2e7149935839bb7aa69b5bfe9558ba449e4db363
+ */
+#if 0
case 'G':
if ((ch = cmd_getc()) == 'Q') { /* query graphics */
tt_printf((unsigned char *) "\033G0\n");/* no graphics */
@@ -1185,6 +1190,7 @@
} while (ch != ':');
}
break;
+#endif
case 'H':
scr_set_tab(1);
break;
Bug#988214: fixed in rails 2:6.0.3.7+dfsg-1
Hi Paul, On Fri, Jun 4, 2021 at 1:38 AM Paul Gevers wrote: > > You haven't answered my question: "does rails still work with the old > > version of ruby-marcel and can the version bump be reverted" > > Ping. Without a proper answer, I can't decide. Thanks, I'm yet to figure that out and hopefully do this on weekend. If it were to work with the older ruby-marcel, can I then just push the newer rails to bullseye directly? Now that marcel's at v1.0 in unstable, I don't want to downgrade again. - u
Bug#905456: Please create new list debian-clojure
Hi Alex, On Mon, May 24, 2021 at 11:22 PM Alexander Wirt wrote: > > Ack, please send me the gpg encrypted list of subscribers and I will > > provide the new list asap. > jftr, I created the list, it is ready to use. I will import the > subscribers as soon as I receive them. Thanks a bunch! \o/ Attaching the subscribers' list with your and Elana's key. Let me know if you need anything else. - u members.enc Description: Binary data
Bug#988214: fixed in rails 2:6.0.3.7+dfsg-1
Hi Paul, On Wed, 19 May 2021 22:12:59 +0200 Paul Gevers wrote: > This new rails version renewed its versioned dependency on ruby-marcel. > The new ruby-marcel version doesn't look like a targeted fix, so it > doesn't fit the freeze policy. If I read the changelog correctly, this > dependency is there to give rails a more relaxed license. I think such a > change is not really needed at this stage of the freeze, does rails > still work with the old version of ruby-marcel and can the version bump > be reverted? Apologies, I missed (naturally because it wasn't copied) the conversation on this bug prior to opening an unblock request for both. Whilst I agree that ruby-marcel isn't really a targeted fix, I believe the bump was necessary to maintain sanity with future bug-fix releases of rails. I've been trying to maintain rails from sid (back to jessie), ensuring that the CVEs are at least timely fixed. During that course, I've hit a lot of bumps because of the version gaps, et al, so in this release I wanted rails to be at par with its supported bug-fix only release (that is, the 6.0.3.x branch). 6.0.3.6 brings in an unusual change by bumping ruby-marcel to 1.0.0. But after a lot of testing, sanity checking, et al, I found that the changes in marcel are a no-op, that is, it doesn't really affect how marcel was before and it is now. Marcel wanted to drop mimemagic dependency and so they introduced a Magic class (Marcel::Magic) for mime type detection. I know that it doesn't go along with the freeze policy atm, but I also believe that it's not really something that'd actually cause problems. IIUC, the bump doesn't really affect much but just does things differently internally. So is this edge case worth giving an exception along those lines? The bump shall yield nothing but (really) help in providing support to rails for the next couple of years in/for bullseye (at least while it's still supported). Let me know what you think? Thanks! - u
Bug#905456: Please create new list debian-clojure
Hi Alex, On Wed, 10 Mar 2021 14:23:10 -0800 Elana Hashman wrote: > On 2021-03-10 11:34, Alexander Wirt wrote: > > [...] > > Uh, oh. Yeah, please. > > There's been no objections since this email was last sent -- anyone on > the list who does not want to be migrated over to the new list, speak > now (privately emailing me) or forever hold your peace. It's been a while since this^^, do you think we can proceed with the list creation/migration? Or are there still any blockers? Let me know if I can help. Thanks!
Bug#989037: unblock: rails/2:6.0.3.7+dfsg-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: debian-r...@lists.debian.org
Hello,
Rails was recently affected by 3 CVEs (CVE-2021-2290{2,4} and CVE-2021-22885).
I'm attaching a filtered diff for your review; the diff is really
small and minimal which should be clear by looking at it. The only
caveat is that it needs ruby-marcel, which has an unblock request
(#989036) opened a few minutes ago.
rails has been in unstable for around 9 days now[1]; I've done some
testing and it all works OK w/ Bullseye, so it should be good to go.
[1]: https://tracker.debian.org/pkg/rails
The command used to filter the debdiff is as follows:
filterdiff --exclude='*/Gemfile.lock' --exclude='*/CHANGELOG.md'
--exclude='*/gem_version.rb' --exclude='*/package.json'
--exclude='*/test/*' ../rails.debdiff
Let me know if you need any other information from my end. Thanks!
- u
rails_filtered.debdiff
Description: Binary data
Bug#989036: unblock: ruby-marcel/1.0.1+dfsg-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: debian-r...@lists.debian.org Hello, We had to bump ruby-marcel to a newer version because the mimemagic dependency - which relies on GPL-licensed mime type data from freedesktop.org’s shared-mime-info project - is removed. Marcel now directly uses mime type data adapted from the Apache Tika project, distributed under the Apache License. This is the only major change here + some other bug fixes to get everything working. ruby-marcel has been in unstable for around 9 days now[1]; I've done some testing and it all works OK w/ Bullseye, so it should be good to go. [1]: https://tracker.debian.org/pkg/ruby-marcel Since this is licensing + bug fix, I believe it'd be a good idea to have this included in Bullseye; this is also needed for rails to be unblocked (another separate request). Attaching a filtered debdiff for your review. The command used to filter the debdiff is as follows: filterdiff --exclude='*/APACHE-LICENSE' --exclude='*/.*' --exclude='*/data/*' --exclude='*/script/*' --exclude='*/test/*' --exclude='*/Gemfile.lock' --exclude='*/README.md' ../ruby-marcel.debdiff Let me know if you need any other information from my end. Thanks! - u ruby-marcel_filtered.debdiff Description: Binary data
Bug#871958: dnsmasq: Service start hangs with postfix+resolvconf+systemd
Hello Simon, Just slightly pinging this to get your attention. There's a bug on Launchpad as well, which got an interesting comment from one of the user who debgugged this further: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1778073. Hoping that'd help. Thanks! - u
Bug#988289: htmldoc: CVE-2019-19630
Hi Håvard, On Wed, May 12, 2021 at 9:05 PM Håvard Flaget Aasen wrote: > Thanks for the sponsoring Utkarsh! You're very welcome! :) > I made a package for stretch as well, and uploaded it to mentors. [0] > Though I'm not sure about this lts stuff. So far this package I made > just targets "stretch". else it's quite identical to the package you > sponsored to buster. > > If you have your own package it might be better suited. Thanks, again. I have had a patch prepared, too. This will help me compare and verify that everything's indeed in order. Further, we have a slightly different workflow, we upload to -security (since no pu) and have to announce and publish an update for the website. I'll do them all, just letting you know. Thanks, again! - u
Bug#988289: htmldoc: CVE-2019-19630
Hi Håvard, On Wed, May 12, 2021 at 2:11 AM Håvard Flaget Aasen wrote: > I've got the release ready for buster and uploaded it to mentors [0]. I > also sent a request to the RM, for buster-pu, but haven't got any > response yet [1]. Thanks for the buster update; uploaded! \o/ You'll not receive any reply to -pu bug unless the release team has some problem with it. However, you'll receive a reply when someone from the release team will batch-accept the uploads from the proposed queue. So basically, we're all good and set! > I was lucky with the sponsoring to unstable, the package got uploaded > earlier today. I also got it unblocked, so it will migrate to bullseye. Awesome, thank you! - u
Bug#988289: htmldoc: CVE-2019-19630
Hi Håvard, On Tue, May 11, 2021 at 3:09 AM Håvard Flaget Aasen wrote: > I wasn't aware this versioning could be a problem. Yep, a big one sometimes :) > I can make a release to buster if you want. I would need a sponsor > though, so if your determined, I won't rip it out of your hands. That'd be helpful, thank you! Please let me know when you have a dsc ready? > Regardless who does it, can we fix CVE-2021-20308 [0] as well? It's > marked as unimportant but since we already is preparing packages... Absolutely, by all means! > I'v prepared a release to unstable and bullseye with the fix for > cve-2021-20308 it's on the mentors site now. Since this CVE is "unimportant", uploading to bullseye won't make sense. Rather we can upload to unstable and file an unblock request, that'd be a good way out here. That said, I couldn't find the dsc there, could you sense the link to dsc for unstable and I'll be very happy to sponsor the upload. Thanks! :) - u
Bug#988289: htmldoc: CVE-2019-19630
Hello, That's pretty unfortunate what happened. Since I fixed this in jessie (back when it was LTS), I'll take care of stretch (now that it's LTS) and subsequently buster as well. Thanks!
Bug#941199: Upstream has valid debian packaging
Hi Seunghun, > Thank you for the notification. I am still working on this and > would finish it soon. Let me know if you need some kind of help or something. I'll be happy to help and thanks for working on this! - u
Bug#987531: buster-pu: package opendmarc/1.3.2-6+deb10u2
Package: release.debian.org User: release.debian@packages.debian.org Usertags: pu User: debian-rele...@lists.debian.org Usertags: bsp-2021-04-at-salzburg X-Debbugs-Cc: t...@security.debian.org Tags: buster Severity: normal Hello, src:opendmarc has been affected by CVE-2020-12460, which is fixed in sid, bullseye, and stretch. Therefore, I'd like for it to be fixed in buster as well. And hence this pu update. The debdiff is duly attached. Let me know if you need any more information. TIA! - u opendmarc-buster.debdiff Description: Binary data
Bug#987501: unblock ruby-librarian/0.6.4-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock bsp-2021-04-AT-Salzburg Hello, This upload fixes #987113 and is actually a one-liner change: ``` - project_path = Pathname.new(__FILE__).expand_path + project_path = Pathname.pwd.expand_path ``` A more formal debdiff is attached. Requesting you to please unblock this. Should you need any more details, please let me know. TIA! - u ruby-librarian-sid.debdiff Description: Binary data
Bug#987494: buster-pu: package fluidsynth/1.1.11-1+deb10u1
Package: release.debian.org User: release.debian@packages.debian.org X-Debbugs-Cc: t...@security.debian.org, a...@debian.org Usertags: pu bsp-2021-04-AT-Salzburg Tags: buster Severity: normal Hello, src:fluidsynth has been affected by CVE-2021-28421 which is fixed in sid and unblocked for bullseye. Since this affects buster as well, I'm hereby opening a pu update bug for tracking. Thanks to Reiner Herrmann for preparing and testing the update. I've reviewed and it looks good; the debdiff is duly attached. Let me know if you need any more information. TIA! - u fluidsynth-buster.debdiff Description: Binary data
Bug#987489: buster-pu: package jackson-databind/2.9.8-3+deb10u3
Package: release.debian.org User: release.debian@packages.debian.org X-Debbugs-Cc: t...@security.debian.org, a...@debian.org Usertags: pu bsp-2021-04-AT-Salzburg Tags: buster Severity: normal Hello, src:jackson-databind has been affected by 18 CVEs which are fixed in unstable and bullseye (and also jessie). Therefore, I'd like them to be fixed in buster as well. And hence this pu update. The debdiff is duly attached. Let me know if you need any more information. TIA! - u jackson-databind-buster.debdiff Description: Binary data
Bug#987471:
user debian-rele...@lists.debian.org usertags -1 + bsp-2021-04-AT-Salzburg thank you
Bug#986806: CVE-2021-28965
Hi Praveen, On Fri, Apr 16, 2021 at 3:24 PM Pirate Praveen wrote: > I think the separate package was introduced by mistake without seeing > the copy embedded in ruby. I think the right way is to fix this in ruby > and remove this separate package. But I'd like someone from ruby team > to confirm this. Makes sense. Probably the time to RM ruby-rexml from the archive is *now*? As for fixing this in src:ruby2.7, see #986742. TL;DR: ruby2.7 2.7.3-1 was uploaded to fix this earlier today. - u
Bug#986742: unblock: ruby2.7/2.7.3-1
Hi Sebastian, On Sat, Apr 17, 2021 at 3:08 PM Sebastian Ramacher wrote: > Thanks, please go ahead and remove the moreinfo tag once the version is > available in unstable. Uploaded to unstable, thanks. And removed the tag as well. - u
Bug#986622: [Pkg-clamav-devel] Bug#986622: fixes
Hello, On Wed, Apr 14, 2021 at 12:32 AM Sebastian Andrzej Siewior wrote: > Usually yes, I let it slide (unfortunatelly) and was checking best > options moving forward. After all I need reasons to present to the > release team. I just noticed that the only CVE that affects buster is CVE-2021-1405. The other two affects only 0.103.0 and 0.103.1 and the patch for CVE-2021-1405 could be easily backported to buster. Maybe we could instead do that now? And later when there's a need, we can backport the entire new version? What do you think? - u
Bug#986622: [Pkg-clamav-devel] Bug#986622: fixes
Hi Sebastian, Sebastian Andrzej Siewior wrote: > My plan is to get 103.2 into Buster after I spent the day today > to look what should be backported and what not. Do we not generally backport clamav as-is to buster (of course, after thoroughly checking) so as to get the latest release there? I ask/confirm because I'd like to further backport this to stretch/jessie for LTS/ELTS as well. We generally wait for buster to be updated and then we backport to stretch and then jessie. Also, once you get the update prepared for buster and plan to release, could you also let me know so I get a heads up and thus plan accordingly for stretch and jessie? Thanks. - u
Bug#986146: unblock: rabbitmq-server/3.8.9-2
Hello, Awesome, thanks for this upload, Thomas. I can confirm that this is a pure bug-fix release only and indeed fixes the problems raised, thereby making this package even better for bullseye. A huge +1 for unblocking. - u
Bug#984615: xterm: bug in CVE-2021-27135 patch in at least stretch
Awesome, thank you for the confirmation. I've rolled out the announcement and published the website update. Thanks, everyone! \o/ - u
Bug#985421: Adding DEP8 tests for at package
Source: at Version: 3.1.23-1.1 Severity: normal Tags: patch Hello, Since at is missing DEP8 tests, I'd like to add them. I wanted to propose an MR on salsa but the git history isn't in sync with what's uploaded to the archive, so asking here. I've prepared the basic testing script to ensure that there's no regression. I initially submitted this in Ubuntu but want to get it merged and uploaded here. Attaching the debdiff here for your review. Let me know what you think about this. Can I proceed with the upload? - u at-dep8.debdiff Description: Binary data
Bug#985314: asterisk spams console output to syslog due to systemd misconfiguration
Source: asterisk Version: 1:16.16.1~dfsg-1 Severity: normal Tags: patch X-Debbugs-Cc: 1909...@bugs.launchpad.net Hi Bernhard, Thanks for taking care of asterisk. This bug report is just a mere forward of what was originally reported in Ubuntu; cf: https://bugs.launchpad.net/ubuntu/+source/asterisk/+bug/1909816. So I'll rather not copy-paste its content here, instead just copy my findings: The service file seems to be coming from "contrib/systemd/asterisk.service" file, which is a part of the upstream source. Interestingly, there's also a Debian patch named "debian/patches/systemd.patch" which adds a new file, "contrib/asterisk.service", which is where the default service file is created from. Therefore, would you be interested to fix this in Debian? The proposed patch is hereby attached. Let me know what you think? Thanks again for your work! - u Description: Set default config to avoid console output to syslog. Author: Utkarsh Gupta Bug: https://bugs.launchpad.net/ubuntu/+source/asterisk/+bug/1909816 Last-Update: 2021-03-16 --- a/debian/patches/systemd.patch +++ b/debian/patches/systemd.patch @@ -96,6 +96,12 @@ +RestartSec=1 +WorkingDirectory=__ASTERISK_VARLIB_DIR__ + ++# The following two lines are by default set to null so as to avoid ++# unnecessary console output to syslog. However, if you to, you can ++# further edit /etc/asterisk/logger.conf to log output to syslog. ++StandardOutput=null ++StandardError=null ++ +# Extra settings: +# If you want to set them, you can add them to a file in the directory +# /lib/systemd/system/asterisk.service.d/ with the extension .conf.
Bug#984689: ruby-vcr: DFSG violation (Hippocratic license)
On Sun, Mar 7, 2021 at 10:49 PM Utkarsh Gupta wrote: > On Sun, Mar 7, 2021 at 10:15 PM Pirate Praveen > wrote: > > It looks like we will have to remove ruby-vcr and we will have to > > disable tests for the following packages. I don't think there is > > another way, thoughts? > > Maybe worth opening an issue upstream and discuss the cons of this > change or something? Or if that doesn't work out and we need this > package or something, would forking be an option? It looks like they just upgraded to the latest version of the license they were previously using; cf: https://github.com/vcr/vcr/pull/813. I didn't read the license but is it realy a problem? If it is, I know Olle (the upstream dev), maybe we can talk this out and they can revert to the previous version of the license. - u
Bug#984689: ruby-vcr: DFSG violation (Hippocratic license)
Hi Praveen, On Sun, Mar 7, 2021 at 10:15 PM Pirate Praveen wrote: > It looks like we will have to remove ruby-vcr and we will have to > disable tests for the following packages. I don't think there is > another way, thoughts? Maybe worth opening an issue upstream and discuss the cons of this change or something? Or if that doesn't work out and we need this package or something, would forking be an option? - u
Bug#984615: xterm: bug in CVE-2021-27135 patch in at least stretch
Hi Thorsten
On Sat, Mar 6, 2021 at 2:25 AM Thorsten Glaser wrote:
> debian/patches/CVE-2021-27135.patch changes button.c line (after
> patching) 3747 to:
>
>line = realloc(line, screen->selection_size);
>
> But “line” is a local variable, the address of the buffer must
> be stored in the one handed out, too, so please change this to:
>
> if ((have * 2) < (size_t) j) {
> Char *next = realloc(line, have + 1);
> if (next) {
> screen->selection_data = line = next;
> screen->selection_size = have + 1;
> }
> }
>
> This also deals properly with realloc failures (since we’re
> shrinking, ignore them and just keep the older, larger area).
Thanks for the very comprehensive bug report and for the patch as well!
> I’ve not looked at jessie-ELTS or buster-security whether they
> are affected as well; sid is clean (and where I got the realloc
> failure check necessity from, although sid’s free()s the buffer
> if realloc fails; this isn’t needed @Tom).
If this seems to be happening in stretch, I assume there's a problem
with jessie-ELTS as well. That said, buster is good because a DSA
wasn't issued and this will be fixed via a point release. I am glad
and surprised that sid is okay and there doesn't seem to be a problem.
Just to cross-check and ensure I get it right (for stretch and
jessie), can you send me the reproducer as well? I'd like to be able
to reproduce this before and after your patch (just to be one the
safer side) and do the same for jessie as well!
Thanks, again, for such a detailed bug report! :D
- u
Bug#983113: buster-pu: package ruby-mechanize/2.7.6-1+deb10u1
Package: release.debian.org
User: release.debian@packages.debian.org
X-Debbugs-Cc: debian-r...@lists.debian.org
Usertags: pu
Tags: buster
Severity: normal
Hello,
ruby-mechanize was affected by CVE-2021-21289, where the package was
vulnerable to command injection vulnerability.
This has been fixed in sid, bullseye, and stretch.
Here's the debdiff for buster-pu:
8<--8<--8<--8<--8<--8<--8<--8<--8<--8<
diff -Nru ruby-mechanize-2.7.6/debian/changelog
ruby-mechanize-2.7.6/debian/changelog
--- ruby-mechanize-2.7.6/debian/changelog2019-01-04 16:57:45.0 +0530
+++ ruby-mechanize-2.7.6/debian/changelog2021-02-19 22:47:27.0 +0530
@@ -1,3 +1,10 @@
+ruby-mechanize (2.7.6-1+deb10u1) buster; urgency=medium
+
+ * Team upload for buster-pu.
+ * Add patch to prevent OS command injection. (Fixes: CVE-2021-21289)
+
+ -- Utkarsh Gupta Fri, 19 Feb 2021 22:47:27 +0530
+
ruby-mechanize (2.7.6-1) unstable; urgency=medium
* Team upload
diff -Nru ruby-mechanize-2.7.6/debian/patches/CVE-2021-21289.patch
ruby-mechanize-2.7.6/debian/patches/CVE-2021-21289.patch
--- ruby-mechanize-2.7.6/debian/patches/CVE-2021-21289.patch
1970-01-01 05:30:00.0 +0530
+++ ruby-mechanize-2.7.6/debian/patches/CVE-2021-21289.patch
2021-02-19 22:46:52.0 +0530
@@ -0,0 +1,260 @@
+From aae0b13514a1a0caf93b1cf233733c50e679069a Mon Sep 17 00:00:00 2001
+From: Katsuhiko YOSHIDA
+Date: Sat, 20 Jul 2019 11:03:40 +0900
+Subject: [PATCH 1/7] fix(security): prevent command injection in CookieJar
+
+Related to
https://github.com/sparklemotion/mechanize/security/advisories/GHSA-qrqm-fpv6-6r8g
+---
+ lib/mechanize/cookie_jar.rb | 4 ++--
+ test/test_mechanize_cookie_jar.rb | 30 ++
+ 2 files changed, 32 insertions(+), 2 deletions(-)
+
+--- a/lib/mechanize/cookie_jar.rb
b/lib/mechanize/cookie_jar.rb
+@@ -65,7 +65,7 @@
+ class CookieJar < ::HTTP::CookieJar
+ def save(output, *options)
+ output.respond_to?(:write) or
+-return open(output, 'w') { |io| save(io, *options) }
++return ::File.open(output, 'w') { |io| save(io, *options) }
+
+ opthash = {
+ :format => :yaml,
+@@ -119,7 +119,7 @@
+
+ def load(input, *options)
+ input.respond_to?(:write) or
+-return open(input, 'r') { |io| load(io, *options) }
++return ::File.open(input, 'r') { |io| load(io, *options) }
+
+ opthash = {
+ :format => :yaml,
+--- a/test/test_mechanize_cookie_jar.rb
b/test/test_mechanize_cookie_jar.rb
+@@ -1,4 +1,5 @@
+ require 'mechanize/test_case'
++require 'fileutils'
+
+ class TestMechanizeCookieJar < Mechanize::TestCase
+
+@@ -500,6 +501,35 @@
+ assert_equal(0, @jar.cookies(url).length)
+ end
+
++ def test_prevent_command_injection_when_saving
++url = URI 'http://rubygems.org/'
++path = '| ruby -rfileutils -e \'FileUtils.touch("vul.txt")\''
++
++@jar.add(url, Mechanize::Cookie.new(cookie_values))
++
++in_tmpdir do
++ @jar.save_as(path, :cookiestxt)
++ assert_equal(false, File.exist?('vul.txt'))
++end
++ end
++
++ def test_prevent_command_injection_when_loading
++url = URI 'http://rubygems.org/'
++path = '| ruby -rfileutils -e \'FileUtils.touch("vul.txt")\''
++
++@jar.add(url, Mechanize::Cookie.new(cookie_values))
++
++in_tmpdir do
++ @jar.save_as("cookies.txt", :cookiestxt)
++ @jar.clear!
++
++ assert_raises Errno::ENOENT do
++@jar.load(path, :cookiestxt)
++ end
++ assert_equal(false, File.exist?('vul.txt'))
++end
++ end
++
+ def test_save_and_read_expired_cookies
+ url = URI 'http://rubyforge.org/'
+
+--- a/lib/mechanize.rb
b/lib/mechanize.rb
+@@ -396,7 +396,7 @@
+ io = if io_or_filename.respond_to? :write then
+io_or_filename
+ else
+- open io_or_filename, 'wb'
++ ::File.open(io_or_filename, 'wb')
+ end
+
+ case page
+--- a/test/test_mechanize.rb
b/test/test_mechanize.rb
+@@ -345,6 +345,14 @@
+ end
+ end
+
++ def test_download_does_not_allow_command_injection
++in_tmpdir do
++ @mech.download('http://example', '| ruby -rfileutils -e
\'FileUtils.touch("vul.txt")\'')
++
++ refute_operator(File, :exist?, "vul.txt")
++end
++ end
++
+ def test_get
+ uri = URI 'http://localhost'
+
+--- a/lib/mechanize/download.rb
b/lib/mechanize/download.rb
+@@ -71,7 +71,7 @@
+ dirname = File.dirname filename
+ FileUtils.mkdir_p dirname
+
+-open filename, 'wb' do |io|
++::File.open(filename, 'wb')do |io|
+ until @body_io.eof? do
+ io.write @body_io.read 16384
+ end
+--- a/test/test_mechanize_download.rb
b/test/test_mechanize_download.rb
+@@ -46,6 +46,18 @@
+ end
+ end
+
++ def test_save_bang_does_not_allow_command_injection
++uri = URI.parse 'http://example/
Bug#982435: [screen-devel] [bug #60030] Screen segfaults by displaying some UTF-8 character combination
Hi Axel, Salvatore, On Fri, Feb 19, 2021 at 2:44 PM Axel Beckert wrote: > No issue popped up so far during production use on Stretch and Buster. > I'd say, we can publish these in good conscience. Perfect, thanks for all your work on this! \o/ I've uploaded to stretch-security (& pushed the commit and tag as well). Salvatore, do you want me to push to buster-security as well? - u
Bug#982435: [screen-devel] [bug #60030] Screen segfaults by displaying some UTF-8 character combination
Hi Axel, Sorry for the late reply, I was a bit occupied with my school homework. On Wed, Feb 17, 2021 at 8:59 AM Axel Beckert wrote: > > So I created one with the latest dsc (4.2.1-3+deb8u1) and added 2 > > commits on top of it. > > Thanks for the effort, but this seems to have a separate git root > (why?!?) instead of being simply based on the tag debian/4.2.1-3 which > points to commit 80eaffbae4363a79987e0e9fc07d1df96e0abd83. It's a different root because I took the latest .dsc and created a branch from there. More on this below. > I fixed it by cherry-picking and applying your relevant commits — with > proper commit messages _NOT_ including the whole (!) debian/changelog > in the commit message but just the relevant entry — on top of the old > jessie branch and force pushed it. > > (And unless "gbp dch" is used, I prefer to keep debian/changelog in > sync with the packaging changes and not adding debian/changelog > entries in a separate commit. But I didn't merge those two commits of > yours as I wasn't sure about the reasons for that and it's a > style/workflow thing and might subject to taste.) Indeed, like many others, I like to keep changelog entries separate. And the reasoning behind this is it actually helps when I have to backport stuff, so merging branches becomes easier with the only conflict in the d/ch file and I can just fix it because it's all tied together in a single commit. But that said, of course, everybody has a different way and I respect that, so thanks for fixing it! :) > > By importing the dsc and creating a branch out of it, the commit history, > > I am afraid, is lost. > > I don't see why this is necessary nor how this could have happened at > all. The task would have been so simple.. Actually, it was intentional and my follow-up question (about you wanting to restore all that) was to know if you actually want all the history back or not. But you already did restore, so all good, thanks! > > Do you want to restore all that? > > I already fixed it (except for tags, but you didn't seem to have > pushed the one expected tag anyways), because I was annoyed even > before I read that far in your mail. Yes, I didn't push the tag because I never uploaded it to jessie. I just prepared the upload and shall only tag the commit once I *actually* upload. I am sure you'd *not* want (me) to tag releases w/o actually uploading? :) > https://salsa.debian.org/debian/screen/-/commits/jessie/ now has a > proper history again. Ack, thanks. But...(more below). > > I'll be happy to do that after checking out from master and then > > applying +deb8u1 changes and then pushing mine on top of it, but I > > don't see any value to it, really. > > Huh, "no value"?!? Sorry, but a proper versioning is _essential_. Maybe I wasn't clear because there seems to be a misunderstanding here. When I said "no value", I meant not for the versioning part but "no value" in restoring all the history for the jessie branch. Because you see, next time somebody does the upload for jessie (or for stretch some years later) might not really care about pushing to salsa. Exactly what happened for deb8u1 upload. The general workflow is to get the latest dsc from the pool, do changes on top of that, and upload. And repeat. And this is because we don't expect all maintainers to actually keep a jessie branch alive and stuff. And some maintainers really, really don't like to be contacted for such trivial things. So we don't really disturb them from our end unless needed. Hopefully, I gave you the bigger picture and the real reasoning behind my "no value" phrase. Please let me know if it's still not clear or anything. I'll be happy to expand more! > Regards, Axel (not amused) ... :( - u
Bug#982435: [screen-devel] [bug #60030] Screen segfaults by displaying some UTF-8 character combination
Hi Axel, On Tue, Feb 16, 2021 at 11:12 PM Axel Beckert wrote: > I'm running these patches (as in git) now for about 1.5 days on > Stretch and Buster in production. I'd say if I don't find any > regression until Wednesday evening (i.e. in 1 day), feel free to > finalise the packages as needed (the're currently all sporting > "UNRELEASED" in the debian/changelog) and release them. > > Please push your changes and tags into the git repo. It's in > collab-maint^Wthe "debian" group, so you should have write access. Sure thing, once you give a go-ahead, I'll edit the changelog entry and shall push that to the salsa repository. > If you want to prepare a Jessie ELTS update, feel free to use the > existing jessie branch in git. (It has no commit besides those being > part of the master branch. Not sure why I or someone else has created > it already.) There's no "jessie" branch on salsa, at least. So I created one with the latest dsc (4.2.1-3+deb8u1) and added 2 commits on top of it. By importing the dsc and creating a branch out of it, the commit history, I am afraid, is lost. Do you want to restore all that? I'll be happy to do that after checking out from master and then applying +deb8u1 changes and then pushing mine on top of it, but I don't see any value to it, really. But with your maintainer hat on, if you want me to do that, I'll do so! :) The jessie branch atm looks like this: https://salsa.debian.org/debian/screen/-/tree/jessie Please let me know if you have any questions or suggestions or if you hoped to see something else than this? :) - u
Bug#982435: [screen-devel] [bug #60030] Screen segfaults by displaying some UTF-8 character combination
Hi Axel, On Mon, Feb 15, 2021 at 12:13 PM Axel Beckert wrote: > Please slow down! > > What so far was in git in the stretch and buster branches was > incomplete and did FTBFS for multiple reasons. (Just pushed a bunch of > fixes. It at least builds now on both releases.) > > And in Stretch the patch didn't even apply properly and needed manual > massaging. So at least for Stretch (and Jessie) this needs additional > testing. Oh sure! I'll hold off any work until uploads in other releases have been settled down. - u
Bug#982435: [screen-devel] [bug #60030] Screen segfaults by displaying some UTF-8 character combination
Hi, On Sun, Feb 14, 2021 at 9:03 PM Axel Beckert wrote: > > Since it's been ~3 days, do you think now would be the time to prepare > > and upload to buster and stretch? > > While I prepared the uploads in git, I haven't yet tested them on > Stretch and Buster. Currently still running the patch from 4.8.0-4, > mostly due to time contraints and an RC bug in aptitude. > > If you want some more coverage, I'd wait until Monday evening or > Tuesday. I hope to get the equivalent of the 4.8.0-5 patch installed > on Stretch and Buster later this evening. That sounds good! Meanwhile, I'll compare the debdiff (for stretch) and try to prepare something similar for jessie as well! - u
Bug#982435: [screen-devel] [bug #60030] Screen segfaults by displaying some UTF-8 character combination
Hi Axel, On Fri, Feb 12, 2021 at 11:07 AM Salvatore Bonaccorso wrote: > Thanks for all your coordinaton, investigation, work on this! Seconded! Thanks for all your awesome and super fast work, really! \o/ > Sounds good. I propose to have the potential final patch as well first > slightly exposed first in unstable for a couple of days (2-3)? to see > if anybody reports any further problems and only then release an > update in buster, stretch. The potential final patch was uploaded to unstable on 2021-02-11, I believe? Did you hear any problems with that? Any bug reports (none that I can see though!)? Since it's been ~3 days, do you think now would be the time to prepare and upload to buster and stretch? - u
Bug#982548: wpasupplicant: Missing support for WPA-EAP-SUITE-B(-192)
Hi Thorsten, On Fri, Feb 12, 2021 at 2:03 PM Andrej Shadura wrote: > > It was observed that Debian's wpa_supplicant is not able to connect to > > connect to networks with key_mgmt WPA-EAP-SUITE-B and/or > > WPA-EAP-SUITE-B-192 (aka WPA3-Enterprise 192-bit mode). The upstream > > wpa_supplicant supports this since 2.4. Following is seen when trying > > to load a config with this kind of configuration: > > I’m afraid 2:2.4-1 is part of Debian Stretch, which is no longer supported. > You can, however, install a newer version from stretch-backports, but I’d > rather recommend you to upgrade to Buster; please be aware that Bullseye > is likely going to be released later this year. > > Alternatively, the Debian LTS project might consider enabling this even > though it’s not technically in their scope, as this is not a security issue > (cc'ed the LTS mailing list), but I’m personally not interested in supporting > such an old version. Whilst working on the security update for stretch, do you think you can accommodate this request for a bug fix as well? - u
Bug#982435: screen: CVE-2021-26937
Hello, On Wed, Feb 10, 2021 at 6:56 PM Utkarsh Gupta wrote: > I'll take care of fixing stretch and jessie and I am aware of all this > since I was the one who got this CVE assigned! :D Somewhat related, I also got CVE-2021-27135 assigned for xterm. I'll take care of the updates when the patch is available. But interestingly, while reproducing the issue in screen, you can also easily reproduce this issue in xterm. See[1]. [1]: https://www.openwall.com/lists/oss-security/2021/02/09/7 - u
Bug#982435: screen: CVE-2021-26937
On Wed, Feb 10, 2021 at 6:56 PM Utkarsh Gupta wrote: > I'll take care of fixing stretch and jessie and I am aware of all this > since I was the one who got this CVE assigned! :D Oh, I forgot to mention, I say this with my LTS and ELTS hat on!^ But in case if you want to work on the package yourself, that's very welcome too! :) Either way, thanks for CCing and keeping everybody in the loop this way! - u
Bug#982435: screen: CVE-2021-26937
Hi Axel, On Wed, Feb 10, 2021 at 5:17 PM Axel Beckert wrote: > Thanks for the heads up! Hadn't notice that upstream bug report > yesterday, but I do have it in my inbox. > > https://savannah.gnu.org/bugs/?60030 got locked down in the meanwhile > as it seems. > > Can you keep me in the loop wrt. to patches, e.g. by GPG-encrypted > mail? Me, too, please (though I'll keep an eye on it myself)! :) I'll take care of fixing stretch and jessie and I am aware of all this since I was the one who got this CVE assigned! :D - u
Bug#962596: Backport to stretch?
Hello, On Tue, Feb 2, 2021 at 5:09 PM Utkarsh Gupta wrote: > On Mon, Feb 1, 2021 at 9:48 PM Julien Cristau wrote: > > stretch is EOL, so I am not planning on touching it myself. > > Cc:ing the team that looks after stretch-lts in case they want to handle > > this. > > Thanks, I'll start to take a look at it. > IIUC, this commit[1] needs a backport to stretch, correct? > > [1]: > https://salsa.debian.org/debian/ca-certificates/-/commit/62a6fc666ddc27baa0150e2b210814ecf1fc587e Just a slight ping on this since I haven't really heard back. I'll be happy to backport this and prepare an update for stretch once somebody gives me an ack on the above mail. - u
Bug#962596: Backport to stretch?
Hi, On Mon, Feb 1, 2021 at 9:48 PM Julien Cristau wrote: > stretch is EOL, so I am not planning on touching it myself. > Cc:ing the team that looks after stretch-lts in case they want to handle > this. Thanks, I'll start to take a look at it. IIUC, this commit[1] needs a backport to stretch, correct? [1]: https://salsa.debian.org/debian/ca-certificates/-/commit/62a6fc666ddc27baa0150e2b210814ecf1fc587e - u
Bug#981271: buster-pu: package python-bottle/0.12.15-2+deb10u1
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: buster
Severity: normal
Hello,
python-bottle was affected by CVE-2020-28473, where the package was
vulnerable to Web Cache Poisoning by using a vector called parameter
cloaking.
This has been fixed in Sid, Bullseye, and Stretch (& Jessie).
Here's the debdiff for buster-pu:
8<--8<--8<--8<--8<--8<--8<--8<--8<--8<
diff -Nru python-bottle-0.12.15/debian/changelog
python-bottle-0.12.15/debian/changelog
--- python-bottle-0.12.15/debian/changelog2019-03-27
05:13:08.0 +0530
+++ python-bottle-0.12.15/debian/changelog2021-01-28
20:22:22.0 +0530
@@ -1,3 +1,10 @@
+python-bottle (0.12.15-2+deb10u1) buster; urgency=high
+
+ * Non-maintainer upload by the Security team.
+ * Do not split query strings on `;` anymore. (Fixes: CVE-2020-28473)
+
+ -- Utkarsh Gupta Thu, 28 Jan 2021 20:22:22 +0530
+
python-bottle (0.12.15-2) unstable; urgency=medium
* Update tox dependency (Closes: #924836)
diff -Nru python-bottle-0.12.15/debian/patches/CVE-2020-28473.patch
python-bottle-0.12.15/debian/patches/CVE-2020-28473.patch
--- python-bottle-0.12.15/debian/patches/CVE-2020-28473.patch
1970-01-01 05:30:00.0 +0530
+++ python-bottle-0.12.15/debian/patches/CVE-2020-28473.patch
2021-01-28 20:21:24.0 +0530
@@ -0,0 +1,25 @@
+From 57a2f22e0c1d2b328c4f54bf75741d74f47f1a6b Mon Sep 17 00:00:00 2001
+From: Marcel Hellkamp
+Date: Wed, 11 Nov 2020 19:24:29 +0100
+Subject: [PATCH] Do not split query strings on `;` anymore.
+
+Using `;` as a separator instead of `&` was allowed a long time ago,
+but is now obsolete and actually invalid according to the 2014 W3C
+recommendations. Even if this change is technically backwards-incompatible,
+no real-world application should depend on broken behavior. If you REALLY
+need this functionality, monkey-patch the _parse_qsl() function.
+---
+ bottle.py | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/bottle.py
b/bottle.py
+@@ -2577,7 +2577,7 @@
+
+ def _parse_qsl(qs):
+ r = []
+-for pair in qs.replace(';','&').split('&'):
++for pair in qs.split('&'):
+ if not pair: continue
+ nv = pair.split('=', 1)
+ if len(nv) != 2: nv.append('')
diff -Nru python-bottle-0.12.15/debian/patches/series
python-bottle-0.12.15/debian/patches/series
--- python-bottle-0.12.15/debian/patches/series2019-03-27
05:13:08.0 +0530
+++ python-bottle-0.12.15/debian/patches/series2021-01-28
20:21:33.0 +0530
@@ -1,2 +1,3 @@
0001-Remove-bottle.py-from-scripts.patch
0002-Add-CLI-manpage.patch
+CVE-2020-28473.patch
8<--8<--8<--8<--8<--8<--8<--8<--8<--8<
- u
---
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.6.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=>
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#980585: ruby-in-parallel: FTBFS: ERROR: Test "ruby2.7" failed: Failure/Error: expect(@result_3).to_not eq(true)
On Thu, Jan 21, 2021 at 12:50 PM Sébastien Delafond wrote: > I'm not expecting upstream to fix it either, but it'd feel more > comfortable to close this bug on our side while still linking to an > existing upstream issue. Of course. Here it is: https://github.com/samwoods1/in-parallel/issues/8 Feel free to add more if I missed something. > Ideally we'd only skip this test in 2.x, while keeping it in 3.0 to see > if same race eventually pops up on debci. Yeah, but I'd rather keep it disabled now and then re-work it when working on the interpreter transition. That said, I am preparing an upload for this as we speak! :) Best, Utkarsh
Bug#980585: ruby-in-parallel: FTBFS: ERROR: Test "ruby2.7" failed: Failure/Error: expect(@result_3).to_not eq(true)
Hi Sébastien, On Thu, Jan 21, 2021 at 12:42 PM Sébastien Delafond wrote: > > Aah, okay. So I ran sbuild + autopkgtest 10 times, all passed for me. > > But when I ran these tests locally with rake, it failed for me exactly > > like the report just for the first time. And then passed all 9 times > > afterward. > > I haven't been able to reproduce it here: local rake, autopkgtest+lxc, > autopkgtest+qemu. Aah. > > Then I tried to trace back the origin of this problem but couldn't > > find anything. I am not sure what's causing this (I haven't gone > > through the source thoroughly) but I am inclined towards skipping this > > test if that's OK with you? > > It definitely looks like a race, so I agree we can skip it if we create > an upstream bug documenting the issue. I can create an issue in the original fork. However, just know that this library is *not* being maintained at all. So there won't be much help from anywhere. Either way, I'd also like to mention that we did a build for ruby-in-parallel against ruby3.0 and everything seems to work, including those tests as well. See logs here: https://people.debian.org/~kanashiro/ruby3.0/builds/3/ruby-in-parallel/ruby-in-parallel_0.1.17-1.1+rebuild1610557786_amd64-2021-01-13T17:09:48Z.build Best, Utkarsh
Bug#980585: ruby-in-parallel: FTBFS: ERROR: Test "ruby2.7" failed: Failure/Error: expect(@result_3).to_not eq(true)
Hi Sébastien, On Thu, Jan 21, 2021 at 11:51 AM Utkarsh Gupta wrote: > I've started to look into it already but I wasn't able to reproduce > it. All tests pass for me + autopkgtest (which is what I fixed last > time). So I am not sure what's going wrong here. Aah, okay. So I ran sbuild + autopkgtest 10 times, all passed for me. But when I ran these tests locally with rake, it failed for me exactly like the report just for the first time. And then passed all 9 times afterward. Then I tried to trace back the origin of this problem but couldn't find anything. I am not sure what's causing this (I haven't gone through the source thoroughly) but I am inclined towards skipping this test if that's OK with you? It'd be best if we fix it but I am not sure if it's worth a lot of time. Let me know what you think? Best, Utkarsh
Bug#980585: ruby-in-parallel: FTBFS: ERROR: Test "ruby2.7" failed: Failure/Error: expect(@result_3).to_not eq(true)
Hi Sébastien, On Thu, Jan 21, 2021 at 11:37 AM Sébastien Delafond wrote: > since you took care of the last upload, do you also plan to fix this > FTBFS? If not, please let me know and I'll look into it. I've started to look into it already but I wasn't able to reproduce it. All tests pass for me + autopkgtest (which is what I fixed last time). So I am not sure what's going wrong here. If you have some time and can take a look as well, that'd be really helpful. If you find something, let me know. - u
Bug#963477: ruby-rack: CVE-2020-8184
Hi Salvatore, On Sun, Jan 3, 2021 at 1:34 AM Salvatore Bonaccorso wrote: > Not any right now. Well there is CVE-2020-26247 but that one might be > too risky at this stage (AFAIU it is a breaking change, and thus ws > moved to the 1.11.x version). Lucas uploaded a new version, thereby fixing this as well. So yay! \o/ - u
Bug#979498: ITP: ruby-rake-ant -- Ant tasks and integration for Rake
Package: wnpp Severity: wishlist Owner: Utkarsh Gupta * Package name : ruby-rake-ant Version : 1.0.4 Upstream Author : Charles Oliver Nutter * URL : https://github.com/jruby/rake-ant * License : EPL-1.0 Programming Lang : Ruby Description : Ant tasks and integration for Rake This package provides a wrapper and Rake tasks for using Ant from any Rake build. - u
Bug#979497: ITP: ruby-scanf -- Implementation of the C function scanf
Package: wnpp Severity: wishlist Owner: Utkarsh Gupta * Package name : ruby-scanf Version : 1.0.0 Upstream Author : Yukihiro Matsumoto * URL : https://github.com/ruby/scanf * License : BSD-2-clause Programming Lang : Ruby Description : Implementation of the C function scanf scanf is an implementation of the C function scanf(3), modified as necessary for Ruby compatibility. . The methods provided are String#scanf, IO#scanf, and Kernel#scanf. Kernel#scanf is a wrapper around STDIN.scanf. IO#scanf can be used on any IO stream, including file handles and sockets. scanf can be called either with or without a block. - u
Bug#963477: ruby-rack: CVE-2020-8184
Hi Salvatore, On Sat, Jan 2, 2021 at 5:55 PM Salvatore Bonaccorso wrote: > > Of course. Uploaded a fix! :) > > (thanks for the explicit CC, please do it next time as well if you > > want me to take care of something which falls under the Ruby team). > > Thanks! About the explicit CC, well actually I was a bit "vary", > because if it's team maintained one should not start explicitly ping > some of the uploaders. But I'm glad if this was possible. It's not a problem, I am happy to help the security team as much as I possibly can (though you'd hopefully know that by now ;)). > Indeed there would be more ruby team maintained packages which > are currently no-dsa marked but maybe would be good to fix for > and in bullseye. There are issues for instance in ruby-faye and > ruby-faye-websocket as well: 967061, 959392, 967063. Eeks, sorry for not noticing them earlier. But I've uploaded a fix for all three of them^ :) Let me know if there are more that needs immediate fixing or so! \o/ - u
Bug#963477: ruby-rack: CVE-2020-8184
Hello, On Sat, Jan 2, 2021 at 2:02 AM Salvatore Bonaccorso wrote: > While strictly speaking this issue is no-dsa for buster, I'm raising > the severity to RC, would it be possible to address this issue for > unstable (and so bullseye) before the freeze? Of course. Uploaded a fix! :) (thanks for the explicit CC, please do it next time as well if you want me to take care of something which falls under the Ruby team). - u
Bug#978640: undefined symbol: _ZTIN3fmt2v612format_errorE
Hi Hubert, On Thu, Dec 31, 2020 at 3:21 AM Hubert Chathi wrote: > binNMU requested at > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978722 > > Apparently waiting for an update to spdlog. Awesome, thanks for processing this! - u
Bug#978640: undefined symbol: _ZTIN3fmt2v612format_errorE
Hi Hubert, On Tue, Dec 29, 2020 at 11:17 PM Hubert Chathi wrote: > Hmm. Can you try installing libfmt7 (from sid) and see if that fixes > it? The issue could be fixed by rebuilding nheko against the newly updated libfmt-dev version. I've prepared and pushed a fix to the salsa repository. If it's okay with you, can I do the upload as well? - u
Bug#978640: undefined symbol: _ZTIN3fmt2v612format_errorE
Package: nheko Version: 0.7.2-3 Severity: grave Dear maintainer, Whilst trying to open nheko, it fails to open with the following message: ``` $ nheko nheko: symbol lookup error: nheko: undefined symbol: _ZTIN3fmt2v612format_errorE ``` Is that known? Any idea what caused this regression or failure? Any workaround this? -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-5-amd64 (SMP w/8 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages nheko depends on: ii libboost-iostreams1.74.0 1.74.0-6 ii libboost-thread1.74.0 1.74.0-6 ii libc6 2.31-6 ii libcmark0.29.0 0.29.0-4 ii libgcc-s1 10.2.1-3 ii liblmdb0 0.9.24-1 ii libolm33.2.1~dfsg-5 ii libqt5core5a 5.15.2+dfsg-2 ii libqt5dbus55.15.2+dfsg-2 ii libqt5gui5 5.15.2+dfsg-2 ii libqt5network5 5.15.2+dfsg-2 ii libqt5qml5 5.15.2+dfsg-2 ii libqt5quick5 5.15.2+dfsg-2 ii libqt5quickwidgets55.15.2+dfsg-2 ii libqt5widgets5 5.15.2+dfsg-2 ii libsodium231.0.18-1 ii libspdlog1 1:1.8.1+ds-2+b1 ii libssl1.1 1.1.1i-1 ii libstdc++6 10.2.1-3 ii qml-module-qt-labs-settings5.15.2+dfsg-2 ii qml-module-qtgraphicaleffects 5.15.2-2 ii qml-module-qtmultimedia5.15.2-2 ii qml-module-qtquick-controls2 5.15.2+dfsg-2 ii qml-module-qtquick-layouts 5.15.2+dfsg-2 ii qml-module-qtquick-window2 5.15.2+dfsg-2 ii qml-module-qtquick25.15.2+dfsg-2 Versions of packages nheko recommends: ii ca-certificates 20200601 ii fonts-noto-color-emoji 0~20200916-1
Bug#972574: libgit2: merge request with a proposition
Hi Cédric, On Sun, Dec 27, 2020 at 2:57 AM Cédric Boutillier wrote: > I've just created a merge request on salsa > https://salsa.debian.org/debian/libgit2/-/merge_requests/3 > with a proposition. > This adds an extra libgit2-fixtures binary package, shipping the > examples under tests/resources in > /usr/share/doc/libgit2-fixtures/examples. > > Feel free to suggest another path if you think it is more appropriate. > > This allows me to run correctly the testsuite of ruby-rugged, once > indicating the correct location of libgit2 fixtures directory. This is great, thank you so much for working on this! \o/ I've merged the MR and uploaded to NEW! - u
Bug#976291: rails: please drop Build-Depends on qunit-selenium
Hello, On Fri, Dec 11, 2020 at 2:52 PM Pirate Praveen wrote: > On Wed, 2 Dec 2020 22:11:27 +0100 Paul Gevers wrote: > > I love tests. As one of the maintainers of the ci.debian.net > > infrastructure, I really do. However, with my Release Team member hat > > on, I'm asking you to stop Build-Depending on qunit-selenium which you > > need to run your build time tests. > > > > The reason I'm asking is that we want to remove chromium from bullseye > > because it's currently in a bad shape and qunit-selenium Depends on it, > > so has to go too. > > This is now applied in the git repo. Utkarsh wanted to make some more > changes before the upload. Alrighty, so it seems that it's time to say goodbye to chromium o/ - u
Bug#971571: transition: libgit2
Hey, On Wed, Dec 9, 2020 at 3:13 PM Utkarsh Gupta wrote: > I'll take a look at python-pygit2 today as well. So leaves us with > ruby-rugged. I'll come to that in next few days if no one beats me to > it. FWIW, I've uploaded both, thereby completing all the blockers. Hopefully this transition should complete soon :) Thanks to everybody who was involved here, especially Ximin and Sebastian! \o/ - u
Bug#971571: transition: libgit2
Hello, On Wed, Dec 9, 2020 at 2:23 AM Sebastian Ramacher wrote: > > So I conclude that it's probably fine to upload libgit2 1.1.0 to unstable > > now? > Okay, then let's do this now. Please go ahead. Awesome, uploaded! I'll take a look at python-pygit2 today as well. So leaves us with ruby-rugged. I'll come to that in next few days if no one beats me to it. - u
Bug#971571: transition: libgit2
Hi Sebastian,
On Tue, Dec 8, 2020 at 3:30 PM Sebastian Ramacher wrote:
> v30 was accepted. Please perform a source-only upload for the arch: all
> packages.
That should be done now! \o/
> > The only reverse-{,build-}dependency is gitaly, it seems. So I'm CCing
> > Praveen so he gets a heads up.
>
> Filed #976820 against gitaly.
>
> In any case, I'll remove golang-gopkg-libgit2-git2go.v28 and
> gitaly from testing to unblock this transition. gitaly is blocked by
> ruby-faraday which is currently causing a bunch of autopkgtest
> regressions.
Great, thanks for this!
I do have another (stupid) question :)
libgit2 upstream has released 1.1.0 after 1.0.1 (which is the
transition we're pusruing). However, libgit2 1.1.0 if backwards
compatible *but* still a transition is needed for it.
I've already worked on updating the same in experimental and it is now
accepted as well. Do you think we can do a 1.1.0 transition along with
this as well?
Whilst I didn't build all the reverse-{build-}dependencies but I
believe there shouldn't be much of a problem.
- u
Bug#971571: transition: libgit2
Hi Peter,
On Sun, Dec 6, 2020 at 11:06 AM peter green wrote:
> In addition to the packages mentioned here, it seems there is another
> package involved: golang-gopkg-libgit2-git2go.v28 . It only builds
> arch-all packages and does not directly depend on the library, but it
> FTBFS and it's autopkgtest fails with the new version.
>
> The FTBFS was picked up in a rebuild test by Lucas and a bug report
> was filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976522
Yes, because v28 is only compatible with libgit2 v0.28. For libgit2
v1.0, we need v30 for git2go. So I've uploaded
golang-gopkg-libgit2-git2go.v30 to NEW and once accepted, I'll file an
RM for v28.
The only reverse-{,build-}dependency is gitaly, it seems. So I'm CCing
Praveen so he gets a heads up.
Bug#971571: transition: libgit2
Hi, On Sat, Dec 5, 2020 at 1:41 AM Sebastian Ramacher wrote: > Scheduled the binNMUs except for horizon-eda (involved in python3.9-defaults). Great, thank you! I've, meanwhile, uploaded python-pygit2 and libgit-raw-perl! Will hopefully get on to ruby-rugged, as well! \o/ - u
Bug#971571: transition: libgit2
Hi Sebastian, On Fri, Dec 4, 2020 at 10:54 PM Sebastian Ramacher wrote: > Please go ahead with the upload to unstable. Great, thanks, I did an upload just now! :) - u
Bug#976270: [Pkg-puppet-devel] Bug#976270: ruby-puppet-forge: autopkgtest/ftbfs with ruby-faraday-middleware 1.x
Hi Praveen, On Wed, Dec 2, 2020 at 8:06 PM Pirate Praveen wrote: > I can see there is already a patch for relaxing faraday. > https://salsa.debian.org/puppet-team/ruby-puppet-forge/-/blob/master/debian/patches/002_loosen_deps.patch > This will need to be extended to cover ruby-faraday-middleware as well. I've updated the patch and even updated the version from 2.3.2 to 2.3.4. But the test failures are legit. The codebase is not prepared for faraday v1.x. I'll raise the issue upstream but you probably need to consider adding Breaks. - u
Bug#975607: libgit2-28: relative paths in alternates mishandled when nested
Hi Eric, On Tue, Nov 24, 2020 at 6:00 AM Eric Wong wrote: > I've noticed libgit2 fails to handle relative paths for > alternates properly when a relative path is nested from > within another alternate. Regular git(1) works fine > (as shown in the attached script). > > I initially hit this in some Inline::C (Perl) code, but the Ruby > "rugged" library hits it, too. > > I've attached a small Ruby script which reliably reproduces it > with the "ruby-rugged" gem. I chose Ruby for this bug report > since I expect libgit2 maintainers to be familiar with it. > > More detailed info is in the comments of the attached script. > > This also affects libgit2-27 (0.27.7+dfsg.1-0.2) in buster in > addition to buster-backports. > > This is an upstream bug, please forward as appropriate. Thanks for reporting this here. I've forwarded the bug upstream: https://github.com/libgit2/libgit2/issues/5711 As soon as we have a fix available for this, I'll be happy to backport this :) - u
Bug#973562: wordpress: Wordpress 5.5.2 security release
Hi Craig, On Tue, Nov 3, 2020 at 12:00 PM Craig Small wrote: > Hi Utkarsh, I've got Sid uploading now and will start on Buster in a moment. Perfect! Thanks for your great work on wordpress! - u
Bug#973562: wordpress: Wordpress 5.5.2 security release
Hi Craig, Seb, Salvatore, On Mon, 02 Nov 2020 08:01:44 +1100 Craig Small wrote: > Debian LTS have released 4.7.19 which fixes this already. Yep, I have already bumped the version and fixed these CVEs in stretch LTS. Please let me know in case I can help with any of the other updates? I don't mean to interfere, of course, but will be happy to prepare an update for buster or sid, if you need me to! :) - u
Bug#972161: buster-pu: package ruby2.5/2.5.5-3+deb10u3
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: buster
X-Debbugs-CC: debian-r...@lists.debian.org
Severity: normal
Hello,
ruby2.5 was affected by CVE-2020-25613, where WEBrick, a simple HTTP
server bundled with Ruby, had not checked the transfer-encoding header
value rigorously.
This has been fixed in Sid, Bullseye, and Stretch.
Here's the debdiff for buster-pu:
8<--8<--8<--8<--8<--8<--8<--8<--8<--8<
diff -Nru ruby2.5-2.5.5/debian/changelog ruby2.5-2.5.5/debian/changelog
--- ruby2.5-2.5.5/debian/changelog2020-07-04 00:07:58.0 +0530
+++ ruby2.5-2.5.5/debian/changelog2020-10-13 18:32:32.0 +0530
@@ -1,3 +1,10 @@
+ruby2.5 (2.5.5-3+deb10u3) buster; urgency=high
+
+ * Add patch to fix a potential HTTP request smuggling
+vulnerability in WEBrick. (Fixes: CVE-2020-25613)
+
+ -- Utkarsh Gupta Tue, 13 Oct 2020 18:32:32 +0530
+
ruby2.5 (2.5.5-3+deb10u2) buster-security; urgency=high
* Non-maintainer upload by the Security Team.
diff -Nru ruby2.5-2.5.5/debian/patches/CVE-2020-25613.patch
ruby2.5-2.5.5/debian/patches/CVE-2020-25613.patch
--- ruby2.5-2.5.5/debian/patches/CVE-2020-25613.patch1970-01-01
05:30:00.0 +0530
+++ ruby2.5-2.5.5/debian/patches/CVE-2020-25613.patch2020-10-13
18:31:51.0 +0530
@@ -0,0 +1,30 @@
+From 8946bb38b4d87549f0d99ed73c62c41933f97cc7 Mon Sep 17 00:00:00 2001
+From: Yusuke Endoh
+Date: Tue, 29 Sep 2020 13:15:58 +0900
+Subject: [PATCH] Make it more strict to interpret some headers
+
+Some regexps were too tolerant.
+
+--- a/lib/webrick/httprequest.rb
b/lib/webrick/httprequest.rb
+@@ -226,9 +226,9 @@
+ raise HTTPStatus::BadRequest, "bad URI `#{@unparsed_uri}'."
+ end
+
+- if /close/io =~ self["connection"]
++ if /\Aclose\z/io =~ self["connection"]
+ @keep_alive = false
+- elsif /keep-alive/io =~ self["connection"]
++ elsif /\Akeep-alive\z/io =~ self["connection"]
+ @keep_alive = true
+ elsif @http_version < "1.1"
+ @keep_alive = false
+@@ -475,7 +475,7 @@
+ return unless socket
+ if tc = self['transfer-encoding']
+ case tc
+-when /chunked/io then read_chunked(socket, block)
++when /\Achunked\z/io then read_chunked(socket, block)
+ else raise HTTPStatus::NotImplemented, "Transfer-Encoding: #{tc}."
+ end
+ elsif self['content-length'] || @remaining_size
diff -Nru ruby2.5-2.5.5/debian/patches/series
ruby2.5-2.5.5/debian/patches/series
--- ruby2.5-2.5.5/debian/patches/series2020-07-04 00:06:34.0 +0530
+++ ruby2.5-2.5.5/debian/patches/series2020-10-13 18:32:04.0 +0530
@@ -15,3 +15,4 @@
0015-lib-shell-command-processor.rb-Shell-prevent-unknown.patch
CVE-2020-10933.patch
CVE-2020-10663.patch
+CVE-2020-25613.patch
8<--8<--8<--8<--8<--8<--8<--8<--8<--8<
- u
---
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.6.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=>
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
