Uploaded image for project: 'Maven Shared Components'
  1. Maven Shared Components
  2. MSHARED-661

Remove manifest entry "Built-By: <username>" for reproducible builds

Details

    • Wish
    • Status: Closed
    • Minor
    • Resolution: Fixed
    • maven-archiver-3.3.0
    • maven-archiver-3.4.0
    • maven-archiver
    • None

    Description

      Maven-archiver automatically creates "Built-By: <username>", "Build-Jdk: <detailed JDK version>" and "Created-By: <Maven detailed version>" Manifest entries.

      In the frame of a reproducible build (cf. MNG-6276) these entries make the build not reproducible.

      Maven-archiver should propose an option to disable the creation of these non-reproducible manifest entries.

      Then if you want the usual value of Built-By, you must add the following entry

       <manifestEntries>
          <Built-by>${user.name}</Built-by>
        </manifestEntries>
      

      Attachments

        Issue Links

          Activity

            michael-o Michael Osipov added a comment -

            I'd be more than happy to drop this. Infact, I have proposed this in several other tickets because the information itself isn't really helpful. I wouldn't make them optional, but completely drop them. Everyone can readd them via POM.

            michael-o Michael Osipov added a comment - I'd be more than happy to drop this. Infact, I have proposed this in several other tickets because the information itself isn't really helpful. I wouldn't make them optional, but completely drop them. Everyone can readd them via POM.
            Zlika Zlika added a comment -

            I would not cry if these entries disappear
            I forgot another entry that could also disappear to ease build reproducibility : "Created-By" (who cares the exact Maven version?).

            Zlika Zlika added a comment - I would not cry if these entries disappear I forgot another entry that could also disappear to ease build reproducibility : "Created-By" (who cares the exact Maven version?).
            afloom Anders Hammar added a comment -

            I beg to differ. What JDK version and Maven version an artifact was built with is of interest. And that info is not available in the pom.

            afloom Anders Hammar added a comment - I beg to differ. What JDK version and Maven version an artifact was built with is of interest. And that info is not available in the pom.
            michael-o Michael Osipov added a comment -

            I somewhat second that what Anders have said because you need to have the same environment, thus Java version and Maven version to reproduce the build. The username is not necessary.

            michael-o Michael Osipov added a comment - I somewhat second that what Anders have said because you need to have the same environment, thus Java version and Maven version to reproduce the build. The username is not necessary.
            Zlika Zlika added a comment -

            That's true on a theoretical point of view. However in pratice you will have exactly the same build result with Maven 3.0 and Maven 3.5, and with jdk8u0 and jdk8u999. Adding this info just make the build more difficult to reproduce because you need to use exactly the same Maven and jdk versions, and this info is not easily available (you have to unpack the jar and look at the manifest, unless you use maven-enforcer-plugin to explicitly enforce the Maven and jdk versions). That's why I propose to have an option to disable all these automatically added manifest entries.

            Zlika Zlika added a comment - That's true on a theoretical point of view. However in pratice you will have exactly the same build result with Maven 3.0 and Maven 3.5, and with jdk8u0 and jdk8u999. Adding this info just make the build more difficult to reproduce because you need to use exactly the same Maven and jdk versions, and this info is not easily available (you have to unpack the jar and look at the manifest, unless you use maven-enforcer-plugin to explicitly enforce the Maven and jdk versions). That's why I propose to have an option to disable all these automatically added manifest entries.
            hboutemy Herve Boutemy added a comment - - edited

            from the beginning, I like these manifest entries since they give you info on some key facts on how the binary was done: I like traceability

            with Reproducible/Verifiable Builds https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318 , the general logic completely change with IMHO a more accurate/ambitious strategy: it's not just about traceability, but verifiability

            when you have verifiable builds, traceability of such details are not useful

            we don't have verifiable builds yet: that's why simply removing traceability is for me a little bit too early
            but adding an option to drop some traceability when you're working on verifiability, when traceability is causing issues to verifiability, is an approach I find consistent, isn't it?

            hboutemy Herve Boutemy added a comment - - edited from the beginning, I like these manifest entries since they give you info on some key facts on how the binary was done: I like traceability with Reproducible/Verifiable Builds https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318 , the general logic completely change with IMHO a more accurate/ambitious strategy: it's not just about traceability, but verifiability when you have verifiable builds, traceability of such details are not useful we don't have verifiable builds yet: that's why simply removing traceability is for me a little bit too early but adding an option to drop some traceability when you're working on verifiability, when traceability is causing issues to verifiability, is an approach I find consistent, isn't it?
            ebourg Emmanuel Bourg added a comment -

            Capturing information about the tools used to build the artifacts is important, because for achieving reproducibility one is supposed to reuse the same tools and dependencies that were originally used. However this information probably doesn't belong to the jar manifest. For example in Debian the build environment of a package is captured in a .buildinfo file deployed along the package. This file is then used to recreate an identical build environment. In the Maven world this could translate into an additional artifact detailing the relevant info about the build environment and deployed along the pom, or extra information added inside the pom at build time.

            I think it's fine to keep the Created-By and Built-Jdk attributes for now until another way of capturing the build environment is agreed upon. The Built-By attribute on the other hand should be removed right off, the identity of the person creating the artifact is already known with the GPG signature anyway.

            ebourg Emmanuel Bourg added a comment - Capturing information about the tools used to build the artifacts is important, because for achieving reproducibility one is supposed to reuse the same tools and dependencies that were originally used. However this information probably doesn't belong to the jar manifest. For example in Debian the build environment of a package is captured in a .buildinfo file deployed along the package. This file is then used to recreate an identical build environment. In the Maven world this could translate into an additional artifact detailing the relevant info about the build environment and deployed along the pom, or extra information added inside the pom at build time. I think it's fine to keep the Created-By and Built-Jdk attributes for now until another way of capturing the build environment is agreed upon. The Built-By attribute on the other hand should be removed right off, the identity of the person creating the artifact is already known with the GPG signature anyway.
            michael-o Michael Osipov added a comment -

            I think it's fine to keep the Created-By and Built-Jdk attributes for now until another way of capturing the build environment is agreed upon. The Built-By attribute on the other hand should be removed right off, the identity of the person creating the artifact is already known with the GPG signature anyway.

            I fully agree.

            michael-o Michael Osipov added a comment - I think it's fine to keep the Created-By and Built-Jdk attributes for now until another way of capturing the build environment is agreed upon. The Built-By attribute on the other hand should be removed right off, the identity of the person creating the artifact is already known with the GPG signature anyway. I fully agree.
            michael-o Michael Osipov added a comment -

            As agreed, Built-By will go, the rest will stay for now.

            michael-o Michael Osipov added a comment - As agreed, Built-By will go, the rest will stay for now.
            michael-o Michael Osipov added a comment -

            The issue with Built-Jdk is that it does not reflect toolchains. It implies that the same JDK is being used for building the source as running the Maven instance. I would consider dropping this one too in a separate ticket.

            michael-o Michael Osipov added a comment - The issue with Built-Jdk is that it does not reflect toolchains. It implies that the same JDK is being used for building the source as running the Maven instance. I would consider dropping this one too in a separate ticket.
            hudson Hudson added a comment -

            Build succeeded in Jenkins: Maven TLP » maven-archiver » MSHARED-661 #2

            See https://builds.apache.org/job/maven-box/job/maven-archiver/job/MSHARED-661/2/

            hudson Hudson added a comment - Build succeeded in Jenkins: Maven TLP » maven-archiver » MSHARED-661 #2 See https://builds.apache.org/job/maven-box/job/maven-archiver/job/MSHARED-661/2/
            michael-o Michael Osipov added a comment - Fixed with b1dd894993da4bb2fb724f4af36c2f86e9fed89c .
            hudson Hudson added a comment -

            Build succeeded in Jenkins: Maven TLP » maven-archiver » master #41

            See https://builds.apache.org/job/maven-box/job/maven-archiver/job/master/41/

            hudson Hudson added a comment - Build succeeded in Jenkins: Maven TLP » maven-archiver » master #41 See https://builds.apache.org/job/maven-box/job/maven-archiver/job/master/41/
            hboutemy Herve Boutemy added a comment -

            FYI, I just created some proposal for buildinfo files in Maven repositories: https://reproducible-builds.org/docs/jvm/

            hboutemy Herve Boutemy added a comment - FYI, I just created some proposal for buildinfo files in Maven repositories: https://reproducible-builds.org/docs/jvm/
            michael-o Michael Osipov added a comment -

            hboutemy, good idea. Can we have a seperate issue on that? I have some change proposals to make.

            michael-o Michael Osipov added a comment - hboutemy , good idea. Can we have a seperate issue on that? I have some change proposals to make.
            hboutemy Herve Boutemy added a comment -

            michael-o discussion on https://reproducible-builds.org/docs/jvm/ happens on Reproducible Builds mailing list
            and it's not focused on Maven, but more widely on the JVM: implementation by build tools will follow

            hboutemy Herve Boutemy added a comment - michael-o discussion on https://reproducible-builds.org/docs/jvm/ happens on Reproducible Builds mailing list and it's not focused on Maven, but more widely on the JVM: implementation by build tools will follow
            michael-o Michael Osipov added a comment -

            Unfortunately, this isn't a list I can follow due to my limited amount of time

            michael-o Michael Osipov added a comment - Unfortunately, this isn't a list I can follow due to my limited amount of time

            People

              michael-o Michael Osipov
              Zlika Zlika
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: