Re: gunicorn and CVE-2024-1135
On Wed, Jul 17, 2024 at 04:08:34AM +, jgart wrote: > I provided gunicorn-next in a recent commit to master which fixes > CVE-2024-1135 but I don't have time at the moment to fix the bad gunicorn's > dependents* against gunicorn-next. I'm not sure I understand the question. Gunicorn-next contains the CVE fix, but gunicorn does not? Is that correct?
Re: [PATCH Cuirass 1/4] specification: Ensure name is a symbol.
Hi, On Mon, 17 Jun 2024 at 15:16, Ludovic Courtès wrote: > statically-typed language programmers would be > right to laugh at us here, I admit Nah because the new feature is really nice! :-) Thanks. But it remembers me one of our first in-person discussion back then on December 2018… My 6-years patience is paying off. ;-) Cheers, simon
Re: Reducing "You found a bug" reports
Hi, On Mon, 17 Jun 2024 at 14:59, Ludovic Courtès wrote: >> It doesn’t feel great to tell users to report a bug for things that >> aren’t bugs. They’re either closed, or never followed up on; it’s a >> poor experience on both ends. > > I agree, it’s pretty bad. > > I’m fine removing the “report a bug” message, maybe replacing it with > some clearer diagnostic and suggestion? WDYT? Could we detect if it comes from networking? Somehow catch the error and run some code that checks stuff and so report more “accurate” messages? Well, easier to say… :-) Cheers, simon
Re: Question about changing versioning for TeX Live packages
Hi Nicolas, Sorry if this had been answered elsewhere, I have missed it. On Sat, 15 Jun 2024 at 19:07, Nicolas Goaziou via "Development of GNU Guix and the GNU System distribution." wrote: > I'd like to change versioning for TeX Live packages. Currently, it > refers to a revision number in the upstream SVN repository, such as > 70951. > > I'd rather use tags from TeX Live releases, e.g., "2023.0", for at least > two reasons: > > 1. We don't need a granularity to the revision level for TeX Live >packages; > 2. Revision numbers are not very user-friendly, while tags are. > > In a nutshell, my plan is to change version for all packages from > (revision) 66594 to the equivalent tag "2023.0". Unfortunately, as > mathematics go, 2023 is lesser than 66594. As a consequence, this may > introduce trouble when upgrading those packages. Therefore, my question > is the following: how could I proceed to make this version change as > smooth as possible for end-users? Well, if I read correctly, there is: guix/build-system/texlive.scm: (define %texlive-tag "texlive-2023.0") (define %texlive-revision 66594) gnu/packages/texlive.scm: (define %texlive-date "20230313") (define %texlive-year (string-take %texlive-date 4)) And the issue seems: (define-public texlive (package (name "texlive") (version %texlive-date) and (define-public texlive-scripts (package (name "texlive-scripts") (version (number->string %texlive-revision)) Therefore, indeed it will be complicated to replace the ’version’ of ’texlive-scripts’ by something as ’2023’. But why not a ’version’ as something as ’texlive’? Or just 2023XY? Where XY is something to determine as the month or something else. Are we speaking a change only for the package field ’version’? Or is the discussion also about replacing the way to fetch from upstream? Cheers, simon
Re: gunicorn and CVE-2024-1135
> I'm not sure I understand the question. Gunicorn-next contains the CVE > > fix, but gunicorn does not? Is that correct? Yep, that is correct. gunicorn does not contain the fix and gunicorn-next does contain the fix.
Re: gunicorn and CVE-2024-1135
On Wed, Jul 17, 2024 at 09:21:53PM +, jgart wrote: > > I'm not sure I understand the question. Gunicorn-next contains the CVE > > > > fix, but gunicorn does not? Is that correct? > > Yep, that is correct. gunicorn does not contain the fix and gunicorn-next > does contain the fix. Okay. Is there a reason to create gunicorn-next rather than updating gunicorn? We can't simply remove gunicorn without also removing the packages that depend on it, or making it so that those packages do not depend on it. Otherwise, Guix will not build, and we won't have successfully mitigated the vulnerability for our users.
Re: gunicorn and CVE-2024-1135
> Okay. Is there a reason to create gunicorn-next rather than updating > > gunicorn? Hi Leo, Yes, time. Updating the packages that depend on that bad gunicorn will take time which I don't have at the moment to fix them, unfortunately. I might not be able to get to updating all those packages until maybe up to 2 or more weeks from now depending on how busy I am. > Otherwise, Guix will not build, and we won't have successfully mitigated > > the vulnerability for our users. Yep, I just made the gunicorn-next package available for anyone that wants to use it but it's not integrated into the dependents as listed by `guix refresh -l gunicorn@20.1.0`. It is standalone. If anyone would like to work on it before I am able to get to it feel free. I just thought I'd let people know here in case it is higher priority for anyone else. all best, jgart
Guix in the News
Hi everyone, Here is an article from LWN that mentions Guix (without GNU): https://lwn.net/SubscriberLink/981124/9284136ea244d238/ Kind regards Felix
