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.
>
Hi,
Updating the package r-chemminer, it leads to this huge stack of
grafts. To be concrete, it is 84 grafts for a “simple” R packages. On
my machine, the grafting steps are longer than building (compiling and R
dance).
We definitively need a way to tackle this. Maybe when is in frozen
state,
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.
Done in commit 21b3b755151028647081fe96d2992b3743531d71 on the 'master'
Hi,
Currently the package Python 2 python2-pylibmc fails to build because
Cuirass fails to build the dependency libmemcached. However, this
package libmemcached locally builds.
Well, I think it fails because this test:
--8<---cut here---start->8---
On 11.03.2021 08:37, Maxime Devos wrote:
> On Thu, 2021-03-11 at 00:15 +0100, Taylan Kammer wrote:
>> [...]
>> Damn, sorry about that. I assumed of course that an improperly signed
>> commit would not be accepted, so I didn't pay any special mind.
>>
>> However, I also assumed that adding a new
Hi Tobias,
On Thu, 11 Mar 2021 at 00:37, Tobias Geerinckx-Rice wrote:
>> Attached, the list of the 180 ghc-* packages.
>
> I've started the builds on berlin except haddock. Not restarted:
> none of these had failed. Judging by how quickly it finished I
> think most of them had already been
On Thu, Mar 11, 2021 at 12:58:50AM -0800, Chris Marusich wrote:
> Hi Efraim,
>
> Efraim Flashner writes:
>
> > I wanted an Easy Win™ and I've pushed a branch wip-ppc64le-for-master,
> > which cherry-picked (I think) all of the powerpc64le commits and
> > adjusted them to work against master
Also, make sure to install the pre-push hook, it should not have let you commit
without checking your commits were properly recognised.
Le 11 mars 2021 08:11:38 GMT-05:00, Taylan Kammer a
écrit :
>On 11.03.2021 08:37, Maxime Devos wrote:
>> On Thu, 2021-03-11 at 00:15 +0100, Taylan Kammer
Taylan,
So if I needed to send you encrypted mail, I'd have to possess all
of your current GPG keys and encrypt to all of them? Thanks for
the heads-up ;-) I'm not sure if that's how GPG is supposed to
work (‘who does’, you say? fair point).
I do know that UIDs like ‘Jessie Doe
On Thu, Mar 11, 2021 at 12:15:19AM +0100, Taylan Kammer wrote:
> Damn, sorry about that. I assumed of course that an improperly signed
> commit would not be accepted, so I didn't pay any special mind.
The security model is based on the client-side, i.e. `guix pull`. That
way, we don't have to
On 11.03.2021 20:16, Leo Famulari wrote:
> On Thu, Mar 11, 2021 at 12:15:19AM +0100, Taylan Kammer wrote:
>> Damn, sorry about that. I assumed of course that an improperly signed
>> commit would not be accepted, so I didn't pay any special mind.
>
> The security model is based on the
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
On 11.03.2021 15:59, Tobias Geerinckx-Rice wrote:
> Taylan,
>
> So if I needed to send you encrypted mail, I'd have to possess all of
> your current GPG keys and encrypt to all of them? Thanks for the
> heads-up ;-) I'm not sure if that's how GPG is supposed to work (‘who
> does’, you say? fair
Léo Le Bouter writes:
> 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
Hi Léo,
Léo Le Bouter writes:
> CVE-2021-2815311.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
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
Hi,
On Thu, 11 Mar 2021 at 03:11, Léo Le Bouter wrote:
> On Wed, 2021-03-10 at 11:37 +0100, Ludovic Courtès wrote:
>> So I think there’s a genuine bug here. Could you take a look? At
>> worst, we should skip the offending test on i686 (and perhaps
>> ARMv7?).
>
> I pushed
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
On Thu, 11 Mar 2021 at 10:40, Léo Le Bouter wrote:
> 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.
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
Hi,
I've rebased wip-ppc64le again just now onto the latest core-updates.
There were no conflicts.
Because I committed 5d2863dfe4613d5091e61800fcd5a48922c8ce4e and
001fc29b43fd0beb365d536774fae96624309413 directly to core-updates before
rebasing, I removed some similar commits from wip-ppc64le
Am 11.03.21 um 09:08 schrieb Ricardo Wurmus:
Léo Le Bouter writes:
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
Hi Efraim,
Efraim Flashner writes:
> I wanted an Easy Win™ and I've pushed a branch wip-ppc64le-for-master,
> which cherry-picked (I think) all of the powerpc64le commits and
> adjusted them to work against master WITHOUT affecting other
> architectures.
It looks like you modified "gnu: glibc:
Hi Ricardo!
Thanks for the update!
Also, then reason GNOME work got messed up is that, in wip-desktop, [1]
I was not just working gnome packages, but also its dependencies [2]
Work involved not just updates, but also improvements. This kinda
complicated the "update stuff" norm.
I think
Hi Léo,
I appreciate your recent work on Guix security. Thank you for that.
Léo Le Bouter writes:
> 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
Hi Ricardo!
I don’t know if anyone is working on it right now, though. I was told
months ago that Raghav Gururajan was working on GNOME upgrades as part
of the wip-desktop branch, but my occasional questions for a status
upgrade have gone unanswered. Raghav, please correct me if I’m
mistaken.
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,
Hi Léo,
Thanks for bringing this to our attention.
Léo Le Bouter writes:
> Upstream does not provide fixes for the 2.62.x series so we need to
> backport ourselves.
One does not follow from the other. Besides upstream, there exist other
competent organizations (such as Debian, Red Hat, and
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.
Vincent Legoll writes:
> I'm all for that, what can I do to help ?
Thank you for offering to help!
> I don't have a Talos, though...
>
> So only cross- or emulated- stuff...
>
> Willing to help, but needs directions.
I can probably also set you up with a temporary multi-core VM for
testing,
Raghav Gururajan writes:
> Hi Ricardo!
>
>> I don’t know if anyone is working on it right now, though. I was told
>> months ago that Raghav Gururajan was working on GNOME upgrades as part
>> of the wip-desktop branch, but my occasional questions for a status
>> upgrade have gone unanswered.
31 matches
Mail list logo
