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