bug#71729: Emacs 29.4 emergency bugfix release

bug#71729: Emacs 29.4 emergency bugfix release

[Adam Porter]

Hello,

Today an emergency bugfix release was made of Emacs v29.4.  It fixes an 
important security vulnerability.

FWIW, I had hoped that I could install it by running:

   guix install --with-version=emacs=29.4 emacs

But that fails the validate-comp-integrity phase, showing that all of 
its tests fail, with every function being loaded in byte-compiled form 
instead of native-compiled.

And despite my best efforts at comparing the emacs.git tags for 29.3 and 
29.4 to look for any relevant changes, and digging through the relevant 
source code, and scanning through the build logs, I can't find a cause 
for this problem.

Is this failure expected?  If so, is it something unique to the Emacs 
packaging, and could it be fixed?  (Before Emacs 28 was released, I was 
able to use a similar "--with-commit" option to build and install what 
was then the emacs-next package to get native-compilation support, 
keeping it updated with Emacs's master branch at the time.  It would be 
helpful if that could still be used by users rather than having to wait 
for an update to the package definition, especially in a case like this.)

Thanks for your work on Emacs in Guix.

--Adam

bug#71729: Emacs 29.4 emergency bugfix release

[Liliana Marie Prikler]

Am Samstag, dem 22.06.2024 um 19:52 -0500 schrieb Adam Porter:
> Hello,
> 
> Today an emergency bugfix release was made of Emacs v29.4.  It fixes
> an important security vulnerability.
Note: Security bugs should go to guix-security instead.  But thanks for
pointing out the new Emacs release, I've pushed an update. (Thus
marking this done)

> FWIW, I had hoped that I could install it by running:
> 
>    guix install --with-version=emacs=29.4 emacs
> 
> But that fails the validate-comp-integrity phase, showing that all of
> its tests fail, with every function being loaded in byte-compiled
> form instead of native-compiled.
Ah, yes, that is not something you can do with --with-version, as it
disregards our patches and everything.

> And despite my best efforts at comparing the emacs.git tags for 29.3
> and 29.4 to look for any relevant changes, and digging through the
> relevant source code, and scanning through the build logs, I can't
> find a cause for this problem.
> 
> Is this failure expected?  If so, is it something unique to the Emacs
> packaging, and could it be fixed?  (Before Emacs 28 was released, I
> was able to use a similar "--with-commit" option to build and install
> what was then the emacs-next package to get native-compilation
> support, keeping it updated with Emacs's master branch at the time. 
> It would be helpful if that could still be used by users rather than
> having to wait for an update to the package definition, especially in
> a case like this.)
I understand your pain, but I doubt there is a reasonable fix to this.
Perhaps the check should honour tests?, but then you'd disable all the
other tests as well as part of the build.  Maybe a --without-phase
option to the Guix CLI would be better?

As for how to work around this, you can do a more elaborate package
definition:

  (package
    (inherit emacs)
    (version NEW_VERSION)
    (source (origin (inherit (package-source emacs))
                    (uri NEW_URI))))

This should automatically apply our patches.  Or, you can locally run
`guix refresh -u emacs'.

Cheers

bug#71729: Emacs 29.4 emergency bugfix release

[Leo Famulari]

On Sun, Jun 23, 2024 at 10:39:18AM +0200, Liliana Marie Prikler wrote:
> Note: Security bugs should go to guix-security instead.  But thanks for
> pointing out the new Emacs release, I've pushed an update. (Thus
> marking this done)

I think that only secret security bugs should go to guix-security,
unless the policy has changed. Public issues should go to bug-guix.

bug#71729: Emacs 29.4 emergency bugfix release

[Adam Porter]

Hi Liliana,

On 6/23/24 03:39, Liliana Marie Prikler wrote:
> Am Samstag, dem 22.06.2024 um 19:52 -0500 schrieb Adam Porter:
>> Hello,
>>
>> Today an emergency bugfix release was made of Emacs v29.4.  It fixes
>> an important security vulnerability.
> Note: Security bugs should go to guix-security instead.  But thanks for
> pointing out the new Emacs release, I've pushed an update. (Thus
> marking this done)

Thanks.

If I may ask here, as it seems relevant and might help other users in 
the future:

A few minutes ago I ran "guix pull", but after it finished, "guix show 
emacs" still shows:

   name: emacs
   version: 29.3

Am I missing something?  e.g. the equivalents in Debian, like "apt show 
emacs" or "apt policy emacs", show both installed and available versions.

So as a user, how am I to know whether I'm using the latest version of a 
package?  I also tried "guix upgrade -n" (which updates substitute lists 
from the network, which can significantly delay its finishing for a 
simple check like this), and it shows:

   The following packages would be upgraded:
    emacs             (dependencies or package changed)

But maybe that's affected by the workaround I'm using (see below).

>> FWIW, I had hoped that I could install it by running:
>>
>>     guix install --with-version=emacs=29.4 emacs
>>
>> But that fails the validate-comp-integrity phase, showing that all of
>> its tests fail, with every function being loaded in byte-compiled
>> form instead of native-compiled.

> Ah, yes, that is not something you can do with --with-version, as it
> disregards our patches and everything.

Ah, I wish I had known that.  FWIW, looking at 
<https://guix.gnu.org/manual/en/html_node/Package-Transformation-Options.html>, 
I can't even find "--with-version" documented at all.  But besides that, 
none of them seem to explain that such options may discard parts of the 
package definition, such as patches (if any of those other options 
do--is it only "--with-version" that does?).  Does a documentation bug 
need to be filed about this?

> As for how to work around this, you can do a more elaborate package
> definition:
> 
>    (package
>      (inherit emacs)
>      (version NEW_VERSION)
>      (source (origin (inherit (package-source emacs))
>                      (uri NEW_URI))))
> 
> This should automatically apply our patches.  Or, you can locally run
> `guix refresh -u emacs'.

Thanks for the pointer.  I defined a package called "emacs-jit" (and a 
corresponding "emacs-minimal-jit") that comments out the JIT-disabling 
patches, so that I can still JIT-compile packages installed through 
Emacs, and it seems to be working fine.

Would you be willing to accept some kind of package definition like that 
being added to Guix, as an alternative to the main "emacs" package?  (I 
won't quibble over the name.)  I think that there are a significant 
number of users who would like to use Guix to keep Emacs up-to-date 
without sacrificing the ability to native-compile packages installed 
from within Emacs.  It would be nice to have this in Guix so that I 
wouldn't have to manually update the package definition according to 
upstream changes.

Thanks,
Adam

bug#71729: Emacs 29.4 emergency bugfix release

[Liliana Marie Prikler]

Hi Adam,

Am Donnerstag, dem 27.06.2024 um 08:57 -0500 schrieb Adam Porter:
> Thanks.
> 
> If I may ask here, as it seems relevant and might help other users in
> the future:
> 
> A few minutes ago I ran "guix pull", but after it finished, "guix
> show emacs" still shows:
> 
>    name: emacs
>    version: 29.3
> 
> Am I missing something?  e.g. the equivalents in Debian, like "apt
> show emacs" or "apt policy emacs", show both installed and available
> versions.
You're missing the graft, which apparently does not show up in "guix
show".  

> So as a user, how am I to know whether I'm using the latest version
> of a package?  I also tried "guix upgrade -n" (which updates
> substitute lists from the network, which can significantly delay its
> finishing for a simple check like this), and it shows:
> 
>    The following packages would be upgraded:
>     emacs             (dependencies or package changed)
> 
> But maybe that's affected by the workaround I'm using (see below).
FWIW, with emacs you can check (emacs-version).  More generally, this
is a bug – replacements ought to be announced somehow.

> > > FWIW, I had hoped that I could install it by running:
> > > 
> > >     guix install --with-version=emacs=29.4 emacs
> > > 
> > > But that fails the validate-comp-integrity phase, showing that
> > > all of
> > > its tests fail, with every function being loaded in byte-compiled
> > > form instead of native-compiled.
> 
> > Ah, yes, that is not something you can do with --with-version, as
> > it
> > disregards our patches and everything.
> 
> Ah, I wish I had known that.  FWIW, looking at 
> <
> https://guix.gnu.org/manual/en/html_node/Package-Transformation-Option
> s.html>, I can't even find "--with-version" documented at all.  But
> besides that, none of them seem to explain that such options may
> discard parts of the package definition, such as patches (if any of
> those other options do--is it only "--with-version" that does?). 
> Does a documentation bug need to be filed about this?
The info manual (which you can read locally) has both, as well as the
warning you seek.

> > As for how to work around this, you can do a more elaborate package
> > definition:
> > 
> >    (package
> >      (inherit emacs)
> >      (version NEW_VERSION)
> >      (source (origin (inherit (package-source emacs))
> >                      (uri NEW_URI))))
> > 
> > This should automatically apply our patches.  Or, you can locally
> > run `guix refresh -u emacs'.
> 
> Thanks for the pointer.  I defined a package called "emacs-jit" (and
> a corresponding "emacs-minimal-jit") that comments out the
> JIT-disabling patches, so that I can still JIT-compile packages
> installed through Emacs, and it seems to be working fine.
> 
> Would you be willing to accept some kind of package definition like
> that being added to Guix, as an alternative to the main "emacs"
> package? (I won't quibble over the name.)  I think that there are a
> significant number of users who would like to use Guix to keep Emacs
> up-to-date without sacrificing the ability to native-compile packages
> installed from within Emacs.  It would be nice to have this in Guix
> so that I wouldn't have to manually update the package definition
> according to upstream changes.
But then you'd be shifting the maintenance burden to us Guix.  We
already have enough Emacs variants to keep track of as-is, and adding
yet another orthogonal angle is not going to scale well.  Plus, for
this variant you'd lose all the benefits that Guix provides – I don't
see this as a reasonable thing to ship, to be honest.

Cheers