Guix release broken without substitutes on ungrafted openssl

Guix release broken without substitutes on ungrafted openssl

[Greg Hogan]

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

Guix,

Installing guix from source fails on the build of openssl@1.1.1l. I
see the same error on my working system (log attached) when executing
the command below. The issue looks to be caused by OpenSSL's expired
test certs fixed in 1.1.1p [0]. Guix currently grafts openssl 1.1.1s
but it seems grafts are not part of the bootstrap process (substitutes
disabled).

If this is the correct diagnosis then we should be ungrafting before
future releases any bootstrap dependencies relating to build failures
(not necessarily for security updates).

My personal fix was to adapt my installation script to iteratively set
back then reset the clock, as openssl only builds in the past but
diffutils-boot0 then fails due to newly created files being older than
distributed files.

Greg

[0] https://github.com/openssl/openssl/pull/18446

--8<---------------cut here---------------start------------->8---
$ guix build --no-grafts openssl@1.1.1l
[...]
Test Summary Report
-------------------
../test/recipes/80-test_ssl_new.t                (Wstat: 256 Tests: 29
Failed: 1)
  Failed test:  12
  Non-zero exit status: 1
Files=158, Tests=2636, 285 wallclock secs ( 1.86 usr  0.16 sys +
104.62 cusr  8.73 csys = 115.37 CPU)
Result: FAIL
make[1]: *** [Makefile:208: _tests] Error 1
make[1]: Leaving directory '/tmp/guix-build-openssl-1.1.1l.drv-0/openssl-1.1.1l'
make: *** [Makefile:205: tests] Error 2

Test suite failed, dumping logs.
error: in phase 'check': uncaught exception:
%exception #<&invoke-error program: "make" arguments: ("test")
exit-status: 2 term-signal: #f stop-signal: #f>
phase `check' failed after 285.6 seconds
command "make" "test" failed with status 2
builder for `/gnu/store/bb29cw1ngmyja9jc1sjf65m91x04kcqz-openssl-1.1.1l.drv'
failed with exit code 1
build of /gnu/store/bb29cw1ngmyja9jc1sjf65m91x04kcqz-openssl-1.1.1l.drv failed
View build log at
'/var/log/guix/drvs/bb/29cw1ngmyja9jc1sjf65m91x04kcqz-openssl-1.1.1l.drv.gz'.
guix build: error: build of
`/gnu/store/bb29cw1ngmyja9jc1sjf65m91x04kcqz-openssl-1.1.1l.drv'
failed
--8<---------------cut here---------------end--------------->8---

[-- Attachment #2: 29cw1ngmyja9jc1sjf65m91x04kcqz-openssl-1.1.1l.drv.gz --]
[-- Type: application/gzip, Size: 54586 bytes --]

Re: Guix release broken without substitutes on ungrafted openssl

[Leo Famulari]

On Wed, Feb 15, 2023 at 12:15:21PM -0500, Greg Hogan wrote:
> Installing guix from source fails on the build of openssl@1.1.1l. I
> see the same error on my working system (log attached) when executing
> the command below. The issue looks to be caused by OpenSSL's expired
> test certs fixed in 1.1.1p [0]. Guix currently grafts openssl 1.1.1s
> but it seems grafts are not part of the bootstrap process (substitutes
> disabled).
> 
> If this is the correct diagnosis then we should be ungrafting before
> future releases any bootstrap dependencies relating to build failures
> (not necessarily for security updates).
> 
> My personal fix was to adapt my installation script to iteratively set
> back then reset the clock, as openssl only builds in the past but
> diffutils-boot0 then fails due to newly created files being older than
> distributed files.

Thanks for the notes.

I do believe this has been discussed previously, to be found in the
archives!

In general, SSL/TLS implementations keep making this... unfortunate
mistake in their test suites.

It only really affects distros like Guix or Nix, so it's our problem to
fix.

I'd guess it's happened 4 times in the last several years.

It's one of several reasons that rebuilding old Guix releases actually
approaches being a Hard Problem.

Re: Guix release broken without substitutes on ungrafted openssl

[Greg Hogan]

On Wed, Feb 15, 2023 at 1:33 PM Leo Famulari <leo@famulari.name> wrote:
>
> It only really affects distros like Guix or Nix, so it's our problem to
> fix.

I forgot to mention that I also needed to switch the pull url from
https to http, otherwise git would fail on certificate verification. I
believe this is secure with Guix handling the git authentication.

I see the same openssl@1.1.1l error when building with the system
clock set to 2022/12/19, the date of the 1.4.0 release, so it appears
that the release was never bootstrappable without hijinks.

For the general case perhaps there could be a way to describe the
build environment similar to the manifest and channels. Could a build
date be specified and faketime used similar to how Guix makes use of
fakeroot? Perhaps this has already been proposed in the archive.

Greg

Re: Guix release broken without substitutes on ungrafted openssl

[Simon Tournier]

Hi,

On Wed, 15 Feb 2023 at 13:33, Leo Famulari <leo@famulari.name> wrote:

> I'd guess it's happened 4 times in the last several years.
>
> It's one of several reasons that rebuilding old Guix releases actually
> approaches being a Hard Problem.

The issue is from the impure world. ;-)

Well, yeah it would probably be difficult to install from scratch Guix
v1.0 in some future.

However, the hope is that,

    guix time-machine --commit=v1.0 -- <command>

using distant future Guix to run <command> from Guix v1.0.  The distant
future Guix should be able to deal with the distant future impure world
and populate for the past <command> running inside a pure world.

For sure, it is a Hard Problem.  As I like to say when presenting “guix
time-machine”, it is a real world experiment, probably unique, to know
what is the size of the time frame where reproducible time-travel is
possible.  I try to explain that this reproducible time-travel requires
three conditions:

 1. source code availability
 2. Linux kernel compatibility
 3. hardware compatibility

Now, I would add:

 4. being able to communicate with the world via the network


Cheers,
simon

Re: Guix release broken without substitutes on ungrafted openssl

[Simon Tournier]

Hi,

I overlooked the issue.  Here, it is about just building because the
test suite is time-dependant.  Arf!

IHMO, it does not change my previous but unrelated message. :-)

Cheers,
simon

Re: Guix release broken without substitutes on ungrafted openssl

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> skribis:

> On Wed, Feb 15, 2023 at 12:15:21PM -0500, Greg Hogan wrote:
>> Installing guix from source fails on the build of openssl@1.1.1l. I
>> see the same error on my working system (log attached) when executing
>> the command below. The issue looks to be caused by OpenSSL's expired
>> test certs fixed in 1.1.1p [0]. Guix currently grafts openssl 1.1.1s
>> but it seems grafts are not part of the bootstrap process (substitutes
>> disabled).
>> 
>> If this is the correct diagnosis then we should be ungrafting before
>> future releases any bootstrap dependencies relating to build failures
>> (not necessarily for security updates).
>> 
>> My personal fix was to adapt my installation script to iteratively set
>> back then reset the clock, as openssl only builds in the past but
>> diffutils-boot0 then fails due to newly created files being older than
>> distributed files.
>
> Thanks for the notes.
>
> I do believe this has been discussed previously, to be found in the
> archives!

Here: https://issues.guix.gnu.org/58650

I think the most viable/easily feasible option would be to run OpenSSL’s
tests under ‘datefudge’, as discussed in the issue above.

Ludo’.

Re: Guix release broken without substitutes on ungrafted openssl

[Aleksandr Vityazev]

Hi, 

On 2023-02-15, 12:15 -0500, Greg Hogan <code@greghogan.com> wrote:

> Guix,
>
> Installing guix from source fails on the build of openssl@1.1.1l. I
> see the same error on my working system (log attached) when executing
> the command below. The issue looks to be caused by OpenSSL's expired
> test certs fixed in 1.1.1p [0]. Guix currently grafts openssl 1.1.1s
> but it seems grafts are not part of the bootstrap process (substitutes
> disabled).
>
> If this is the correct diagnosis then we should be ungrafting before
> future releases any bootstrap dependencies relating to build failures
> (not necessarily for security updates).
>
> My personal fix was to adapt my installation script to iteratively set
> back then reset the clock, as openssl only builds in the past but
> diffutils-boot0 then fails due to newly created files being older than
> distributed files.
>
> Greg

I was recently building a deb pack of guix for riscv and encountered the
same problem, so far I just turned off the tests for openssl@1.1.1l

-- 
Best regards,
Aleksandr Vityazev