NixOS / nixpkgs

Nix Packages collection & NixOS
MIT License
18.38k stars 14.33k forks source link

gnome.nautilus: leaks build date into metainfo #313164

Open raboof opened 6 months ago

raboof commented 6 months ago

Building this package multiple times does not yield bit-by-bit identical results, complicating the detection of Continuous Integration (CI) breaches. For more information on this issue, visit reproducible-builds.org.

Fixing bit-by-bit reproducibility also has additional advantages, such as avoiding hard-to-reproduce bugs, making content-addressed storage more effective and reducing rebuilds in such systems.

Steps To Reproduce

In the following steps, replace <package> with the canonical name of the package.

1. Build the package

This step will build the package. Specific arguments are passed to the command to keep the build artifacts so we can compare them in case of differences.

Execute the following command:

nix-build '<nixpkgs>' -A gnome3.nautilus && nix-build '<nixpkgs>' -A gnome3.nautilus --check --keep-failed

Or using the new command line style:

nix build nixpkgs#gnome3.nautilus && nix build nixpkgs#gnome3.nautilus --rebuild --keep-failed

2. Compare the build artifacts

If the previous command completes successfully, no differences were found and there's nothing to do, builds are reproducible. If it terminates with the error message error: derivation '<X>' may not be deterministic: output '<Y>' differs from '<Z>', use diffoscope to investigate the discrepancies between the two build outputs. You may need to add the --exclude-directory-metadata recursive option to ignore files and directories metadata (e.g. timestamp) differences.

nix run nixpkgs#diffoscopeMinimal -- --exclude-directory-metadata recursive <Y> <Z>

3. Examine the build log

To examine the build log, use:

nix-store --read-log $(nix-instantiate '<nixpkgs>' -A gnome3.nautilus)

Or with the new command line style:

nix log $(nix path-info --derivation nixpkgs#gnome3.nautilus)

Additional context

Diffoscope shows the build uses the build date (rather than the source date) as the 'release date' in org.gnome.Nautilus.metainfo.xml:

│ │ │ ├── +++ /nix/store/53yfm1x6wpbh3qc3n4q24gd10fzly3v4-nautilus-46.1.check/share/metainfo/org.gnome.Nautilus.metainfo.xml
│ │ │ │ @@ -291,15 +291,15 @@
│ │ │ │    # For stable releases:
│ │ │ │      <release version="46.1" type="stable" date="YYYY-MM-DD"/>
│ │ │ │  
│ │ │ │    # For Unstable (alpha, beta, rc) releases:
│ │ │ │      <release version="46.1" type="development" date="YYYY-MM-DD"/>
│ │ │ │  
│ │ │ │    # Between releases (at post-release version bump):
│ │ │ │ -    <release version="46.1" date="2024-05-17"/>
│ │ │ │ +    <release version="46.1" date="2024-05-20"/>
│ │ │ │    -->
│ │ │ │    <releases>
│ │ │ │      <release version="46.1" type="stable" date="2024-04-21"/>
│ │ │ │    </releases>
│ │ │ │    <project_group>GNOME</project_group>
│ │ │ │    <project_license>GPL-3.0-or-later</project_license>
│ │ │ │    <developer id="org.gnome">

/cc @bobby285271 @hedning @jtojnar @dasj19


Add a :+1: reaction to issues you find important.

jtojnar commented 6 months ago

This was fixed in https://gitlab.gnome.org/GNOME/nautilus/-/commit/b7e44006b66b2aff2f6c51afb6100b3bab40557c and reverted in https://gitlab.gnome.org/GNOME/nautilus/-/commit/979891166ad36e3352322e22f23b3cd20b0a7ff1

raboof commented 6 months ago

Interesting! I wonder if they'd be open to determining build_date based on SOURCE_DATE_EPOCH

jtojnar commented 6 months ago

I would argue that the dynamic releases as introduced in https://gitlab.gnome.org/GNOME/nautilus/-/commit/5a4fc5664e05f7633894ebb564a7e0b0e73c2e0f should not be used in stable releases in the first place. Instead the stable versions should be added as suggested by the comment in https://gitlab.gnome.org/GNOME/nautilus/-/commit/979891166ad36e3352322e22f23b3cd20b0a7ff. Ideally with release notes (example) so that libadwaita can display what’s new in the about dialogue. (And generate the NEWS file from the XML then.)

And for snapshots, it should use the commit date, not the current or fake one. That can be easily, if uglily obtained in Meson:

vcs_tag(
  command: ['git', 'show', '-s', '--format=%cs'],
  input: configure_file(
    input: files('org.gnome.Nautilus.appdata.xml.in.in.in'),
    output: 'org.gnome.Nautilus.appdata.xml.in.in',
    configuration: appdata_conf
  ),
  output:'gnome.Nautilus.appdata.xml.in',
  replace_string:'@BUILD_DATE@',
)

By the way, looks like GTK dropped the date altogether but that probably makes it invalid AppStream file.