Re: [DISCUSS] configuration for Reproducible Builds

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] configuration for Reproducible Builds

Hervé BOUTEMY
regarding the property name, I had an idea:

why not do like we already did for  ${project.build.sourceEncoding}, ie. mimic
a future element in pom.xml, in build?

could be project.build.timestamp?

Le samedi 28 septembre 2019, 17:55:24 CEST Hervé BOUTEMY a écrit :

> Achieving Reproducible Builds require only one parameter: plugins that
> create zip or tar archives require a fixed timestamp for entries
>
> Putting that parameter as a pom property with a well known name and value
> format permits to share the configuration between every packaging plugin.
> This also has the advantage that child poms will inherit from parent value,
> and eventually override.
>
> The question is: *what property name and what value format should we keep?*
>
> For the PoC, I chose to extrapolate from a convention from Reproducible
> Builds project, which is very Linux-oriented: SOURCE_DATE_EPOCH environment
> variable, that I transformed into source-date-epoch property name, keeping
> the "date + %s" value
> https://reproducible-builds.org/docs/source-date-epoch/
>
>
> But I feel we can do a more user-readable solution by choosing another name
> and format, like "reproducible-build-timestamp" with an ISO-8601 combined
> date and time representation
>
>
> WDYT? Any other idea?
>
> Regards,
>
> Hervé
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] configuration for Reproducible Builds

Hervé BOUTEMY
Le dimanche 29 septembre 2019, 12:16:48 CEST Robert Scholte a écrit :
> I would think that all project.* properties represent the pom.xml and are
> immutable. To be more precise: the same pom.xml should effectively stay
> the same with every build.
+1

> Instead this seems more related the (maven)session, right?
no
It has to be reproducible from build to build = that's the objective.
That's why a value has to be recorded, whatever the exact value is.
A consequence is that the value won't be the effective build time, since it has
to be the same value next month, next year, or next century.
It has to be recorded one day, then stay for posterity.

Ideally, it will be recorded during a release process: that's why I imagine
that we'll have maven-release-plugin do an automated update.
But it can stay to a point in time: who cares of the exact value? As I already
said, to avoid a debate, some Reproducible Builds solutions just use
1970-01-01T00:00:00Z as timestamp: basic, but it works

Regards,

Hervé

>
> Robert
>
> On Sun, 29 Sep 2019 11:19:45 +0200, Hervé BOUTEMY <[hidden email]>
>
> wrote:
> > regarding the property name, I had an idea:
> >
> > why not do like we already did for  ${project.build.sourceEncoding}, ie.
> > mimic
> > a future element in pom.xml, in build?
> >
> > could be project.build.timestamp?
> >
> > Le samedi 28 septembre 2019, 17:55:24 CEST Hervé BOUTEMY a écrit :
> >> Achieving Reproducible Builds require only one parameter: plugins that
> >> create zip or tar archives require a fixed timestamp for entries
> >>
> >> Putting that parameter as a pom property with a well known name and
> >> value
> >> format permits to share the configuration between every packaging
> >> plugin.
> >> This also has the advantage that child poms will inherit from parent
> >> value,
> >> and eventually override.
> >>
> >> The question is: *what property name and what value format should we
> >> keep?*
> >>
> >> For the PoC, I chose to extrapolate from a convention from Reproducible
> >> Builds project, which is very Linux-oriented: SOURCE_DATE_EPOCH
> >> environment
> >> variable, that I transformed into source-date-epoch property name,
> >> keeping
> >> the "date + %s" value
> >> https://reproducible-builds.org/docs/source-date-epoch/
> >>
> >>
> >> But I feel we can do a more user-readable solution by choosing another
> >> name
> >> and format, like "reproducible-build-timestamp" with an ISO-8601
> >> combined
> >> date and time representation
> >>
> >>
> >> WDYT? Any other idea?
> >>
> >> Regards,
> >>
> >> Hervé
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] configuration for Reproducible Builds

Hervé BOUTEMY
In reply to this post by Hervé BOUTEMY
Le dimanche 29 septembre 2019, 12:29:47 CEST Karl Heinz Marbaise a écrit :

> Hi Hervé,
>
> On 29.09.19 11:19, Hervé BOUTEMY wrote:
> > regarding the property name, I had an idea:
> >
> > why not do like we already did for  ${project.build.sourceEncoding}, ie.
> > mimic a future element in pom.xml, in build?
> >
> > could be project.build.timestamp?
>
> This sounds like the best idea...
>
>
> This would mean to define something like this:
>
> <properties>
>    <project.build.timestamp>..</project.build.timestamp>
> </properties>
>
> But now there are coming up some questions:
>
> * Is that the real value to be used?
> * Or should it activate the mechanism ? (boolean?)
we can define both a boolean and a timestamp
but the timestamp de-facto means also a boolean: defined means true, undefined  
means false

>
> <properties>
>    <project.build.timestamp.usage>true</project.build.timestamp.usage>
> </properties>
>
>
> * Or should we use it by default and giving the user the opportunity
>    to overrite the current timestamp by fixed timestamp for building ?
>    This means we would define only the real time to be used during
>    building. No need for a kind of activation etc.
>    So you could call Maven via:
>
>    mvn -Dproject.build.timestamp=... package
>
>
> * Or do we need a combination of the above
>
>    First activate, define the format and the timestamp to be used.
>
>
> Furthermore do we need to define a format either which could look like this:
>
> <properties>
>    <project.build.timestamp.usage>true</project.build.timestamp.usage>
>    <project.build.timestamp>..</project.build.timestamp>
>    <project.build.timestamp.format>ISO-8601</project.build.timestamp.format>
> </properties>
letting the format as a third parameter is of course feasible, but adds
complexity: is it really necessary? Isn't ISO-8601 sufficient to you?

>
>
> Kind regards
> Karl Heinz Marbaise
>
> > Le samedi 28 septembre 2019, 17:55:24 CEST Hervé BOUTEMY a écrit :
> >> Achieving Reproducible Builds require only one parameter: plugins that
> >> create zip or tar archives require a fixed timestamp for entries
> >>
> >> Putting that parameter as a pom property with a well known name and value
> >> format permits to share the configuration between every packaging plugin.
> >> This also has the advantage that child poms will inherit from parent
> >> value,
> >> and eventually override.
> >>
> >> The question is: *what property name and what value format should we
> >> keep?*
> >>
> >> For the PoC, I chose to extrapolate from a convention from Reproducible
> >> Builds project, which is very Linux-oriented: SOURCE_DATE_EPOCH
> >> environment
> >> variable, that I transformed into source-date-epoch property name,
> >> keeping
> >> the "date + %s" value
> >> https://reproducible-builds.org/docs/source-date-epoch/
> >>
> >>
> >> But I feel we can do a more user-readable solution by choosing another
> >> name
> >> and format, like "reproducible-build-timestamp" with an ISO-8601 combined
> >> date and time representation
> >>
> >>
> >> WDYT? Any other idea?
> >>
> >> Regards,
> >>
> >> Hervé





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] configuration for Reproducible Builds

Hervé BOUTEMY
In reply to this post by Hervé BOUTEMY
perhaps I should basically show how Reproducible Builds was configured in the PoC:

1. in apache-parent:
https://github.com/apache/maven-apache-parent/commit/d379a72d07173c500be65fd6e549da1fedb46b5f
It's about 3 packaging plugins that have a version supporting Reproducible Builds
and one parameter: the timestamp to put on archive entries = the value of "now" when I commited the feature

2. in maven-parent:
https://github.com/apache/maven-parent/commit/d213125b171c8a2f7e4cbb74b713e11e0fd055dd
I just updated the parent POM
And chose to define a local value for timestamp, to override the value defined in parent
But honestly, who cares if the timestamp in zip file was 2019-09-21T16:03:05Z (the value inherited from parent) instead of 2019-09-21T16:15:16Z (the overridden value)?

3. in maven:
https://github.com/apache/maven/commit/d23d3b4fab9b3951177eac5bbfa109e990e95899
same as before: changed parent, and chose to define a local value for timestamp
Every commit after that is just little improvement or fixes because a few plugins don't yet bring reproducible output


This is exactly how I see Reproducible Builds for the future:
- select versions of plugins that bring reproducible output
- either inherit or define a local timestamp

et voilà, it's so easy (once plugins support)...

Regards,

Hervé

Le samedi 28 septembre 2019, 17:55:24 CEST Hervé BOUTEMY a écrit :

> Achieving Reproducible Builds require only one parameter: plugins that
> create zip or tar archives require a fixed timestamp for entries
>
> Putting that parameter as a pom property with a well known name and value
> format permits to share the configuration between every packaging plugin.
> This also has the advantage that child poms will inherit from parent value,
> and eventually override.
>
> The question is: *what property name and what value format should we keep?*
>
> For the PoC, I chose to extrapolate from a convention from Reproducible
> Builds project, which is very Linux-oriented: SOURCE_DATE_EPOCH environment
> variable, that I transformed into source-date-epoch property name, keeping
> the "date + %s" value
> https://reproducible-builds.org/docs/source-date-epoch/
>
>
> But I feel we can do a more user-readable solution by choosing another name
> and format, like "reproducible-build-timestamp" with an ISO-8601 combined
> date and time representation
>
>
> WDYT? Any other idea?
>
> Regards,
>
> Hervé
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]