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