Mejorando tu fluja de Caja
Consigue Ingresos Extras Con Profesionales…. Si quieres acelerar tu ahorro, llegar con mayor efectivo a final de mes o hacer un regalo a alguien especial comienza a capitalizar tus ahorros. Get Extra Income With Professionals…. If you want to accelerate your savings, arrive with more cash at the end of the month or make a gift to someone special, start capitalizing on your savings. https://office2.pietraverdi.com/inversiones5015 Te propondremos alternativas para que generes ingresos diarios, pronto veras como tu cuenta bancaria tiene el disponible que requieres… We will propose alternatives for you to generate daily income, you will soon see how your bank account has the available that you require ... https://cliente.gdenlinea.net/inversiones5010/unete/1609 Pero necesitaras hacer uso CRIPTOMONEDAS… antes que todo se requiere tener acceso a este medio…. But you will need to make use of CRYPTOCURRENCIES… first of all it is required to have access to this medium…. https://r.kraken.com/c/2599012/741638/10583
Bug#996997: buster-pu: Cleaning up the http-parser ABI breakage in Debian 10 ("buster")
Thanks for your swift and kind response.
Adam D. Barratt wrote...
> On Fri, 2021-10-22 at 09:18 +0200, Christoph Biedl wrote:
> > ## Rework the patch
> >
> > Revert the ABI break by reworking the patch to restore the previous
> > struct layout - while maintaining the purpose of the change: Storing
> > a ninth status bit. Hilko Bengen did a great job implementing this,
> > and also reported success with several tests.
> >
> This seems like the best option if we can, although I realise it does
> break from our usual desire to use a patch as-implemented in later
> versions.
>
> Do you already have a proposed new upload / debdiff?
Find a debdiff attached, there is a lengthy explanation in the patch.
Still open on my side is a *huge* round of tests, preferably all
archtectures supported in buster, especially big-endian. This may take
major parts of the weekend.
> > PS: Related, do you check autopkgtest (...)
>
> We did discuss this on IRC briefly, but for the record - there's a
> britney instance that produces "excuses" for p-u and o-p-u, including
> scheduling autopkgtests via ci.d.n. The results show up on our tracking
> pages and we (mainly Paul; thanks!) investigate any failures raised to
> determine if they resulted from the proposed update and, if so, what to
> do about that.
Follow-up question, I might have asked that before or it has already
been answered: In case a package gets an update via a stable point
release ... I think it makes sense to take this as a chance to add an
autopkgtest if not present yet?
Rationale: The tang package I maintain as well was updated via a stable
point release in January. If I had included a backported autopkgtest, we
would have learned about the current issue in http-parser in time.
Christoph
diff -Nru http-parser-2.8.1/debian/changelog http-parser-2.8.1/debian/changelog
--- http-parser-2.8.1/debian/changelog 2021-06-04 20:59:56.0 +0200
+++ http-parser-2.8.1/debian/changelog 2021-10-22 19:02:29.0 +0200
@@ -1,3 +1,11 @@
+http-parser (2.8.1-1+deb10u2) NOT-FOR-RELEASE; urgency=medium
+
+ + NOT FOR RELEASE: This is only for review and testing.
+ * Fix ABI breakage introduced by accident in 2.8.1-1+deb10u1.
+Closes: #996460, #996939, #996997
+
+ -- Christoph Biedl Fri, 22 Oct 2021
19:02:29 +0200
+
http-parser (2.8.1-1+deb10u1) buster; urgency=medium
* Cherry-pick "Support multi-coding Transfer-Encoding".
diff -Nru http-parser-2.8.1/debian/patches/fix-ABI-breakage.patch
http-parser-2.8.1/debian/patches/fix-ABI-breakage.patch
--- http-parser-2.8.1/debian/patches/fix-ABI-breakage.patch 1970-01-01
01:00:00.0 +0100
+++ http-parser-2.8.1/debian/patches/fix-ABI-breakage.patch 2021-10-22
19:02:29.0 +0200
@@ -0,0 +1,191 @@
+Subject: Fix ABI breakage introduced by accident in 2.8.1-1+deb10u1
+Author: Hilko Bengen
+Date: 2021-10-22
+Bug-Debian:
+https://bugs.debian.org/996460
+https://bugs.debian.org/996939
+https://bugs.debian.org/996997
+Comment: (by the http-parser maintainer)
+ The fix for CVE-2019-15605 introduced an ABI break by changing the
+ layout of struct http_parser - a change that was needed to store a
+ ninth bit in the "flags" field. However, this affected offsets of
+ fields declared as public, causing applications to break.
+
+ To restore the previous layout while stil implementing the fix: Steal
+ one bit from the content_length element (the remaining 63 are more
+ than enough) to store the newly introduced F_TRANSFER_ENCODING flag.
+ Also rename the constant to F_TRANSFER_ENCODING2 as a safeguard
+ against applications that try to manipulate information that is by
+ definition private.
+
+ Thanks a lot to Hilko Bengen for the idea, implementation, a first
+ round of tests and many suggestions. -CB
+
+--- a/http_parser.c
b/http_parser.c
+@@ -25,9 +25,7 @@
+ #include
+ #include
+
+-#ifndef ULLONG_MAX
+-# define ULLONG_MAX ((uint64_t) -1) /* 2^64-1 */
+-#endif
++#define CONTENT_LENGTH_MAX (((uint64_t)-1) >> 1)
+
+ #ifndef MIN
+ # define MIN(a,b) ((a) < (b) ? (a) : (b))
+@@ -724,7 +722,8 @@
+ if (ch == CR || ch == LF)
+ break;
+ parser->flags = 0;
+-parser->content_length = ULLONG_MAX;
++parser->flags2 = 0;
++parser->content_length = CONTENT_LENGTH_MAX;
+
+ if (ch == 'H') {
+ UPDATE_STATE(s_res_or_resp_H);
+@@ -759,7 +758,8 @@
+ case s_start_res:
+ {
+ parser->flags = 0;
+-parser->content_length = ULLONG_MAX;
++parser->flags2 = 0;
++parser->content_length = CONTENT_LENGTH_MAX;
+
+ switch (ch) {
+ case 'H':
+@@ -923,7 +923,8 @@
+ if (ch == CR || ch == LF)
+ break;
+ parser->flags = 0;
+-parser->content_length = ULLONG_MAX;
++parser->flags2 = 0;
++parser->content_length = CONTENT_LENGTH_MAX;
+
+ if (UNLIKELY(!IS_ALPHA(ch))) {
+
Bug#993680: transition: proj
On 10/22/21 5:51 PM, Sebastiaan Couwenberg wrote: > On 10/22/21 1:49 PM, Sebastiaan Couwenberg wrote: >> On 10/22/21 11:19 AM, Sebastiaan Couwenberg wrote: >>> On 10/21/21 11:17 PM, Sebastian Ramacher wrote: On 2021-09-04 19:49:39 +0200, Bas Couwenberg wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org > Control: forwarded -1 > https://release.debian.org/transitions/html/auto-proj.html > Control: block -1 by 983222 983224 983229 983230 983253 983254 983299 > 983345 > > For the Debian GIS team I'd like to transition to PROJ 8. Please go ahead. Please also raise the remaining FTBFS bugs to serious. >>> >>> proj (8.1.1-1) and python-cartopy (0.20.1+dfsg-1) have been uploaded to >>> unstable. And the severity of the bugreports has been raised to serious. >>> >>> Thanks for already scheduling the dependency level 2 NMUs, these are >>> almost done except for mips64el where they had to wait for proj to be >>> installed which it is now. >> >> libgeotiff & spatialite are built & installed on all release >> architectures, dependency level 3 can be NMUed now. > > magics++ is built and installed on all release architectures, cdo can be > NMUed now. gdal is now also built & installed on all release architectures, the rest of dependency level 4 can be NMUed now too. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#993680: transition: proj
On 10/22/21 1:49 PM, Sebastiaan Couwenberg wrote: > On 10/22/21 11:19 AM, Sebastiaan Couwenberg wrote: >> On 10/21/21 11:17 PM, Sebastian Ramacher wrote: >>> On 2021-09-04 19:49:39 +0200, Bas Couwenberg wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org Control: forwarded -1 https://release.debian.org/transitions/html/auto-proj.html Control: block -1 by 983222 983224 983229 983230 983253 983254 983299 983345 For the Debian GIS team I'd like to transition to PROJ 8. >>> >>> Please go ahead. Please also raise the remaining FTBFS bugs to serious. >> >> proj (8.1.1-1) and python-cartopy (0.20.1+dfsg-1) have been uploaded to >> unstable. And the severity of the bugreports has been raised to serious. >> >> Thanks for already scheduling the dependency level 2 NMUs, these are >> almost done except for mips64el where they had to wait for proj to be >> installed which it is now. > > libgeotiff & spatialite are built & installed on all release > architectures, dependency level 3 can be NMUed now. magics++ is built and installed on all release architectures, cdo can be NMUed now. > The rebuild of octave-octproj is blocked by sundials not having been > rebuilt with the new petsc yet. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#996204: transition: numerical library stack
Great, thanks! Will do it very shortly. Anton Sebastian Ramacher schrieb am Fr., 22. Okt. 2021, 14:35: > Hi Anton > > On 2021-10-12 13:09:02, Drew Parsons wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > X-Debbugs-Cc: debian-scie...@lists.debian.org, Anton Gladky < > gl...@debian.org> > > > > I'd like to proceed with a transition of the numerical library stack. > > This involves > > > > superlu 5.2.2+dfsg1 -> 5.3.0+dfsg1 (both libsuperlu5 so not > really a transition) > > superlu-dist libsuperlu-dist6 -> libsuperlu-dist7 > > hypre 2.18.2 -> 2.22.1 (internal within libhypre-dev) > > mumps libmumps-5.3 -> libmumps-5.4 > > scotch6.1.0 -> 6.1.1 (both libscotch-6.1 so not a transition) > > petsc libpetsc-.*3.14 -> libpetsc-.*3.15 > > slepc libslepc-.*3.14 -> libslepc-.*3.15 > > (together with petsc4py, slepc4py) > > > > Header packages libxtensor-dev, libxtensor-blas-dev will also be > > upgraded (xtl-dev 0.7.2 already got uploaded to unstable). > > > > fenics-dolfinx will upgrade > > libdolfinx-.*2019.2 -> libdolfinx-.*0.3 > > (along with other fenics components). There is currently some problem > > with fenics-dolfinx 1:0.3.0-4 on 32-bit arches i386, armel, armhf. > > I'll skip the demo_poisson_mpi tests for them if necessary. > > > > sundials 5.7.0 is incompatible with hypre 2.22, Anton Gladky (cc:d) will > > upgrade to sundials 5.8.0. > > I think we are ready for the sundials upload. > > Cheers > > > > > openmpi/mpi4py/h5py have recently migrated to testing so shouldn't give > > any particular trouble (apart from the known 32-bit dolfinx problem) > > > > auto transitions are already in place: > > > > https://release.debian.org/transitions/html/auto-superlu-dist.html > > https://release.debian.org/transitions/html/auto-mumps.html > > https://release.debian.org/transitions/html/auto-petsc.html > > https://release.debian.org/transitions/html/auto-slepc.html > > > > > > Ben file: > > > > title = "numerical library stack"; > > is_affected = .depends ~ "libpetsc-.*3.14" | .depends ~ > "libpetsc-.*3.15"; > > is_good = .depends ~ "libpetsc-.*3.15"; > > is_bad = .depends ~ "libpetsc-.*3.14"; > > > > -- > Sebastian Ramacher >
Bug#996204: transition: numerical library stack
Hi Anton On 2021-10-12 13:09:02, Drew Parsons wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: debian-scie...@lists.debian.org, Anton Gladky > > I'd like to proceed with a transition of the numerical library stack. > This involves > > superlu 5.2.2+dfsg1 -> 5.3.0+dfsg1 (both libsuperlu5 so not really a > transition) > superlu-dist libsuperlu-dist6 -> libsuperlu-dist7 > hypre 2.18.2 -> 2.22.1 (internal within libhypre-dev) > mumps libmumps-5.3 -> libmumps-5.4 > scotch6.1.0 -> 6.1.1 (both libscotch-6.1 so not a transition) > petsc libpetsc-.*3.14 -> libpetsc-.*3.15 > slepc libslepc-.*3.14 -> libslepc-.*3.15 > (together with petsc4py, slepc4py) > > Header packages libxtensor-dev, libxtensor-blas-dev will also be > upgraded (xtl-dev 0.7.2 already got uploaded to unstable). > > fenics-dolfinx will upgrade > libdolfinx-.*2019.2 -> libdolfinx-.*0.3 > (along with other fenics components). There is currently some problem > with fenics-dolfinx 1:0.3.0-4 on 32-bit arches i386, armel, armhf. > I'll skip the demo_poisson_mpi tests for them if necessary. > > sundials 5.7.0 is incompatible with hypre 2.22, Anton Gladky (cc:d) will > upgrade to sundials 5.8.0. I think we are ready for the sundials upload. Cheers > > openmpi/mpi4py/h5py have recently migrated to testing so shouldn't give > any particular trouble (apart from the known 32-bit dolfinx problem) > > auto transitions are already in place: > > https://release.debian.org/transitions/html/auto-superlu-dist.html > https://release.debian.org/transitions/html/auto-mumps.html > https://release.debian.org/transitions/html/auto-petsc.html > https://release.debian.org/transitions/html/auto-slepc.html > > > Ben file: > > title = "numerical library stack"; > is_affected = .depends ~ "libpetsc-.*3.14" | .depends ~ "libpetsc-.*3.15"; > is_good = .depends ~ "libpetsc-.*3.15"; > is_bad = .depends ~ "libpetsc-.*3.14"; > -- Sebastian Ramacher
Bug#993680: transition: proj
On 10/22/21 11:19 AM, Sebastiaan Couwenberg wrote: > On 10/21/21 11:17 PM, Sebastian Ramacher wrote: >> On 2021-09-04 19:49:39 +0200, Bas Couwenberg wrote: >>> Package: release.debian.org >>> Severity: normal >>> User: release.debian@packages.debian.org >>> Usertags: transition >>> X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org >>> Control: forwarded -1 >>> https://release.debian.org/transitions/html/auto-proj.html >>> Control: block -1 by 983222 983224 983229 983230 983253 983254 983299 983345 >>> >>> For the Debian GIS team I'd like to transition to PROJ 8. >> >> Please go ahead. Please also raise the remaining FTBFS bugs to serious. > > proj (8.1.1-1) and python-cartopy (0.20.1+dfsg-1) have been uploaded to > unstable. And the severity of the bugreports has been raised to serious. > > Thanks for already scheduling the dependency level 2 NMUs, these are > almost done except for mips64el where they had to wait for proj to be > installed which it is now. libgeotiff & spatialite are built & installed on all release architectures, dependency level 3 can be NMUed now. The rebuild of octave-octproj is blocked by sundials not having been rebuilt with the new petsc yet. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#993680: transition: proj
On 10/21/21 11:17 PM, Sebastian Ramacher wrote: > On 2021-09-04 19:49:39 +0200, Bas Couwenberg wrote: >> Package: release.debian.org >> Severity: normal >> User: release.debian@packages.debian.org >> Usertags: transition >> X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org >> Control: forwarded -1 >> https://release.debian.org/transitions/html/auto-proj.html >> Control: block -1 by 983222 983224 983229 983230 983253 983254 983299 983345 >> >> For the Debian GIS team I'd like to transition to PROJ 8. > > Please go ahead. Please also raise the remaining FTBFS bugs to serious. proj (8.1.1-1) and python-cartopy (0.20.1+dfsg-1) have been uploaded to unstable. And the severity of the bugreports has been raised to serious. Thanks for already scheduling the dependency level 2 NMUs, these are almost done except for mips64el where they had to wait for proj to be installed which it is now. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#996997: buster-pu: Cleaning up the http-parser ABI breakage in Debian 10 ("buster")
On Fri, 2021-10-22 at 09:18 +0200, Christoph Biedl wrote:
> As described in #996939: The fix for CVE-2019-15605 changed, among
> other things, the layout of "struct http_parser", by increasing the
> size of the "flag" field and also its position¹ within the struct.
>
> The latter ought not to do harm as the fields affected are marked as
> private. But since that is not enforced in C, applications still
> might access them.
>
> The size change however is way worse, it caused the following
> elements, especially "public" ones like "data" to change their
> offset.
>
Ack. :-(
>
> # Solutions
>
> After some discussion with Hilko Bengen (Cc:'ed) I can see two ways
> out of this:
>
[...]
> ## Rework the patch
>
> Revert the ABI break by reworking the patch to restore the previous
> struct layout - while maintaining the purpose of the change: Storing
> a ninth status bit. Hilko Bengen did a great job implementing this,
> and also reported success with several tests.
>
This seems like the best option if we can, although I realise it does
break from our usual desire to use a patch as-implemented in later
versions.
Do you already have a proposed new upload / debdiff?
> Pros:
> * Only http-parser needs an upload.
> * External applications (built using Debian but not shipped by
> Debian)
> continue to work. While this is not within our scope, it provides a
> good service.
>
> Cons:
> * Requires testing on all architectures supported in buster. My job.
> * Applications that access private fields still might break. Highly
> unlikely to happen, and I have little mercy here.
> * Applications and packages built *since* the ABI break will require
> a rebuild since technically this is a second ABI break. For Debian,
> the intersection with
> https://release.debian.org/proposed-updates/oldstable.html
> seems to be empty.
>
[...]
> Please advise how to proceed. I would like to see this handled as
> soon as possible - knowing users out there encounter problems and
> will do so until the next oldstable point release is not quite a
> pleasant situation.
>
> Personally I have a slight preference for the second ("rework the
> patch") way, but that's not put in stone.
>
>From the information you've provided above, I think I agree. We could
release the update via buster-updates to make it available to users in
advance of 10.12.
> Kind regards,
>
> Christoph
>
> PS: Related, do you check autopkgtest of reverse dependencies as part
> of a stable point release procedure? If not, please consider
> doing
> so - although this time it would not have avoided the situation:
> Of
> the list of packages, only libgit2 has an autopkgtest in buster,
> and it still passes.
We did discuss this on IRC briefly, but for the record - there's a
britney instance that produces "excuses" for p-u and o-p-u, including
scheduling autopkgtests via ci.d.n. The results show up on our tracking
pages and we (mainly Paul; thanks!) investigate any failures raised to
determine if they resulted from the proposed update and, if so, what to
do about that.
Regards,
Adam
Bug#996997: buster-pu: Cleaning up the http-parser ABI breakage in Debian 10 ("buster")
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Folks,
perhaps I should start with an outright confession: When doing
http-parser version 2.8.1-1+deb10u1 for a buster point release,
I messed up things horribly. Nobody noticed in time, it's in stable
now, and all I can do now is bringing things back in order.
# Problem
As described in #996939: The fix for CVE-2019-15605 changed, among
other things, the layout of "struct http_parser", by increasing the
size of the "flag" field and also its position¹ within the struct.
The latter ought not to do harm as the fields affected are marked as
private. But since that is not enforced in C, applications still might
access them.
The size change however is way worse, it caused the following elements,
especially "public" ones like "data" to change their offset.
Subsequently, applications built using the old header file will access
the wrong offset, and possibly segfault. This has been reported for the
tang package in #996460, and I have reason to assume *all* nine²
packages that use http-parser are affected.
# Solutions
After some discussion with Hilko Bengen (Cc:'ed) I can see two ways out
of this:
## Rebuild rdeps
In buster, re-build all packages that were built against http-parser.
So more or less a binNMU, but in a rather unusual area. Tightening the
install dependency to something like "libhttp-parser2.8 (>=
2.8.1-1+deb10u1~)" was nice to have.
Pros:
* If you have a process/automation for that, it should be little work
and therefore the risk of mistakes rather low.
Cons:
* Several packages are affected.
* If this has to be done manually, co-ordination with package
maintainers is needed, yada-yada.
* The ruby-http-parser.rb will FTBFS as mentioned in #989494. My old
patch for unstable should apply. That would be my job.
## Rework the patch
Revert the ABI break by reworking the patch to restore the previous
struct layout - while maintaining the purpose of the change: Storing a
ninth status bit. Hilko Bengen did a great job implementing this, and
also reported success with several tests.
Pros:
* Only http-parser needs an upload.
* External applications (built using Debian but not shipped by Debian)
continue to work. While this is not within our scope, it provides a
good service.
Cons:
* Requires testing on all architectures supported in buster. My job.
* Applications that access private fields still might break. Highly
unlikely to happen, and I have little mercy here.
* Applications and packages built *since* the ABI break will require
a rebuild since technically this is a second ABI break. For Debian,
the intersection with
https://release.debian.org/proposed-updates/oldstable.html
seems to be empty.
## Or ...
Still I am open for other ideas - my main goal is to find a sensible
fix for this issue.
Please advise how to proceed. I would like to see this handled as soon
as possible - knowing users out there encounter problems and will do so
until the next oldstable point release is not quite a pleasant
situation.
Personally I have a slight preference for the second ("rework the
patch") way, but that's not put in stone.
Kind regards,
Christoph
PS: Related, do you check autopkgtest of reverse dependencies as part
of a stable point release procedure? If not, please consider doing
so - although this time it would not have avoided the situation: Of
the list of packages, only libgit2 has an autopkgtest in buster,
and it still passes.
Related (not so) fun fact: Out of curiosity, I backported the
autopkgtest of the tang package locally, and it failed due to the
ABI breakage. Lesson learned: Do more autopkgtests!
¹ See
https://sources.debian.org/src/http-parser/2.8.1-1+deb10u1/debian/patches/1580760635.v2.9.2-2-g7d5c99d.support-multi-coding-transfer-encoding.patch/#L223
and line 228
² Affected packages should be:
cargo
jabberd2
libgit2
libgit-raw-perl
ocserv
python-httptools
ruby-http-parser.rb
sssd
tang
tcpflow
signature.asc
Description: PGP signature
