Mojo RPM Plugin

Allow specifying the gpg passphrase when signing the RPM i.e. ${gpg.passphrase}

Details

  • Type: New Feature New Feature
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.0-beta-3
  • Fix Version/s: 2.0-beta-4
  • Component/s: rpm
  • Labels:
    None
  • Number of attachments :
    0

Description

This would allow automation of building signed rpms, where the $

{gpg.passphrase}

could be stored in settings.xml for security reasons.

I understand this may be a difficult task since rpmbuild itself does not accept a passphrase as a passthrough to gpg. Some trickery may be required, but it would be an excellent feature to use with tools such as Spacewalk, which requires a signed RPM to deploy.

Using a gpg-agent to cache the passphrase is possibly an option but the cache expires.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Brett Okken added a comment -

Would something like this[1] be acceptable?

It would require that expect be installed, but does not look terribly difficult. It may also mean changing the signing strategy a bit to build the rpm and then sign it, rather than build and sign all in in step.

[1] - http://aaronhawley.livejournal.com/10615.html

Show
Brett Okken added a comment - Would something like this [1] be acceptable? It would require that expect be installed, but does not look terribly difficult. It may also mean changing the signing strategy a bit to build the rpm and then sign it, rather than build and sign all in in step. [1] - http://aaronhawley.livejournal.com/10615.html
Hide
Permalink
Wendy Smoak added a comment -

There is already a gpg plugin that can create signatures for all the artifacts attached to the build.

If it can't be used directly, maybe some code can be borrowed.

Show
Wendy Smoak added a comment - There is already a gpg plugin that can create signatures for all the artifacts attached to the build. If it can't be used directly, maybe some code can be borrowed.
Hide
Permalink
Luke Forehand added a comment -

Brett, this is exactly what I was thinking. The signing could happen after the RPM build. I don't think requiring expect is a big deal.

Wendy, I did infact attempt to use the gpg plugin to perform the signing of the RPM after the rpm build, but I couldn't get the gpg plugin to actually sign the rpm, it just placed ascii signature files next to the rpm. Maybe I was doing something wrong.

Show
Luke Forehand added a comment - Brett, this is exactly what I was thinking. The signing could happen after the RPM build. I don't think requiring expect is a big deal. Wendy, I did infact attempt to use the gpg plugin to perform the signing of the RPM after the rpm build, but I couldn't get the gpg plugin to actually sign the rpm, it just placed ascii signature files next to the rpm. Maybe I was doing something wrong.
Hide
Permalink
Brett Okken added a comment -

The other problem is that your passphrase is going to be visible in plain text if you run maven in debug mode (i.e. mvn package -X).

The only way I see around that is to utilize a "complex" wrapper object for the keyPassphrase attribute of the MOJO. The draw back to that, however, is that the property $

{gpg.passphrase} would not be automagically linked to the attribute. Rather you would have to put it in your pom:

<keyPassphrase>
<passphrase>${gpg.passphrase}

</passphrase>
</keyPassphrase>

Show
Brett Okken added a comment - The other problem is that your passphrase is going to be visible in plain text if you run maven in debug mode (i.e. mvn package -X). The only way I see around that is to utilize a "complex" wrapper object for the keyPassphrase attribute of the MOJO. The draw back to that, however, is that the property $ {gpg.passphrase} would not be automagically linked to the attribute. Rather you would have to put it in your pom: <keyPassphrase> <passphrase>${gpg.passphrase} </passphrase> </keyPassphrase>
Hide
Permalink
Luke Forehand added a comment -

That's not too bad, in my opinion.

Show
Luke Forehand added a comment - That's not too bad, in my opinion.

People

  • Assignee:
    Brett Okken
    Reporter:
    Luke Forehand
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: