On 13 December 2011 13:53, William Speirs <wspe...@apache.org> wrote:
> On Tue, Dec 13, 2011 at 12:16 AM, Gary Gregory <garydgreg...@gmail.com> wrote:
>> Did you do the whole master pass phrase/obfuscated stuff that the top
>> of the Using Nexus wiki points to?
>
> I did not do this at first, but I have since tried. I setup my
> settings-security.xml file as show on the wiki page, and added the
> encrypted passwords to my settings.xml file. Still doesn't work.
>
> Below is my entire settings.xml file (with passwords removed). By
> adding the <mavenExecutorId> element, it will not hang but prompt me
> for a password if it's not supplied via <gpg.passphrase>. However,
> even when I type my passphrase in, it still rejects it. Again, if I
> use gpg -c somefile.txt and type in that same passphrase, everything
> works.
>
> I'm testing this by running: mvn -Prc,apache package gpg:sign
Not sure what the rc profile does compared with the release profile.
What version of GPG are you using?
> And I keep getting:
>
> [INFO] [gpg:sign {execution: default-cli}]
> gpg: skipped "B0EC1E65": bad passphrase
> gpg: signing failed: bad passphrase
>
> I'm at a loss at this point...
>
> Bill-
>
> * settings.xml *
>
> <?xml version="1.0"?>
> <settings xmlns="http://maven.apache.org/SETTINGS/1.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd";>
> <servers>
> <server>
> <id>apache.releases</id>
> <username>wspeirs</username>
> <password>{my encrypted Apache password here}</password>
> <filePermissions>664</filePermissions>
> <directoryPermissions>775</directoryPermissions>
> </server>
> <server>
> <id>apache.website</id>
> <username>wspeirs</username>
> <password>{my encrypted Apache password here}</password>
> <filePermissions>664</filePermissions>
> <directoryPermissions>775</directoryPermissions>
> </server>
> <server>
> <id>apache.snapshots</id>
> <username>wspeirs</username>
> <password>{my encrypted Apache password here}</password>
> <filePermissions>664</filePermissions>
> <directoryPermissions>775</directoryPermissions>
> </server>
> </servers>
> <profiles>
> <profile>
> <id>apache</id>
> <activation>
> <activeByDefault>false</activeByDefault>
> </activation>
> <properties>
> <mavenExecutorId>forked-path</mavenExecutorId>
> <commons.deployment.protocol>scp</commons.deployment.protocol>
> <gpg.keyname>B0EC1E65</gpg.keyname>
> <gpg.passphrase>{my encrypted GPG password here}</gpg.passphrase>
> </properties>
> </profile>
> </profiles>
> </settings>
I use an external GPG database (on a USB stick); but for test purposes
I have a dummy signing key using a local database.
<profile>
<id>keyTest</id>
<properties>
<gpg.keyname>Deploy Test User</gpg.keyname>
<gpg.passphrase>password in clear</gpg.passphrase>
<gpg.useagent>false</gpg.useagent>
</properties>
</profile>
Here's the real key profile:
<profile>
<id>keyReal</id>
<properties>
<gpg.keyname>4FAD5F62</gpg.keyname>
<gpg.secretKeyring>/path/to/secring.gpg</gpg.secretKeyring>
<!-- must be on the execution path -->
<gpg.executable>gpg2</gpg.executable>
<gpg.useagent>false</gpg.useagent>
</properties>
</profile>
I found gpg2 worked better for me, but I still use gpg1 sometimes.
The real gpg password is not stored anywhere; I have to enter it at run-time.
For example, if I remove the test password, I see the following:
mvn package gpg:sign -PkeyTest
...
[INFO] [jar:jar {execution: default-jar}]
[INFO] [jar:test-jar {execution: default}]
[INFO] [gpg:sign {execution: default-cli}]
GPG Passphrase: * <= enter the passphrase here.
The same applies to gpg1 and gpg2, but if I use gpg2, I also get the
following warnings:
gpg: WARNING: "--no-use-agent" is an obsolete option - it has no effect
gpg: WARNING: "--no-use-agent" is an obsolete option - it has no effect
gpg: WARNING: "--no-use-agent" is an obsolete option - it has no effect
The settings-security.xml file is not needed for GPG passwords.
And I've not tried it.
I suggest you set up a dummy local key and password as per my example.
Get that working, then try specifying the secret key ring to point to
the dummy key.
When that works, drop the password.
Then fix the secret key ring tag to point to your real secret key ring.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
