You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@maven.apache.org by Robert Scholte <rf...@apache.org> on 2020/11/02 20:35:55 UTC

Re: Maven Sign Plugin

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 <s....@gmail.com> 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

AW: Maven Sign Plugin

Posted by Markus KARG <ma...@headcrashing.eu>.

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:s.jaranowski@gmail.com] 
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 <ma...@headcrashing.eu> 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:s.jaranowski@gmail.com]
> 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 <s....@gmail.com>
> 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 <rf...@apache.org>
> 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 <s....@gmail.com>
> >> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

-- 
Sławomir Jaranowski


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Maven Sign Plugin

Posted by Slawomir Jaranowski <s....@gmail.com>.

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 <ma...@headcrashing.eu> 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:s.jaranowski@gmail.com]
> 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 <s....@gmail.com>
> 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 <rf...@apache.org>
> 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 <s....@gmail.com>
> >> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

-- 
Sławomir Jaranowski

AW: Maven Sign Plugin

Posted by Markus KARG <ma...@headcrashing.eu>.

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:s.jaranowski@gmail.com] 
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 <s....@gmail.com>
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 <rf...@apache.org> 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 <s....@gmail.com>
>> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Maven Sign Plugin

Posted by Slawomir Jaranowski <s....@gmail.com>.

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 <s....@gmail.com>
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 <rf...@apache.org> 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 <s....@gmail.com>
>> 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

Re: Maven Sign Plugin

Posted by Slawomir Jaranowski <s....@gmail.com>.

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 <rf...@apache.org> 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 <s....@gmail.com>
> 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