all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Guile 2.0.13
@ 2016-10-12 12:38 Ludovic Courtès
  2016-10-12 16:20 ` Christopher Allan Webber
  2016-10-12 16:35 ` Leo Famulari
  0 siblings, 2 replies; 10+ messages in thread
From: Ludovic Courtès @ 2016-10-12 12:38 UTC (permalink / raw)
  To: guix-devel

Hello!

Guile 2.0.13 fixes a couple of security issues:

  https://lists.gnu.org/archive/html/guile-user/2016-10/msg00010.html

CVE-2016-8606 can be serious (remote code execution), but developers
using Guile can readily work around it; see the description at:

  https://lists.gnu.org/archive/html/guile-user/2016-10/msg00007.html

In particular, Geiser already uses Unix-domain sockets to talk to Guile,
which means we’re safe here.

CVE-2016-8605 is about the possibility of creating files with insecure
permissions in multithreaded programs.  Apart from our own grafting code
(the infamous <http://bugs.gnu.org/22954>), this is probably a rare
situation.

So, what do we do?

Given that core-updates with Guile 2.0.12 is on its way and that master
is still at 2.0.11, I’d suggest to leave master as-is and focus on
core-updates.

There we have 2 options:

  1. Changing ‘guile-2.0/fixed’ to 2.0.13, but 1,310 packages depend on it.

  2. Grafting 2.0.13, which is doable since 2.0.12 and .13 have the same ABI.

I have a preference for #2.

Thoughts?

Ludo’.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Guile 2.0.13
  2016-10-12 12:38 Guile 2.0.13 Ludovic Courtès
@ 2016-10-12 16:20 ` Christopher Allan Webber
  2016-10-12 16:35 ` Leo Famulari
  1 sibling, 0 replies; 10+ messages in thread
From: Christopher Allan Webber @ 2016-10-12 16:20 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel

Ludovic Courtès writes:

> Given that core-updates with Guile 2.0.12 is on its way and that master
> is still at 2.0.11, I’d suggest to leave master as-is and focus on
> core-updates.
>
> There we have 2 options:
>
>   1. Changing ‘guile-2.0/fixed’ to 2.0.13, but 1,310 packages depend on it.
>
>   2. Grafting 2.0.13, which is doable since 2.0.12 and .13 have the same ABI.
>
> I have a preference for #2.

I think grafting is fine!

 - Chris

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Guile 2.0.13
  2016-10-12 12:38 Guile 2.0.13 Ludovic Courtès
  2016-10-12 16:20 ` Christopher Allan Webber
@ 2016-10-12 16:35 ` Leo Famulari
  2016-10-12 18:26   ` Christopher Allan Webber
  2016-10-12 20:13   ` Ludovic Courtès
  1 sibling, 2 replies; 10+ messages in thread
From: Leo Famulari @ 2016-10-12 16:35 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel

On Wed, Oct 12, 2016 at 02:38:26PM +0200, Ludovic Courtès wrote:
> Given that core-updates with Guile 2.0.12 is on its way and that master
> is still at 2.0.11, I’d suggest to leave master as-is and focus on
> core-updates.
> 
> There we have 2 options:
> 
>   1. Changing ‘guile-2.0/fixed’ to 2.0.13, but 1,310 packages depend on it.
> 
>   2. Grafting 2.0.13, which is doable since 2.0.12 and .13 have the same ABI.

Considering that 2.0.13 fixes a bug that is exposed by grafting, it's a
bit of shame to provide it with a graft. But if we are too far along,
it's understandable.

We could always un-graft it between releases if Hydra isn't busy.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Guile 2.0.13
  2016-10-12 16:35 ` Leo Famulari
@ 2016-10-12 18:26   ` Christopher Allan Webber
  2016-10-12 20:13   ` Ludovic Courtès
  1 sibling, 0 replies; 10+ messages in thread
From: Christopher Allan Webber @ 2016-10-12 18:26 UTC (permalink / raw)
  To: Leo Famulari; +Cc: guix-devel

Leo Famulari writes:

> On Wed, Oct 12, 2016 at 02:38:26PM +0200, Ludovic Courtès wrote:
>
> Considering that 2.0.13 fixes a bug that is exposed by grafting, it's a
> bit of shame to provide it with a graft. But if we are too far along,
> it's understandable.
>
> We could always un-graft it between releases if Hydra isn't busy.

Ha... that's an interesting point.

Hopefully most Guix users have gotten the message, "don't use localhost
+ port"... most Guix users are probably paying attention closely to
Guile happenings, if any community was?

But of course, we really don't want to put our users at risk.

 - Chris

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Guile 2.0.13
  2016-10-12 16:35 ` Leo Famulari
  2016-10-12 18:26   ` Christopher Allan Webber
@ 2016-10-12 20:13   ` Ludovic Courtès
  2016-10-12 20:30     ` Leo Famulari
  1 sibling, 1 reply; 10+ messages in thread
From: Ludovic Courtès @ 2016-10-12 20:13 UTC (permalink / raw)
  To: Leo Famulari; +Cc: guix-devel

Leo Famulari <leo@famulari.name> skribis:

> On Wed, Oct 12, 2016 at 02:38:26PM +0200, Ludovic Courtès wrote:
>> Given that core-updates with Guile 2.0.12 is on its way and that master
>> is still at 2.0.11, I’d suggest to leave master as-is and focus on
>> core-updates.
>> 
>> There we have 2 options:
>> 
>>   1. Changing ‘guile-2.0/fixed’ to 2.0.13, but 1,310 packages depend on it.
>> 
>>   2. Grafting 2.0.13, which is doable since 2.0.12 and .13 have the same ABI.
>
> Considering that 2.0.13 fixes a bug that is exposed by grafting,

That *was* exposed by grafting; commit
d72267863382041b84a9712eea354882be72ef55 works around the problem, so
that’s fine.

> We could always un-graft it between releases if Hydra isn't busy.

Yeah.  I was thinking that we’d want to finish this core-updates cycle
and then later do an ungrafting round or something.

WDYT?

Ludo’.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Guile 2.0.13
  2016-10-12 20:13   ` Ludovic Courtès
@ 2016-10-12 20:30     ` Leo Famulari
  2016-10-13 21:11       ` Ludovic Courtès
  0 siblings, 1 reply; 10+ messages in thread
From: Leo Famulari @ 2016-10-12 20:30 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel

On Wed, Oct 12, 2016 at 10:13:32PM +0200, Ludovic Courtès wrote:
> Leo Famulari <leo@famulari.name> skribis:
> 
> > On Wed, Oct 12, 2016 at 02:38:26PM +0200, Ludovic Courtès wrote:
> >> Given that core-updates with Guile 2.0.12 is on its way and that master
> >> is still at 2.0.11, I’d suggest to leave master as-is and focus on
> >> core-updates.
> >> 
> >> There we have 2 options:
> >> 
> >>   1. Changing ‘guile-2.0/fixed’ to 2.0.13, but 1,310 packages depend on it.
> >> 
> >>   2. Grafting 2.0.13, which is doable since 2.0.12 and .13 have the same ABI.
> >
> > Considering that 2.0.13 fixes a bug that is exposed by grafting,
> 
> That *was* exposed by grafting; commit
> d72267863382041b84a9712eea354882be72ef55 works around the problem, so
> that’s fine.

Oh, right!

> > We could always un-graft it between releases if Hydra isn't busy.
> 
> Yeah.  I was thinking that we’d want to finish this core-updates cycle
> and then later do an ungrafting round or something.
> 
> WDYT?

That sounds good. I think we should try doing some more specific
"updates" branches in between releases, assuming we have the compute
power and the motivation.

And we could also have some periodic ungrafting rebuilds when necessary
and feasible.

So, we would graft guile-2.0, make guile-2.0/fixed use 2.0.12, and set
replacement #f in guile-next? Anything else?

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Guile 2.0.13
  2016-10-12 20:30     ` Leo Famulari
@ 2016-10-13 21:11       ` Ludovic Courtès
  2016-10-15 17:13         ` Efraim Flashner
  0 siblings, 1 reply; 10+ messages in thread
From: Ludovic Courtès @ 2016-10-13 21:11 UTC (permalink / raw)
  To: Leo Famulari; +Cc: guix-devel

Leo Famulari <leo@famulari.name> skribis:

> On Wed, Oct 12, 2016 at 10:13:32PM +0200, Ludovic Courtès wrote:

[...]

>> Yeah.  I was thinking that we’d want to finish this core-updates cycle
>> and then later do an ungrafting round or something.
>> 
>> WDYT?
>
> That sounds good. I think we should try doing some more specific
> "updates" branches in between releases, assuming we have the compute
> power and the motivation.
>
> And we could also have some periodic ungrafting rebuilds when necessary
> and feasible.

Yes, definitely.

More generally, we could try to have a “staging” branch for safe changes
that involve a rebuild of between ~300 and ~1200 packages, that we’d
merge more frequently than ‘core-updates’ (I think the Nix folks do
that).  By “safe” I mean things like ungrafting, minor upgrades and
improvements; the goal would be to reduce the latency for such changes.

Things that rebuild more than ~1200 packages would still go to
‘core-updates’.

WDYT?

> So, we would graft guile-2.0, make guile-2.0/fixed use 2.0.12, and set
> replacement #f in guile-next? Anything else?

Yes, and a couple of related changes.  Pushed as
c62a31ca802c2b225279c4b0360a4cfc2723ad28.

Thanks!

Ludo’.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Guile 2.0.13
  2016-10-13 21:11       ` Ludovic Courtès
@ 2016-10-15 17:13         ` Efraim Flashner
  2016-10-15 19:46           ` Leo Famulari
  2016-10-18 14:26           ` Ludovic Courtès
  0 siblings, 2 replies; 10+ messages in thread
From: Efraim Flashner @ 2016-10-15 17:13 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel

[-- Attachment #1: Type: text/plain, Size: 1223 bytes --]

On Thu, Oct 13, 2016 at 11:11:38PM +0200, Ludovic Courtès wrote:
> 
> More generally, we could try to have a “staging” branch for safe changes
> that involve a rebuild of between ~300 and ~1200 packages, that we’d
> merge more frequently than ‘core-updates’ (I think the Nix folks do
> that).  By “safe” I mean things like ungrafting, minor upgrades and
> improvements; the goal would be to reduce the latency for such changes.
> 
> Things that rebuild more than ~1200 packages would still go to
> ‘core-updates’.
> 
> WDYT?
> 
> Thanks!
> 
> Ludo’.
> 

This sounds like a good idea in general. A quick `guix refresh -l cmake'
showed ~1100 packages, which would make this a good spot for the patch I
tossed into core-updates to also build the ccmake binary.

Currently I think most of us try to keep the number of rebuilds under
~150, so it might be nice to have some sort of guidelines in a separate
post (and in HACKING eventually) so that people don't miss it.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Guile 2.0.13
  2016-10-15 17:13         ` Efraim Flashner
@ 2016-10-15 19:46           ` Leo Famulari
  2016-10-18 14:26           ` Ludovic Courtès
  1 sibling, 0 replies; 10+ messages in thread
From: Leo Famulari @ 2016-10-15 19:46 UTC (permalink / raw)
  To: Efraim Flashner; +Cc: guix-devel

[-- Attachment #1: Type: text/plain, Size: 1130 bytes --]

On Sat, Oct 15, 2016 at 08:13:12PM +0300, Efraim Flashner wrote:
> On Thu, Oct 13, 2016 at 11:11:38PM +0200, Ludovic Courtès wrote:
> > 
> > More generally, we could try to have a “staging” branch for safe changes
> > that involve a rebuild of between ~300 and ~1200 packages, that we’d
> > merge more frequently than ‘core-updates’ (I think the Nix folks do
> > that).  By “safe” I mean things like ungrafting, minor upgrades and
> > improvements; the goal would be to reduce the latency for such changes.
> > 
> > Things that rebuild more than ~1200 packages would still go to
> > ‘core-updates’.
> > 
> > WDYT?
> > 
> > Thanks!
> > 
> > Ludo’.
> > 
> 
> This sounds like a good idea in general. A quick `guix refresh -l cmake'
> showed ~1100 packages, which would make this a good spot for the patch I
> tossed into core-updates to also build the ccmake binary.

+1

> Currently I think most of us try to keep the number of rebuilds under
> ~150, so it might be nice to have some sort of guidelines in a separate
> post (and in HACKING eventually) so that people don't miss it.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Guile 2.0.13
  2016-10-15 17:13         ` Efraim Flashner
  2016-10-15 19:46           ` Leo Famulari
@ 2016-10-18 14:26           ` Ludovic Courtès
  1 sibling, 0 replies; 10+ messages in thread
From: Ludovic Courtès @ 2016-10-18 14:26 UTC (permalink / raw)
  To: Efraim Flashner; +Cc: guix-devel

Efraim Flashner <efraim@flashner.co.il> skribis:

> On Thu, Oct 13, 2016 at 11:11:38PM +0200, Ludovic Courtès wrote:
>> 
>> More generally, we could try to have a “staging” branch for safe changes
>> that involve a rebuild of between ~300 and ~1200 packages, that we’d
>> merge more frequently than ‘core-updates’ (I think the Nix folks do
>> that).  By “safe” I mean things like ungrafting, minor upgrades and
>> improvements; the goal would be to reduce the latency for such changes.
>> 
>> Things that rebuild more than ~1200 packages would still go to
>> ‘core-updates’.
>> 
>> WDYT?
>> 
>> Thanks!
>> 
>> Ludo’.
>> 
>
> This sounds like a good idea in general. A quick `guix refresh -l cmake'
> showed ~1100 packages, which would make this a good spot for the patch I
> tossed into core-updates to also build the ccmake binary.
>
> Currently I think most of us try to keep the number of rebuilds under
> ~150, so it might be nice to have some sort of guidelines in a separate
> post (and in HACKING eventually) so that people don't miss it.

I’ve posted a summary here:

  https://lists.gnu.org/archive/html/guix-devel/2016-10/msg00933.html

Ludo’.

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2016-10-18 14:26 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-10-12 12:38 Guile 2.0.13 Ludovic Courtès
2016-10-12 16:20 ` Christopher Allan Webber
2016-10-12 16:35 ` Leo Famulari
2016-10-12 18:26   ` Christopher Allan Webber
2016-10-12 20:13   ` Ludovic Courtès
2016-10-12 20:30     ` Leo Famulari
2016-10-13 21:11       ` Ludovic Courtès
2016-10-15 17:13         ` Efraim Flashner
2016-10-15 19:46           ` Leo Famulari
2016-10-18 14:26           ` Ludovic Courtès

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.