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/10/02 08:45:53 UTC

Re: Maven Sign Plugin

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