Hi
On the weekend I will have some spare time, so I can do something about it .. My questions: - are there git repository, jira project for new plugin - does anybody working on it now - what is progress - if you want to use Apache Common OpenGPG, I think should be refreshed first - is there git repo for it czw., 24 wrz 2020 o 18:57 Robert Scholte <[hidden email]> napisał(a): > Thanks for the offer. > Signing is very delicate process, so I appreciate the extra help. > > thanks, > Robert > On 21-9-2020 09:14:54, Slawomir Jaranowski <[hidden email]> wrote: > Hi > > I have some experience in case of verifying pgp signatures using Bouncy > Castle during work on my pgpverify-maven-plugin. > So If you would, I can try to help with the sign plugin. > > Let me know if you are interested. > > niedz., 20 wrz 2020 o 20:38 Robert Scholte > napisał(a): > > > With the next release of Maven the current maven-gpg-plugin will become > > useless. > > With the build//consumer pom, the local pom will be different compared to > > the uploaded pom. > > However, the maven-gpg-plugin now uses the pom.xml of the local project. > > (btw, the plugin uses the gpg commandline with a bunch of arguments. The > > stdio is used for passing the passphrase, you cannot stream the file via > > commandline) > > > > In Maven 3.6.x changes have been made to support InputStream next to > File. > > This way we don't have to create a backdoor of writing a temporary file, > > which is likely to cause issues with very creative plugin/extension > > writers. Instead we should do in memory signing. > > > > It would make sense to introduce a new plugin, and during a discussion > > with the PMC the idea of maven-sign-plugin was proposed (a much better > > alternative campared to maven-gpg2-plugin) > > > > Dennis Lundberg started a POC based on Apache Common OpenGPG, however, it > > is still in the sandbox[1] > > > > Olivier Lamy already discovered that signing doesn't work with the > current > > Maven 3.7.0-SNAPSHOT. > > Before we can even start thinking of an alpha-release, this issue must be > > fixed, because signing is a critical step for sharing artifacts. > > > > I'm still struggling with MNG-6957, but in parallel a few should be able > > implement this. > > > > Anybody willing to make this work? > > > > thanks, > > Robert > > > > [1] http://commons.apache.org/sandbox/commons-openpgp/ [ > > http://commons.apache.org/sandbox/commons-openpgp/] > > > > > -- > Sławomir Jaranowski > -- Sławomir Jaranowski |
In the end a signer is just another file transformer, so we need to achieve something like this:
local pom >> build/consumer pom (distribute) >> sign (distribute) The plugin must be able to register a SignFileTransformer, which should only be called during deploy. For the latter I can imagine we need to extend the API. thanks, Robert On 28-9-2020 00:35:45, Slawomir Jaranowski <[hidden email]> wrote: In order to remove reflection and possibility to call: FileTransformerManager fileTransformerManager = repositorySystemSession.getFileTransformerManager(); I must add: org.eclipse.aether.transform in: https://github.com/apache/maven/blob/0e3c7a433fc4f700cc2ae6d2c11ae39ec93cbadb/maven-core/src/main/resources/META-INF/maven/extension.xml#L58 Without it I have: java.lang.ClassNotFoundException: org.eclipse.aether.transform.FileTransformerManager this change will be possible in the latest maven version, call above method on older maven version will cause ClassNotFoundException adding direct dependency to maven-resolver-api (even in newer version) in plugin not help, I suppose that classloader for plugin is prepare in special way according to META-INF/maven/extension.xml I don't know why reflection works ... niedz., 27 wrz 2020 o 20:30 Robert Scholte napisał(a): > For now I would focus on making it work for Maven 3.7.0 and above. > That would remove the need for reflection right? > > If there are multiple transfomers, in the end their result should all be > signed. > The reason behind this is that in the future we could upload multiple > files based on the same pom. > We should always upload a model 4.0.0 compatible version, but we might > also transform the local pom to a more efficient file preferred by Maven 5. > > thanks, > Robert > > > > On 27-9-2020 13:06:45, Slawomir Jaranowski wrote: > Ok. > I did some research and spike. > > We need access to *FileTransformerManager*, it look like this is method, > which we want: > > * org.eclipse.aether.RepositorySystemSession#getFileTransformerManager* > We can use it from maven 3.6 (without overwriting the version of > maven-resolver-api) ... so the plugin has a minimum maven requirement for > this version. But even in 3.6 and 3.7-SNAPSHOT i have exception during > execution: > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-sign-plugin:1.0-SNAPSHOT:sign > (with-method-call) on project test1: Execution with-method-call of goal > org.apache.maven.plugins:maven-sign-plugin:1.0-SNAPSHOT:sign failed: A > required class was missing while executing > org.apache.maven.plugins:maven-sign-plugin:1.0-SNAPSHOT:sign: > org/eclipse/aether/transform/FileTransformerManager > > So next I try by reflection ... (now looks not good) ... but I have > expected result > > So when we must use reflection maybe this magic should be done in separate > utils like > *maven-resolver, maven-artifact-transfer *(where we have magic with > reflections) > When we prepare a method/class for transparent transformation in an > external library we can simply use it in the gpg plugin and problems for > the new version of maven will be solved. > Gpg plugin already use *maven-resolver, maven-artifact-transfer* > > Of course we can continue work on the new plugin - but we need more time to > develop the first production/beta version. > > Another question in about api for > > *org.eclipse.aether.transform.FileTransformerManager#getTransformersForArtifact* > result is collection of *FileTransformer* so what should happen when we > have more then one transformer. > In > > https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultInstaller.java#L246 > result file is overwrited by last transformer from list. > > You can look at what I did at my fork: > https://github.com/slawekjaranowski/maven-studies/tree/maven-sign-plugin > > I'm waiting for a decision on what should be done next ... > > sob., 26 wrz 2020 o 11:46 Slawomir Jaranowski > napisał(a): > > > Ok, I don't want to reinvent the wheels, so > > > > How to reach handle to project artifacts list, especially project pom > > after transformation in plugin code? > > > > Some plugin examples, point which component should I use to achieve this > > will be great. > > > > pt., 25 wrz 2020 o 17:05 Robert Scholte napisał(a): > > > >> There no plugin yet, but I suggest to start with a branch under > >> https://github.com/apache/maven-studies before making an official new > >> repository. > >> > >> Let me quote 2 points mentioned by Stephen Connolly, which we still need > >> to address: > >> > >> - If we switch to bouncycastle based, we will now own the key storage. > >> This is both good and bad. > >> * People who have their keys stored in gpg2 will have a “fun time” > >> extracting them... or else we will have to do the dance of extracting > them > >> ourselves. > >> * If we “own” the key storage, publishing keys to a key registry and > >> generating keys may become our problem from the user’s perspective. > >> * One of the biggest complaints about publishing on central has been > >> the difficulty of gpg signing. New users will likely thank us if we > make it > >> easier. > >> > >> - PGP functionality provider security issues become our problem. Before, > >> users could independently upgrade the gpg CLI tooling to work past > security > >> issues (causing it’s own issues as CLI options changed from gpg1 to > gpg2). > >> With this plugin, the pgp provider version will be baked into the pom. > How > >> will users be able to assure their security team that signatures have > been > >> made in the version without a security issue? > >> > >> thanks, > >> Robert > >> On 25-9-2020 15:35:01, Slawomir Jaranowski > >> wrote: > >> Hi > >> > >> On the weekend I will have some spare time, so I can do something about > it > >> .. > >> > >> My questions: > >> - are there git repository, jira project for new plugin > >> - does anybody working on it now - what is progress > >> - if you want to use Apache Common OpenGPG, I think should be refreshed > >> first - is there git repo for it > >> > >> > >> czw., 24 wrz 2020 o 18:57 Robert Scholte napisał(a): > >> > >> > Thanks for the offer. > >> > Signing is very delicate process, so I appreciate the extra help. > >> > > >> > thanks, > >> > Robert > >> > On 21-9-2020 09:14:54, Slawomir Jaranowski wrote: > >> > Hi > >> > > >> > I have some experience in case of verifying pgp signatures using > Bouncy > >> > Castle during work on my pgpverify-maven-plugin. > >> > So If you would, I can try to help with the sign plugin. > >> > > >> > Let me know if you are interested. > >> > > >> > niedz., 20 wrz 2020 o 20:38 Robert Scholte > >> > napisał(a): > >> > > >> > > With the next release of Maven the current maven-gpg-plugin will > >> become > >> > > useless. > >> > > With the build//consumer pom, the local pom will be different > >> compared to > >> > > the uploaded pom. > >> > > However, the maven-gpg-plugin now uses the pom.xml of the local > >> project. > >> > > (btw, the plugin uses the gpg commandline with a bunch of arguments. > >> The > >> > > stdio is used for passing the passphrase, you cannot stream the file > >> via > >> > > commandline) > >> > > > >> > > In Maven 3.6.x changes have been made to support InputStream next to > >> > File. > >> > > This way we don't have to create a backdoor of writing a temporary > >> file, > >> > > which is likely to cause issues with very creative plugin/extension > >> > > writers. Instead we should do in memory signing. > >> > > > >> > > It would make sense to introduce a new plugin, and during a > discussion > >> > > with the PMC the idea of maven-sign-plugin was proposed (a much > better > >> > > alternative campared to maven-gpg2-plugin) > >> > > > >> > > Dennis Lundberg started a POC based on Apache Common OpenGPG, > >> however, it > >> > > is still in the sandbox[1] > >> > > > >> > > Olivier Lamy already discovered that signing doesn't work with the > >> > current > >> > > Maven 3.7.0-SNAPSHOT. > >> > > Before we can even start thinking of an alpha-release, this issue > >> must be > >> > > fixed, because signing is a critical step for sharing artifacts. > >> > > > >> > > I'm still struggling with MNG-6957, but in parallel a few should be > >> able > >> > > implement this. > >> > > > >> > > Anybody willing to make this work? > >> > > > >> > > thanks, > >> > > Robert > >> > > > >> > > [1] http://commons.apache.org/sandbox/commons-openpgp/ [ > >> > > http://commons.apache.org/sandbox/commons-openpgp/] > >> > > > >> > > >> > > >> > -- > >> > Sławomir Jaranowski > >> > > >> > >> > >> -- > >> Sławomir Jaranowski > >> > > > > > > -- > > Sławomir Jaranowski > > > > > -- > Sławomir Jaranowski > -- Sławomir Jaranowski |
First working version is ready:
https://github.com/apache/maven-studies/pull/2 I'm waiting for your opinion pt., 2 paź 2020 o 17:05 Slawomir Jaranowski <[hidden email]> napisał(a): > Targeting to maven 3.7.0-SNAPSHOT makes easier access to Transformer api. > So one issue is need to resolve: > https://issues.apache.org/jira/browse/MNG-6992 > > Of course it is clear that all "uploaded" files must be signed. > Question is - if we should use transformer api only for POM or for all? > > pt., 2 paź 2020 o 15:57 Robert Scholte <[hidden email]> napisał(a): > >> All "uploaded" files must be signed, see for instance >> https://repo1.maven.org/maven2/org/apache/maven/maven-core/3.6.3/ >> And don't care about older Maven versions, for now just set the >> prerequisite for Maven to 3.7.0-SNAPSHOT in the pom. >> >> On 2-10-2020 14:21:02, Slawomir Jaranowski <[hidden email]> >> wrote: >> But on the other side, plugins must sign other artifacts associated with a >> given project. >> >> So in this way we have two different processes - one for pom with >> transformation and ather for rest artifacts. >> >> Maybe all project artifacts should go through the transformation process >> then we can have one way for all. >> >> Anyway, first we should resolve how to access Transformers from the >> plugin. >> And how (if we want) get comparability for old maven versions. >> >> >> pt., 2 paź 2020 o 10:46 Robert Scholte napisał(a): >> >> > In the end a signer is just another file transformer, so we need to >> > achieve something like this: >> > local pom >> build/consumer pom (distribute) >> sign (distribute) >> > The plugin must be able to register a SignFileTransformer, which should >> > only be called during deploy. For the latter I can imagine we need to >> > extend the API. >> > >> > thanks, >> > Robert >> > On 28-9-2020 00:35:45, Slawomir Jaranowski wrote: >> > In order to remove reflection and possibility to call: >> > >> > FileTransformerManager fileTransformerManager = >> > repositorySystemSession.getFileTransformerManager(); >> > >> > I must add: >> > >> > org.eclipse.aether.transform >> > >> > in: >> > >> > >> https://github.com/apache/maven/blob/0e3c7a433fc4f700cc2ae6d2c11ae39ec93cbadb/maven-core/src/main/resources/META-INF/maven/extension.xml#L58 >> > >> > Without it I have: >> > java.lang.ClassNotFoundException: >> > org.eclipse.aether.transform.FileTransformerManager >> > >> > this change will be possible in the latest maven version, call above >> method >> > on older maven version will cause ClassNotFoundException >> > >> > adding direct dependency to maven-resolver-api (even in newer version) >> in >> > plugin not help, >> > I suppose that classloader for plugin is prepare in special way >> according >> > to META-INF/maven/extension.xml >> > >> > I don't know why reflection works ... >> > >> > >> > >> > niedz., 27 wrz 2020 o 20:30 Robert Scholte >> > napisał(a): >> > >> > > For now I would focus on making it work for Maven 3.7.0 and above. >> > > That would remove the need for reflection right? >> > > >> > > If there are multiple transfomers, in the end their result should all >> be >> > > signed. >> > > The reason behind this is that in the future we could upload multiple >> > > files based on the same pom. >> > > We should always upload a model 4.0.0 compatible version, but we might >> > > also transform the local pom to a more efficient file preferred by >> Maven >> > 5. >> > > >> > > thanks, >> > > Robert >> > > >> > > >> > > >> > > On 27-9-2020 13:06:45, Slawomir Jaranowski wrote: >> > > Ok. >> > > I did some research and spike. >> > > >> > > We need access to *FileTransformerManager*, it look like this is >> method, >> > > which we want: >> > > >> > > * >> org.eclipse.aether.RepositorySystemSession#getFileTransformerManager* >> > > We can use it from maven 3.6 (without overwriting the version of >> > > maven-resolver-api) ... so the plugin has a minimum maven requirement >> for >> > > this version. But even in 3.6 and 3.7-SNAPSHOT i have exception during >> > > execution: >> > > >> > > [ERROR] Failed to execute goal >> > > org.apache.maven.plugins:maven-sign-plugin:1.0-SNAPSHOT:sign >> > > (with-method-call) on project test1: Execution with-method-call of >> goal >> > > org.apache.maven.plugins:maven-sign-plugin:1.0-SNAPSHOT:sign failed: A >> > > required class was missing while executing >> > > org.apache.maven.plugins:maven-sign-plugin:1.0-SNAPSHOT:sign: >> > > org/eclipse/aether/transform/FileTransformerManager >> > > >> > > So next I try by reflection ... (now looks not good) ... but I have >> > > expected result >> > > >> > > So when we must use reflection maybe this magic should be done in >> > separate >> > > utils like >> > > *maven-resolver, maven-artifact-transfer *(where we have magic with >> > > reflections) >> > > When we prepare a method/class for transparent transformation in an >> > > external library we can simply use it in the gpg plugin and problems >> for >> > > the new version of maven will be solved. >> > > Gpg plugin already use *maven-resolver, maven-artifact-transfer* >> > > >> > > Of course we can continue work on the new plugin - but we need more >> time >> > to >> > > develop the first production/beta version. >> > > >> > > Another question in about api for >> > > >> > > >> > >> *org.eclipse.aether.transform.FileTransformerManager#getTransformersForArtifact* >> > > result is collection of *FileTransformer* so what should happen when >> we >> > > have more then one transformer. >> > > In >> > > >> > > >> > >> https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultInstaller.java#L246 >> > > result file is overwrited by last transformer from list. >> > > >> > > You can look at what I did at my fork: >> > > >> https://github.com/slawekjaranowski/maven-studies/tree/maven-sign-plugin >> > > >> > > I'm waiting for a decision on what should be done next ... >> > > >> > > sob., 26 wrz 2020 o 11:46 Slawomir Jaranowski >> > > napisał(a): >> > > >> > > > Ok, I don't want to reinvent the wheels, so >> > > > >> > > > How to reach handle to project artifacts list, especially project >> pom >> > > > after transformation in plugin code? >> > > > >> > > > Some plugin examples, point which component should I use to achieve >> > this >> > > > will be great. >> > > > >> > > > pt., 25 wrz 2020 o 17:05 Robert Scholte napisał(a): >> > > > >> > > >> There no plugin yet, but I suggest to start with a branch under >> > > >> https://github.com/apache/maven-studies before making an official >> new >> > > >> repository. >> > > >> >> > > >> Let me quote 2 points mentioned by Stephen Connolly, which we still >> > need >> > > >> to address: >> > > >> >> > > >> - If we switch to bouncycastle based, we will now own the key >> storage. >> > > >> This is both good and bad. >> > > >> * People who have their keys stored in gpg2 will have a “fun time” >> > > >> extracting them... or else we will have to do the dance of >> extracting >> > > them >> > > >> ourselves. >> > > >> * If we “own” the key storage, publishing keys to a key registry >> and >> > > >> generating keys may become our problem from the user’s perspective. >> > > >> * One of the biggest complaints about publishing on central has >> been >> > > >> the difficulty of gpg signing. New users will likely thank us if we >> > > make it >> > > >> easier. >> > > >> >> > > >> - PGP functionality provider security issues become our problem. >> > Before, >> > > >> users could independently upgrade the gpg CLI tooling to work past >> > > security >> > > >> issues (causing it’s own issues as CLI options changed from gpg1 to >> > > gpg2). >> > > >> With this plugin, the pgp provider version will be baked into the >> pom. >> > > How >> > > >> will users be able to assure their security team that signatures >> have >> > > been >> > > >> made in the version without a security issue? >> > > >> >> > > >> thanks, >> > > >> Robert >> > > >> On 25-9-2020 15:35:01, Slawomir Jaranowski >> > > >> wrote: >> > > >> Hi >> > > >> >> > > >> On the weekend I will have some spare time, so I can do something >> > about >> > > it >> > > >> .. >> > > >> >> > > >> My questions: >> > > >> - are there git repository, jira project for new plugin >> > > >> - does anybody working on it now - what is progress >> > > >> - if you want to use Apache Common OpenGPG, I think should be >> > refreshed >> > > >> first - is there git repo for it >> > > >> >> > > >> >> > > >> czw., 24 wrz 2020 o 18:57 Robert Scholte napisał(a): >> > > >> >> > > >> > Thanks for the offer. >> > > >> > Signing is very delicate process, so I appreciate the extra help. >> > > >> > >> > > >> > thanks, >> > > >> > Robert >> > > >> > On 21-9-2020 09:14:54, Slawomir Jaranowski wrote: >> > > >> > Hi >> > > >> > >> > > >> > I have some experience in case of verifying pgp signatures using >> > > Bouncy >> > > >> > Castle during work on my pgpverify-maven-plugin. >> > > >> > So If you would, I can try to help with the sign plugin. >> > > >> > >> > > >> > Let me know if you are interested. >> > > >> > >> > > >> > niedz., 20 wrz 2020 o 20:38 Robert Scholte >> > > >> > napisał(a): >> > > >> > >> > > >> > > With the next release of Maven the current maven-gpg-plugin >> will >> > > >> become >> > > >> > > useless. >> > > >> > > With the build//consumer pom, the local pom will be different >> > > >> compared to >> > > >> > > the uploaded pom. >> > > >> > > However, the maven-gpg-plugin now uses the pom.xml of the local >> > > >> project. >> > > >> > > (btw, the plugin uses the gpg commandline with a bunch of >> > arguments. >> > > >> The >> > > >> > > stdio is used for passing the passphrase, you cannot stream the >> > file >> > > >> via >> > > >> > > commandline) >> > > >> > > >> > > >> > > In Maven 3.6.x changes have been made to support InputStream >> next >> > to >> > > >> > File. >> > > >> > > This way we don't have to create a backdoor of writing a >> temporary >> > > >> file, >> > > >> > > which is likely to cause issues with very creative >> > plugin/extension >> > > >> > > writers. Instead we should do in memory signing. >> > > >> > > >> > > >> > > It would make sense to introduce a new plugin, and during a >> > > discussion >> > > >> > > with the PMC the idea of maven-sign-plugin was proposed (a much >> > > better >> > > >> > > alternative campared to maven-gpg2-plugin) >> > > >> > > >> > > >> > > Dennis Lundberg started a POC based on Apache Common OpenGPG, >> > > >> however, it >> > > >> > > is still in the sandbox[1] >> > > >> > > >> > > >> > > Olivier Lamy already discovered that signing doesn't work with >> the >> > > >> > current >> > > >> > > Maven 3.7.0-SNAPSHOT. >> > > >> > > Before we can even start thinking of an alpha-release, this >> issue >> > > >> must be >> > > >> > > fixed, because signing is a critical step for sharing >> artifacts. >> > > >> > > >> > > >> > > I'm still struggling with MNG-6957, but in parallel a few >> should >> > be >> > > >> able >> > > >> > > implement this. >> > > >> > > >> > > >> > > Anybody willing to make this work? >> > > >> > > >> > > >> > > thanks, >> > > >> > > Robert >> > > >> > > >> > > >> > > [1] http://commons.apache.org/sandbox/commons-openpgp/ [ >> > > >> > > http://commons.apache.org/sandbox/commons-openpgp/] >> > > >> > > >> > > >> > >> > > >> > >> > > >> > -- >> > > >> > Sławomir Jaranowski >> > > >> > >> > > >> >> > > >> >> > > >> -- >> > > >> Sławomir Jaranowski >> > > >> >> > > > >> > > > >> > > > -- >> > > > Sławomir Jaranowski >> > > > >> > > >> > > >> > > -- >> > > Sławomir Jaranowski >> > > >> > >> > >> > -- >> > Sławomir Jaranowski >> > >> >> >> -- >> Sławomir Jaranowski >> > > > -- > Sławomir Jaranowski > -- Sławomir Jaranowski |
Hi
What next step do you plan with this plugin? I believe that can be usable even now for users. It is not too much work to prepare a plugin to work with maven 3.6 so we can publish it and take feedback from users. I think that early release can help users to prepare their project to be ready for maven 3.7. If you wish I will take care about this plugin. niedz., 4 paź 2020 o 15:32 Slawomir Jaranowski <[hidden email]> napisał(a): > First working version is ready: > > https://github.com/apache/maven-studies/pull/2 > > I'm waiting for your opinion > > pt., 2 paź 2020 o 17:05 Slawomir Jaranowski <[hidden email]> > napisał(a): > >> Targeting to maven 3.7.0-SNAPSHOT makes easier access to Transformer api. >> So one issue is need to resolve: >> https://issues.apache.org/jira/browse/MNG-6992 >> >> Of course it is clear that all "uploaded" files must be signed. >> Question is - if we should use transformer api only for POM or for all? >> >> pt., 2 paź 2020 o 15:57 Robert Scholte <[hidden email]> napisał(a): >> >>> All "uploaded" files must be signed, see for instance >>> https://repo1.maven.org/maven2/org/apache/maven/maven-core/3.6.3/ >>> And don't care about older Maven versions, for now just set the >>> prerequisite for Maven to 3.7.0-SNAPSHOT in the pom. >>> >>> On 2-10-2020 14:21:02, Slawomir Jaranowski <[hidden email]> >>> wrote: >>> But on the other side, plugins must sign other artifacts associated with >>> a >>> given project. >>> >>> So in this way we have two different processes - one for pom with >>> transformation and ather for rest artifacts. >>> >>> Maybe all project artifacts should go through the transformation process >>> then we can have one way for all. >>> >>> Anyway, first we should resolve how to access Transformers from the >>> plugin. >>> And how (if we want) get comparability for old maven versions. >>> >>> >>> pt., 2 paź 2020 o 10:46 Robert Scholte napisał(a): >>> >>> > In the end a signer is just another file transformer, so we need to >>> > achieve something like this: >>> > local pom >> build/consumer pom (distribute) >> sign (distribute) >>> > The plugin must be able to register a SignFileTransformer, which should >>> > only be called during deploy. For the latter I can imagine we need to >>> > extend the API. >>> > >>> > thanks, >>> > Robert >>> > On 28-9-2020 00:35:45, Slawomir Jaranowski wrote: >>> > In order to remove reflection and possibility to call: >>> > >>> > FileTransformerManager fileTransformerManager = >>> > repositorySystemSession.getFileTransformerManager(); >>> > >>> > I must add: >>> > >>> > org.eclipse.aether.transform >>> > >>> > in: >>> > >>> > >>> https://github.com/apache/maven/blob/0e3c7a433fc4f700cc2ae6d2c11ae39ec93cbadb/maven-core/src/main/resources/META-INF/maven/extension.xml#L58 >>> > >>> > Without it I have: >>> > java.lang.ClassNotFoundException: >>> > org.eclipse.aether.transform.FileTransformerManager >>> > >>> > this change will be possible in the latest maven version, call above >>> method >>> > on older maven version will cause ClassNotFoundException >>> > >>> > adding direct dependency to maven-resolver-api (even in newer version) >>> in >>> > plugin not help, >>> > I suppose that classloader for plugin is prepare in special way >>> according >>> > to META-INF/maven/extension.xml >>> > >>> > I don't know why reflection works ... >>> > >>> > >>> > >>> > niedz., 27 wrz 2020 o 20:30 Robert Scholte >>> > napisał(a): >>> > >>> > > For now I would focus on making it work for Maven 3.7.0 and above. >>> > > That would remove the need for reflection right? >>> > > >>> > > If there are multiple transfomers, in the end their result should >>> all be >>> > > signed. >>> > > The reason behind this is that in the future we could upload multiple >>> > > files based on the same pom. >>> > > We should always upload a model 4.0.0 compatible version, but we >>> might >>> > > also transform the local pom to a more efficient file preferred by >>> Maven >>> > 5. >>> > > >>> > > thanks, >>> > > Robert >>> > > >>> > > >>> > > >>> > > On 27-9-2020 13:06:45, Slawomir Jaranowski wrote: >>> > > Ok. >>> > > I did some research and spike. >>> > > >>> > > We need access to *FileTransformerManager*, it look like this is >>> method, >>> > > which we want: >>> > > >>> > > * >>> org.eclipse.aether.RepositorySystemSession#getFileTransformerManager* >>> > > We can use it from maven 3.6 (without overwriting the version of >>> > > maven-resolver-api) ... so the plugin has a minimum maven >>> requirement for >>> > > this version. But even in 3.6 and 3.7-SNAPSHOT i have exception >>> during >>> > > execution: >>> > > >>> > > [ERROR] Failed to execute goal >>> > > org.apache.maven.plugins:maven-sign-plugin:1.0-SNAPSHOT:sign >>> > > (with-method-call) on project test1: Execution with-method-call of >>> goal >>> > > org.apache.maven.plugins:maven-sign-plugin:1.0-SNAPSHOT:sign failed: >>> A >>> > > required class was missing while executing >>> > > org.apache.maven.plugins:maven-sign-plugin:1.0-SNAPSHOT:sign: >>> > > org/eclipse/aether/transform/FileTransformerManager >>> > > >>> > > So next I try by reflection ... (now looks not good) ... but I have >>> > > expected result >>> > > >>> > > So when we must use reflection maybe this magic should be done in >>> > separate >>> > > utils like >>> > > *maven-resolver, maven-artifact-transfer *(where we have magic with >>> > > reflections) >>> > > When we prepare a method/class for transparent transformation in an >>> > > external library we can simply use it in the gpg plugin and problems >>> for >>> > > the new version of maven will be solved. >>> > > Gpg plugin already use *maven-resolver, maven-artifact-transfer* >>> > > >>> > > Of course we can continue work on the new plugin - but we need more >>> time >>> > to >>> > > develop the first production/beta version. >>> > > >>> > > Another question in about api for >>> > > >>> > > >>> > >>> *org.eclipse.aether.transform.FileTransformerManager#getTransformersForArtifact* >>> > > result is collection of *FileTransformer* so what should happen when >>> we >>> > > have more then one transformer. >>> > > In >>> > > >>> > > >>> > >>> https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultInstaller.java#L246 >>> > > result file is overwrited by last transformer from list. >>> > > >>> > > You can look at what I did at my fork: >>> > > >>> https://github.com/slawekjaranowski/maven-studies/tree/maven-sign-plugin >>> > > >>> > > I'm waiting for a decision on what should be done next ... >>> > > >>> > > sob., 26 wrz 2020 o 11:46 Slawomir Jaranowski >>> > > napisał(a): >>> > > >>> > > > Ok, I don't want to reinvent the wheels, so >>> > > > >>> > > > How to reach handle to project artifacts list, especially project >>> pom >>> > > > after transformation in plugin code? >>> > > > >>> > > > Some plugin examples, point which component should I use to achieve >>> > this >>> > > > will be great. >>> > > > >>> > > > pt., 25 wrz 2020 o 17:05 Robert Scholte napisał(a): >>> > > > >>> > > >> There no plugin yet, but I suggest to start with a branch under >>> > > >> https://github.com/apache/maven-studies before making an >>> official new >>> > > >> repository. >>> > > >> >>> > > >> Let me quote 2 points mentioned by Stephen Connolly, which we >>> still >>> > need >>> > > >> to address: >>> > > >> >>> > > >> - If we switch to bouncycastle based, we will now own the key >>> storage. >>> > > >> This is both good and bad. >>> > > >> * People who have their keys stored in gpg2 will have a “fun time” >>> > > >> extracting them... or else we will have to do the dance of >>> extracting >>> > > them >>> > > >> ourselves. >>> > > >> * If we “own” the key storage, publishing keys to a key registry >>> and >>> > > >> generating keys may become our problem from the user’s >>> perspective. >>> > > >> * One of the biggest complaints about publishing on central has >>> been >>> > > >> the difficulty of gpg signing. New users will likely thank us if >>> we >>> > > make it >>> > > >> easier. >>> > > >> >>> > > >> - PGP functionality provider security issues become our problem. >>> > Before, >>> > > >> users could independently upgrade the gpg CLI tooling to work past >>> > > security >>> > > >> issues (causing it’s own issues as CLI options changed from gpg1 >>> to >>> > > gpg2). >>> > > >> With this plugin, the pgp provider version will be baked into the >>> pom. >>> > > How >>> > > >> will users be able to assure their security team that signatures >>> have >>> > > been >>> > > >> made in the version without a security issue? >>> > > >> >>> > > >> thanks, >>> > > >> Robert >>> > > >> On 25-9-2020 15:35:01, Slawomir Jaranowski >>> > > >> wrote: >>> > > >> Hi >>> > > >> >>> > > >> On the weekend I will have some spare time, so I can do something >>> > about >>> > > it >>> > > >> .. >>> > > >> >>> > > >> My questions: >>> > > >> - are there git repository, jira project for new plugin >>> > > >> - does anybody working on it now - what is progress >>> > > >> - if you want to use Apache Common OpenGPG, I think should be >>> > refreshed >>> > > >> first - is there git repo for it >>> > > >> >>> > > >> >>> > > >> czw., 24 wrz 2020 o 18:57 Robert Scholte napisał(a): >>> > > >> >>> > > >> > Thanks for the offer. >>> > > >> > Signing is very delicate process, so I appreciate the extra >>> help. >>> > > >> > >>> > > >> > thanks, >>> > > >> > Robert >>> > > >> > On 21-9-2020 09:14:54, Slawomir Jaranowski wrote: >>> > > >> > Hi >>> > > >> > >>> > > >> > I have some experience in case of verifying pgp signatures using >>> > > Bouncy >>> > > >> > Castle during work on my pgpverify-maven-plugin. >>> > > >> > So If you would, I can try to help with the sign plugin. >>> > > >> > >>> > > >> > Let me know if you are interested. >>> > > >> > >>> > > >> > niedz., 20 wrz 2020 o 20:38 Robert Scholte >>> > > >> > napisał(a): >>> > > >> > >>> > > >> > > With the next release of Maven the current maven-gpg-plugin >>> will >>> > > >> become >>> > > >> > > useless. >>> > > >> > > With the build//consumer pom, the local pom will be different >>> > > >> compared to >>> > > >> > > the uploaded pom. >>> > > >> > > However, the maven-gpg-plugin now uses the pom.xml of the >>> local >>> > > >> project. >>> > > >> > > (btw, the plugin uses the gpg commandline with a bunch of >>> > arguments. >>> > > >> The >>> > > >> > > stdio is used for passing the passphrase, you cannot stream >>> the >>> > file >>> > > >> via >>> > > >> > > commandline) >>> > > >> > > >>> > > >> > > In Maven 3.6.x changes have been made to support InputStream >>> next >>> > to >>> > > >> > File. >>> > > >> > > This way we don't have to create a backdoor of writing a >>> temporary >>> > > >> file, >>> > > >> > > which is likely to cause issues with very creative >>> > plugin/extension >>> > > >> > > writers. Instead we should do in memory signing. >>> > > >> > > >>> > > >> > > It would make sense to introduce a new plugin, and during a >>> > > discussion >>> > > >> > > with the PMC the idea of maven-sign-plugin was proposed (a >>> much >>> > > better >>> > > >> > > alternative campared to maven-gpg2-plugin) >>> > > >> > > >>> > > >> > > Dennis Lundberg started a POC based on Apache Common OpenGPG, >>> > > >> however, it >>> > > >> > > is still in the sandbox[1] >>> > > >> > > >>> > > >> > > Olivier Lamy already discovered that signing doesn't work >>> with the >>> > > >> > current >>> > > >> > > Maven 3.7.0-SNAPSHOT. >>> > > >> > > Before we can even start thinking of an alpha-release, this >>> issue >>> > > >> must be >>> > > >> > > fixed, because signing is a critical step for sharing >>> artifacts. >>> > > >> > > >>> > > >> > > I'm still struggling with MNG-6957, but in parallel a few >>> should >>> > be >>> > > >> able >>> > > >> > > implement this. >>> > > >> > > >>> > > >> > > Anybody willing to make this work? >>> > > >> > > >>> > > >> > > thanks, >>> > > >> > > Robert >>> > > >> > > >>> > > >> > > [1] http://commons.apache.org/sandbox/commons-openpgp/ [ >>> > > >> > > http://commons.apache.org/sandbox/commons-openpgp/] >>> > > >> > > >>> > > >> > >>> > > >> > >>> > > >> > -- >>> > > >> > Sławomir Jaranowski >>> > > >> > >>> > > >> >>> > > >> >>> > > >> -- >>> > > >> Sławomir Jaranowski >>> > > >> >>> > > > >>> > > > >>> > > > -- >>> > > > Sławomir Jaranowski >>> > > > >>> > > >>> > > >>> > > -- >>> > > Sławomir Jaranowski >>> > > >>> > >>> > >>> > -- >>> > Sławomir Jaranowski >>> > >>> >>> >>> -- >>> Sławomir Jaranowski >>> >> >> >> -- >> Sławomir Jaranowski >> > > > -- > Sławomir Jaranowski > -- Sławomir Jaranowski |
I want to have another look at Maven Resolver. I don't want to store it as a file, but stream it directly to a repository.
The goal is now bound to verify, but that's incorrect (it has nothing to do with verifying integration results). Looking at it, I think this should not be a maven-plugin, but a Maven extension, so it can hook itself during deploy, no need for an explicit goal to call I need to work it out a bit more. thanks, Robert On 19-10-2020 22:47:06, Slawomir Jaranowski <[hidden email]> wrote: Hi What next step do you plan with this plugin? I believe that can be usable even now for users. It is not too much work to prepare a plugin to work with maven 3.6 so we can publish it and take feedback from users. I think that early release can help users to prepare their project to be ready for maven 3.7. If you wish I will take care about this plugin. niedz., 4 paź 2020 o 15:32 Slawomir Jaranowski napisał(a): > First working version is ready: > > https://github.com/apache/maven-studies/pull/2 > > I'm waiting for your opinion > > pt., 2 paź 2020 o 17:05 Slawomir Jaranowski > napisał(a): > >> Targeting to maven 3.7.0-SNAPSHOT makes easier access to Transformer api. >> So one issue is need to resolve: >> https://issues.apache.org/jira/browse/MNG-6992 >> >> Of course it is clear that all "uploaded" files must be signed. >> Question is - if we should use transformer api only for POM or for all? >> >> pt., 2 paź 2020 o 15:57 Robert Scholte napisał(a): >> >>> All "uploaded" files must be signed, see for instance >>> https://repo1.maven.org/maven2/org/apache/maven/maven-core/3.6.3/ >>> And don't care about older Maven versions, for now just set the >>> prerequisite for Maven to 3.7.0-SNAPSHOT in the pom. >>> >>> On 2-10-2020 14:21:02, Slawomir Jaranowski >>> wrote: >>> But on the other side, plugins must sign other artifacts associated with >>> a >>> given project. >>> >>> So in this way we have two different processes - one for pom with >>> transformation and ather for rest artifacts. >>> >>> Maybe all project artifacts should go through the transformation process >>> then we can have one way for all. >>> >>> Anyway, first we should resolve how to access Transformers from the >>> plugin. >>> And how (if we want) get comparability for old maven versions. >>> >>> >>> pt., 2 paź 2020 o 10:46 Robert Scholte napisał(a): >>> >>> > In the end a signer is just another file transformer, so we need to >>> > achieve something like this: >>> > local pom >> build/consumer pom (distribute) >> sign (distribute) >>> > The plugin must be able to register a SignFileTransformer, which should >>> > only be called during deploy. For the latter I can imagine we need to >>> > extend the API. >>> > >>> > thanks, >>> > Robert >>> > On 28-9-2020 00:35:45, Slawomir Jaranowski wrote: >>> > In order to remove reflection and possibility to call: >>> > >>> > FileTransformerManager fileTransformerManager = >>> > repositorySystemSession.getFileTransformerManager(); >>> > >>> > I must add: >>> > >>> > org.eclipse.aether.transform >>> > >>> > in: >>> > >>> > >>> https://github.com/apache/maven/blob/0e3c7a433fc4f700cc2ae6d2c11ae39ec93cbadb/maven-core/src/main/resources/META-INF/maven/extension.xml#L58 >>> > >>> > Without it I have: >>> > java.lang.ClassNotFoundException: >>> > org.eclipse.aether.transform.FileTransformerManager >>> > >>> > this change will be possible in the latest maven version, call above >>> method >>> > on older maven version will cause ClassNotFoundException >>> > >>> > adding direct dependency to maven-resolver-api (even in newer version) >>> in >>> > plugin not help, >>> > I suppose that classloader for plugin is prepare in special way >>> according >>> > to META-INF/maven/extension.xml >>> > >>> > I don't know why reflection works ... >>> > >>> > >>> > >>> > niedz., 27 wrz 2020 o 20:30 Robert Scholte >>> > napisał(a): >>> > >>> > > For now I would focus on making it work for Maven 3.7.0 and above. >>> > > That would remove the need for reflection right? >>> > > >>> > > If there are multiple transfomers, in the end their result should >>> all be >>> > > signed. >>> > > The reason behind this is that in the future we could upload multiple >>> > > files based on the same pom. >>> > > We should always upload a model 4.0.0 compatible version, but we >>> might >>> > > also transform the local pom to a more efficient file preferred by >>> Maven >>> > 5. >>> > > >>> > > thanks, >>> > > Robert >>> > > >>> > > >>> > > >>> > > On 27-9-2020 13:06:45, Slawomir Jaranowski wrote: >>> > > Ok. >>> > > I did some research and spike. >>> > > >>> > > We need access to *FileTransformerManager*, it look like this is >>> method, >>> > > which we want: >>> > > >>> > > * >>> org.eclipse.aether.RepositorySystemSession#getFileTransformerManager* >>> > > We can use it from maven 3.6 (without overwriting the version of >>> > > maven-resolver-api) ... so the plugin has a minimum maven >>> requirement for >>> > > this version. But even in 3.6 and 3.7-SNAPSHOT i have exception >>> during >>> > > execution: >>> > > >>> > > [ERROR] Failed to execute goal >>> > > org.apache.maven.plugins:maven-sign-plugin:1.0-SNAPSHOT:sign >>> > > (with-method-call) on project test1: Execution with-method-call of >>> goal >>> > > org.apache.maven.plugins:maven-sign-plugin:1.0-SNAPSHOT:sign failed: >>> A >>> > > required class was missing while executing >>> > > org.apache.maven.plugins:maven-sign-plugin:1.0-SNAPSHOT:sign: >>> > > org/eclipse/aether/transform/FileTransformerManager >>> > > >>> > > So next I try by reflection ... (now looks not good) ... but I have >>> > > expected result >>> > > >>> > > So when we must use reflection maybe this magic should be done in >>> > separate >>> > > utils like >>> > > *maven-resolver, maven-artifact-transfer *(where we have magic with >>> > > reflections) >>> > > When we prepare a method/class for transparent transformation in an >>> > > external library we can simply use it in the gpg plugin and problems >>> for >>> > > the new version of maven will be solved. >>> > > Gpg plugin already use *maven-resolver, maven-artifact-transfer* >>> > > >>> > > Of course we can continue work on the new plugin - but we need more >>> time >>> > to >>> > > develop the first production/beta version. >>> > > >>> > > Another question in about api for >>> > > >>> > > >>> > >>> *org.eclipse.aether.transform.FileTransformerManager#getTransformersForArtifact* >>> > > result is collection of *FileTransformer* so what should happen when >>> we >>> > > have more then one transformer. >>> > > In >>> > > >>> > > >>> > >>> https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultInstaller.java#L246 >>> > > result file is overwrited by last transformer from list. >>> > > >>> > > You can look at what I did at my fork: >>> > > >>> https://github.com/slawekjaranowski/maven-studies/tree/maven-sign-plugin >>> > > >>> > > I'm waiting for a decision on what should be done next ... >>> > > >>> > > sob., 26 wrz 2020 o 11:46 Slawomir Jaranowski >>> > > napisał(a): >>> > > >>> > > > Ok, I don't want to reinvent the wheels, so >>> > > > >>> > > > How to reach handle to project artifacts list, especially project >>> pom >>> > > > after transformation in plugin code? >>> > > > >>> > > > Some plugin examples, point which component should I use to achieve >>> > this >>> > > > will be great. >>> > > > >>> > > > pt., 25 wrz 2020 o 17:05 Robert Scholte napisał(a): >>> > > > >>> > > >> There no plugin yet, but I suggest to start with a branch under >>> > > >> https://github.com/apache/maven-studies before making an >>> official new >>> > > >> repository. >>> > > >> >>> > > >> Let me quote 2 points mentioned by Stephen Connolly, which we >>> still >>> > need >>> > > >> to address: >>> > > >> >>> > > >> - If we switch to bouncycastle based, we will now own the key >>> storage. >>> > > >> This is both good and bad. >>> > > >> * People who have their keys stored in gpg2 will have a “fun time” >>> > > >> extracting them... or else we will have to do the dance of >>> extracting >>> > > them >>> > > >> ourselves. >>> > > >> * If we “own” the key storage, publishing keys to a key registry >>> and >>> > > >> generating keys may become our problem from the user’s >>> perspective. >>> > > >> * One of the biggest complaints about publishing on central has >>> been >>> > > >> the difficulty of gpg signing. New users will likely thank us if >>> we >>> > > make it >>> > > >> easier. >>> > > >> >>> > > >> - PGP functionality provider security issues become our problem. >>> > Before, >>> > > >> users could independently upgrade the gpg CLI tooling to work past >>> > > security >>> > > >> issues (causing it’s own issues as CLI options changed from gpg1 >>> to >>> > > gpg2). >>> > > >> With this plugin, the pgp provider version will be baked into the >>> pom. >>> > > How >>> > > >> will users be able to assure their security team that signatures >>> have >>> > > been >>> > > >> made in the version without a security issue? >>> > > >> >>> > > >> thanks, >>> > > >> Robert >>> > > >> On 25-9-2020 15:35:01, Slawomir Jaranowski >>> > > >> wrote: >>> > > >> Hi >>> > > >> >>> > > >> On the weekend I will have some spare time, so I can do something >>> > about >>> > > it >>> > > >> .. >>> > > >> >>> > > >> My questions: >>> > > >> - are there git repository, jira project for new plugin >>> > > >> - does anybody working on it now - what is progress >>> > > >> - if you want to use Apache Common OpenGPG, I think should be >>> > refreshed >>> > > >> first - is there git repo for it >>> > > >> >>> > > >> >>> > > >> czw., 24 wrz 2020 o 18:57 Robert Scholte napisał(a): >>> > > >> >>> > > >> > Thanks for the offer. >>> > > >> > Signing is very delicate process, so I appreciate the extra >>> help. >>> > > >> > >>> > > >> > thanks, >>> > > >> > Robert >>> > > >> > On 21-9-2020 09:14:54, Slawomir Jaranowski wrote: >>> > > >> > Hi >>> > > >> > >>> > > >> > I have some experience in case of verifying pgp signatures using >>> > > Bouncy >>> > > >> > Castle during work on my pgpverify-maven-plugin. >>> > > >> > So If you would, I can try to help with the sign plugin. >>> > > >> > >>> > > >> > Let me know if you are interested. >>> > > >> > >>> > > >> > niedz., 20 wrz 2020 o 20:38 Robert Scholte >>> > > >> > napisał(a): >>> > > >> > >>> > > >> > > With the next release of Maven the current maven-gpg-plugin >>> will >>> > > >> become >>> > > >> > > useless. >>> > > >> > > With the build//consumer pom, the local pom will be different >>> > > >> compared to >>> > > >> > > the uploaded pom. >>> > > >> > > However, the maven-gpg-plugin now uses the pom.xml of the >>> local >>> > > >> project. >>> > > >> > > (btw, the plugin uses the gpg commandline with a bunch of >>> > arguments. >>> > > >> The >>> > > >> > > stdio is used for passing the passphrase, you cannot stream >>> the >>> > file >>> > > >> via >>> > > >> > > commandline) >>> > > >> > > >>> > > >> > > In Maven 3.6.x changes have been made to support InputStream >>> next >>> > to >>> > > >> > File. >>> > > >> > > This way we don't have to create a backdoor of writing a >>> temporary >>> > > >> file, >>> > > >> > > which is likely to cause issues with very creative >>> > plugin/extension >>> > > >> > > writers. Instead we should do in memory signing. >>> > > >> > > >>> > > >> > > It would make sense to introduce a new plugin, and during a >>> > > discussion >>> > > >> > > with the PMC the idea of maven-sign-plugin was proposed (a >>> much >>> > > better >>> > > >> > > alternative campared to maven-gpg2-plugin) >>> > > >> > > >>> > > >> > > Dennis Lundberg started a POC based on Apache Common OpenGPG, >>> > > >> however, it >>> > > >> > > is still in the sandbox[1] >>> > > >> > > >>> > > >> > > Olivier Lamy already discovered that signing doesn't work >>> with the >>> > > >> > current >>> > > >> > > Maven 3.7.0-SNAPSHOT. >>> > > >> > > Before we can even start thinking of an alpha-release, this >>> issue >>> > > >> must be >>> > > >> > > fixed, because signing is a critical step for sharing >>> artifacts. >>> > > >> > > >>> > > >> > > I'm still struggling with MNG-6957, but in parallel a few >>> should >>> > be >>> > > >> able >>> > > >> > > implement this. >>> > > >> > > >>> > > >> > > Anybody willing to make this work? >>> > > >> > > >>> > > >> > > thanks, >>> > > >> > > Robert >>> > > >> > > >>> > > >> > > [1] http://commons.apache.org/sandbox/commons-openpgp/ [ >>> > > >> > > http://commons.apache.org/sandbox/commons-openpgp/] >>> > > >> > > >>> > > >> > >>> > > >> > >>> > > >> > -- >>> > > >> > Sławomir Jaranowski >>> > > >> > >>> > > >> >>> > > >> >>> > > >> -- >>> > > >> Sławomir Jaranowski >>> > > >> >>> > > > >>> > > > >>> > > > -- >>> > > > Sławomir Jaranowski >>> > > > >>> > > >>> > > >>> > > -- >>> > > Sławomir Jaranowski >>> > > >>> > >>> > >>> > -- >>> > Sławomir Jaranowski >>> > >>> >>> >>> -- >>> Sławomir Jaranowski >>> >> >> >> -- >> Sławomir Jaranowski >> > > > -- > Sławomir Jaranowski > -- Sławomir Jaranowski |
Hi,
First version of Sign Maven Plugin was released - https://github.com/s4u/sign-maven-plugin It works with Maven 3.6.x and future version 4.x If somebody is interested I invite them to test and collaborate. pon., 14 gru 2020 o 21:42 Slawomir Jaranowski <[hidden email]> napisał(a): > Hi, > > The Idea of making a signature by java code without an external binary is > very good. > > I have plans to automate some of CI/CD and such plugin will be very > useful for me. > I can customise it for easy use with CI system > > So waiting for you, > I will release it under my github organization, probably at the end of > year. If someone is interested please let me know. > > > pon., 2 lis 2020 o 21:36 Robert Scholte <[hidden email]> napisał(a): > >> I want to have another look at Maven Resolver. I don't want to store it >> as a file, but stream it directly to a repository. >> The goal is now bound to verify, but that's incorrect (it has nothing to >> do with verifying integration results). >> Looking at it, I think this should not be a maven-plugin, but a Maven >> extension, so it can hook itself during deploy, no need for an explicit >> goal to call >> I need to work it out a bit more. >> >> thanks, >> Robert >> >> On 19-10-2020 22:47:06, Slawomir Jaranowski <[hidden email]> >> wrote: >> Hi >> >> What next step do you plan with this plugin? >> >> I believe that can be usable even now for users. >> >> It is not too much work to prepare a plugin to work with maven 3.6 so we >> can publish it and take feedback from users. >> >> I think that early release can help users to prepare their project to be >> ready for maven 3.7. >> >> If you wish I will take care about this plugin. >> >> niedz., 4 paź 2020 o 15:32 Slawomir Jaranowski >> napisał(a): >> >> > First working version is ready: >> > >> > https://github.com/apache/maven-studies/pull/2 >> > >> > I'm waiting for your opinion >> > >> > pt., 2 paź 2020 o 17:05 Slawomir Jaranowski >> > napisał(a): >> > >> >> Targeting to maven 3.7.0-SNAPSHOT makes easier access to Transformer >> api. >> >> So one issue is need to resolve: >> >> https://issues.apache.org/jira/browse/MNG-6992 >> >> >> >> Of course it is clear that all "uploaded" files must be signed. >> >> Question is - if we should use transformer api only for POM or for all? >> >> >> >> pt., 2 paź 2020 o 15:57 Robert Scholte napisał(a): >> >> >> >>> All "uploaded" files must be signed, see for instance >> >>> https://repo1.maven.org/maven2/org/apache/maven/maven-core/3.6.3/ >> >>> And don't care about older Maven versions, for now just set the >> >>> prerequisite for Maven to 3.7.0-SNAPSHOT in the pom. >> >>> >> >>> On 2-10-2020 14:21:02, Slawomir Jaranowski >> >>> wrote: >> >>> But on the other side, plugins must sign other artifacts associated >> with >> >>> a >> >>> given project. >> >>> >> >>> So in this way we have two different processes - one for pom with >> >>> transformation and ather for rest artifacts. >> >>> >> >>> Maybe all project artifacts should go through the transformation >> process >> >>> then we can have one way for all. >> >>> >> >>> Anyway, first we should resolve how to access Transformers from the >> >>> plugin. >> >>> And how (if we want) get comparability for old maven versions. >> >>> >> >>> >> >>> pt., 2 paź 2020 o 10:46 Robert Scholte napisał(a): >> >>> >> >>> > In the end a signer is just another file transformer, so we need to >> >>> > achieve something like this: >> >>> > local pom >> build/consumer pom (distribute) >> sign (distribute) >> >>> > The plugin must be able to register a SignFileTransformer, which >> should >> >>> > only be called during deploy. For the latter I can imagine we need >> to >> >>> > extend the API. >> >>> > >> >>> > thanks, >> >>> > Robert >> >>> > On 28-9-2020 00:35:45, Slawomir Jaranowski wrote: >> >>> > In order to remove reflection and possibility to call: >> >>> > >> >>> > FileTransformerManager fileTransformerManager = >> >>> > repositorySystemSession.getFileTransformerManager(); >> >>> > >> >>> > I must add: >> >>> > >> >>> > org.eclipse.aether.transform >> >>> > >> >>> > in: >> >>> > >> >>> > >> >>> >> https://github.com/apache/maven/blob/0e3c7a433fc4f700cc2ae6d2c11ae39ec93cbadb/maven-core/src/main/resources/META-INF/maven/extension.xml#L58 >> >>> > >> >>> > Without it I have: >> >>> > java.lang.ClassNotFoundException: >> >>> > org.eclipse.aether.transform.FileTransformerManager >> >>> > >> >>> > this change will be possible in the latest maven version, call above >> >>> method >> >>> > on older maven version will cause ClassNotFoundException >> >>> > >> >>> > adding direct dependency to maven-resolver-api (even in newer >> version) >> >>> in >> >>> > plugin not help, >> >>> > I suppose that classloader for plugin is prepare in special way >> >>> according >> >>> > to META-INF/maven/extension.xml >> >>> > >> >>> > I don't know why reflection works ... >> >>> > >> >>> > >> >>> > >> >>> > niedz., 27 wrz 2020 o 20:30 Robert Scholte >> >>> > napisał(a): >> >>> > >> >>> > > For now I would focus on making it work for Maven 3.7.0 and above. >> >>> > > That would remove the need for reflection right? >> >>> > > >> >>> > > If there are multiple transfomers, in the end their result should >> >>> all be >> >>> > > signed. >> >>> > > The reason behind this is that in the future we could upload >> multiple >> >>> > > files based on the same pom. >> >>> > > We should always upload a model 4.0.0 compatible version, but we >> >>> might >> >>> > > also transform the local pom to a more efficient file preferred by >> >>> Maven >> >>> > 5. >> >>> > > >> >>> > > thanks, >> >>> > > Robert >> >>> > > >> >>> > > >> >>> > > >> >>> > > On 27-9-2020 13:06:45, Slawomir Jaranowski wrote: >> >>> > > Ok. >> >>> > > I did some research and spike. >> >>> > > >> >>> > > We need access to *FileTransformerManager*, it look like this is >> >>> method, >> >>> > > which we want: >> >>> > > >> >>> > > * >> >>> org.eclipse.aether.RepositorySystemSession#getFileTransformerManager* >> >>> > > We can use it from maven 3.6 (without overwriting the version of >> >>> > > maven-resolver-api) ... so the plugin has a minimum maven >> >>> requirement for >> >>> > > this version. But even in 3.6 and 3.7-SNAPSHOT i have exception >> >>> during >> >>> > > execution: >> >>> > > >> >>> > > [ERROR] Failed to execute goal >> >>> > > org.apache.maven.plugins:maven-sign-plugin:1.0-SNAPSHOT:sign >> >>> > > (with-method-call) on project test1: Execution with-method-call of >> >>> goal >> >>> > > org.apache.maven.plugins:maven-sign-plugin:1.0-SNAPSHOT:sign >> failed: >> >>> A >> >>> > > required class was missing while executing >> >>> > > org.apache.maven.plugins:maven-sign-plugin:1.0-SNAPSHOT:sign: >> >>> > > org/eclipse/aether/transform/FileTransformerManager >> >>> > > >> >>> > > So next I try by reflection ... (now looks not good) ... but I >> have >> >>> > > expected result >> >>> > > >> >>> > > So when we must use reflection maybe this magic should be done in >> >>> > separate >> >>> > > utils like >> >>> > > *maven-resolver, maven-artifact-transfer *(where we have magic >> with >> >>> > > reflections) >> >>> > > When we prepare a method/class for transparent transformation in >> an >> >>> > > external library we can simply use it in the gpg plugin and >> problems >> >>> for >> >>> > > the new version of maven will be solved. >> >>> > > Gpg plugin already use *maven-resolver, maven-artifact-transfer* >> >>> > > >> >>> > > Of course we can continue work on the new plugin - but we need >> more >> >>> time >> >>> > to >> >>> > > develop the first production/beta version. >> >>> > > >> >>> > > Another question in about api for >> >>> > > >> >>> > > >> >>> > >> >>> >> *org.eclipse.aether.transform.FileTransformerManager#getTransformersForArtifact* >> >>> > > result is collection of *FileTransformer* so what should happen >> when >> >>> we >> >>> > > have more then one transformer. >> >>> > > In >> >>> > > >> >>> > > >> >>> > >> >>> >> https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultInstaller.java#L246 >> >>> > > result file is overwrited by last transformer from list. >> >>> > > >> >>> > > You can look at what I did at my fork: >> >>> > > >> >>> >> https://github.com/slawekjaranowski/maven-studies/tree/maven-sign-plugin >> >>> > > >> >>> > > I'm waiting for a decision on what should be done next ... >> >>> > > >> >>> > > sob., 26 wrz 2020 o 11:46 Slawomir Jaranowski >> >>> > > napisał(a): >> >>> > > >> >>> > > > Ok, I don't want to reinvent the wheels, so >> >>> > > > >> >>> > > > How to reach handle to project artifacts list, especially >> project >> >>> pom >> >>> > > > after transformation in plugin code? >> >>> > > > >> >>> > > > Some plugin examples, point which component should I use to >> achieve >> >>> > this >> >>> > > > will be great. >> >>> > > > >> >>> > > > pt., 25 wrz 2020 o 17:05 Robert Scholte napisał(a): >> >>> > > > >> >>> > > >> There no plugin yet, but I suggest to start with a branch under >> >>> > > >> https://github.com/apache/maven-studies before making an >> >>> official new >> >>> > > >> repository. >> >>> > > >> >> >>> > > >> Let me quote 2 points mentioned by Stephen Connolly, which we >> >>> still >> >>> > need >> >>> > > >> to address: >> >>> > > >> >> >>> > > >> - If we switch to bouncycastle based, we will now own the key >> >>> storage. >> >>> > > >> This is both good and bad. >> >>> > > >> * People who have their keys stored in gpg2 will have a “fun >> time” >> >>> > > >> extracting them... or else we will have to do the dance of >> >>> extracting >> >>> > > them >> >>> > > >> ourselves. >> >>> > > >> * If we “own” the key storage, publishing keys to a key >> registry >> >>> and >> >>> > > >> generating keys may become our problem from the user’s >> >>> perspective. >> >>> > > >> * One of the biggest complaints about publishing on central has >> >>> been >> >>> > > >> the difficulty of gpg signing. New users will likely thank us >> if >> >>> we >> >>> > > make it >> >>> > > >> easier. >> >>> > > >> >> >>> > > >> - PGP functionality provider security issues become our >> problem. >> >>> > Before, >> >>> > > >> users could independently upgrade the gpg CLI tooling to work >> past >> >>> > > security >> >>> > > >> issues (causing it’s own issues as CLI options changed from >> gpg1 >> >>> to >> >>> > > gpg2). >> >>> > > >> With this plugin, the pgp provider version will be baked into >> the >> >>> pom. >> >>> > > How >> >>> > > >> will users be able to assure their security team that >> signatures >> >>> have >> >>> > > been >> >>> > > >> made in the version without a security issue? >> >>> > > >> >> >>> > > >> thanks, >> >>> > > >> Robert >> >>> > > >> On 25-9-2020 15:35:01, Slawomir Jaranowski >> >>> > > >> wrote: >> >>> > > >> Hi >> >>> > > >> >> >>> > > >> On the weekend I will have some spare time, so I can do >> something >> >>> > about >> >>> > > it >> >>> > > >> .. >> >>> > > >> >> >>> > > >> My questions: >> >>> > > >> - are there git repository, jira project for new plugin >> >>> > > >> - does anybody working on it now - what is progress >> >>> > > >> - if you want to use Apache Common OpenGPG, I think should be >> >>> > refreshed >> >>> > > >> first - is there git repo for it >> >>> > > >> >> >>> > > >> >> >>> > > >> czw., 24 wrz 2020 o 18:57 Robert Scholte napisał(a): >> >>> > > >> >> >>> > > >> > Thanks for the offer. >> >>> > > >> > Signing is very delicate process, so I appreciate the extra >> >>> help. >> >>> > > >> > >> >>> > > >> > thanks, >> >>> > > >> > Robert >> >>> > > >> > On 21-9-2020 09:14:54, Slawomir Jaranowski wrote: >> >>> > > >> > Hi >> >>> > > >> > >> >>> > > >> > I have some experience in case of verifying pgp signatures >> using >> >>> > > Bouncy >> >>> > > >> > Castle during work on my pgpverify-maven-plugin. >> >>> > > >> > So If you would, I can try to help with the sign plugin. >> >>> > > >> > >> >>> > > >> > Let me know if you are interested. >> >>> > > >> > >> >>> > > >> > niedz., 20 wrz 2020 o 20:38 Robert Scholte >> >>> > > >> > napisał(a): >> >>> > > >> > >> >>> > > >> > > With the next release of Maven the current maven-gpg-plugin >> >>> will >> >>> > > >> become >> >>> > > >> > > useless. >> >>> > > >> > > With the build//consumer pom, the local pom will be >> different >> >>> > > >> compared to >> >>> > > >> > > the uploaded pom. >> >>> > > >> > > However, the maven-gpg-plugin now uses the pom.xml of the >> >>> local >> >>> > > >> project. >> >>> > > >> > > (btw, the plugin uses the gpg commandline with a bunch of >> >>> > arguments. >> >>> > > >> The >> >>> > > >> > > stdio is used for passing the passphrase, you cannot stream >> >>> the >> >>> > file >> >>> > > >> via >> >>> > > >> > > commandline) >> >>> > > >> > > >> >>> > > >> > > In Maven 3.6.x changes have been made to support >> InputStream >> >>> next >> >>> > to >> >>> > > >> > File. >> >>> > > >> > > This way we don't have to create a backdoor of writing a >> >>> temporary >> >>> > > >> file, >> >>> > > >> > > which is likely to cause issues with very creative >> >>> > plugin/extension >> >>> > > >> > > writers. Instead we should do in memory signing. >> >>> > > >> > > >> >>> > > >> > > It would make sense to introduce a new plugin, and during a >> >>> > > discussion >> >>> > > >> > > with the PMC the idea of maven-sign-plugin was proposed (a >> >>> much >> >>> > > better >> >>> > > >> > > alternative campared to maven-gpg2-plugin) >> >>> > > >> > > >> >>> > > >> > > Dennis Lundberg started a POC based on Apache Common >> OpenGPG, >> >>> > > >> however, it >> >>> > > >> > > is still in the sandbox[1] >> >>> > > >> > > >> >>> > > >> > > Olivier Lamy already discovered that signing doesn't work >> >>> with the >> >>> > > >> > current >> >>> > > >> > > Maven 3.7.0-SNAPSHOT. >> >>> > > >> > > Before we can even start thinking of an alpha-release, this >> >>> issue >> >>> > > >> must be >> >>> > > >> > > fixed, because signing is a critical step for sharing >> >>> artifacts. >> >>> > > >> > > >> >>> > > >> > > I'm still struggling with MNG-6957, but in parallel a few >> >>> should >> >>> > be >> >>> > > >> able >> >>> > > >> > > implement this. >> >>> > > >> > > >> >>> > > >> > > Anybody willing to make this work? >> >>> > > >> > > >> >>> > > >> > > thanks, >> >>> > > >> > > Robert >> >>> > > >> > > >> >>> > > >> > > [1] http://commons.apache.org/sandbox/commons-openpgp/ [ >> >>> > > >> > > http://commons.apache.org/sandbox/commons-openpgp/] >> >>> > > >> > > >> >>> > > >> > >> >>> > > >> > >> >>> > > >> > -- >> >>> > > >> > Sławomir Jaranowski >> >>> > > >> > >> >>> > > >> >> >>> > > >> >> >>> > > >> -- >> >>> > > >> Sławomir Jaranowski >> >>> > > >> >> >>> > > > >> >>> > > > >> >>> > > > -- >> >>> > > > Sławomir Jaranowski >> >>> > > > >> >>> > > >> >>> > > >> >>> > > -- >> >>> > > Sławomir Jaranowski >> >>> > > >> >>> > >> >>> > >> >>> > -- >> >>> > Sławomir Jaranowski >> >>> > >> >>> >> >>> >> >>> -- >> >>> Sławomir Jaranowski >> >>> >> >> >> >> >> >> -- >> >> Sławomir Jaranowski >> >> >> > >> > >> > -- >> > Sławomir Jaranowski >> > >> >> >> -- >> Sławomir Jaranowski >> > > > -- > Sławomir Jaranowski > -- Sławomir Jaranowski |
I understand your concerns (had the same situation), and really would ask the PMC to find a solution for that long delays. My motto is "release early, release often" but at Apache this seems to be not wanted or not possile. :-(
Let's do it this way: We incubate the plugin until we think it is ripe for moving it to Apache and hope the PMC will find a way for quicker release cycles until then! :-) -Markus -----Ursprüngliche Nachricht----- Von: Slawomir Jaranowski [mailto:[hidden email]] Gesendet: Montag, 28. Dezember 2020 14:32 An: Maven Developers List Betreff: Re: Maven Sign Plugin I'm really open to help developing / maintaining such a plugin under Apache Organization. But as we see the release process in Apache is very slow ... I need it now, and I don't want to wait for years so I decided to release it by myself. Probably it is another topic how to make Apache projects more agile and more friendly for external contributors. For example I did a few feature / fix for maven-invoker-plugin and I wait about year for release next version, I don't have knowledge when it can happen ... pon., 28 gru 2020 o 14:04 Markus KARG <[hidden email]> napisał(a): > Please turn it into an official Maven plugin, as there are many people out > there reluctant when it comes to third party due to sustained support etc.! > :-) > -Markus > > > -----Ursprüngliche Nachricht----- > Von: Slawomir Jaranowski [mailto:[hidden email]] > Gesendet: Montag, 28. Dezember 2020 13:09 > An: Maven Developers List > Betreff: Re: Maven Sign Plugin > > Hi, > > First version of Sign Maven Plugin was released - > https://github.com/s4u/sign-maven-plugin > > It works with Maven 3.6.x and future version 4.x > > If somebody is interested I invite them to test and collaborate. > > pon., 14 gru 2020 o 21:42 Slawomir Jaranowski <[hidden email]> > napisał(a): > > > Hi, > > > > The Idea of making a signature by java code without an external binary is > > very good. > > > > I have plans to automate some of CI/CD and such plugin will be very > > useful for me. > > I can customise it for easy use with CI system > > > > So waiting for you, > > I will release it under my github organization, probably at the end of > > year. If someone is interested please let me know. > > > > > > pon., 2 lis 2020 o 21:36 Robert Scholte <[hidden email]> > napisał(a): > > > >> I want to have another look at Maven Resolver. I don't want to store it > >> as a file, but stream it directly to a repository. > >> The goal is now bound to verify, but that's incorrect (it has nothing to > >> do with verifying integration results). > >> Looking at it, I think this should not be a maven-plugin, but a Maven > >> extension, so it can hook itself during deploy, no need for an explicit > >> goal to call > >> I need to work it out a bit more. > >> > >> thanks, > >> Robert > >> > >> On 19-10-2020 22:47:06, Slawomir Jaranowski <[hidden email]> > >> wrote: > >> Hi > >> > >> What next step do you plan with this plugin? > >> > >> I believe that can be usable even now for users. > >> > >> It is not too much work to prepare a plugin to work with maven 3.6 so we > >> can publish it and take feedback from users. > >> > >> I think that early release can help users to prepare their project to be > >> ready for maven 3.7. > >> > >> If you wish I will take care about this plugin. > >> > >> niedz., 4 paź 2020 o 15:32 Slawomir Jaranowski > >> napisał(a): > >> > >> > First working version is ready: > >> > > >> > https://github.com/apache/maven-studies/pull/2 > >> > > >> > I'm waiting for your opinion > >> > > >> > pt., 2 paź 2020 o 17:05 Slawomir Jaranowski > >> > napisał(a): > >> > > >> >> Targeting to maven 3.7.0-SNAPSHOT makes easier access to Transformer > >> api. > >> >> So one issue is need to resolve: > >> >> https://issues.apache.org/jira/browse/MNG-6992 > >> >> > >> >> Of course it is clear that all "uploaded" files must be signed. > >> >> Question is - if we should use transformer api only for POM or for > all? > >> >> > >> >> pt., 2 paź 2020 o 15:57 Robert Scholte napisał(a): > >> >> > >> >>> All "uploaded" files must be signed, see for instance > >> >>> https://repo1.maven.org/maven2/org/apache/maven/maven-core/3.6.3/ > >> >>> And don't care about older Maven versions, for now just set the > >> >>> prerequisite for Maven to 3.7.0-SNAPSHOT in the pom. > >> >>> > >> >>> On 2-10-2020 14:21:02, Slawomir Jaranowski > >> >>> wrote: > >> >>> But on the other side, plugins must sign other artifacts associated > >> with > >> >>> a > >> >>> given project. > >> >>> > >> >>> So in this way we have two different processes - one for pom with > >> >>> transformation and ather for rest artifacts. > >> >>> > >> >>> Maybe all project artifacts should go through the transformation > >> process > >> >>> then we can have one way for all. > >> >>> > >> >>> Anyway, first we should resolve how to access Transformers from the > >> >>> plugin. > >> >>> And how (if we want) get comparability for old maven versions. > >> >>> > >> >>> > >> >>> pt., 2 paź 2020 o 10:46 Robert Scholte napisał(a): > >> >>> > >> >>> > In the end a signer is just another file transformer, so we need > to > >> >>> > achieve something like this: > >> >>> > local pom >> build/consumer pom (distribute) >> sign (distribute) > >> >>> > The plugin must be able to register a SignFileTransformer, which > >> should > >> >>> > only be called during deploy. For the latter I can imagine we need > >> to > >> >>> > extend the API. > >> >>> > > >> >>> > thanks, > >> >>> > Robert > >> >>> > On 28-9-2020 00:35:45, Slawomir Jaranowski wrote: > >> >>> > In order to remove reflection and possibility to call: > >> >>> > > >> >>> > FileTransformerManager fileTransformerManager = > >> >>> > repositorySystemSession.getFileTransformerManager(); > >> >>> > > >> >>> > I must add: > >> >>> > > >> >>> > org.eclipse.aether.transform > >> >>> > > >> >>> > in: > >> >>> > > >> >>> > > >> >>> > >> > https://github.com/apache/maven/blob/0e3c7a433fc4f700cc2ae6d2c11ae39ec93cbadb/maven-core/src/main/resources/META-INF/maven/extension.xml#L58 > >> >>> > > >> >>> > Without it I have: > >> >>> > java.lang.ClassNotFoundException: > >> >>> > org.eclipse.aether.transform.FileTransformerManager > >> >>> > > >> >>> > this change will be possible in the latest maven version, call > above > >> >>> method > >> >>> > on older maven version will cause ClassNotFoundException > >> >>> > > >> >>> > adding direct dependency to maven-resolver-api (even in newer > >> version) > >> >>> in > >> >>> > plugin not help, > >> >>> > I suppose that classloader for plugin is prepare in special way > >> >>> according > >> >>> > to META-INF/maven/extension.xml > >> >>> > > >> >>> > I don't know why reflection works ... > >> >>> > > >> >>> > > >> >>> > > >> >>> > niedz., 27 wrz 2020 o 20:30 Robert Scholte > >> >>> > napisał(a): > >> >>> > > >> >>> > > For now I would focus on making it work for Maven 3.7.0 and > above. > >> >>> > > That would remove the need for reflection right? > >> >>> > > > >> >>> > > If there are multiple transfomers, in the end their result > should > >> >>> all be > >> >>> > > signed. > >> >>> > > The reason behind this is that in the future we could upload > >> multiple > >> >>> > > files based on the same pom. > >> >>> > > We should always upload a model 4.0.0 compatible version, but we > >> >>> might > >> >>> > > also transform the local pom to a more efficient file preferred > by > >> >>> Maven > >> >>> > 5. > >> >>> > > > >> >>> > > thanks, > >> >>> > > Robert > >> >>> > > > >> >>> > > > >> >>> > > > >> >>> > > On 27-9-2020 13:06:45, Slawomir Jaranowski wrote: > >> >>> > > Ok. > >> >>> > > I did some research and spike. > >> >>> > > > >> >>> > > We need access to *FileTransformerManager*, it look like this is > >> >>> method, > >> >>> > > which we want: > >> >>> > > > >> >>> > > * > >> >>> > org.eclipse.aether.RepositorySystemSession#getFileTransformerManager* > >> >>> > > We can use it from maven 3.6 (without overwriting the version of > >> >>> > > maven-resolver-api) ... so the plugin has a minimum maven > >> >>> requirement for > >> >>> > > this version. But even in 3.6 and 3.7-SNAPSHOT i have exception > >> >>> during > >> >>> > > execution: > >> >>> > > > >> >>> > > [ERROR] Failed to execute goal > >> >>> > > org.apache.maven.plugins:maven-sign-plugin:1.0-SNAPSHOT:sign > >> >>> > > (with-method-call) on project test1: Execution with-method-call > of > >> >>> goal > >> >>> > > org.apache.maven.plugins:maven-sign-plugin:1.0-SNAPSHOT:sign > >> failed: > >> >>> A > >> >>> > > required class was missing while executing > >> >>> > > org.apache.maven.plugins:maven-sign-plugin:1.0-SNAPSHOT:sign: > >> >>> > > org/eclipse/aether/transform/FileTransformerManager > >> >>> > > > >> >>> > > So next I try by reflection ... (now looks not good) ... but I > >> have > >> >>> > > expected result > >> >>> > > > >> >>> > > So when we must use reflection maybe this magic should be done > in > >> >>> > separate > >> >>> > > utils like > >> >>> > > *maven-resolver, maven-artifact-transfer *(where we have magic > >> with > >> >>> > > reflections) > >> >>> > > When we prepare a method/class for transparent transformation in > >> an > >> >>> > > external library we can simply use it in the gpg plugin and > >> problems > >> >>> for > >> >>> > > the new version of maven will be solved. > >> >>> > > Gpg plugin already use *maven-resolver, maven-artifact-transfer* > >> >>> > > > >> >>> > > Of course we can continue work on the new plugin - but we need > >> more > >> >>> time > >> >>> > to > >> >>> > > develop the first production/beta version. > >> >>> > > > >> >>> > > Another question in about api for > >> >>> > > > >> >>> > > > >> >>> > > >> >>> > >> > *org.eclipse.aether.transform.FileTransformerManager#getTransformersForArtifact* > >> >>> > > result is collection of *FileTransformer* so what should happen > >> when > >> >>> we > >> >>> > > have more then one transformer. > >> >>> > > In > >> >>> > > > >> >>> > > > >> >>> > > >> >>> > >> > https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultInstaller.java#L246 > >> >>> > > result file is overwrited by last transformer from list. > >> >>> > > > >> >>> > > You can look at what I did at my fork: > >> >>> > > > >> >>> > >> > https://github.com/slawekjaranowski/maven-studies/tree/maven-sign-plugin > >> >>> > > > >> >>> > > I'm waiting for a decision on what should be done next ... > >> >>> > > > >> >>> > > sob., 26 wrz 2020 o 11:46 Slawomir Jaranowski > >> >>> > > napisał(a): > >> >>> > > > >> >>> > > > Ok, I don't want to reinvent the wheels, so > >> >>> > > > > >> >>> > > > How to reach handle to project artifacts list, especially > >> project > >> >>> pom > >> >>> > > > after transformation in plugin code? > >> >>> > > > > >> >>> > > > Some plugin examples, point which component should I use to > >> achieve > >> >>> > this > >> >>> > > > will be great. > >> >>> > > > > >> >>> > > > pt., 25 wrz 2020 o 17:05 Robert Scholte napisał(a): > >> >>> > > > > >> >>> > > >> There no plugin yet, but I suggest to start with a branch > under > >> >>> > > >> https://github.com/apache/maven-studies before making an > >> >>> official new > >> >>> > > >> repository. > >> >>> > > >> > >> >>> > > >> Let me quote 2 points mentioned by Stephen Connolly, which we > >> >>> still > >> >>> > need > >> >>> > > >> to address: > >> >>> > > >> > >> >>> > > >> - If we switch to bouncycastle based, we will now own the key > >> >>> storage. > >> >>> > > >> This is both good and bad. > >> >>> > > >> * People who have their keys stored in gpg2 will have a “fun > >> time” > >> >>> > > >> extracting them... or else we will have to do the dance of > >> >>> extracting > >> >>> > > them > >> >>> > > >> ourselves. > >> >>> > > >> * If we “own” the key storage, publishing keys to a key > >> registry > >> >>> and > >> >>> > > >> generating keys may become our problem from the user’s > >> >>> perspective. > >> >>> > > >> * One of the biggest complaints about publishing on central > has > >> >>> been > >> >>> > > >> the difficulty of gpg signing. New users will likely thank us > >> if > >> >>> we > >> >>> > > make it > >> >>> > > >> easier. > >> >>> > > >> > >> >>> > > >> - PGP functionality provider security issues become our > >> problem. > >> >>> > Before, > >> >>> > > >> users could independently upgrade the gpg CLI tooling to work > >> past > >> >>> > > security > >> >>> > > >> issues (causing it’s own issues as CLI options changed from > >> gpg1 > >> >>> to > >> >>> > > gpg2). > >> >>> > > >> With this plugin, the pgp provider version will be baked into > >> the > >> >>> pom. > >> >>> > > How > >> >>> > > >> will users be able to assure their security team that > >> signatures > >> >>> have > >> >>> > > been > >> >>> > > >> made in the version without a security issue? > >> >>> > > >> > >> >>> > > >> thanks, > >> >>> > > >> Robert > >> >>> > > >> On 25-9-2020 15:35:01, Slawomir Jaranowski > >> >>> > > >> wrote: > >> >>> > > >> Hi > >> >>> > > >> > >> >>> > > >> On the weekend I will have some spare time, so I can do > >> something > >> >>> > about > >> >>> > > it > >> >>> > > >> .. > >> >>> > > >> > >> >>> > > >> My questions: > >> >>> > > >> - are there git repository, jira project for new plugin > >> >>> > > >> - does anybody working on it now - what is progress > >> >>> > > >> - if you want to use Apache Common OpenGPG, I think should be > >> >>> > refreshed > >> >>> > > >> first - is there git repo for it > >> >>> > > >> > >> >>> > > >> > >> >>> > > >> czw., 24 wrz 2020 o 18:57 Robert Scholte napisał(a): > >> >>> > > >> > >> >>> > > >> > Thanks for the offer. > >> >>> > > >> > Signing is very delicate process, so I appreciate the extra > >> >>> help. > >> >>> > > >> > > >> >>> > > >> > thanks, > >> >>> > > >> > Robert > >> >>> > > >> > On 21-9-2020 09:14:54, Slawomir Jaranowski wrote: > >> >>> > > >> > Hi > >> >>> > > >> > > >> >>> > > >> > I have some experience in case of verifying pgp signatures > >> using > >> >>> > > Bouncy > >> >>> > > >> > Castle during work on my pgpverify-maven-plugin. > >> >>> > > >> > So If you would, I can try to help with the sign plugin. > >> >>> > > >> > > >> >>> > > >> > Let me know if you are interested. > >> >>> > > >> > > >> >>> > > >> > niedz., 20 wrz 2020 o 20:38 Robert Scholte > >> >>> > > >> > napisał(a): > >> >>> > > >> > > >> >>> > > >> > > With the next release of Maven the current > maven-gpg-plugin > >> >>> will > >> >>> > > >> become > >> >>> > > >> > > useless. > >> >>> > > >> > > With the build//consumer pom, the local pom will be > >> different > >> >>> > > >> compared to > >> >>> > > >> > > the uploaded pom. > >> >>> > > >> > > However, the maven-gpg-plugin now uses the pom.xml of the > >> >>> local > >> >>> > > >> project. > >> >>> > > >> > > (btw, the plugin uses the gpg commandline with a bunch of > >> >>> > arguments. > >> >>> > > >> The > >> >>> > > >> > > stdio is used for passing the passphrase, you cannot > stream > >> >>> the > >> >>> > file > >> >>> > > >> via > >> >>> > > >> > > commandline) > >> >>> > > >> > > > >> >>> > > >> > > In Maven 3.6.x changes have been made to support > >> InputStream > >> >>> next > >> >>> > to > >> >>> > > >> > File. > >> >>> > > >> > > This way we don't have to create a backdoor of writing a > >> >>> temporary > >> >>> > > >> file, > >> >>> > > >> > > which is likely to cause issues with very creative > >> >>> > plugin/extension > >> >>> > > >> > > writers. Instead we should do in memory signing. > >> >>> > > >> > > > >> >>> > > >> > > It would make sense to introduce a new plugin, and > during a > >> >>> > > discussion > >> >>> > > >> > > with the PMC the idea of maven-sign-plugin was proposed > (a > >> >>> much > >> >>> > > better > >> >>> > > >> > > alternative campared to maven-gpg2-plugin) > >> >>> > > >> > > > >> >>> > > >> > > Dennis Lundberg started a POC based on Apache Common > >> OpenGPG, > >> >>> > > >> however, it > >> >>> > > >> > > is still in the sandbox[1] > >> >>> > > >> > > > >> >>> > > >> > > Olivier Lamy already discovered that signing doesn't work > >> >>> with the > >> >>> > > >> > current > >> >>> > > >> > > Maven 3.7.0-SNAPSHOT. > >> >>> > > >> > > Before we can even start thinking of an alpha-release, > this > >> >>> issue > >> >>> > > >> must be > >> >>> > > >> > > fixed, because signing is a critical step for sharing > >> >>> artifacts. > >> >>> > > >> > > > >> >>> > > >> > > I'm still struggling with MNG-6957, but in parallel a few > >> >>> should > >> >>> > be > >> >>> > > >> able > >> >>> > > >> > > implement this. > >> >>> > > >> > > > >> >>> > > >> > > Anybody willing to make this work? > >> >>> > > >> > > > >> >>> > > >> > > thanks, > >> >>> > > >> > > Robert > >> >>> > > >> > > > >> >>> > > >> > > [1] http://commons.apache.org/sandbox/commons-openpgp/ [ > >> >>> > > >> > > http://commons.apache.org/sandbox/commons-openpgp/] > >> >>> > > >> > > > >> >>> > > >> > > >> >>> > > >> > > >> >>> > > >> > -- > >> >>> > > >> > Sławomir Jaranowski > >> >>> > > >> > > >> >>> > > >> > >> >>> > > >> > >> >>> > > >> -- > >> >>> > > >> Sławomir Jaranowski > >> >>> > > >> > >> >>> > > > > >> >>> > > > > >> >>> > > > -- > >> >>> > > > Sławomir Jaranowski > >> >>> > > > > >> >>> > > > >> >>> > > > >> >>> > > -- > >> >>> > > Sławomir Jaranowski > >> >>> > > > >> >>> > > >> >>> > > >> >>> > -- > >> >>> > Sławomir Jaranowski > >> >>> > > >> >>> > >> >>> > >> >>> -- > >> >>> Sławomir Jaranowski > >> >>> > >> >> > >> >> > >> >> -- > >> >> Sławomir Jaranowski > >> >> > >> > > >> > > >> > -- > >> > Sławomir Jaranowski > >> > > >> > >> > >> -- > >> Sławomir Jaranowski > >> > > > > > > -- > > Sławomir Jaranowski > > > > > -- > Sławomir Jaranowski > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > -- Sławomir Jaranowski --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
Free forum by Nabble | Edit this page |