Bug#1070069: fossil: CVE-2024-24795 unreleated breakage
Well, it would certainly be simple enough: the source code should compile fine, and the debian/* scripts would need only the very most minor tweaks.
Bug#1070069: fossil: CVE-2024-24795 unreleated breakage
Le lundi 29 avril 2024, 18:40:39 UTC Barak A. Pearlmutter a écrit : > Bastien, > > Okay, got it. Thanks for letting me know. > > I can cherry-pick that fossil commit, but you know the right magic for > a versioned apache2 breakage and how to deal with proposed-updates. > So I think it would make sense for you to do all of this in a > coordinated fashion? > If that's okay with you, please feel free to just do a regular upload > if you want, or an NMU, as you please. > I will push your changes into the debian fossil branch, unless you'd > like write access to my fossil packaging repo > https://people.debian.org/~bap/fossil.fsl > which I'd be happy to set up. > > Cheers, > > --Barak. > Thanks for you work, do you think a full backport of fossil is worthwhile for stable ? Bastien signature.asc Description: This is a digitally signed message part.
Bug#1070069: fossil: CVE-2024-24795 unreleated breakage
Le mardi 30 avril 2024, 14:56:07 UTC Barak A. Pearlmutter a écrit : > I've uploaded a package with this fixed to unstable, 1:2.24-5, and > it's been autobuilt and pushed out. Seems to work okay, and can be > co-installed with apache2/sid. > > Just uploaded 1:2.24-6 that adds Breaks: apach2-bin per your recent message. > > Honestly, I'm not confident in my ability to properly back-port > security-related patches to old versions of fossil. It's a big > network-facing program with a large number of moving parts and a > substantial attack surface, all written in C. It uses its own sqlite3 > copy when the shared library in Debian isn't a high enough version or > doesn't have the right options enabled (currently Debian sqlite3 is > compiled without SQLITE_ENABLE_JSON1 so the internal version is used.) > All this means it would be super easy for me to miss some issue and > introduce a vulnerability if I try to back-port a security patch, > > particularly without myself deeply understanding the security issue. > > Stable has 1:2.21-1. > > I just made a debian-bookworm-proposed-updates branch rooted there and > tried to cherry-pick the fix, > https://fossil-scm.org/home/info/f4ffefe708793b03 but it does not > apply cleanly. Obviously I can do it manually though, however there > have been changes in the neighborhood. > > Also, are you *sure* I shouldn't also be applying > https://fossil-scm.org/home/info/71919ad1b542832c to the fixed > versions? Because I'm not! I'd be most comfortable if upstream simply > made a proper release with this fixed (which I bet they'd do upon > request), and I uploaded that with the appropriate "Breaks: > apache2-bin (<<...)", and did the (trivial) backport of that package > to bookworm and bullseye, with the "breaks:" modified to the > appropriate version. I agree with you, may be a fullbackport is better for bookworm see changes here (line with * are interesting commit to backport) Yadd do you have a piece of advice ? Bastien 2024-04-22 *16:29 cgi.md: be less specific about the Apache version in which the Content-Length change happened because a new forum post reports that it happens at least as far back as 2.4.41. ... 2024-04-21 18:51 Merge the update to zLib-1.3.1. ... 18:46 Improvements to comments in graph.c. No changes to actual code. ... *16:20 Fix parsing of the argument to the "Connection:" header of HTTP reply messages to deal with unusual arguments added by Apache mod_cgi. See forum thread ca6fc85c80f4704f. ... *15:37 Simplify parsing of the Connection: header in HTTP replies. ... *06:15 Only accept commas as separators for multiple values in "Connection:" HTTP headers, and ignore any white space surrounding (but not embedded into) values. The previous method would fall for (fictional) HTTP header values containing spaces, like "Connection: don't close", and recognize a value of "close". ... 2024-04-20 21:58 In /chat preview mode, apply the click handlers to pikchrs in the preview. ... *14:42 Fix parsing of "Connection:" HTTP headers with multiple values. ... 2024-04-19 16:08 Fix a minor problem in graph layout for timelines that made use of the offset-merge-riser enhancement. Problem originally seen on the bottom node of /timeline?p=6da255034b30b4b4=47362306a7dd7c6f. ... *13:11 More change-log enhancements: More details about the work-around for the Apache mod_cgi breakage, and put that work-around first on the change log since it seems to be important to people. ... 12:59 Formatting enhancements to the change log for the upcoming 2.24 release. ... 2024-04-18 17:14 Update the built-in SQLite to the latest pre-release of version 3.46.0, including the bug fix for the use of VALUES-as-coroutine with an OUTER JOIN. ... 17:00 Typo fix and add specific Apache version number to the notes about the Content-Length change. ... 2024-04-17 17:59 Change log updates. ... *15:30 • Edit [18d76fff]: Edit check-in comment. ... *14:02 Output a warning if a client sync or clone gets back a keep-alive HTTP reply that lacks a content-length header. ... *13:27 Only process HTTP replies that lack a Content-Length header if the connection is set to be closed. Suggested by https://bz.apache.org/bugzilla/show_bug.cgi?id=68905. ... *13:21 Update the change log in order to mention the Apache mod_cgi/Content-Length fix. ... *13:14 Update Apache mod_cgi/Content-Length documentation. ... *12:58 Fix the HTTP-reply parser so that it is able to deal with replies that lack a Content-Length header field. This resolves the issue reported by forum post 12ac403fd29cfc89. Also in this merge: (1) Add the --xverbose option to "fossil clone". (2) Improved error messages when web
Bug#1070069: fossil: CVE-2024-24795 unreleated breakage
Le mardi 30 avril 2024, 14:56:07 UTC Barak A. Pearlmutter a écrit : > currently Debian sqlite3 is > compiled without SQLITE_ENABLE_JSON1 so the internal version is used.) On this proble could you cross check ? >SQLITE_ENABLE_JSON1 > >This compile-time option is a no-op. Prior to SQLite version 3.38.0 > (2022-02-22), it was necessary to compile with this option in order to > include the JSON SQL functions in the build. However, beginning with SQLite > version 3.38.0, those functions are included by default. Use the > -DSQLITE_OMIT_JSON option to omit them. If so you could drop for bookworm (if release team is ok) and sid this embeded code copy BTW I have just opened a bug and add some comment on embded code copy Bastien signature.asc Description: This is a digitally signed message part.
Bug#1070069: fossil: CVE-2024-24795 unreleated breakage
I've uploaded a package with this fixed to unstable, 1:2.24-5, and it's been autobuilt and pushed out. Seems to work okay, and can be co-installed with apache2/sid. Just uploaded 1:2.24-6 that adds Breaks: apach2-bin per your recent message. Honestly, I'm not confident in my ability to properly back-port security-related patches to old versions of fossil. It's a big network-facing program with a large number of moving parts and a substantial attack surface, all written in C. It uses its own sqlite3 copy when the shared library in Debian isn't a high enough version or doesn't have the right options enabled (currently Debian sqlite3 is compiled without SQLITE_ENABLE_JSON1 so the internal version is used.) All this means it would be super easy for me to miss some issue and introduce a vulnerability if I try to back-port a security patch, particularly without myself deeply understanding the security issue. Stable has 1:2.21-1. I just made a debian-bookworm-proposed-updates branch rooted there and tried to cherry-pick the fix, https://fossil-scm.org/home/info/f4ffefe708793b03 but it does not apply cleanly. Obviously I can do it manually though, however there have been changes in the neighborhood. Also, are you *sure* I shouldn't also be applying https://fossil-scm.org/home/info/71919ad1b542832c to the fixed versions? Because I'm not! I'd be most comfortable if upstream simply made a proper release with this fixed (which I bet they'd do upon request), and I uploaded that with the appropriate "Breaks: apache2-bin (<<...)", and did the (trivial) backport of that package to bookworm and bullseye, with the "breaks:" modified to the appropriate version.
Bug#1070069: fossil: CVE-2024-24795 unreleated breakage
Le lundi 29 avril 2024, 18:40:39 UTC Barak A. Pearlmutter a écrit : > Bastien, > > Okay, got it. Thanks for letting me know. > > I can cherry-pick that fossil commit, but you know the right magic for > a versioned apache2 breakage and how to deal with proposed-updates. > So I think it would make sense for you to do all of this in a > coordinated fashion? > If that's okay with you, please feel free to just do a regular upload > if you want, or an NMU, as you please. > I will push your changes into the debian fossil branch, unless you'd > like write access to my fossil packaging repo > https://people.debian.org/~bap/fossil.fsl > which I'd be happy to set up. Hi I give up for fossil patches (i am not fossil fluent) The bookworm version will need: - to add the patch - Breaks against apache2-bin ( 2.4.59-1~) The bullseye version will need: - to add the patch - Breaks against apache2-bin ( 2.4.59-1~) We have done a full backport of apache due to several bug BTW I suppose that sid version should for extra safety break against apache2-bin ( 2.4.59-1~) instead of apache2 You should begin and apache2 will follow ASAP Bastien For buster I will reprod you when done, > > Cheers, > > --Barak. > signature.asc Description: This is a digitally signed message part.
Bug#1070069: fossil: CVE-2024-24795 unreleated breakage
uploaded
Bug#1070069: fossil: CVE-2024-24795 unreleated breakage
will do
Bug#1070069: fossil: CVE-2024-24795 unreleated breakage
Le lundi 29 avril 2024, 18:40:39 UTC Barak A. Pearlmutter a écrit : > Bastien, > > Okay, got it. Thanks for letting me know. > > I can cherry-pick that fossil commit, but you know the right magic for > a versioned apache2 breakage and how to deal with proposed-updates. > So I think it would make sense for you to do all of this in a > coordinated fashion? Yes except for unstable where you could go without coordination Fixed apache is 2.4.59-1 So I think a breaks: apache2 (<<2.4.59-1~) is safe on your side (transition will be blocked) When done I will upload a apache2 version with breaks: fossil ( << 2.4.59-2~) I will do the bpu when done with release team Bastien > If that's okay with you, please feel free to just do a regular upload > if you want, or an NMU, as you please. > I will push your changes into the debian fossil branch, unless you'd > like write access to my fossil packaging repo > https://people.debian.org/~bap/fossil.fsl > which I'd be happy to set up. > > Cheers, > > --Barak. > signature.asc Description: This is a digitally signed message part.
Bug#1070069: fossil: CVE-2024-24795 unreleated breakage
Bastien, Okay, got it. Thanks for letting me know. I can cherry-pick that fossil commit, but you know the right magic for a versioned apache2 breakage and how to deal with proposed-updates. So I think it would make sense for you to do all of this in a coordinated fashion? If that's okay with you, please feel free to just do a regular upload if you want, or an NMU, as you please. I will push your changes into the debian fossil branch, unless you'd like write access to my fossil packaging repo https://people.debian.org/~bap/fossil.fsl which I'd be happy to set up. Cheers, --Barak.
Bug#1070069: fossil: CVE-2024-24795 unreleated breakage
Package: fossil Severity: serious Justification: break unreleated package affects: apache2 Dear Maintainer, CVE-2024-24795 is fixed in apache2. However it break fossil You need to apply https://fossil-scm.org/home/info/f4ffefe708793b03 See bug here: https://bz.apache.org/bugzilla/show_bug.cgi?id=68905 I can help here and do proposed update We also need to use breaks relationship in apache2, in order to allow smooth upgrade Bastien signature.asc Description: This is a digitally signed message part.
