Re: License of your contributions to the blog at guix.gnu.org

On Sat, 2022-02-05 at 14:47 +0100, Ludovic Courtès wrote: > Hello, > > I am emailing you on behalf of the GNU Guix project because you are > the > author or coauthor of one or more articles to the blog at > . > > With a few exceptions, these articles do not have a

Re: Leaving the GNU Guix community

Hello Tobias, On Sat, 2021-05-01 at 04:34 +0200, Tobias Geerinckx-Rice wrote: > Léo, > > Leo Le Bouter 写道： > > I feel like what has happened is really a disaster, > > I'm relieved that we share, at least, this.  I think everyone > does. > > > I don't feel like contributing to GNU Guix anymore

Re: A "cosmetic changes" commit that removes security fixes

On Thu, 2021-04-29 at 13:46 +0200, Leo Prikler wrote: > Am Donnerstag, den 29.04.2021, 11:13 +0200 schrieb Léo Le Bouter: > > On Wed, 2021-04-28 at 17:52 +0200, Marius Bakke wrote: > > > Léo, > > > > > > We maintainers have been disappointed by Marks harsh tone

Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

On Wed, 2021-04-28 at 12:43 -0400, Mark H Weaver wrote: > I'm sorry if this comes off as obtuse, but having now re-read all of > my > messages in this thread, I honestly do not see what I did wrong here. > I will need some help to understand. > > With very few exceptions, almost every sentence

Re: A "cosmetic changes" commit that removes security fixes

On Wed, 2021-04-28 at 17:52 +0200, Marius Bakke wrote: > Léo, > > We maintainers have been disappointed by Marks harsh tone which do > not > meet the project's communication standards, but also by your apparent > lack of will to reply constructively to legitimate criticism. > > This is the next

Re: A "cosmetic changes" commit that removes security fixes

On Fri, 2021-04-23 at 15:18 -0400, Leo Famulari wrote: > I have to agree with everybody in this thead. > > The commits in question were problematic (especially on core-updates, > which is not a "WIP" branch and thus cannot be rewritten to fix past > problems). I'm not confident that the security

Re: A "cosmetic changes" commit that removes security fixes

On Mon, 2021-04-26 at 17:23 +0200, Tobias Geerinckx-Rice wrote: > Hi Léo, > > > https://git.sr.ht/~lle-bout/guix/commit/a045a48dd961f0c5c3d536dcc3fd21d9c08d2d50 > > https://git.sr.ht/~lle-bout/guix/commit/6477daa338fbf1c9edacfc3690aca77cacfe0008 > > > > Can you please explain what went wrong

Re: A "cosmetic changes" commit that removes security fixes

On Sat, 2021-04-24 at 03:46 -0400, Mark H Weaver wrote: > Hi Léo, > > Léo Le Bouter writes: > > > On Fri, 2021-04-23 at 15:18 -0400, Leo Famulari wrote: > > > Léo and Raghav, you need to keep learning our workflow around > > > security updates. It's

Re: A "cosmetic changes" commit that removes security fixes

On Fri, 2021-04-23 at 15:18 -0400, Leo Famulari wrote: > Léo and Raghav, you need to keep learning our workflow around > security > updates. It's not okay to remove security patches and later update a > package to a fixed version in a different commit. `git rebase` is the > tool to learn for

Re: A "cosmetic changes" commit that removes security fixes

On Fri, 2021-04-23 at 13:52 -0400, Maxim Cournoyer wrote: > Actually, there *is* a "new" stable release available on their > release > page, 1.17.2 [0] > > According to NVD [1], that latest version has no known CVE [1]. > > Léo, could it be that you had planned to do this update, but it >

Re: Another misleading commit log (was Re: A "cosmetic changes" commit that removes security fixes)

On Thu, 2021-04-22 at 13:40 -0400, Mark H Weaver wrote: > This commit was digitally signed and pushed to the 'wip-gnome' branch > by > Raghav, but it's also "Signed-off-by: Léo Le Bouter", so I'm not sure > who bears primary responsibility for this one. It seems you are

Re: A "cosmetic changes" commit that removes security fixes

On Thu, 2021-04-22 at 00:08 -0400, Mark H Weaver wrote: > Hi Raghav, > > Raghav Gururajan writes: > > > > Those commits on 'core-updates' were digitally signed by Léo Le > > > Bouter > > > and have the same problems: they remove > > > security

bug#47631: Add graphical installation and solve tons of headache

On Thu, 2021-04-15 at 10:00 +, bo0od wrote: > Guix need to improve itself when first time initiated, Please check > other projects like NixOS,Triskel,Mint,Ubuntu...etc > > > If you dont like that live graphical gui access, then do it as debian > is > doing it which give you proper gui

Re: Running shepherd as user: incompatible bytecode version

On Fri, 2021-04-16 at 00:39 +0900, elaexuo...@wilsonb.com wrote: > Hey Guix, > > Reading https://guix.gnu.org/en/blog/2020/gnu-shepherd-user-services/ > , I was > inspired to start trying this out on my own. However, I immediately > ran into > this huge mess: > > $ shepherd > ... >

Re: Please review blog post draft: powerpc64le-linux support

On Mon, 2021-04-12 at 12:46 -0700, Chris Marusich wrote: > Hi, > > Chris Marusich writes: > > > This is the final draft, I think. I intend to commit it to the > > "posts" > > directory in guix-artwork on Monday morning, USA time, at which > > point I > > believe it will automatically show up

bug#47627: syncthing package is vulnerable to CVE-2021-21404

On Thu, 2021-04-08 at 20:01 -0400, Leo Famulari wrote: > On Tue, Apr 06, 2021 at 06:51:47PM -0400, Leo Famulari wrote: > > Yeah. Given this report, we could also just build Syncthing with > > the > > bundled source code, which is freely licensed. > > I've attached the patch. I tested this patch

Re: Please help reviewing CVE entries

On Fri, 2021-04-09 at 15:25 +0200, Nicolò Balzarotti wrote: > Léo Le Bouter writes: > > > Hello! > > Hi! > > I have been feeling considerable amount of stress reviewing CVE > > entries > > alone, these days I want to focus on other things and I've been

Please help reviewing CVE entries

Hello! I have been feeling considerable amount of stress reviewing CVE entries alone, these days I want to focus on other things and I've been feeling held back because I abandonned the CVE entries reviewing task without anyone doing it when I'm not here. Right now at time of sending this email,

Re: Semi-automated patch review

On Wed, 2021-04-07 at 17:00 +0200, Andreas Enge wrote: > posting messages to the issues looks like a feasible and good thing > to me, > then all relevant information would be present in the same place. I also think that's what should be done but it seems there are worries that this may cause

bug#47140: libupnp package vulnerable to CVE-2021-28302

Fixed by 2b605ef3b145ec136530f08ee7aa27382aa64b46 signature.asc Description: This is a digitally signed message part

Re: Please review blog post draft: powerpc64le-linux support

On Thu, 2021-04-08 at 09:37 -0700, Chris Marusich wrote: > They also say in that Twitter thread: "We have been putting together > our > systems from blob-free components only (sans NIC as is known and > being > actively worked), and this is an area where no low-cost blob-free > silicon is

Re: Please review blog post draft: powerpc64le-linux support

On Tue, 2021-04-06 at 00:15 -0700, Chris Marusich wrote: > Hi, > > Léo and I have drafted the following blog post. Could you take a few > minutes to read it and give us your thoughts? > > It's a work in progress. The primary goal is to announce the new > powerpc64le-linux support and explain

Re: guix home: Call for Early Adopters

On Tue, 2021-04-06 at 20:21 +0300, Andrew Tropin wrote: > Guix Home has most essential features ready and now requires some > real-world usage from a few more people to be sure that there are no > fundamental issues with it. > > We are looking for 3-5 advanced GNU/Linux users (not necessary

bug#47627: syncthing package is vulnerable to CVE-2021-21404

CVE-2021-21404 06.04.21 22:15 Syncthing is a continuous file synchronization program. In Syncthing before version 1.15.0, the relay server `strelaysrv` can be caused to crash and exit by sending a relay message with a negative length field. Similarly, Syncthing itself can crash for the same

bug#47614: [security] Chunked store references in .zo files in Racket 8

On Tue, 2021-04-06 at 17:27 -0400, Mark H Weaver wrote: > Hi Léo, > > Léo Le Bouter writes: > > > I think that probably replacing arbitrary paths in built binaries > > is a > > risky and maybe unreliable engineering choice and that mechanisms > > inside

bug#47624: Various IP handling perl packages may be vulnerable

Read: https://blog.urth.org/2021/03/29/security-issues-in-perl-ip-address-distros/ I have not had time to investigate deeply, posting here so the info is not lost. I have already fixed one issue related to perl-data-validate- ip in 8ec03ed5475ca7919a7d11541ff8cbf33a9ffe67, but it seems there's

bug#47614: [security] Chunked store references in .zo files in Racket 8

I think that probably replacing arbitrary paths in built binaries is a risky and maybe unreliable engineering choice and that mechanisms inside kernels should be preferred to give processes a different view of the file system (retaining the path but changing the contents of the folder). OTOH,

bug#47622: vigra package is vulnerable to CVE-2021-30046

CVE-2021-30046 15:15 VIGRA Computer Vision Library Version-1-11-1 contains a segmentation fault vulnerability in the impex.hxx read_image_band() function, in which a crafted file can cause a denial of service. Upstream issue: https://github.com/ukoethe/vigra/issues/494 No fix provided yet.

bug#47222: Serious bug in Nettle's ecdsa_verify

I am no expert cryptographer, it is likely that if I try backporting such patches I will get something wrong that introduces more flaws. https://security-tracker.debian.org/tracker/CVE-2021-20305 - no patch backported yet https://packages.ubuntu.com/source/focal/nettle - no patch backported

Re: Document our WIP

On Wed, 2021-03-31 at 14:16 -0400, Leo Famulari wrote: > > Yeah, I agree that it's hard to learn about "what's cooking" when you > first arrive at the mailing lists. > > It's true that wikis tend to get out of date, but I think that it > won't > be too bad for this use case. At least, it won't

Semi-automated patch review

Hello! Cbaines already runs automated patch testing infra at https://data.guix-patches.cbaines.net/ and https://patches.guix-patches.cbaines.net/project/guix-patches/list/ Considering that posting robot messages with test/lint/+ result information on the issues directly and on the ML might get

bug#47143: pjproject package is vulnerable to CVE-2021-21375 and CVE-2020-15260

upstream released 2.11 which fixed the issue. Update to 2.11 pushed as 45136b3673bcdba21fa0d1fd6edb3d388a645fcc signature.asc Description: This is a digitally signed message part

bug#47140: libupnp package vulnerable to CVE-2021-28302

Upstream created and merged a probable patch: https://github.com/pupnp/pupnp/pull/306 Reporter still needs to confirm if it fixes the issue. signature.asc Description: This is a digitally signed message part

bug#47142: squid package vulnerable to CVE-2021-28116

Still no fix available from upstream (unclear) signature.asc Description: This is a digitally signed message part

bug#47260: Package GNU MediaGoblin as a Guix service

On Tue, 2021-04-06 at 00:17 +1000, Ben Sturmfels wrote: > On Thu, 01 Apr 2021, Ben Sturmfels wrote: > > > 7. Work out why H264 support is missing. > > This is now fixed MediaGoblin's master branch guix-env.scm by adding > gst-libav to propagated inputs. Hello! I suggest not using

bug#47141: Zabbix packages vulnerable to CVE-2021-27927

Fixed in dda88cda120d75f7d139e54367c0d76e574091dc signature.asc Description: This is a digitally signed message part

bug#47587: 'guix system edit' subcommand

Hello! Like 'guix edit hello' we could have 'guix system edit screen-locker' for easy access to customize services. What do you think? Is this hard to do? Léo signature.asc Description: This is a digitally signed message part

bug#47573: make check-system fails on master

It seems running 'make clean' then 'make check-system' again solved the issue. Probably some build system inconsistency issue. signature.asc Description: This is a digitally signed message part

Re: Secure GNU Guix offloading

On Tue, 2021-03-30 at 10:26 +0200, Ludovic Courtès wrote: > Hi! > > Léo Le Bouter skribis: > > > I don't want to give more access than what SSH non-root access > > would > > give, and I think it would be possible to do something helpful in > > GNU > > G

Re: Rust and parametric packages

On Sat, 2021-04-03 at 17:47 +0200, Hartmut Goebel wrote: > Am 17.03.21 um 19:23 schrieb Léo Le Bouter: > > I advise you look there also: > > https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/rlib-intermediate-object-reuse/near/225653640 > > Ac

Re: Security related tooling project

On Sat, 2021-04-03 at 11:41 +0100, Christopher Baines wrote: > Hey, > > In May last year (2020), I submitted an application to NLNet. The > work I > set out wasn't something I was doing at the time, but something I > hadn't > yet found time to work on, tooling specifically around security >

bug#47573: make check-system fails on master

Hello! $ ./pre-inst-env guix describe Git checkout: repository: /home/lle-bout/src/guix branch: master commit: 8d89d3c9bf7cacd9c79b4aacf348044d4fe7800b $ make check-system Compiling Scheme modules... ice-9/eval.scm:142:16: In procedure compile-top-call: error: channel-source->package:

Re: Application for aarch64 computing resources

On Fri, 2021-04-02 at 16:25 -0400, Leo Famulari wrote: > I will keep this in mind, pending their reply. > > The ticket system automatically added the tag 'hardware/ampere- > altra'. > So, it may be a case of "we can have any CPU we want, as long as it's > an > Ampere ALTRA"... as Henry Ford said,

bug#47563: [PATCH v2] gnu: curl: Update to 7.76.0 [security fixes].

To me, that last patch is ready to merge. Please push if you feel that's OK too, don't wait for me! Thanks! signature.asc Description: This is a digitally signed message part

bug#47563: [PATCH v2] gnu: curl: Update to 7.76.0 [security fixes].

Fixes CVE-2021-22876 and CVE-2021-22890. * gnu/packages/patches/curl-7.76-use-ssl-cert-env.patch: New patch. * gnu/local.mk (dist_patch_DATA): Register it. * gnu/packages/curl.scm (curl/fixed): New variable. Apply patch. (curl)[replacement]: Graft. --- gnu/local.mk

bug#47563: [PATCH] gnu: curl: Update to 7.76.0 [security fixes].

Fixes CVE-2021-22876 and CVE-2021-22890. * gnu/packages/patches/curl-7.76-use-ssl-cert-env.patch: New patch. * gnu/local.mk (dist_patch_DATA): Register it. * gnu/packages/curl.scm (curl/fixed): New variable. Apply patch. (curl)[replacement]: Graft. --- gnu/local.mk

bug#47563: [PATCH 0/1] gnu: curl: Fix CVE-2021-22876 and CVE-2021-22890.

On Fri, 2021-04-02 at 14:22 -0400, Leo Famulari wrote: > > Can we try grafting an "upgrade" to 7.76.0? In my experience, most > curl > upgrades are graftable. > > Curl's developers are very careful with their ABI and even maintain > their own page on the subject:

Re: Document our WIP

On Thu, 2021-04-01 at 21:33 +, Luis Felipe wrote: > I just sent a patch to include a link to the wiki in the Help page ( > https://issues.guix.gnu.org/47555). > > If the patch is applied, I can send a separate patch to update the > Help menu as Vincent suggested: > > Help > • GNU Guix Manual

bug#47563: [PATCH 1/1] gnu: curl: Fix CVE-2021-22876 and CVE-2021-22890.

* gnu/packages/patches/curl-CVE-2021-22876.patch, gnu/packages/patches/curl-CVE-2021-22890.patch: New patches. * gnu/local.mk (dist_patch_DATA): Register them. * gnu/packages/curl.scm (curl): Apply patches. --- gnu/local.mk | 2 + gnu/packages/curl.scm

bug#47563: [PATCH 0/1] gnu: curl: Fix CVE-2021-22876 and CVE-2021-22890.

/commit/?h=core-updates=2e0b1b62e94b926041ca9af70537dd9b3ab64edf but unfortunately since curl requires so many rebuilds it seems we can't use such commit on master for now. Léo Le Bouter (1): gnu: curl: Fix CVE-2021-22876 and CVE-2021-22890. gnu/local.mk | 2

bug#47563: curl is vulnerable to CVE-2021-22890 and CVE-2021-22876

CVE-2021-22890 01.04.21 20:15 curl 7.63.0 to and including 7.75.0 includes vulnerability that allows a malicious HTTPS proxy to MITM a connection due to bad handling of TLS 1.3 session tickets. When using a HTTPS proxy and TLS 1.3, libcurl can confuse session tickets arriving from the HTTPS proxy

bug#47562: java-eclipse-jetty-* packages are vulnerable to CVE-2021-28165, CVE-2021-28164 and CVE-2021-28163 (also probably MANY others, 4y w/o upgrade)

CVE-2021-28165 01.04.21 17:15 In Eclipse Jetty 7.2.2 to 9.4.38, 10.0.0.alpha0 to 10.0.1, and 11.0.0.alpha0 to 11.0.1, CPU usage can reach 100% upon receiving a large invalid TLS frame. CVE-2021-28164 01.04.21 17:15 In Eclipse Jetty 9.4.37.v20210219 to 9.4.38.v20210224, the default compliance

bug#47509: OpenEXR may be vulnerable to CVE-2021-3474, CVE-2021-3476 and CVE-2021-3475

Another: CVE-2021-20296 01.04.21 16:15 A flaw was found in OpenEXR in versions before 3.0.0-beta. A crafted input file supplied by an attacker, that is processed by the Dwa decompression functionality of OpenEXR's IlmImf library, could cause a NULL pointer dereference. The highest threat from

Re: Security patching and the branching workflow: a new security-updates branch

Sorry for duplicated email, On Thu, 2021-04-01 at 16:58 +0200, Ricardo Wurmus wrote: > I don’t think we should have a security-updates > branch, because the role of that branch is effectively taken by > staging. I don't think that's the case because staging is documented for things that do not

Re: Security patching and the branching workflow: a new security-updates branch

On Thu, 2021-04-01 at 16:58 +0200, Ricardo Wurmus wrote: > Hi Léo, > [...] > That’s fine. We have no deadlines, so stepping back from what feels > like a heated discussion for a while and revisiting the points later > comes at very little cost. > > Obviously, you don’t *have* to accept other

bug#47544: rust-slice-deque is vulnerable to CVE-2021-29938

CVE-2021-29938 07:15 An issue was discovered in the slice-deque crate through 2021-02-19 for Rust. A double drop can occur in SliceDeque::drain_filter upon a panic in a predicate function. Upstream PR: https://github.com/gnzlbg/slice_deque/pull/91 I suggest we wait for merge then update our

bug#47542: rust-stackvector package is vulnerable to CVE-2021-29939

CVE-2021-29939 07:15 An issue was discovered in the stackvector crate through 2021-02-19 for Rust. There is an out-of-bounds write in StackVec::extend if size_hint provides certain anomalous data. No fix released upstream yet: https://github.com/Alexhuszagh/rust-stackvector/issues/2 Out of

bug#47509: OpenEXR may be vulnerable to CVE-2021-3474, CVE-2021-3476 and CVE-2021-3475

Another wave it seems: CVE-2021-3479 31.03.21 16:15 There's a flaw in OpenEXR's Scanline API functionality in versions before 3.0.0-beta. An attacker who is able to submit a crafted file to be processed by OpenEXR could trigger excessive consumption of memory, resulting in an impact to

Re: Security patching and the branching workflow: a new security-updates branch

Hello Ludo, On Wed, 2021-03-31 at 23:29 +0200, Ludovic Courtès wrote: > It’s unacceptable to call someone “obsessed” just because you > disagree > and calling Simon’s comments “harassment” is equally inappropriate. I really do feel harassed by their comments, it's not just because I disagree,

Re: Document our WIP

On Tue, 2021-03-30 at 12:37 +0200, Ludovic Courtès wrote: > To me, a good way to make sure work remains “in progress” is to post > regular updates to this list, and then to write blog posts for the > web > site whenever an important milestone is reached. > > I think a web page is likely to

Re: GNOME 40 work should be done on Savannah

On Tue, 2021-03-30 at 21:55 -0400, Mark H Weaver wrote: > I'm sorry if that happened. It was not my intent. Can you show me > what > I wrote that misrepresents your position? I don't have the energy now I feel already bad enough this discussion even happened, in a way that even Ludo, the

bug#47510: cflow is vulnerable to CVE-2019-16165 and CVE-2019-16166

I asked the maintainer to fix the issues because they were unfixed since a while, they have done so recently: https://git.savannah.gnu.org/cgit/cflow.git/commit/?id=b9a7cd5e9d4efb54141dd0d11c319bb97a4600c6 They have not made a recently, also it seems they fixed other issues that could be

bug#47509: OpenEXR may be vulnerable to CVE-2021-3474, CVE-2021-3476 and CVE-2021-3475

CVE-2021-3474 30.03.21 20:15 There's a flaw in OpenEXR in versions before 3.0.0-beta. A crafted input file that is processed by OpenEXR could cause a shift overflow in the FastHufDecoder, potentially leading to problems with application availability. Fix:

Re: GNOME 40 work should be done on Savannah

On Tue, 2021-03-30 at 14:12 +0200, Ludovic Courtès wrote: > > I don't feel like people should be barred to contribute to that > > GNOME > > 40 upgrade because they arent an approved committer. That doesnt > > feel > > inclusive to me. > > I respectfully think you misunderstand the review process.

Re: GNOME 40 work should be done on Savannah

On Tue, 2021-03-30 at 14:12 +0200, Ludovic Courtès wrote: > I respectfully think you misunderstand the review process. Review is > about sharing responsibilities and reducing the likelihood of > mistakes. > > It’s crucial from many different perspectives: security-wise, > socially > (the process

Re: Security patching and the branching workflow: a new security-updates branch

On Tue, 2021-03-30 at 13:48 +0200, zimoun wrote: > Ahah, I am happy to know it. I hope it is because a > “miscommunication» > and not because you do not carefully read or because maybe you only > see > through the tiny lens of known security vulnerabilities. From my > opinion, your point of view

Re: GNOME 40 work should be done on Savannah (was: Re: GNOME 40)

On Tue, 2021-03-30 at 02:41 -0400, Mark H Weaver wrote: > Sorry, but that's simply false. You _do_ have a choice. You can do > what we've been doing in the Guix community for years: as a > committer, > _you_ can commit the work of non-committers on their behalf. If not > you, then any of the

Re: Release 1.2.1: zstd 1.4.4 -> 1.4.9: grafting or core-updates?

For reference, crossposting: I pushed 00c67375b17f4a4cfad53399d1918f2e7eba2c7d to core-updates. Your patch. Thank you for it. Let's watch for upstream zstd fix also. I pushed 9feef62b73e284e106717a386624d6da90750a3d to master. Ubuntu released a patch in the mean time, so while we couldnt make

bug#47257: mariadb is vulnerable to CVE-2021-27928 (RCE)

Hello! Simon, I pushed 00c67375b17f4a4cfad53399d1918f2e7eba2c7d to core-updates. Your patch. Thank you for it. Let's watch for upstream zstd fix also. I pushed 9feef62b73e284e106717a386624d6da90750a3d to master. Ubuntu released a patch in the mean time, so while we couldnt make such patch in a

Re: GNOME 40 work should be done on Savannah (was: Re: GNOME 40)

Hello! On Mon, 2021-03-29 at 19:02 -0400, Mark H Weaver wrote: > This sounds theoretical. Concretely, what needs do you have that > aren't > being met by Savannah? Per-branch access control > I don't understand this. It seems to me the opposite. > > If I want to contribute to this external

Re: GNOME 40

On Sun, 2021-03-28 at 16:48 -0400, Mark H Weaver wrote: > How is it more flexible than a "wip-*" branch on Savannah? > > Thanks, >Mark Because as the GNU Guix project we have no control on the forge to catter it to our own needs, because there is bureaucracy involved with approving

bug#47375: guix test failure: tests/print

On Sun, 2021-03-28 at 18:25 +0200, Ludovic Courtès wrote: > When updating the ‘guix’ package, what you need to run is: > > ./pre-inst-env guix build guix > > It’s similar to other packages. > > In general, we update it when there are changes to the daemon and its > helper programs (‘guix

Re: GNOME 40

If anyone is curious of the work or wants to participate, we are working there: https://git.guix-patches.cbaines.net/guix-patches/log/?h=wip-gnome-40 The branch is based on core-updates and we will rebase it every now and then, as well as merging patches to official core-updates as we feel it is

Re: Document our WIP

On Sat, 2021-03-27 at 16:42 +, Luis Felipe wrote: > I'm fine with that too (for now). I can send that patch. > > The reason I didn't suggest that, though, is that the primary menu > has already grown too big in my opinion. And, with the current > design, the visibility of the primary menu

Re: Document our WIP

On Sat, 2021-03-27 at 15:54 +, Luis Felipe wrote: > Or that, yes. I can send a patch to add a Wiki entry to the Help page > instead of adding a "Wiki" item to the "About" menu. I think we should be looking forward to including it in the primary menu and not hidden in some submenu.

Re: Document our WIP

On Sat, 2021-03-27 at 16:41 +0100, Vincent Legoll wrote: > I don't know if libreplanet's wiki meets Léo's requirements, > but this is probably OK from a PoV of spam management. I could create an FSF account with automated approval by email. It seems I cannot create new pages, however it seems we

Re: Document our WIP

On Sat, 2021-03-27 at 15:44 +, Luis Felipe wrote: > What do you think about adding a "Wiki" item to the "About" menu of > the website linking to that Guix group on LibrePlanet? At least as a > quick solution to try out. I think this would be the best thing to do, however I don't know if I can

Re: Document our WIP

On Sat, 2021-03-27 at 11:32 -0400, Joshua Branson wrote: > Good point. Perhaps we should link to this wiki from the guix > website? I think that we should do that for this wiki resource to be really useful. Widespread knowledge of the location is a must. signature.asc Description: This is a

Re: Cuirass not processing core-updates (or weirdly)

On Sat, 2021-03-27 at 04:24 +0100, Léo Le Bouter wrote: > Hello! > > If you look at https://ci.guix.gnu.org/eval/13652 you can see that > the > evaluation of the derivation seems completed but there's no pending > builds. > > What is happening here? > > Thank you

Re: Document our WIP

On Sat, 2021-03-27 at 11:07 +0100, Vincent Legoll wrote: > Hello, > > I'd like to reiterate my proposal to document our > ongoing projects, maybe with a "WIP" page on the > web site (even if I'm not a web guy, I volunteer > the maintenance of it). > > * CI-built pinebook-pro images [1] > * other

Re: Security patching and the branching workflow: a new security-updates branch

On Sat, 2021-03-27 at 14:56 +0100, zimoun wrote: > Oh, I am a big boy and I can think whatever I want! :-) > > Kidding aside. ... > > First, what does it mean «risk»? How do you evaluate it? Is it a > relative evaluation or an absolute one? Most if not all users do not want their machines

bug#47418: [PATCH] gnu: imagemagick: Fix CVE-2020-27829.

On Sat, 2021-03-27 at 09:27 -0400, Mark H Weaver wrote: > Your patch looks good to me, but I've just posted an alternative > patch > set to 'guix-devel' which should enable us to keep ImageMagick > up-to-date without grafting, and which fixes this security flaw and > more. > >

Re: Security patching and the branching workflow: a new security-updates branch

Thanks for your feedback. On Sat, 2021-03-27 at 13:29 +0100, zimoun wrote: > And as I said elsewhere, “to me, security is important. But it's > no less important than everything *else* that is also important!“, so > personally I am not convinced that security updates deserve a special > treatment

Cuirass not processing core-updates (or weirdly)

Hello! If you look at https://ci.guix.gnu.org/eval/13652 you can see that the evaluation of the derivation seems completed but there's no pending builds. What is happening here? Thank you signature.asc Description: This is a digitally signed message part

bug#47418: [PATCH] gnu: imagemagick: Fix CVE-2020-27829.

On Sat, 2021-03-27 at 00:12 +0100, Maxime Devos wrote: > This patch seems about right to me. However, > > $ guix lint -c cve imagemagick > gnu/packages/imagemagick.scm:132:2: imagemagick@6.9.12-2g: probably > vulnerable to CVE-2021-20176, CVE-2021-20243, CVE-2021-20244, CVE- > 2020-25663,

Re: Security patching and the branching workflow: a new security-updates branch

On Fri, 2021-03-26 at 22:13 +, Christopher Baines wrote: > Can you clarify what specific problem or problems you're proposing > this > security-updates branch to address? Substitute availability of security updates when they are released, without causing big rebuilds on master for users

bug#47420: binutils is vulnerable to CVE-2021-20197 (and various others)

Another: CVE-2021-20284 18:15 A flaw was found in GNU Binutils 2.35.1, where there is a heap-based buffer overflow in _bfd_elf_slurp_secondary_reloc_section in elf.c due to the number of symbols not calculated correctly. The highest threat from this vulnerability is to system availability.

bug#47422: tar is vulnerable to CVE-2021-20193

CVE-2021-20193 18:15 A flaw was found in the src/list.c of tar 1.33 and earlier. This flaw allows an attacker who can submit a crafted input file to tar to cause uncontrolled consumption of memory. The highest threat from this vulnerability is to system availability. Patch available here:

bug#47420: binutils is vulnerable to CVE-2021-20197 (and various others)

CVE-2021-20197 18:15 There is an open race window when writing output in the following utilities in GNU binutils version 2.35 and earlier:ar, objcopy, strip, ranlib. When these utilities are run as a privileged user (presumably as part of a script updating binaries across different users), an

Security patching and the branching workflow: a new security-updates branch

Hello! There is two ways to ship security fixes to packages: 1. Update to a patched version if upstream provides one 2. Apply or backport individual patches to fix the issues in the shipped version Grafts are most reliable for 2. but there's cases where using 2. is lots of work and we can't

bug#47418: [PATCH] gnu: imagemagick: Fix CVE-2020-27829.

* gnu/packages/patches/imagemagick-CVE-2020-27829.patch: New patch. * gnu/local.mk (dist_patch_DATA): Register it. * gnu/packages/imagemagick.scm (imagemagick/fixed): Apply patch to existing graft. --- gnu/local.mk | 1 + gnu/packages/imagemagick.scm

bug#47418: imagemagick is vulnerable to CVE-2020-27829

CVE-2020-27829 18:15 A heap based buffer overflow in coders/tiff.c may result in program crash and denial of service in ImageMagick before 7.0.10-45. Upstream patch available at https://github.com/ImageMagick/ImageMagick/commit/6ee5059cd3ac8d82714a1ab1321399b88539abf0 Not yet backported to 6.x

Specify runtime dependencies with propagated-inputs or wrapper scripts

Hello! I often meet problems where some packages don't work out of the box because they have some runtime dependencies like themes or third party programs. I solved these problems on occasion by making commits such as this:

bug#47231: sqlite package is vulnerable to CVE-2020-11655, CVE-2020-11656, CVE-2020-13434, CVE-2020-13435, CVE-2020-13630, CVE-2020-13631, CVE-2020-13632, CVE-2020-15358 and CVE-2020-9327

On Thu, 2021-03-25 at 21:23 -0400, Mark H Weaver wrote: > > Just a reminder that, just as with 'mysql/fixed', 'sqlite/fixed' > should > *not* use 'package/inherit', since the package you're defining is the > replacement for the package you're inheriting from. > > Otherwise, it looks good to me!

bug#47257: [PATCH v3] gnu: mariadb: Fix CVE-2021-27928.

On Thu, 2021-03-25 at 21:16 -0400, Mark H Weaver wrote: > > Looks good to me. Please push. Thank you! > > Mark Thank you for the review, pushed as 52c8d07a4f7033534a71ac7efeec21a65d35c125. signature.asc Description: This is a digitally signed message part

bug#47398: generic-html updater does not work for exiv2 package

$ ./pre-inst-env guix refresh exiv2 gnu/packages/image.scm:1343:2: warning: 'generic-html' updater failed to determine available releases for exiv2 It seems applying this patch does not help either: diff --git a/gnu/packages/image.scm b/gnu/packages/image.scm index d04a247976..8ede48eea5 100644

bug#47375: guix test failure: tests/print

On Fri, 2021-03-26 at 00:24 +0100, Ludovic Courtès wrote: > Léo Le Bouter skribis: > > > Full log: https://ci.guix.gnu.org/build/117996/log/raw > > Speaking of which: please always build packages before pushing. :-) > > Thanks, > Ludo’. I ran 'guix pull' but turn

bug#47257: [PATCH v3] gnu: mariadb: Fix CVE-2021-27928.

v3 tested and builds fine: $ ./pre-inst-env guix build mariadb /gnu/store/f70jymwyfcnsghy4jg8caibci59p8rgq-mariadb-10.5.8-dev /gnu/store/cj3qym1x1jjh02m2g23cqpbhchrbmn6c-mariadb-10.5.8-lib /gnu/store/mpb5bdf1vkwazqfmmwcvskdm50g191bg-mariadb-10.5.8 Since we don't have PoC, I can't verify the

bug#47257: [PATCH v3] gnu: mariadb: Fix CVE-2021-27928.

* gnu/packages/patches/mariadb-CVE-2021-27928.patch: New patch. * gnu/local.mk (dist_patch_DATA): Register it. * gnu/packages/databases.scm (mariadb/fixed): New variable. Apply patch. (mariadb)[replacement]: Graft. --- gnu/local.mk | 1 +

bug#47257: mariadb is vulnerable to CVE-2021-27928 (RCE)

On Fri, 2021-03-19 at 12:35 +0100, zimoun wrote: > Instead of grafting, I would fix first check the compatibility > between > mariadb and zstd. Because mariadb@10.5.8 does not build with > zstd@1.4.9, at least on my machine. Can you post build logs and repro scenario? mariadb@10.5.8 built fine

  1   2   3   >