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