From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?G=C3=A1bor?= Boskovits Subject: bug#22533: Python bytecode reproducibility Date: Sun, 4 Mar 2018 10:21:17 +0100 Message-ID: References: <20160202051544.GA11744@jasmine> <87bmqfu44s.fsf@fastmail.com> <87606c23bq.fsf@elephly.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a1144a158521715056692bbd8" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:49096) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1esPqI-0004f8-Gh for bug-guix@gnu.org; Sun, 04 Mar 2018 04:22:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1esPqE-0001H0-BT for bug-guix@gnu.org; Sun, 04 Mar 2018 04:22:06 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:35592) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1esPqE-0001GV-7d for bug-guix@gnu.org; Sun, 04 Mar 2018 04:22:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1esPqD-0007nk-Sj for bug-guix@gnu.org; Sun, 04 Mar 2018 04:22:01 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87606c23bq.fsf@elephly.net> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Ricardo Wurmus Cc: 22533@debbugs.gnu.org --001a1144a158521715056692bbd8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2018-03-03 23:37 GMT+01:00 Ricardo Wurmus : > Hi Guix, > > Marius Bakke writes: > > > It would be great to revive this longstanding bug! > > Indeed. > > Here=E2=80=99s another attempt. As far as I understand, the timestamp in= the > pyc files only affects the header. > > Up until Python 3.6 (incl) the header looks like this: > > magic | timestamp | size > > Since Python 3.7 the header may either contain a timestamp or a hash: > > magic | 00000000000000000000000000000000 | timestamp | size > magic | 00000000000000000000000000000001 | hash | size > > This means we likely won=E2=80=99t have this problem any more with Python= 3.7. > For Python 3.6 I guess we could add a final build phase that overwrites > the timestamp in the *binary*. This needs to happen before any of the > compiled files are wrapped up in a wheel. > > Should we just wait for Python 3.7 which is expected to be released in > June 2018? We=E2=80=99d still have to deal with this problem in Python 2= , > though. > > Is it a bad idea to override the timestamps in the generated binaries? > I think that we could avoid the recency check then, which was an > obstacle to resetting the timestamps of the source files. -- > Ricardo > > GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC > https://elephly.net > > Nix had this issue, it seems they have a python 3.5 solution, which should be easy to adopt: https://github.com/NixOS/nixpkgs/issues/22570. WDYT? --001a1144a158521715056692bbd8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
2018= -03-03 23:37 GMT+01:00 Ricardo Wurmus <rekado@elephly.net>:=
Hi Guix,

Marius Bakke <mbakke@fastmail.com= > writes:

> It would be great to revive this longstanding bug!

Indeed.

Here=E2=80=99s another attempt.=C2=A0 As far as I understand, the timestamp= in the
pyc files only affects the header.

Up until Python 3.6 (incl) the header looks like this:

=C2=A0 magic | timestamp | size

Since Python 3.7 the header may either contain a timestamp or a hash:

=C2=A0 magic | 00000000000000000000000000000000 | timestamp | size
=C2=A0 magic | 00000000000000000000000000000001 | hash=C2=A0 =C2=A0 = =C2=A0 | size

This means we likely won=E2=80=99t have this problem any more with Python 3= .7.
For Python 3.6 I guess we could add a final build phase that overwrites
the timestamp in the *binary*.=C2=A0 This needs to happen before any of the=
compiled files are wrapped up in a wheel.

Should we just wait for Python 3.7 which is expected to be released in
June 2018?=C2=A0 We=E2=80=99d still have to deal with this problem in Pytho= n 2,
though.

Is it a bad idea to override the timestamps in the generated binaries?
I think that we could avoid the recency check then, which was an
obstacle to resetting the timestamps of the source files.
--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6=C2=A0 2150 197A 5888 235F ACAC
https:= //elephly.net


Nix had this issue, it seems they have= a python 3.5 solution, which
WDYT?

--001a1144a158521715056692bbd8--