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

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

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

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

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

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 >

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,

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

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

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

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

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

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

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

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

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

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:

Re: [opinion] CVE-patching is not sufficient for package security patching

On Wed, 2021-03-24 at 21:24 +0100, Vincent Legoll wrote: > Hello, > > On Wed, Mar 24, 2021 at 8:51 PM Leo Famulari > wrote: > > > We bought a handful of Overdrive 1000 in the past (they are no > > > longer > > > sold), and hosting was always an obstacle. > > > > I volunteer to host one or two

Re: I have merged wip-ppc64le-for-master to master

On Tue, 2021-03-23 at 23:41 -0700, Chris Marusich wrote: > Hi, > > FYI, I have merged wip-ppc64le-for-master to master and closed bug > 47182. I have also deleted the wip-ppc64le-for-master branch. > > Later this week, I will update the manual to mention that > powerpc64le-linux is supported,

A proposal for better quality in maintenance of packages by reducing scope

Hello! There's lots of packages in GNU Guix and maintaining all of them is tedious, even if we have tooling, there's only so much we can do. I want to have a secure and reliable system, I would also like to only depend on packages I know are easy to maintain for GNU Guix contributors. I would

Re: imagemagick@6.9.11-48 to graft or not to graft with 6.9.12-2

On Tue, 2021-03-23 at 15:22 +0100, Andreas Enge wrote: > I wrote in my bug report https://issues.guix.gnu.org/47315; grafts > with > different version numbers lead to a command line behaviour that is > not > understandable: > > $ guix package -A imagemagick > imagemagick 6.9.12-2g out,doc

Re: Let's include powerpc64le-linux in the next release

On Tue, 2021-03-23 at 14:42 +0100, Ludovic Courtès wrote: > Like Efraim wrote, the person who makes the release (I’m afraid it’ll > be > me) needs to be able to offload to a “trustworthy” machine for that > platform. > > If we can do that, we should adjust the ‘release’ target in > ‘Makefile.am’

Secure GNU Guix offloading

Hello! I have powerful machines at hand and I would like to share them through the GNU Guix offloading facility so that they are easy to use. The problem is that setting up offloading requires my machine to trust each and every client's store public key which means they can spoof results of

Re: imagemagick@6.9.11-48 to graft or not to graft with 6.9.12-2

In general my opinion is that backporting fixes is time-consuming and that if we have to do it each time I wont be able to keep up with the load. I'd rather update things to a version that already includes fixes and is supported by upstream even at the cost of world rebuilds. I can't deal with

Re: Make guix commands pipeable

> I do agree though that it would be nicer to just have '-' as a guix > input arg causing any guix command to read from stdin. Doesnt /dev/stdin work? The only reason it could not is that somehow the file descriptor needs to be seekable. Léo signature.asc Description: This is a digitally

Re: Why [bug#47081] Remove mongodb?

Hello! > Removing a package and its services is not something to do lightly: > it > breaks user configs with no recourse. > > We must insist on getting more opinions on such matters, and I think > there just wasn’t enough feedback here. I understand it can be > frustrating to wait for input,

imagemagick@6.9.11-48 to graft or not to graft with 6.9.12-2

Hello! See commit: 82e887ba48c2ba91b17aa9b6b17501e3e0ef4aef Following discussion around whether it is safe to graft and whether we should do so or not, first, I apologize for not doing as rigorous checking on this issue as I should have, and also requesting more peer- review, I initially

Re: Why [bug#47081] Remove mongodb?

On Wed, 2021-03-17 at 19:51 +0100, zimoun wrote: > It shows exactly my point. The correct and polite way of doing the > thing is first to examine the issue at hand (3.4.10 is old with > security > vulnerabilities), then propose a fix (e.g., the removal), wait > feedback, > and complete. Actually

Re: Why [bug#47081] Remove mongodb?

The issue with 3.4.24 / 3.4.10 is that Efraim reverted the commit then it was briefly discussed on IRC and Efraim thought I was right about the licensing being fine on 3.4.24 and reverted their revert commit, after some actual checking in the tarball grepping for license headers I found out I was

Re: Rust and parametric packages

On Wed, 2021-03-17 at 18:30 +0100, raingloom wrote: > I'm re-reading the threads about Rust packaging and I realized there > might be a solution to the build artifact reuse problem. > > As I understand it, the problem is that crates can be compiled with > any > number of features enabled or

Re: Why [bug#47081] Remove mongodb?

On Wed, 2021-03-17 at 18:56 +0100, zimoun wrote: > AFAIT, 3.4.10 is released under GNU AGPL 3.0 and Apache 2.0. This > version had been released before the October 16th, 2018. Could you > point which code is non-free? > > IMHO, this claim about non-free code is wrong. The last versions > with

Re: Fedora/Debian release monitoring inspiration for Guix Data Service

On Wed, 2021-03-17 at 18:35 +0100, Ludovic Courtès wrote: > Established distros have great tools and services for that. > > Guix has ‘guix refresh’, which predates some of the trendy > release/CVE > monitoring services and actually works well. It’s not perfect, but > it’s > good, so my advice

Re: Why [bug#47081] Remove mongodb?

Sorry for duplicated email, On Wed, 2021-03-17 at 17:56 +0100, zimoun wrote: > If the removal for security reasons had been discussed on IRC, it > could > be nice to point the discussion here. Otherwise, open a discussion > on > the topic on guix-devel or bug-guix. The full removal is a radical

Re: Why [bug#47081] Remove mongodb?

On Wed, 2021-03-17 at 17:56 +0100, zimoun wrote: > If the removal for security reasons had been discussed on IRC, it > could > be nice to point the discussion here. Otherwise, open a discussion > on > the topic on guix-devel or bug-guix. The full removal is a radical > solution (especially, it

Re: Are gzip-compressed substitutes still used?

Just as a reminder siding with vagrantc here: We must ensure the Debian 'guix' package can still work and upgrade from it's installed version, so ensure that removing gzip doesnt break initial 'guix pull' with it. signature.asc Description: This is a digitally signed message part

Re: Fedora/Debian release monitoring inspiration for Guix Data Service

On Tue, 2021-03-16 at 23:28 +, Christopher Baines wrote: > I did spot these patches > https://patches.guix-patches.cbaines.net/project/guix-patches/list/?series=7298 Awesome!! I did not see them earlier! > I think the Guix Data Service could run the "refresh" code from Guix > and > store

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

On Tue, 2021-03-16 at 21:53 +0100, Tobias Geerinckx-Rice wrote: > Hi L[ée]o, > > Wow, Léo. You've done some seriously impressive CVE squashing in > such a short timespan, and I'm very grateful to have you on board. I spent few days on this, it's not that much! I did not do much work, I didnt

Re: Security-czar needed? WAS: Re: Release 1.2.1: zstd 1.4.4 -> 1.4.9: grafting or core-updates?

On Tue, 2021-03-16 at 22:46 +0100, Bengt Richter wrote: > I would feel better about running guix on my laptop if I > knew all you developers had gotten together and elected > a "security czar" who is the most competent of you to monitor > security and also cares the most, and had the power to

Re: [opinion] CVE-patching is not sufficient for package security patching

Sorry for duplicated email.. On Tue, 2021-03-16 at 19:19 -0400, Mark H Weaver wrote: > If not, it would be good to work toward the goal of making Guix > usable > on non-Intel systems. I'm sorry to say that, in my opinion, your > proposal would move us in the wrong direction to achieve that goal.

Re: [opinion] CVE-patching is not sufficient for package security patching

On Tue, 2021-03-16 at 19:19 -0400, Mark H Weaver wrote: > That said, I strongly disagree that we should "never backport patches > ourselves in most cases". The only way to do that, while addressing > security flaws, would be to promptly update even our lowest-level > libraries in response to

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

On Tue, 2021-03-16 at 19:46 +0100, zimoun wrote: > Well, it seems better to send such changes to guix-patches, waiting > 15 > days, and then if no comment, push. It is what the manual describes: > > Non-trivial patches should always be posted to > guix-patc...@gnu.org (trivial

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

On Tue, 2021-03-16 at 19:19 +0100, zimoun wrote: > I guess that it will not build for i686. Does it? > If not, the patch attached to the previous email tweaks the offending > test; as the original author of zstd has suggested: > >

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

On Tue, 2021-03-16 at 13:55 -0400, Leo Famulari wrote: > I do agree that updating this program 5 versions in a graft was > perhaps > too much. > > We should always try to cherry-pick bug-fix patches when grafting. > > Otherwise the risk of breakage is too high. At least, these types of > patches

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

On Tue, 2021-03-16 at 13:48 -0400, Leo Famulari wrote: > This is off-topic, but I think that CVE scoring is not really that > useful. This bug is a local TOCTOU race which is bad but hardly > critical, IMO. For something to be critical, it should enable remote > execution of arbitrary code. Well

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

I suggest we disable the test-suite or the specific test in the interim for other architectures. The CVE-2021-24032 is Base Score: 9.1 CRITICAL - which is exceptionally high so fixing it is an absolute necessity in any branch. signature.asc Description: This is a digitally signed message part

Re: Fedora/Debian release monitoring inspiration for Guix Data Service

On Tue, 2021-03-16 at 12:12 +0100, Ricardo Wurmus wrote: > Léo Le Bouter writes: > > > I am thinking we should really get something like this with the > > Guix > > Data Service, start including something similar to Debian > > uscan/watch > > rules in

Re: [opinion] CVE-patching is not sufficient for package security patching

On Tue, 2021-03-16 at 12:17 +0100, Jonathan Brielmaier wrote: > I think the only two reasons against that are: time and > CI/rebuilding. I > think thats the reason why stuff like Gnome and others lower in the > dependency tree are lacking behind... Being non-FHS and non-systemd > makes updates for

[opinion] CVE-patching is not sufficient for package security patching

Hello! I would like to share some opinion I have on CVE-patching for non- rolling release GNU/Linux distributions and why we should strive to always update to the latest available releases or always follow upstream supported release series and never backport patches ourselves in most cases (some

Fedora/Debian release monitoring inspiration for Guix Data Service

Hello! It seems Fedora has automated infrastructure and feeds to monitor new upstream releases so that maintainers can get notifications on them. https://release-monitoring.org/ Functional feed: https://apps.fedoraproject.org/datagrepper/raw?rows_per_page=1=127800=hotness I could not find the

Re: Let's include powerpc64le-linux in the next release (was: Re: Release on April 18th?)

On Tue, 2021-03-16 at 09:08 +0200, Efraim Flashner wrote: > On Mon, Mar 15, 2021 at 09:03:04PM -0700, Chris Marusich wrote: > > How shall we build the binary tarball for the release? Of course, > > anybody with a copy of the (source) release tarball can build their > > own > > guix binary by

Re: GNU Mes 0.23 released

Thanks a lot! Keep it up! :-D signature.asc Description: This is a digitally signed message part

Re: Guile Netlink 1.0 released

Exciting new possibilities! Great work! signature.asc Description: This is a digitally signed message part

Re: gnutls package may be vulnerable to CVE-2021-20232

On Sat, 2021-03-13 at 05:12 -0500, Mark H Weaver wrote: > I pushed fixes for this and CVE-2021-20231 to 'master' in commit > 74e2c0e00f58c8bf948f7dc7c5ae2876af910d5a. Thank you, I would otherwise have done it, I was waiting for an answer from upstream first, or some time. > For what it's worth,

gnutls package may be vulnerable to CVE-2021-20232

CVE-2021-20232 12.03.21 20:15 A flaw was found in gnutls. A use after free issue in client_send_params in lib/ext/pre_shared_key.c may lead to memory corruption and other potential consequences. It is not certain whether 3.6.x series are affected as packaged in GNU Guix. I asked the upstream at

libupnp package vulnerable to CVE-2021-28302

CVE-2021-28302 12.03.21 16:15 A stack overflow in pupnp 1.16.1 can cause the denial of service through the Parser_parseDocument() function. ixmlNode_free() will release a child node recursively, which will consume stack space and lead to a crash. Upstream did not provide a patch yet, see <

Re: glib vulnerable to CVE-2021-28153

On Fri, 2021-03-12 at 01:47 -0500, Mark H Weaver wrote: > Thanks. I backported the upstream fix, and pushed it to 'master' in > commit 5a06b83fc92710c5846a83bbf49f0ea84c8ecec2. > > Mark Many thanks to you!! signature.asc Description: This is a digitally signed message part

glib vulnerable to CVE-2021-28153

Hello! CVE-2021-28153 11.03.21 23:15 An issue was discovered in GNOME GLib before 2.66.8. When g_file_replace() is used with G_FILE_CREATE_REPLACE_DESTINATION to replace a path that is a dangling symlink, it incorrectly also creates the target of the symlink as an empty file, which could

Re: glib@2.62.6 is vulnerable to CVE-2021-27218 and CVE-2021-27219

On Thu, 2021-03-11 at 06:23 -0500, Mark H Weaver wrote: > Mark H Weaver writes: > > > As I wrote in another thread: I'll backport the fixes for CVE-2021- > > 27218 > > and CVE-2021-27219 to our version of Glib, based on the backports > > already published by Ubuntu for Glib 2.56.4 and 2.64.4. >

Re: GNU Guix (pull?) on i686 broke after zstd grafting

On Thu, 2021-03-11 at 10:58 +0100, zimoun wrote: > Well, IMHO 1) «not durable» could mean months and 2) disabling all > the > tests for all the architectures is wrong especially when only one > test > is failing for only one architecture. I know that, I was tired yesterday and didnt want to block

Re: GNU Guix (pull?) on i686 broke after zstd grafting

On Thu, 2021-03-11 at 10:37 +0100, zimoun wrote: > This disable the complete test suite for all the architecture. I > have > not look into the details but it seems better to only disable the > offending test only the architecture affected. Yes it does that and it would be better not to but zstd

Re: I've rebased wip-ppc64le onto core-updates

Just wanted to say, Chris, thank you so much for following up steadily on this powerpc64le-linux work. I have been testing your changes on and off but without getting to actually solving issues as I have been busy with other things unrelated with GNU Guix and also GNU Guix CVE patching now.

Re: GNOME 3.34 in GNU Guix and security

On Thu, 2021-03-11 at 03:18 -0500, Mark H Weaver wrote: > Hi Léo, Hello! > I appreciate your recent work on Guix security. Thank you for that. Very happy to catch up there as well for my own usage of GNU Guix as well! > Can you please substantiate this? What vulnerabilities do you know > of,

2443 packages indirectly depend on unsupported openssl@1.0.2u

Hello! $ ./pre-inst-env guix refresh -l openssl@1.0.2u Building the following 2320 packages would ensure 2443 dependent [...] As upstream says at : > Version 1.0.2 is no longer supported. Extended support for 1.0.2 to gain access to security

GNOME 3.34 in GNU Guix and security

Hello! I must come to the conclusion that using GNOME 3.34 in GNU Guix right now is just straight out insecure. I would advise we either, get rid of GNOME, backport all individual security patches (they can be numerous..), or upgrade GNOME to latest and keep up over time. I don't think we can

pjproject package is vulnerable to CVE-2021-21375 and CVE-2020-15260

CVE-2021-21375 00:15 PJSIP is a free and open source multimedia communication library written in C language implementing standard based protocols such as SIP, SDP, RTP, STUN, TURN, and ICE. In PJSIP version 2.10 and earlier, after an initial INVITE has been sent, when two 183 responses are

  1   2   >