Bug#992563: transition: gdal
On 9/23/21 11:47 PM, Sebastian Ramacher wrote: > On 2021-09-23 11:44:14 +0200, Sebastiaan Couwenberg wrote: >> There is also postgis which is blocked by a piuparts regression that's >> not actually caused by postgis. piuparts-de...@alioth-lists.debian.net >> has been contacted about that last week, but no response so far. > > Why is it failing? Have bugs been filed for this issue? Because postgresql-common removed the wrong file, see: https://salsa.debian.org/postgresql/postgresql-common/-/commit/27b62a5edd2e07d6242e51cae2414f4487fbe370 I can't find a bugreport for it. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#992563: transition: gdal
On 2021-09-23 11:44:14 +0200, Sebastiaan Couwenberg wrote: > On 9/23/21 11:40 AM, Sebastian Ramacher wrote: > > On 2021-09-23 11:34:21, Sebastiaan Couwenberg wrote: > >> On 9/18/21 9:57 AM, Sebastian Ramacher wrote: > >>> On 2021-09-18 07:01:38 +0200, Sebastiaan Couwenberg wrote: > On 9/12/21 7:54 PM, Sebastiaan Couwenberg wrote: > > Quite a few packages on mipsel may need a binNMU for the recent glibc > changes, it allowed libgdal-grass to migrate, but there a still quite a > few packages with remaining issues: > > https://linuxminded.nl/debian/gis-transitions/testing/html/gdal.html > >>> > >>> There are a over 200 packages and a bunch of binNMUs that are blocked by > >>> glibc. I'm slowly wading through that list. > >> > >> glibc migrated to testing, this allowed a few packages that are part of > >> the gdal & pdal transitions to migrate but there are still outstanding > >> issues. > >> > >> In the britney update_output.txt you see these packages as reasons why > >> the old gdal & pdal library cannot be removed, but you don't see > >> attempts to migrate those packages. > >> > >> r-cran-rgdal and r-cran-sf are blocked by r-base. > > > > They have been binNMUed in testing-proposed-updates and should migrate > > to testing in the next run. > > > >> What is preventing vtk7 and paraview from migrating? > > > >>From https://release.debian.org/britney/update_excuses.html: both the > > paraview and vtk7 binNMUs are blocked by openmpi. > > Thanks, I was looking at: > > https://qa.debian.org/excuses.php?package=paraview > https://qa.debian.org/excuses.php?package=vtk7 > > There is also postgis which is blocked by a piuparts regression that's > not actually caused by postgis. piuparts-de...@alioth-lists.debian.net > has been contacted about that last week, but no response so far. Why is it failing? Have bugs been filed for this issue? Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Processed: Re: Bug#994560: transition: libffi
Processing control commands: > tags -1 confirmed Bug #994560 [release.debian.org] transition: libffi Added tag(s) confirmed. > forwarded -1 https://release.debian.org/transitions/html/auto-libffi.html Bug #994560 [release.debian.org] transition: libffi Set Bug forwarded-to-address to 'https://release.debian.org/transitions/html/auto-libffi.html'. -- 994560: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994560 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#994560: transition: libffi
Control: tags -1 confirmed Control: forwarded -1 https://release.debian.org/transitions/html/auto-libffi.html On 2021-09-17 20:21:10 +0200, Matthias Klose wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Update libffi to version 3.4.2. The transition was done for Ubuntu, a handful > of bugs regarding build failures (mostly due to GCC 11) are filed in Debian. I > would like to get this done before the ghc version in unstable changes, due to > the rather large number of ghc related no-change uploads. Please go ahead. Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#994946: bullseye-pu: package atftp/0.7.git20120829-3.3
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: a...@debian.org
Hi,
I would like to ask for permission to upload a new atftpd
package 0.7.git20120829-3.3+deb11u1 to fix #994895, buffer
overflow, CVE-2021-41054.
[ Reason ]
Fix a CVE (no DSA)
[ Impact ]
atftpd can be crashed by sending a crafted, but trivial request.
[ Tests ]
I manually tested that the buffer overflow happens in the current
package and is fixed in the new package.
[ Risks ]
very small
[ Checklist ]
[X] *all* changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in (old)stable
[X] the issue is verified as fixed in unstable
[ Changes ]
The patch checks the length of the options of the request and
throws an error if the buffer is too small.
diff -u atftp-0.7.git20120829/debian/changelog
atftp-0.7.git20120829/debian/changelog
--- atftp-0.7.git20120829/debian/changelog
+++ atftp-0.7.git20120829/debian/changelog
@@ -1,3 +1,9 @@
+atftp (0.7.git20120829-3.3+deb11u1) bullseye; urgency=medium
+
+ * Fix for CVE-2021-41054 (Closes: #994895)
+
+ -- Andreas B. Mundt Wed, 22 Sep 2021 21:15:01 +0200
+
atftp (0.7.git20120829-3.3) unstable; urgency=medium
* Non-maintainer upload.
diff -u atftp-0.7.git20120829/tftpd_file.c atftp-0.7.git20120829/tftpd_file.c
--- atftp-0.7.git20120829/tftpd_file.c
+++ atftp-0.7.git20120829/tftpd_file.c
@@ -183,8 +183,17 @@
/* blksize options */
if ((result = opt_get_blksize(data->tftp_options)) > -1)
{
- if ((result < 8) || (result > 65464))
+ /*
+ * If we receive more options, we have to make sure our buffer for
+ * the OACK is not too small. Use the string representation of
+ * the options here for simplicity, which puts us on the save side.
+ * FIXME: Use independent buffers for OACK and data.
+ */
+ opt_options_to_string(data->tftp_options, string, MAXLEN);
+ if ((result < strlen(string)-2) || (result > 65464))
{
+ logger(LOG_NOTICE, "options <%s> require roughly a blksize of
%d for the OACK.",
+ string, strlen(string)-2);
tftp_send_error(sockfd, sa, EOPTNEG, data->data_buffer,
data->data_buffer_size);
if (data->trace)
logger(LOG_DEBUG, "sent ERROR ",
EOPTNEG,
@@ -530,8 +539,17 @@
/* blksize options */
if ((result = opt_get_blksize(data->tftp_options)) > -1)
{
- if ((result < 8) || (result > 65464))
+ /*
+ * If we receive more options, we have to make sure our buffer for
+ * the OACK is not too small. Use the string representation of
+ * the options here for simplicity, which puts us on the save side.
+ * FIXME: Use independent buffers for OACK and data.
+ */
+ opt_options_to_string(data->tftp_options, string, MAXLEN);
+ if ((result < strlen(string)-2) || (result > 65464))
{
+ logger(LOG_NOTICE, "options <%s> require roughly a blksize of
%d for the OACK.",
+ string, strlen(string)-2);
tftp_send_error(sockfd, sa, EOPTNEG, data->data_buffer,
data->data_buffer_size);
if (data->trace)
logger(LOG_DEBUG, "sent ERROR ",
EOPTNEG,
Bug#994943: buster-pu: package atftp/0.7.git20120829-3.2~deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: a...@debian.org
Hi,
I would like to ask for permission to upload a new atftpd
package 0.7.git20120829-3.2+deb10u2 to fix #994895, buffer
overflow, CVE-2021-41054.
[ Reason ]
Fix a CVE (no DSA)
[ Impact ]
atftpd can be crashed by sending a crafted, but trivial request.
[ Tests ]
I manually tested that the buffer overflow happens in the current
package and is fixed in the new package.
[ Risks ]
very small
[ Checklist ]
[X] *all* changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in (old)stable
[X] the issue is verified as fixed in unstable
[ Changes ]
The patch checks the length of the options of the request and throws an
error if the buffer is too small.
[ Other info ]
I chose the package version to increases from -3.2~deb10u1 to -3.2+deb10u2
diff -u atftp-0.7.git20120829/debian/changelog
atftp-0.7.git20120829/debian/changelog
--- atftp-0.7.git20120829/debian/changelog
+++ atftp-0.7.git20120829/debian/changelog
@@ -1,3 +1,9 @@
+atftp (0.7.git20120829-3.2+deb10u2) buster; urgency=medium
+
+ * Fix for CVE-2021-41054 (Closes: #994895)
+
+ -- Andreas B. Mundt Wed, 22 Sep 2021 20:27:34 +0200
+
atftp (0.7.git20120829-3.2~deb10u1) buster; urgency=medium
* Non-maintainer upload.
diff -u atftp-0.7.git20120829/tftpd_file.c atftp-0.7.git20120829/tftpd_file.c
--- atftp-0.7.git20120829/tftpd_file.c
+++ atftp-0.7.git20120829/tftpd_file.c
@@ -183,8 +183,17 @@
/* blksize options */
if ((result = opt_get_blksize(data->tftp_options)) > -1)
{
- if ((result < 8) || (result > 65464))
+ /*
+ * If we receive more options, we have to make sure our buffer for
+ * the OACK is not too small. Use the string representation of
+ * the options here for simplicity, which puts us on the save side.
+ * FIXME: Use independent buffers for OACK and data.
+ */
+ opt_options_to_string(data->tftp_options, string, MAXLEN);
+ if ((result < strlen(string)-2) || (result > 65464))
{
+ logger(LOG_NOTICE, "options <%s> require roughly a blksize of
%d for the OACK.",
+ string, strlen(string)-2);
tftp_send_error(sockfd, sa, EOPTNEG, data->data_buffer,
data->data_buffer_size);
if (data->trace)
logger(LOG_DEBUG, "sent ERROR ",
EOPTNEG,
@@ -530,8 +539,17 @@
/* blksize options */
if ((result = opt_get_blksize(data->tftp_options)) > -1)
{
- if ((result < 8) || (result > 65464))
+ /*
+ * If we receive more options, we have to make sure our buffer for
+ * the OACK is not too small. Use the string representation of
+ * the options here for simplicity, which puts us on the save side.
+ * FIXME: Use independent buffers for OACK and data.
+ */
+ opt_options_to_string(data->tftp_options, string, MAXLEN);
+ if ((result < strlen(string)-2) || (result > 65464))
{
+ logger(LOG_NOTICE, "options <%s> require roughly a blksize of
%d for the OACK.",
+ string, strlen(string)-2);
tftp_send_error(sockfd, sa, EOPTNEG, data->data_buffer,
data->data_buffer_size);
if (data->trace)
logger(LOG_DEBUG, "sent ERROR ",
EOPTNEG,
Re: Bug#992563: transition: gdal
On 23/09/2021 10:40, Sebastian Ramacher wrote: On 2021-09-23 11:34:21, Sebastiaan Couwenberg wrote: On 9/18/21 9:57 AM, Sebastian Ramacher wrote: On 2021-09-18 07:01:38 +0200, Sebastiaan Couwenberg wrote: What is preventing vtk7 and paraview from migrating? >From https://release.debian.org/britney/update_excuses.html: both the paraview and vtk7 binNMUs are blocked by openmpi. openmpi is blocked on removing old eckit 32-bit packages from the archive (#993624) Cheers -- Alastair McKinstry, email: alast...@sceal.ie, matrix: @alastair:sceal.ie, phone: 087-6847928 Green Party Councillor, Galway County Council
Bug#992563: transition: gdal
On 9/23/21 11:40 AM, Sebastian Ramacher wrote: > On 2021-09-23 11:34:21, Sebastiaan Couwenberg wrote: >> On 9/18/21 9:57 AM, Sebastian Ramacher wrote: >>> On 2021-09-18 07:01:38 +0200, Sebastiaan Couwenberg wrote: On 9/12/21 7:54 PM, Sebastiaan Couwenberg wrote: Quite a few packages on mipsel may need a binNMU for the recent glibc changes, it allowed libgdal-grass to migrate, but there a still quite a few packages with remaining issues: https://linuxminded.nl/debian/gis-transitions/testing/html/gdal.html >>> >>> There are a over 200 packages and a bunch of binNMUs that are blocked by >>> glibc. I'm slowly wading through that list. >> >> glibc migrated to testing, this allowed a few packages that are part of >> the gdal & pdal transitions to migrate but there are still outstanding >> issues. >> >> In the britney update_output.txt you see these packages as reasons why >> the old gdal & pdal library cannot be removed, but you don't see >> attempts to migrate those packages. >> >> r-cran-rgdal and r-cran-sf are blocked by r-base. > > They have been binNMUed in testing-proposed-updates and should migrate > to testing in the next run. > >> What is preventing vtk7 and paraview from migrating? > >>From https://release.debian.org/britney/update_excuses.html: both the > paraview and vtk7 binNMUs are blocked by openmpi. Thanks, I was looking at: https://qa.debian.org/excuses.php?package=paraview https://qa.debian.org/excuses.php?package=vtk7 There is also postgis which is blocked by a piuparts regression that's not actually caused by postgis. piuparts-de...@alioth-lists.debian.net has been contacted about that last week, but no response so far. Can that issue be ignored to let it migrate? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#992563: transition: gdal
On 2021-09-23 11:40:15, Sebastian Ramacher wrote: > On 2021-09-23 11:34:21, Sebastiaan Couwenberg wrote: > > On 9/18/21 9:57 AM, Sebastian Ramacher wrote: > > > On 2021-09-18 07:01:38 +0200, Sebastiaan Couwenberg wrote: > > >> On 9/12/21 7:54 PM, Sebastiaan Couwenberg wrote: > > >> > > >> Quite a few packages on mipsel may need a binNMU for the recent glibc > > >> changes, it allowed libgdal-grass to migrate, but there a still quite a > > >> few packages with remaining issues: > > >> > > >> https://linuxminded.nl/debian/gis-transitions/testing/html/gdal.html > > > > > > There are a over 200 packages and a bunch of binNMUs that are blocked by > > > glibc. I'm slowly wading through that list. > > > > glibc migrated to testing, this allowed a few packages that are part of > > the gdal & pdal transitions to migrate but there are still outstanding > > issues. > > > > In the britney update_output.txt you see these packages as reasons why > > the old gdal & pdal library cannot be removed, but you don't see > > attempts to migrate those packages. > > > > r-cran-rgdal and r-cran-sf are blocked by r-base. > > They have been binNMUed in testing-proposed-updates and should migrate > to testing in the next run. > > > > > What is preventing vtk7 and paraview from migrating? > > From https://release.debian.org/britney/update_excuses.html: both the > paraview and vtk7 binNMUs are blocked by openmpi. A fix for gyoto was uploaded, so openmpi should be able to migrate in a few days. Cheers -- Sebastian Ramacher
Bug#992563: transition: gdal
On 2021-09-23 11:34:21, Sebastiaan Couwenberg wrote: > On 9/18/21 9:57 AM, Sebastian Ramacher wrote: > > On 2021-09-18 07:01:38 +0200, Sebastiaan Couwenberg wrote: > >> On 9/12/21 7:54 PM, Sebastiaan Couwenberg wrote: > >> > >> Quite a few packages on mipsel may need a binNMU for the recent glibc > >> changes, it allowed libgdal-grass to migrate, but there a still quite a > >> few packages with remaining issues: > >> > >> https://linuxminded.nl/debian/gis-transitions/testing/html/gdal.html > > > > There are a over 200 packages and a bunch of binNMUs that are blocked by > > glibc. I'm slowly wading through that list. > > glibc migrated to testing, this allowed a few packages that are part of > the gdal & pdal transitions to migrate but there are still outstanding > issues. > > In the britney update_output.txt you see these packages as reasons why > the old gdal & pdal library cannot be removed, but you don't see > attempts to migrate those packages. > > r-cran-rgdal and r-cran-sf are blocked by r-base. They have been binNMUed in testing-proposed-updates and should migrate to testing in the next run. > > What is preventing vtk7 and paraview from migrating? >From https://release.debian.org/britney/update_excuses.html: both the paraview and vtk7 binNMUs are blocked by openmpi. Cheers -- Sebastian Ramacher
Bug#992563: transition: gdal
On 9/18/21 9:57 AM, Sebastian Ramacher wrote: > On 2021-09-18 07:01:38 +0200, Sebastiaan Couwenberg wrote: >> On 9/12/21 7:54 PM, Sebastiaan Couwenberg wrote: >> >> Quite a few packages on mipsel may need a binNMU for the recent glibc >> changes, it allowed libgdal-grass to migrate, but there a still quite a >> few packages with remaining issues: >> >> https://linuxminded.nl/debian/gis-transitions/testing/html/gdal.html > > There are a over 200 packages and a bunch of binNMUs that are blocked by > glibc. I'm slowly wading through that list. glibc migrated to testing, this allowed a few packages that are part of the gdal & pdal transitions to migrate but there are still outstanding issues. In the britney update_output.txt you see these packages as reasons why the old gdal & pdal library cannot be removed, but you don't see attempts to migrate those packages. r-cran-rgdal and r-cran-sf are blocked by r-base. What is preventing vtk7 and paraview from migrating? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
