GNU bug report logs - #40316
nss not reproducible

Previous Next

Full log

Message #102 received at 40316 <at> debbugs.gnu.org (full text, mbox):

From: Christina O'Donnell <cdo <at> mutix.org>
To: Vagrant Cascadian <vagrant <at> reproducible-builds.org>, 40316 <at> debbugs.gnu.org
Cc: zhengjunjie <at> iscas.ac.cn, steve <at> futurile.net
Subject: Re: [PATCH 3/6] gnu: nss: Make reproducible.
Date: Thu, 2 May 2024 13:51:34 +0100

Hi Vagrant,

On 26/04/2024 23:58, Vagrant Cascadian wrote:
> On 2024-04-26, Christina O'Donnell wrote:
>> gnu/packages/patches/nss-Disable-library-signing.patch: Disable library
>> signing to make the build reproducible.
>> gnu/packages/nss.scm (nss): Apply this new patch.
> Nice!

I have reordered my commits to first update to 3.99, before making nss 
reproducible. The more

This is similar to the approach that Nix takes,  though Nix adds a 
parameter that enables FIPS and shlibsign again. Is it worth adding a 
parameter to re-enable FIPS?

>> diff --git a/gnu/packages/patches/nss-Disable-library-signing.patch b/gnu/packages/patches/nss-Disable-library-signing.patch
>> new file mode 100644
>> index 00000000000..b488d29dcad
>> --- /dev/null
>> +++ b/gnu/packages/patches/nss-Disable-library-signing.patch
>> @@ -0,0 +1,67 @@
>> +From 4734b834755822f962af29e9395daa7338084e21 Mon Sep 17 00:00:00 2001
>> +Message-ID: <4734b834755822f962af29e9395daa7338084e21.1714059680.git.cdo <at> mutix.org>
>> +From: Christina O'Donnell <cdo <at> mutix.org>
>> +Date: Thu, 25 Apr 2024 16:35:50 +0100
>> +Subject: [PATCH] nss: Disable library signing.
>> +
>> +---
>> + nss/cmd/shlibsign/Makefile | 32 +-------------------------------
>> + 1 file changed, 1 insertion(+), 31 deletions(-)
> I think it would be good to explain why this patch is included, not just
> in the git commit message, but in the patch comments itself. I realize
> the patch actually includes a comment about non-determinism, but it is a
> bit lost in the diff.
Okay I've added a description to the v3 patch.
> Also, might be worth briefly explaining why disabling this feature is
> unlikely to break anything, etc.

I was actually wrong wrong about this on my v1 patch, that did break the 
FIPS tests. However disabling FIPS is what Nix does by default and all 
other tests pass without it.

I have noticed that Nix parameterizes on whether FIPS is enabled so 
users can re-enable FIPS if they need it for their use-cases. Is it 
worth doing something similar here, or would that add too much complexity?

> Curious if there might be some way to leave most of the code in place,
> disable it... otherwise on version updates it is more likely to result
> in conflicts with even minor changes...

I've shrunk the patches to be a few lines each.

Kind regards,

Christina


> live well,
>    vagrant

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.