You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by sebb <se...@gmail.com> on 2014/01/16 01:23:11 UTC
Re: svn commit: r1558509 - /httpcomponents/project-release-tools/trunk/build.gradle
On 15 January 2014 18:55, <gg...@apache.org> wrote:
> Author: ggregory
> Date: Wed Jan 15 18:55:09 2014
> New Revision: 1558509
>
> URL: http://svn.apache.org/r1558509
> Log:
> Feed the password to Maven through the CLI
>
> Modified:
> httpcomponents/project-release-tools/trunk/build.gradle
>
> Modified: httpcomponents/project-release-tools/trunk/build.gradle
> URL: http://svn.apache.org/viewvc/httpcomponents/project-release-tools/trunk/build.gradle?rev=1558509&r1=1558508&r2=1558509&view=diff
> ==============================================================================
> --- httpcomponents/project-release-tools/trunk/build.gradle (original)
> +++ httpcomponents/project-release-tools/trunk/build.gradle Wed Jan 15 18:55:09 2014
> @@ -247,7 +247,8 @@ if (rcTagFile.exists() && rcRevisionFile
> String name = getProductName(artifactId)
>
> println "Deploying ${name} ${releaseVer} based on ${rcQualifier}"
> - mvn.exec(checkoutRC.localDir, 'deploy', '-Prelease', '-Dmaven.test.skip=true')
> + mvn.exec(checkoutRC.localDir, 'deploy', '-Prelease', '-Dmaven.test.skip=true',
Could be just -DskipTests
> + '-Dgpg.passphrase=' + project.ext.'signing.password')
I think it is risky to insist that the password is passed in on the
command line, as it is easy to sniff on a shared system.
Current RMs I'm sure are aware of the risks, but I don't think this
should be left like this for ever - it sets a bad example.
I'm fairly sure it is not necessary - it should be possible to use gpg-agent.
At the very least, the password should be optional (i.e. only pass it
if it is actually provided).
But better not to encourage risky behaviour.
> }
> }
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: svn commit: r1558509
Posted by sebb <se...@gmail.com>.
On 16 January 2014 21:46, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Thu, 2014-01-16 at 16:43 +0000, sebb wrote:
>
> ...
>
>>
>> However, looking at the gradle wrapper I cannot work out how to easily
>> test signing without going through most of the release process.
>>
>
> Artifact signing is still done by Maven. The script merely starts Maven
> as a separate process. I could replace this task with Gradle but as far
> as I know it still does not support GPG integration, so signing
> credentials need to be sourced from a property file.
>
> I am not sure what is the best way froward here.
I was not suggesting replacing the gradle code.
However, I do need to know how to test Maven signing through gradle.
This may affect the way that Maven prompts for the password, so needs
to be tested.
And I don't really want to have to do most of a release just in order
to test this part of the gradle wrapper.
> Oleg
>
>> With Maven, it's trivial; just change to a valid project workspace and run:
>>
>> mvn package -DskipTests gpg:sign -Dgpg.keyname=xxx
>> or
>> mvn package -DskipTests gpg:sign -Pkeyprofile
>>
>> where the keyprofile includes the keyname (and potentially the
>> gpg.secretKeyring location) and is stored in settings.xml
>>
>>
>> > Oleg
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>> > For additional commands, e-mail: dev-help@hc.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>> For additional commands, e-mail: dev-help@hc.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: svn commit: r1558509
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2014-01-16 at 16:43 +0000, sebb wrote:
...
>
> However, looking at the gradle wrapper I cannot work out how to easily
> test signing without going through most of the release process.
>
Artifact signing is still done by Maven. The script merely starts Maven
as a separate process. I could replace this task with Gradle but as far
as I know it still does not support GPG integration, so signing
credentials need to be sourced from a property file.
I am not sure what is the best way froward here.
Oleg
> With Maven, it's trivial; just change to a valid project workspace and run:
>
> mvn package -DskipTests gpg:sign -Dgpg.keyname=xxx
> or
> mvn package -DskipTests gpg:sign -Pkeyprofile
>
> where the keyprofile includes the keyname (and potentially the
> gpg.secretKeyring location) and is stored in settings.xml
>
>
> > Oleg
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > For additional commands, e-mail: dev-help@hc.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: svn commit: r1558509
Posted by sebb <se...@gmail.com>.
On 16 January 2014 16:11, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Thu, 2014-01-16 at 00:23 +0000, sebb wrote:
>> On 15 January 2014 18:55, <gg...@apache.org> wrote:
>> > Author: ggregory
>> > Date: Wed Jan 15 18:55:09 2014
>> > New Revision: 1558509
>> >
>> > URL: http://svn.apache.org/r1558509
>> > Log:
>> > Feed the password to Maven through the CLI
>> >
>> > Modified:
>> > httpcomponents/project-release-tools/trunk/build.gradle
>> >
>> > Modified: httpcomponents/project-release-tools/trunk/build.gradle
>> > URL: http://svn.apache.org/viewvc/httpcomponents/project-release-tools/trunk/build.gradle?rev=1558509&r1=1558508&r2=1558509&view=diff
>> > ==============================================================================
>> > --- httpcomponents/project-release-tools/trunk/build.gradle (original)
>> > +++ httpcomponents/project-release-tools/trunk/build.gradle Wed Jan 15 18:55:09 2014
>> > @@ -247,7 +247,8 @@ if (rcTagFile.exists() && rcRevisionFile
>> > String name = getProductName(artifactId)
>> >
>> > println "Deploying ${name} ${releaseVer} based on ${rcQualifier}"
>> > - mvn.exec(checkoutRC.localDir, 'deploy', '-Prelease', '-Dmaven.test.skip=true')
>> > + mvn.exec(checkoutRC.localDir, 'deploy', '-Prelease', '-Dmaven.test.skip=true',
>>
>> Could be just -DskipTests
>>
>> > + '-Dgpg.passphrase=' + project.ext.'signing.password')
>>
>> I think it is risky to insist that the password is passed in on the
>> command line, as it is easy to sniff on a shared system.
>> Current RMs I'm sure are aware of the risks, but I don't think this
>> should be left like this for ever - it sets a bad example.
>> I'm fairly sure it is not necessary - it should be possible to use gpg-agent.
>>
>> At the very least, the password should be optional (i.e. only pass it
>> if it is actually provided).
>> But better not to encourage risky behaviour.
>>
>
> I do not think it is any more insecure than passing passwords at the
> command line which appears to be not uncommon in pure Maven world.
Unfortunately this is not the only example of bad practise in the Maven world.
> Naturally I am going to improve the scripts based on Gary's experience
> and feedback and remove this hack. We might have to mandate the use of
> ssh-agent for Windows though. With Linux Maven deploy plugin is able to
> read passphrase from console just fine. This does not seem to work with
> Windows cmd.exe
GPG includes GPG agent which Maven gpg:sign can easily use; it pops up
a Pinentry dialog.
> The trouble is my family no longer own a single Windows PC and I cannot
> test the scripts myself.
However Gary and I have Windows systems.
I'm happy to test changes.
However, looking at the gradle wrapper I cannot work out how to easily
test signing without going through most of the release process.
With Maven, it's trivial; just change to a valid project workspace and run:
mvn package -DskipTests gpg:sign -Dgpg.keyname=xxx
or
mvn package -DskipTests gpg:sign -Pkeyprofile
where the keyprofile includes the keyname (and potentially the
gpg.secretKeyring location) and is stored in settings.xml
> Oleg
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: svn commit: r1558509
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2014-01-16 at 00:23 +0000, sebb wrote:
> On 15 January 2014 18:55, <gg...@apache.org> wrote:
> > Author: ggregory
> > Date: Wed Jan 15 18:55:09 2014
> > New Revision: 1558509
> >
> > URL: http://svn.apache.org/r1558509
> > Log:
> > Feed the password to Maven through the CLI
> >
> > Modified:
> > httpcomponents/project-release-tools/trunk/build.gradle
> >
> > Modified: httpcomponents/project-release-tools/trunk/build.gradle
> > URL: http://svn.apache.org/viewvc/httpcomponents/project-release-tools/trunk/build.gradle?rev=1558509&r1=1558508&r2=1558509&view=diff
> > ==============================================================================
> > --- httpcomponents/project-release-tools/trunk/build.gradle (original)
> > +++ httpcomponents/project-release-tools/trunk/build.gradle Wed Jan 15 18:55:09 2014
> > @@ -247,7 +247,8 @@ if (rcTagFile.exists() && rcRevisionFile
> > String name = getProductName(artifactId)
> >
> > println "Deploying ${name} ${releaseVer} based on ${rcQualifier}"
> > - mvn.exec(checkoutRC.localDir, 'deploy', '-Prelease', '-Dmaven.test.skip=true')
> > + mvn.exec(checkoutRC.localDir, 'deploy', '-Prelease', '-Dmaven.test.skip=true',
>
> Could be just -DskipTests
>
> > + '-Dgpg.passphrase=' + project.ext.'signing.password')
>
> I think it is risky to insist that the password is passed in on the
> command line, as it is easy to sniff on a shared system.
> Current RMs I'm sure are aware of the risks, but I don't think this
> should be left like this for ever - it sets a bad example.
> I'm fairly sure it is not necessary - it should be possible to use gpg-agent.
>
> At the very least, the password should be optional (i.e. only pass it
> if it is actually provided).
> But better not to encourage risky behaviour.
>
I do not think it is any more insecure than passing passwords at the
command line which appears to be not uncommon in pure Maven world.
Naturally I am going to improve the scripts based on Gary's experience
and feedback and remove this hack. We might have to mandate the use of
ssh-agent for Windows though. With Linux Maven deploy plugin is able to
read passphrase from console just fine. This does not seem to work with
Windows cmd.exe
The trouble is my family no longer own a single Windows PC and I cannot
test the scripts myself.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org