Re: Maven Sign Plugin

[Slawomir Jaranowski]

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 <[hidden email]> 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 <[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
>

--
Sławomir Jaranowski

[rfscholte]

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 <[hidden email]> 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

[Slawomir Jaranowski]

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 <[hidden email]>
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 <[hidden email]> 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 <[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
>>
>
>
> --
> Sławomir Jaranowski
>

--
Sławomir Jaranowski

[Slawomir Jaranowski]

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 <[hidden email]>
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 <[hidden email]>
> 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 <[hidden email]> 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 <[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
>>>
>>
>>
>> --
>> Sławomir Jaranowski
>>
>
>
> --
> Sławomir Jaranowski
>

--
Sławomir Jaranowski

[rfscholte]

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

[Slawomir Jaranowski]

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

[Markus KARG-3]

I understand your concerns (had the same situation), and really would ask the PMC to find a solution for that long delays. My motto is "release early, release often" but at Apache this seems to be not wanted or not possile. :-(

Let's do it this way: We incubate the plugin until we think it is ripe for moving it to Apache and hope the PMC will find a way for quicker release cycles until then! :-)

-Markus

-----Ursprüngliche Nachricht-----
Von: Slawomir Jaranowski [mailto:[hidden email]]
Gesendet: Montag, 28. Dezember 2020 14:32
An: Maven Developers List
Betreff: Re: Maven Sign Plugin

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


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