Maven Sign Plugin

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Maven Sign Plugin

rfscholte
With the next release of Maven the current maven-gpg-plugin will become useless.
With the build//consumer pom, the local pom will be different compared to the uploaded pom.
However, the maven-gpg-plugin now uses the pom.xml of the local project.
(btw, the plugin uses the gpg commandline with a bunch of arguments. The stdio is used for passing the passphrase, you cannot stream the file via commandline)

In Maven 3.6.x changes have been made to support InputStream next to File.
This way we don't have to create a backdoor of writing a temporary file, which is likely to cause issues with very creative plugin/extension writers. Instead we should do in memory signing.

It would make sense to introduce a new plugin, and during a discussion with the PMC the idea of maven-sign-plugin was proposed (a much better alternative campared to maven-gpg2-plugin)

Dennis Lundberg started a POC based on Apache Common OpenGPG, however, it is still in the sandbox[1]

Olivier Lamy already discovered that signing doesn't work with the current Maven 3.7.0-SNAPSHOT.
Before we can even start thinking of an alpha-release, this issue must be fixed, because signing is a critical step for sharing artifacts.

I'm still struggling with MNG-6957, but in parallel a few should be able implement this.

Anybody willing to make this work?

thanks,
Robert

[1] http://commons.apache.org/sandbox/commons-openpgp/ [http://commons.apache.org/sandbox/commons-openpgp/
Reply | Threaded
Open this post in threaded view
|

Re: Maven Sign Plugin

rfscholte
Thanks for the offer.
Signing is very delicate process, so I appreciate the extra help.

thanks,
Robert
On 21-9-2020 09:14:54, Slawomir Jaranowski <[hidden email]> wrote:
Hi

I have some experience in case of verifying pgp signatures using Bouncy
Castle during work on my pgpverify-maven-plugin.
So If you would, I can try to help with the sign plugin.

Let me know if you are interested.

niedz., 20 wrz 2020 o 20:38 Robert Scholte
napisał(a):

> With the next release of Maven the current maven-gpg-plugin will become
> useless.
> With the build//consumer pom, the local pom will be different compared to
> the uploaded pom.
> However, the maven-gpg-plugin now uses the pom.xml of the local project.
> (btw, the plugin uses the gpg commandline with a bunch of arguments. The
> stdio is used for passing the passphrase, you cannot stream the file via
> commandline)
>
> In Maven 3.6.x changes have been made to support InputStream next to File.
> This way we don't have to create a backdoor of writing a temporary file,
> which is likely to cause issues with very creative plugin/extension
> writers. Instead we should do in memory signing.
>
> It would make sense to introduce a new plugin, and during a discussion
> with the PMC the idea of maven-sign-plugin was proposed (a much better
> alternative campared to maven-gpg2-plugin)
>
> Dennis Lundberg started a POC based on Apache Common OpenGPG, however, it
> is still in the sandbox[1]
>
> Olivier Lamy already discovered that signing doesn't work with the current
> Maven 3.7.0-SNAPSHOT.
> Before we can even start thinking of an alpha-release, this issue must be
> fixed, because signing is a critical step for sharing artifacts.
>
> I'm still struggling with MNG-6957, but in parallel a few should be able
> implement this.
>
> Anybody willing to make this work?
>
> thanks,
> Robert
>
> [1] http://commons.apache.org/sandbox/commons-openpgp/ [
> http://commons.apache.org/sandbox/commons-openpgp/]
>


--
Sławomir Jaranowski
Reply | Threaded
Open this post in threaded view
|

Re: Maven Sign Plugin

michaelo
In reply to this post by rfscholte
Am 2020-09-20 um 20:38 schrieb Robert Scholte:

> With the next release of Maven the current maven-gpg-plugin will become useless.
> With the build//consumer pom, the local pom will be different compared to the uploaded pom.
> However, the maven-gpg-plugin now uses the pom.xml of the local project.
> (btw, the plugin uses the gpg commandline with a bunch of arguments. The stdio is used for passing the passphrase, you cannot stream the file via commandline)
>
> In Maven 3.6.x changes have been made to support InputStream next to File.
> This way we don't have to create a backdoor of writing a temporary file, which is likely to cause issues with very creative plugin/extension writers. Instead we should do in memory signing.
>
> It would make sense to introduce a new plugin, and during a discussion with the PMC the idea of maven-sign-plugin was proposed (a much better alternative campared to maven-gpg2-plugin)
>
> Dennis Lundberg started a POC based on Apache Common OpenGPG, however, it is still in the sandbox[1]
>
> Olivier Lamy already discovered that signing doesn't work with the current Maven 3.7.0-SNAPSHOT.
> Before we can even start thinking of an alpha-release, this issue must be fixed, because signing is a critical step for sharing artifacts.
>
> I'm still struggling with MNG-6957, but in parallel a few should be able implement this.
>
> Anybody willing to make this work?

The entry interface of OpenPGP leaks abstraction and obviously retained
in incubator for a good reason...

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

Reply | Threaded
Open this post in threaded view
|

Re: Maven Sign Plugin

Slawomir Jaranowski
In reply to this post by rfscholte
In order to remove reflection and possibility to call:

   FileTransformerManager fileTransformerManager =
repositorySystemSession.getFileTransformerManager();

I must add:

    <exportedPackage>org.eclipse.aether.transform</exportedPackage>

in:
https://github.com/apache/maven/blob/0e3c7a433fc4f700cc2ae6d2c11ae39ec93cbadb/maven-core/src/main/resources/META-INF/maven/extension.xml#L58

Without it I have:
   java.lang.ClassNotFoundException:
org.eclipse.aether.transform.FileTransformerManager

this change will be possible in the latest maven version, call above method
on older maven version will cause ClassNotFoundException

adding direct dependency to maven-resolver-api (even in newer version)  in
plugin not help,
I suppose that classloader for plugin is prepare in special way according
to META-INF/maven/extension.xml

I don't know why reflection works ...



niedz., 27 wrz 2020 o 20:30 Robert Scholte <[hidden email]>
napisał(a):

> For now I would focus on making it work for Maven 3.7.0 and above.
> That would remove the need for reflection right?
>
> If there are multiple transfomers, in the end their result should all be
> signed.
> The reason behind this is that in the future we could upload multiple
> files based on the same pom.
> We should always upload a model 4.0.0 compatible version, but we might
> also transform the local pom to a more efficient file preferred by Maven 5.
>
> thanks,
> Robert
>
>
>
> On 27-9-2020 13:06:45, Slawomir Jaranowski <[hidden email]> wrote:
> Ok.
> I did some research and spike.
>
> We need access to *FileTransformerManager*, it look like this is method,
> which we want:
>
> * org.eclipse.aether.RepositorySystemSession#getFileTransformerManager*
> We can use it from maven 3.6 (without overwriting the version of
> maven-resolver-api) ... so the plugin has a minimum maven requirement for
> this version. But even in 3.6 and 3.7-SNAPSHOT i have exception during
> execution:
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-sign-plugin:1.0-SNAPSHOT:sign
> (with-method-call) on project test1: Execution with-method-call of goal
> org.apache.maven.plugins:maven-sign-plugin:1.0-SNAPSHOT:sign failed: A
> required class was missing while executing
> org.apache.maven.plugins:maven-sign-plugin:1.0-SNAPSHOT:sign:
> org/eclipse/aether/transform/FileTransformerManager
>
> So next I try by reflection ... (now looks not good) ... but I have
> expected result
>
> So when we must use reflection maybe this magic should be done in separate
> utils like
> *maven-resolver, maven-artifact-transfer *(where we have magic with
> reflections)
> When we prepare a method/class for transparent transformation in an
> external library we can simply use it in the gpg plugin and problems for
> the new version of maven will be solved.
> Gpg plugin already use *maven-resolver, maven-artifact-transfer*
>
> Of course we can continue work on the new plugin - but we need more time to
> develop the first production/beta version.
>
> Another question in about api for
>
> *org.eclipse.aether.transform.FileTransformerManager#getTransformersForArtifact*
> result is collection of *FileTransformer* so what should happen when we
> have more then one transformer.
> In
>
> https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultInstaller.java#L246
> result file is overwrited by last transformer from list.
>
> You can look at what I did at my fork:
> https://github.com/slawekjaranowski/maven-studies/tree/maven-sign-plugin
>
> I'm waiting for a decision on what should be done next ...
>
> sob., 26 wrz 2020 o 11:46 Slawomir Jaranowski
> napisał(a):
>
> > Ok, I don't want to reinvent the wheels, so
> >
> > How to reach handle to project artifacts list, especially project pom
> > after transformation in plugin code?
> >
> > Some plugin examples, point which component should I use to achieve this
> > will be great.
> >
> > pt., 25 wrz 2020 o 17:05 Robert Scholte napisał(a):
> >
> >> There no plugin yet, but I suggest to start with a branch under
> >> https://github.com/apache/maven-studies before making an official new
> >> repository.
> >>
> >> Let me quote 2 points mentioned by Stephen Connolly, which we still need
> >> to address:
> >>
> >> - If we switch to bouncycastle based, we will now own the key storage.
> >> This is both good and bad.
> >> * People who have their keys stored in gpg2 will have a “fun time”
> >> extracting them... or else we will have to do the dance of extracting
> them
> >> ourselves.
> >> * If we “own” the key storage, publishing keys to a key registry and
> >> generating keys may become our problem from the user’s perspective.
> >> * One of the biggest complaints about publishing on central has been
> >> the difficulty of gpg signing. New users will likely thank us if we
> make it
> >> easier.
> >>
> >> - PGP functionality provider security issues become our problem. Before,
> >> users could independently upgrade the gpg CLI tooling to work past
> security
> >> issues (causing it’s own issues as CLI options changed from gpg1 to
> gpg2).
> >> With this plugin, the pgp provider version will be baked into the pom.
> How
> >> will users be able to assure their security team that signatures have
> been
> >> made in the version without a security issue?
> >>
> >> thanks,
> >> Robert
> >> On 25-9-2020 15:35:01, Slawomir Jaranowski
> >> wrote:
> >> Hi
> >>
> >> On the weekend I will have some spare time, so I can do something about
> it
> >> ..
> >>
> >> My questions:
> >> - are there git repository, jira project for new plugin
> >> - does anybody working on it now - what is progress
> >> - if you want to use Apache Common OpenGPG, I think should be refreshed
> >> first - is there git repo for it
> >>
> >>
> >> czw., 24 wrz 2020 o 18:57 Robert Scholte napisał(a):
> >>
> >> > Thanks for the offer.
> >> > Signing is very delicate process, so I appreciate the extra help.
> >> >
> >> > thanks,
> >> > Robert
> >> > On 21-9-2020 09:14:54, Slawomir Jaranowski wrote:
> >> > Hi
> >> >
> >> > I have some experience in case of verifying pgp signatures using
> Bouncy
> >> > Castle during work on my pgpverify-maven-plugin.
> >> > So If you would, I can try to help with the sign plugin.
> >> >
> >> > Let me know if you are interested.
> >> >
> >> > niedz., 20 wrz 2020 o 20:38 Robert Scholte
> >> > napisał(a):
> >> >
> >> > > With the next release of Maven the current maven-gpg-plugin will
> >> become
> >> > > useless.
> >> > > With the build//consumer pom, the local pom will be different
> >> compared to
> >> > > the uploaded pom.
> >> > > However, the maven-gpg-plugin now uses the pom.xml of the local
> >> project.
> >> > > (btw, the plugin uses the gpg commandline with a bunch of arguments.
> >> The
> >> > > stdio is used for passing the passphrase, you cannot stream the file
> >> via
> >> > > commandline)
> >> > >
> >> > > In Maven 3.6.x changes have been made to support InputStream next to
> >> > File.
> >> > > This way we don't have to create a backdoor of writing a temporary
> >> file,
> >> > > which is likely to cause issues with very creative plugin/extension
> >> > > writers. Instead we should do in memory signing.
> >> > >
> >> > > It would make sense to introduce a new plugin, and during a
> discussion
> >> > > with the PMC the idea of maven-sign-plugin was proposed (a much
> better
> >> > > alternative campared to maven-gpg2-plugin)
> >> > >
> >> > > Dennis Lundberg started a POC based on Apache Common OpenGPG,
> >> however, it
> >> > > is still in the sandbox[1]
> >> > >
> >> > > Olivier Lamy already discovered that signing doesn't work with the
> >> > current
> >> > > Maven 3.7.0-SNAPSHOT.
> >> > > Before we can even start thinking of an alpha-release, this issue
> >> must be
> >> > > fixed, because signing is a critical step for sharing artifacts.
> >> > >
> >> > > I'm still struggling with MNG-6957, but in parallel a few should be
> >> able
> >> > > implement this.
> >> > >
> >> > > Anybody willing to make this work?
> >> > >
> >> > > thanks,
> >> > > Robert
> >> > >
> >> > > [1] http://commons.apache.org/sandbox/commons-openpgp/ [
> >> > > http://commons.apache.org/sandbox/commons-openpgp/]
> >> > >
> >> >
> >> >
> >> > --
> >> > Sławomir Jaranowski
> >> >
> >>
> >>
> >> --
> >> Sławomir Jaranowski
> >>
> >
> >
> > --
> > Sławomir Jaranowski
> >
>
>
> --
> Sławomir Jaranowski
>


--
Sławomir Jaranowski
Reply | Threaded
Open this post in threaded view
|

Re: Maven Sign Plugin

rfscholte
All "uploaded" files must be signed, see for instance https://repo1.maven.org/maven2/org/apache/maven/maven-core/3.6.3/
And don't care about older Maven versions, for now just set the prerequisite for Maven to 3.7.0-SNAPSHOT in the pom.

On 2-10-2020 14:21:02, Slawomir Jaranowski <[hidden email]> wrote:
But on the other side, plugins must sign other artifacts associated with a
given project.

So in this way we have two different processes - one for pom with
transformation and ather for rest artifacts.

Maybe all project artifacts should go through the transformation process
then we can have one way for all.

Anyway, first we should resolve how to access Transformers from the plugin.
And how (if we want) get comparability for old maven versions.


pt., 2 paź 2020 o 10:46 Robert Scholte napisał(a):

> In the end a signer is just another file transformer, so we need to
> achieve something like this:
> local pom >> build/consumer pom (distribute) >> sign (distribute)
> The plugin must be able to register a SignFileTransformer, which should
> only be called during deploy. For the latter I can imagine we need to
> extend the API.
>
> thanks,
> Robert
> On 28-9-2020 00:35:45, Slawomir Jaranowski wrote:
> In order to remove reflection and possibility to call:
>
> FileTransformerManager fileTransformerManager =
> repositorySystemSession.getFileTransformerManager();
>
> I must add:
>
> org.eclipse.aether.transform
>
> in:
>
> https://github.com/apache/maven/blob/0e3c7a433fc4f700cc2ae6d2c11ae39ec93cbadb/maven-core/src/main/resources/META-INF/maven/extension.xml#L58
>
> Without it I have:
> java.lang.ClassNotFoundException:
> org.eclipse.aether.transform.FileTransformerManager
>
> this change will be possible in the latest maven version, call above method
> on older maven version will cause ClassNotFoundException
>
> adding direct dependency to maven-resolver-api (even in newer version) in
> plugin not help,
> I suppose that classloader for plugin is prepare in special way according
> to META-INF/maven/extension.xml
>
> I don't know why reflection works ...
>
>
>
> niedz., 27 wrz 2020 o 20:30 Robert Scholte
> napisał(a):
>
> > For now I would focus on making it work for Maven 3.7.0 and above.
> > That would remove the need for reflection right?
> >
> > If there are multiple transfomers, in the end their result should all be
> > signed.
> > The reason behind this is that in the future we could upload multiple
> > files based on the same pom.
> > We should always upload a model 4.0.0 compatible version, but we might
> > also transform the local pom to a more efficient file preferred by Maven
> 5.
> >
> > thanks,
> > Robert
> >
> >
> >
> > On 27-9-2020 13:06:45, Slawomir Jaranowski wrote:
> > Ok.
> > I did some research and spike.
> >
> > We need access to *FileTransformerManager*, it look like this is method,
> > which we want:
> >
> > * org.eclipse.aether.RepositorySystemSession#getFileTransformerManager*
> > We can use it from maven 3.6 (without overwriting the version of
> > maven-resolver-api) ... so the plugin has a minimum maven requirement for
> > this version. But even in 3.6 and 3.7-SNAPSHOT i have exception during
> > execution:
> >
> > [ERROR] Failed to execute goal
> > org.apache.maven.plugins:maven-sign-plugin:1.0-SNAPSHOT:sign
> > (with-method-call) on project test1: Execution with-method-call of goal
> > org.apache.maven.plugins:maven-sign-plugin:1.0-SNAPSHOT:sign failed: A
> > required class was missing while executing
> > org.apache.maven.plugins:maven-sign-plugin:1.0-SNAPSHOT:sign:
> > org/eclipse/aether/transform/FileTransformerManager
> >
> > So next I try by reflection ... (now looks not good) ... but I have
> > expected result
> >
> > So when we must use reflection maybe this magic should be done in
> separate
> > utils like
> > *maven-resolver, maven-artifact-transfer *(where we have magic with
> > reflections)
> > When we prepare a method/class for transparent transformation in an
> > external library we can simply use it in the gpg plugin and problems for
> > the new version of maven will be solved.
> > Gpg plugin already use *maven-resolver, maven-artifact-transfer*
> >
> > Of course we can continue work on the new plugin - but we need more time
> to
> > develop the first production/beta version.
> >
> > Another question in about api for
> >
> >
> *org.eclipse.aether.transform.FileTransformerManager#getTransformersForArtifact*
> > result is collection of *FileTransformer* so what should happen when we
> > have more then one transformer.
> > In
> >
> >
> https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultInstaller.java#L246
> > result file is overwrited by last transformer from list.
> >
> > You can look at what I did at my fork:
> > https://github.com/slawekjaranowski/maven-studies/tree/maven-sign-plugin
> >
> > I'm waiting for a decision on what should be done next ...
> >
> > sob., 26 wrz 2020 o 11:46 Slawomir Jaranowski
> > napisał(a):
> >
> > > Ok, I don't want to reinvent the wheels, so
> > >
> > > How to reach handle to project artifacts list, especially project pom
> > > after transformation in plugin code?
> > >
> > > Some plugin examples, point which component should I use to achieve
> this
> > > will be great.
> > >
> > > pt., 25 wrz 2020 o 17:05 Robert Scholte napisał(a):
> > >
> > >> There no plugin yet, but I suggest to start with a branch under
> > >> https://github.com/apache/maven-studies before making an official new
> > >> repository.
> > >>
> > >> Let me quote 2 points mentioned by Stephen Connolly, which we still
> need
> > >> to address:
> > >>
> > >> - If we switch to bouncycastle based, we will now own the key storage.
> > >> This is both good and bad.
> > >> * People who have their keys stored in gpg2 will have a “fun time”
> > >> extracting them... or else we will have to do the dance of extracting
> > them
> > >> ourselves.
> > >> * If we “own” the key storage, publishing keys to a key registry and
> > >> generating keys may become our problem from the user’s perspective.
> > >> * One of the biggest complaints about publishing on central has been
> > >> the difficulty of gpg signing. New users will likely thank us if we
> > make it
> > >> easier.
> > >>
> > >> - PGP functionality provider security issues become our problem.
> Before,
> > >> users could independently upgrade the gpg CLI tooling to work past
> > security
> > >> issues (causing it’s own issues as CLI options changed from gpg1 to
> > gpg2).
> > >> With this plugin, the pgp provider version will be baked into the pom.
> > How
> > >> will users be able to assure their security team that signatures have
> > been
> > >> made in the version without a security issue?
> > >>
> > >> thanks,
> > >> Robert
> > >> On 25-9-2020 15:35:01, Slawomir Jaranowski
> > >> wrote:
> > >> Hi
> > >>
> > >> On the weekend I will have some spare time, so I can do something
> about
> > it
> > >> ..
> > >>
> > >> My questions:
> > >> - are there git repository, jira project for new plugin
> > >> - does anybody working on it now - what is progress
> > >> - if you want to use Apache Common OpenGPG, I think should be
> refreshed
> > >> first - is there git repo for it
> > >>
> > >>
> > >> czw., 24 wrz 2020 o 18:57 Robert Scholte napisał(a):
> > >>
> > >> > Thanks for the offer.
> > >> > Signing is very delicate process, so I appreciate the extra help.
> > >> >
> > >> > thanks,
> > >> > Robert
> > >> > On 21-9-2020 09:14:54, Slawomir Jaranowski wrote:
> > >> > Hi
> > >> >
> > >> > I have some experience in case of verifying pgp signatures using
> > Bouncy
> > >> > Castle during work on my pgpverify-maven-plugin.
> > >> > So If you would, I can try to help with the sign plugin.
> > >> >
> > >> > Let me know if you are interested.
> > >> >
> > >> > niedz., 20 wrz 2020 o 20:38 Robert Scholte
> > >> > napisał(a):
> > >> >
> > >> > > With the next release of Maven the current maven-gpg-plugin will
> > >> become
> > >> > > useless.
> > >> > > With the build//consumer pom, the local pom will be different
> > >> compared to
> > >> > > the uploaded pom.
> > >> > > However, the maven-gpg-plugin now uses the pom.xml of the local
> > >> project.
> > >> > > (btw, the plugin uses the gpg commandline with a bunch of
> arguments.
> > >> The
> > >> > > stdio is used for passing the passphrase, you cannot stream the
> file
> > >> via
> > >> > > commandline)
> > >> > >
> > >> > > In Maven 3.6.x changes have been made to support InputStream next
> to
> > >> > File.
> > >> > > This way we don't have to create a backdoor of writing a temporary
> > >> file,
> > >> > > which is likely to cause issues with very creative
> plugin/extension
> > >> > > writers. Instead we should do in memory signing.
> > >> > >
> > >> > > It would make sense to introduce a new plugin, and during a
> > discussion
> > >> > > with the PMC the idea of maven-sign-plugin was proposed (a much
> > better
> > >> > > alternative campared to maven-gpg2-plugin)
> > >> > >
> > >> > > Dennis Lundberg started a POC based on Apache Common OpenGPG,
> > >> however, it
> > >> > > is still in the sandbox[1]
> > >> > >
> > >> > > Olivier Lamy already discovered that signing doesn't work with the
> > >> > current
> > >> > > Maven 3.7.0-SNAPSHOT.
> > >> > > Before we can even start thinking of an alpha-release, this issue
> > >> must be
> > >> > > fixed, because signing is a critical step for sharing artifacts.
> > >> > >
> > >> > > I'm still struggling with MNG-6957, but in parallel a few should
> be
> > >> able
> > >> > > implement this.
> > >> > >
> > >> > > Anybody willing to make this work?
> > >> > >
> > >> > > thanks,
> > >> > > Robert
> > >> > >
> > >> > > [1] http://commons.apache.org/sandbox/commons-openpgp/ [
> > >> > > http://commons.apache.org/sandbox/commons-openpgp/]
> > >> > >
> > >> >
> > >> >
> > >> > --
> > >> > Sławomir Jaranowski
> > >> >
> > >>
> > >>
> > >> --
> > >> Sławomir Jaranowski
> > >>
> > >
> > >
> > > --
> > > Sławomir Jaranowski
> > >
> >
> >
> > --
> > Sławomir Jaranowski
> >
>
>
> --
> Sławomir Jaranowski
>


--
Sławomir Jaranowski
Reply | Threaded
Open this post in threaded view
|

Re: Maven Sign Plugin

Slawomir Jaranowski
I'm really open to help developing / maintaining such a plugin under Apache
Organization.

But as we see the release process in Apache is very slow ... I need it now,
and I don't want to wait for years so I decided to release it by myself.

Probably it is another topic how to make Apache projects more agile and
more friendly for external contributors.

For example I did a few feature / fix for maven-invoker-plugin and I wait
about year for release next version, I don't have knowledge when it can
happen ...

pon., 28 gru 2020 o 14:04 Markus KARG <[hidden email]> napisał(a):

> Please turn it into an official Maven plugin, as there are many people out
> there reluctant when it comes to third party due to sustained support etc.!
> :-)
> -Markus
>
>
> -----Ursprüngliche Nachricht-----
> Von: Slawomir Jaranowski [mailto:[hidden email]]
> Gesendet: Montag, 28. Dezember 2020 13:09
> An: Maven Developers List
> Betreff: Re: Maven Sign Plugin
>
> Hi,
>
> First version of Sign Maven Plugin was released -
> https://github.com/s4u/sign-maven-plugin
>
> It works with Maven 3.6.x and future version 4.x
>
> If somebody is interested I invite them to test and collaborate.
>
> pon., 14 gru 2020 o 21:42 Slawomir Jaranowski <[hidden email]>
> napisał(a):
>
> > Hi,
> >
> > The Idea of making a signature by java code without an external binary is
> > very good.
> >
> > I have plans to automate some  of CI/CD and such plugin will be very
> > useful for me.
> > I can customise it for easy use with CI system
> >
> > So waiting for you,
> > I will release it under my github organization, probably at the end of
> > year. If someone is interested please let me know.
> >
> >
> > pon., 2 lis 2020 o 21:36 Robert Scholte <[hidden email]>
> napisał(a):
> >
> >> I want to have another look at Maven Resolver. I don't want to store it
> >> as a file, but stream it directly to a repository.
> >> The goal is now bound to verify, but that's incorrect (it has nothing to
> >> do with verifying integration results).
> >> Looking at it, I think this should not be a maven-plugin, but a Maven
> >> extension, so it can hook itself during deploy, no need for an explicit
> >> goal to call
> >> I need to work it out a bit more.
> >>
> >> thanks,
> >> Robert
> >>
> >> On 19-10-2020 22:47:06, Slawomir Jaranowski <[hidden email]>
> >> wrote:
> >> Hi
> >>
> >> What next step do you plan with this plugin?
> >>
> >> I believe that can be usable even now for users.
> >>
> >> It is not too much work to prepare a plugin to work with maven 3.6 so we
> >> can publish it and take feedback from users.
> >>
> >> I think that early release can help users to prepare their project to be
> >> ready for maven 3.7.
> >>
> >> If you wish I will take care about this plugin.
> >>
> >> niedz., 4 paź 2020 o 15:32 Slawomir Jaranowski
> >> napisał(a):
> >>
> >> > First working version is ready:
> >> >
> >> > https://github.com/apache/maven-studies/pull/2
> >> >
> >> > I'm waiting for your opinion
> >> >
> >> > pt., 2 paź 2020 o 17:05 Slawomir Jaranowski
> >> > napisał(a):
> >> >
> >> >> Targeting to maven 3.7.0-SNAPSHOT makes easier access to Transformer
> >> api.
> >> >> So one issue is need to resolve:
> >> >> https://issues.apache.org/jira/browse/MNG-6992
> >> >>
> >> >> Of course it is clear that all "uploaded" files must be signed.
> >> >> Question is - if we should use transformer api only for POM or for
> all?
> >> >>
> >> >> pt., 2 paź 2020 o 15:57 Robert Scholte napisał(a):
> >> >>
> >> >>> All "uploaded" files must be signed, see for instance
> >> >>> https://repo1.maven.org/maven2/org/apache/maven/maven-core/3.6.3/
> >> >>> And don't care about older Maven versions, for now just set the
> >> >>> prerequisite for Maven to 3.7.0-SNAPSHOT in the pom.
> >> >>>
> >> >>> On 2-10-2020 14:21:02, Slawomir Jaranowski
> >> >>> wrote:
> >> >>> But on the other side, plugins must sign other artifacts associated
> >> with
> >> >>> a
> >> >>> given project.
> >> >>>
> >> >>> So in this way we have two different processes - one for pom with
> >> >>> transformation and ather for rest artifacts.
> >> >>>
> >> >>> Maybe all project artifacts should go through the transformation
> >> process
> >> >>> then we can have one way for all.
> >> >>>
> >> >>> Anyway, first we should resolve how to access Transformers from the
> >> >>> plugin.
> >> >>> And how (if we want) get comparability for old maven versions.
> >> >>>
> >> >>>
> >> >>> pt., 2 paź 2020 o 10:46 Robert Scholte napisał(a):
> >> >>>
> >> >>> > In the end a signer is just another file transformer, so we need
> to
> >> >>> > achieve something like this:
> >> >>> > local pom >> build/consumer pom (distribute) >> sign (distribute)
> >> >>> > The plugin must be able to register a SignFileTransformer, which
> >> should
> >> >>> > only be called during deploy. For the latter I can imagine we need
> >> to
> >> >>> > extend the API.
> >> >>> >
> >> >>> > thanks,
> >> >>> > Robert
> >> >>> > On 28-9-2020 00:35:45, Slawomir Jaranowski wrote:
> >> >>> > In order to remove reflection and possibility to call:
> >> >>> >
> >> >>> > FileTransformerManager fileTransformerManager =
> >> >>> > repositorySystemSession.getFileTransformerManager();
> >> >>> >
> >> >>> > I must add:
> >> >>> >
> >> >>> > org.eclipse.aether.transform
> >> >>> >
> >> >>> > in:
> >> >>> >
> >> >>> >
> >> >>>
> >>
> https://github.com/apache/maven/blob/0e3c7a433fc4f700cc2ae6d2c11ae39ec93cbadb/maven-core/src/main/resources/META-INF/maven/extension.xml#L58
> >> >>> >
> >> >>> > Without it I have:
> >> >>> > java.lang.ClassNotFoundException:
> >> >>> > org.eclipse.aether.transform.FileTransformerManager
> >> >>> >
> >> >>> > this change will be possible in the latest maven version, call
> above
> >> >>> method
> >> >>> > on older maven version will cause ClassNotFoundException
> >> >>> >
> >> >>> > adding direct dependency to maven-resolver-api (even in newer
> >> version)
> >> >>> in
> >> >>> > plugin not help,
> >> >>> > I suppose that classloader for plugin is prepare in special way
> >> >>> according
> >> >>> > to META-INF/maven/extension.xml
> >> >>> >
> >> >>> > I don't know why reflection works ...
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> > niedz., 27 wrz 2020 o 20:30 Robert Scholte
> >> >>> > napisał(a):
> >> >>> >
> >> >>> > > For now I would focus on making it work for Maven 3.7.0 and
> above.
> >> >>> > > That would remove the need for reflection right?
> >> >>> > >
> >> >>> > > If there are multiple transfomers, in the end their result
> should
> >> >>> all be
> >> >>> > > signed.
> >> >>> > > The reason behind this is that in the future we could upload
> >> multiple
> >> >>> > > files based on the same pom.
> >> >>> > > We should always upload a model 4.0.0 compatible version, but we
> >> >>> might
> >> >>> > > also transform the local pom to a more efficient file preferred
> by
> >> >>> Maven
> >> >>> > 5.
> >> >>> > >
> >> >>> > > thanks,
> >> >>> > > Robert
> >> >>> > >
> >> >>> > >
> >> >>> > >
> >> >>> > > On 27-9-2020 13:06:45, Slawomir Jaranowski wrote:
> >> >>> > > Ok.
> >> >>> > > I did some research and spike.
> >> >>> > >
> >> >>> > > We need access to *FileTransformerManager*, it look like this is
> >> >>> method,
> >> >>> > > which we want:
> >> >>> > >
> >> >>> > > *
> >> >>>
> org.eclipse.aether.RepositorySystemSession#getFileTransformerManager*
> >> >>> > > We can use it from maven 3.6 (without overwriting the version of
> >> >>> > > maven-resolver-api) ... so the plugin has a minimum maven
> >> >>> requirement for
> >> >>> > > this version. But even in 3.6 and 3.7-SNAPSHOT i have exception
> >> >>> during
> >> >>> > > execution:
> >> >>> > >
> >> >>> > > [ERROR] Failed to execute goal
> >> >>> > > org.apache.maven.plugins:maven-sign-plugin:1.0-SNAPSHOT:sign
> >> >>> > > (with-method-call) on project test1: Execution with-method-call
> of
> >> >>> goal
> >> >>> > > org.apache.maven.plugins:maven-sign-plugin:1.0-SNAPSHOT:sign
> >> failed:
> >> >>> A
> >> >>> > > required class was missing while executing
> >> >>> > > org.apache.maven.plugins:maven-sign-plugin:1.0-SNAPSHOT:sign:
> >> >>> > > org/eclipse/aether/transform/FileTransformerManager
> >> >>> > >
> >> >>> > > So next I try by reflection ... (now looks not good) ... but I
> >> have
> >> >>> > > expected result
> >> >>> > >
> >> >>> > > So when we must use reflection maybe this magic should be done
> in
> >> >>> > separate
> >> >>> > > utils like
> >> >>> > > *maven-resolver, maven-artifact-transfer *(where we have magic
> >> with
> >> >>> > > reflections)
> >> >>> > > When we prepare a method/class for transparent transformation in
> >> an
> >> >>> > > external library we can simply use it in the gpg plugin and
> >> problems
> >> >>> for
> >> >>> > > the new version of maven will be solved.
> >> >>> > > Gpg plugin already use *maven-resolver, maven-artifact-transfer*
> >> >>> > >
> >> >>> > > Of course we can continue work on the new plugin - but we need
> >> more
> >> >>> time
> >> >>> > to
> >> >>> > > develop the first production/beta version.
> >> >>> > >
> >> >>> > > Another question in about api for
> >> >>> > >
> >> >>> > >
> >> >>> >
> >> >>>
> >>
> *org.eclipse.aether.transform.FileTransformerManager#getTransformersForArtifact*
> >> >>> > > result is collection of *FileTransformer* so what should happen
> >> when
> >> >>> we
> >> >>> > > have more then one transformer.
> >> >>> > > In
> >> >>> > >
> >> >>> > >
> >> >>> >
> >> >>>
> >>
> https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultInstaller.java#L246
> >> >>> > > result file is overwrited by last transformer from list.
> >> >>> > >
> >> >>> > > You can look at what I did at my fork:
> >> >>> > >
> >> >>>
> >>
> https://github.com/slawekjaranowski/maven-studies/tree/maven-sign-plugin
> >> >>> > >
> >> >>> > > I'm waiting for a decision on what should be done next ...
> >> >>> > >
> >> >>> > > sob., 26 wrz 2020 o 11:46 Slawomir Jaranowski
> >> >>> > > napisał(a):
> >> >>> > >
> >> >>> > > > Ok, I don't want to reinvent the wheels, so
> >> >>> > > >
> >> >>> > > > How to reach handle to project artifacts list, especially
> >> project
> >> >>> pom
> >> >>> > > > after transformation in plugin code?
> >> >>> > > >
> >> >>> > > > Some plugin examples, point which component should I use to
> >> achieve
> >> >>> > this
> >> >>> > > > will be great.
> >> >>> > > >
> >> >>> > > > pt., 25 wrz 2020 o 17:05 Robert Scholte napisał(a):
> >> >>> > > >
> >> >>> > > >> There no plugin yet, but I suggest to start with a branch
> under
> >> >>> > > >> https://github.com/apache/maven-studies before making an
> >> >>> official new
> >> >>> > > >> repository.
> >> >>> > > >>
> >> >>> > > >> Let me quote 2 points mentioned by Stephen Connolly, which we
> >> >>> still
> >> >>> > need
> >> >>> > > >> to address:
> >> >>> > > >>
> >> >>> > > >> - If we switch to bouncycastle based, we will now own the key
> >> >>> storage.
> >> >>> > > >> This is both good and bad.
> >> >>> > > >> * People who have their keys stored in gpg2 will have a “fun
> >> time”
> >> >>> > > >> extracting them... or else we will have to do the dance of
> >> >>> extracting
> >> >>> > > them
> >> >>> > > >> ourselves.
> >> >>> > > >> * If we “own” the key storage, publishing keys to a key
> >> registry
> >> >>> and
> >> >>> > > >> generating keys may become our problem from the user’s
> >> >>> perspective.
> >> >>> > > >> * One of the biggest complaints about publishing on central
> has
> >> >>> been
> >> >>> > > >> the difficulty of gpg signing. New users will likely thank us
> >> if
> >> >>> we
> >> >>> > > make it
> >> >>> > > >> easier.
> >> >>> > > >>
> >> >>> > > >> - PGP functionality provider security issues become our
> >> problem.
> >> >>> > Before,
> >> >>> > > >> users could independently upgrade the gpg CLI tooling to work
> >> past
> >> >>> > > security
> >> >>> > > >> issues (causing it’s own issues as CLI options changed from
> >> gpg1
> >> >>> to
> >> >>> > > gpg2).
> >> >>> > > >> With this plugin, the pgp provider version will be baked into
> >> the
> >> >>> pom.
> >> >>> > > How
> >> >>> > > >> will users be able to assure their security team that
> >> signatures
> >> >>> have
> >> >>> > > been
> >> >>> > > >> made in the version without a security issue?
> >> >>> > > >>
> >> >>> > > >> thanks,
> >> >>> > > >> Robert
> >> >>> > > >> On 25-9-2020 15:35:01, Slawomir Jaranowski
> >> >>> > > >> wrote:
> >> >>> > > >> Hi
> >> >>> > > >>
> >> >>> > > >> On the weekend I will have some spare time, so I can do
> >> something
> >> >>> > about
> >> >>> > > it
> >> >>> > > >> ..
> >> >>> > > >>
> >> >>> > > >> My questions:
> >> >>> > > >> - are there git repository, jira project for new plugin
> >> >>> > > >> - does anybody working on it now - what is progress
> >> >>> > > >> - if you want to use Apache Common OpenGPG, I think should be
> >> >>> > refreshed
> >> >>> > > >> first - is there git repo for it
> >> >>> > > >>
> >> >>> > > >>
> >> >>> > > >> czw., 24 wrz 2020 o 18:57 Robert Scholte napisał(a):
> >> >>> > > >>
> >> >>> > > >> > Thanks for the offer.
> >> >>> > > >> > Signing is very delicate process, so I appreciate the extra
> >> >>> help.
> >> >>> > > >> >
> >> >>> > > >> > thanks,
> >> >>> > > >> > Robert
> >> >>> > > >> > On 21-9-2020 09:14:54, Slawomir Jaranowski wrote:
> >> >>> > > >> > Hi
> >> >>> > > >> >
> >> >>> > > >> > I have some experience in case of verifying pgp signatures
> >> using
> >> >>> > > Bouncy
> >> >>> > > >> > Castle during work on my pgpverify-maven-plugin.
> >> >>> > > >> > So If you would, I can try to help with the sign plugin.
> >> >>> > > >> >
> >> >>> > > >> > Let me know if you are interested.
> >> >>> > > >> >
> >> >>> > > >> > niedz., 20 wrz 2020 o 20:38 Robert Scholte
> >> >>> > > >> > napisał(a):
> >> >>> > > >> >
> >> >>> > > >> > > With the next release of Maven the current
> maven-gpg-plugin
> >> >>> will
> >> >>> > > >> become
> >> >>> > > >> > > useless.
> >> >>> > > >> > > With the build//consumer pom, the local pom will be
> >> different
> >> >>> > > >> compared to
> >> >>> > > >> > > the uploaded pom.
> >> >>> > > >> > > However, the maven-gpg-plugin now uses the pom.xml of the
> >> >>> local
> >> >>> > > >> project.
> >> >>> > > >> > > (btw, the plugin uses the gpg commandline with a bunch of
> >> >>> > arguments.
> >> >>> > > >> The
> >> >>> > > >> > > stdio is used for passing the passphrase, you cannot
> stream
> >> >>> the
> >> >>> > file
> >> >>> > > >> via
> >> >>> > > >> > > commandline)
> >> >>> > > >> > >
> >> >>> > > >> > > In Maven 3.6.x changes have been made to support
> >> InputStream
> >> >>> next
> >> >>> > to
> >> >>> > > >> > File.
> >> >>> > > >> > > This way we don't have to create a backdoor of writing a
> >> >>> temporary
> >> >>> > > >> file,
> >> >>> > > >> > > which is likely to cause issues with very creative
> >> >>> > plugin/extension
> >> >>> > > >> > > writers. Instead we should do in memory signing.
> >> >>> > > >> > >
> >> >>> > > >> > > It would make sense to introduce a new plugin, and
> during a
> >> >>> > > discussion
> >> >>> > > >> > > with the PMC the idea of maven-sign-plugin was proposed
> (a
> >> >>> much
> >> >>> > > better
> >> >>> > > >> > > alternative campared to maven-gpg2-plugin)
> >> >>> > > >> > >
> >> >>> > > >> > > Dennis Lundberg started a POC based on Apache Common
> >> OpenGPG,
> >> >>> > > >> however, it
> >> >>> > > >> > > is still in the sandbox[1]
> >> >>> > > >> > >
> >> >>> > > >> > > Olivier Lamy already discovered that signing doesn't work
> >> >>> with the
> >> >>> > > >> > current
> >> >>> > > >> > > Maven 3.7.0-SNAPSHOT.
> >> >>> > > >> > > Before we can even start thinking of an alpha-release,
> this
> >> >>> issue
> >> >>> > > >> must be
> >> >>> > > >> > > fixed, because signing is a critical step for sharing
> >> >>> artifacts.
> >> >>> > > >> > >
> >> >>> > > >> > > I'm still struggling with MNG-6957, but in parallel a few
> >> >>> should
> >> >>> > be
> >> >>> > > >> able
> >> >>> > > >> > > implement this.
> >> >>> > > >> > >
> >> >>> > > >> > > Anybody willing to make this work?
> >> >>> > > >> > >
> >> >>> > > >> > > thanks,
> >> >>> > > >> > > Robert
> >> >>> > > >> > >
> >> >>> > > >> > > [1] http://commons.apache.org/sandbox/commons-openpgp/ [
> >> >>> > > >> > > http://commons.apache.org/sandbox/commons-openpgp/]
> >> >>> > > >> > >
> >> >>> > > >> >
> >> >>> > > >> >
> >> >>> > > >> > --
> >> >>> > > >> > Sławomir Jaranowski
> >> >>> > > >> >
> >> >>> > > >>
> >> >>> > > >>
> >> >>> > > >> --
> >> >>> > > >> Sławomir Jaranowski
> >> >>> > > >>
> >> >>> > > >
> >> >>> > > >
> >> >>> > > > --
> >> >>> > > > Sławomir Jaranowski
> >> >>> > > >
> >> >>> > >
> >> >>> > >
> >> >>> > > --
> >> >>> > > Sławomir Jaranowski
> >> >>> > >
> >> >>> >
> >> >>> >
> >> >>> > --
> >> >>> > Sławomir Jaranowski
> >> >>> >
> >> >>>
> >> >>>
> >> >>> --
> >> >>> Sławomir Jaranowski
> >> >>>
> >> >>
> >> >>
> >> >> --
> >> >> Sławomir Jaranowski
> >> >>
> >> >
> >> >
> >> > --
> >> > Sławomir Jaranowski
> >> >
> >>
> >>
> >> --
> >> Sławomir Jaranowski
> >>
> >
> >
> > --
> > Sławomir Jaranowski
> >
>
>
> --
> Sławomir Jaranowski
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
Sławomir Jaranowski