From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from einhorn-mail-out.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) by sourceware.org (Postfix) with ESMTPS id C5FE33858C66 for ; Wed, 19 Jul 2023 10:55:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C5FE33858C66 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=debian.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=debian.org X-Envelope-From: doko@debian.org X-Envelope-To: Received: from authenticated.user (localhost [127.0.0.1]) by einhorn.in-berlin.de with ESMTPSA id 36JAswP73309911 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT) for ; Wed, 19 Jul 2023 12:54:58 +0200 Message-ID: <0c22e147-aa0c-12ae-24e0-4f770948054d@debian.org> Date: Wed, 19 Jul 2023 12:54:58 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US To: binutils From: Matthias Klose Subject: [patch] objcopy embeds the current time and ignores SOURCE_DATE_EPOCH making the output unreproducible Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,FORGED_SPF_HELO,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: This is forwarded from https://bugs.debian.org/1040450 is this suitable upstream, or should it be kept as a local patch? SOURCE_DATE_EPOCH is also respected in GCC upstream. Hi, steps to reproduce the unreproducibility: $ objcopy /usr/lib/systemd/boot/efi/linuxaa64.efi.stub bootaa64_1 $ objcopy /usr/lib/systemd/boot/efi/linuxaa64.efi.stub bootaa64_2 $ cmp bootaa64_1 bootaa64_2 bootaa64_1 bootaa64_2 differ: byte 137, line 1 The resulting bootaa64.efi will have the local time embedded which makes it unreproducible unless faketime is used. Setting SOURCE_DATE_EPOCH or adding --enable-deterministic-archives does not make a difference. I identified the part of the code that generates this timestamp and pasted a preliminary patch fixing this issue to the end of this email. With that patch, setting SOURCE_DATE_EPOCH=0 results in a file with: $ objdump -x bootaa64.efi [...] Time/Date Thu Jan 1 01:00:00 1970 Since building binutils takes 7.4 hours on my machine and since I have never interacted with binutils upstream before, I'd appreciate if you could take it from here and see that this problem gets fixed in binutils upstream the way that its developers like to see this fixed. Thanks! cheers, josch --- a/bfd/peXXigen.c +++ b/bfd/peXXigen.c @@ -847,9 +847,17 @@ _bfd_XXi_only_swap_filehdr_out (bfd * ab /* Use a real timestamp by default, unless the no-insert-timestamp option was chosen. */ - if ((pe_data (abfd)->timestamp) == -1) - H_PUT_32 (abfd, time (0), filehdr_out->f_timdat); - else + if ((pe_data (abfd)->timestamp) == -1) { + time_t now; + char *source_date_epoch; + source_date_epoch = getenv("SOURCE_DATE_EPOCH"); + if (source_date_epoch) { + now = (time_t)strtoll(source_date_epoch, NULL, 10); + } else { + now = time(NULL); + } + H_PUT_32 (abfd, now, filehdr_out->f_timdat); + } else H_PUT_32 (abfd, pe_data (abfd)->timestamp, filehdr_out->f_timdat); PUT_FILEHDR_SYMPTR (abfd, filehdr_in->f_symptr,