Guile 2.0.13

Guile 2.0.13

[Ludovic Courtès]

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’.

Re: Guile 2.0.13

[Christopher Allan Webber]

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

Re: Guile 2.0.13

[Leo Famulari]

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.

Re: Guile 2.0.13

[Christopher Allan Webber]

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

Re: Guile 2.0.13

[Ludovic Courtès]

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’.

Re: Guile 2.0.13

[Leo Famulari]

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?

Re: Guile 2.0.13

[Ludovic Courtès]

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’.

Re: Guile 2.0.13

[Efraim Flashner]

[-- 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 --]

Re: Guile 2.0.13

[Leo Famulari]

[-- 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 --]

Re: Guile 2.0.13

[Ludovic Courtès]

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’.