Re: Maven Sign Plugin

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Maven Sign Plugin

Slawomir Jaranowski
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 <[hidden email]> 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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Maven Sign Plugin

Slawomir Jaranowski
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 <[hidden email]>
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 <[hidden email]> 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 <[hidden email]>
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Maven Sign Plugin

michaelo
Am 2020-09-27 um 13:06 schrieb Slawomir Jaranowski:

> 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 ...

Slawomi, thanks for having a look. I will reroll resolver in a week or
so. Do you already know that type of change in Resolver 1.6.x would be
required to satisfy the needs?

Michael

> sob., 26 wrz 2020 o 11:46 Slawomir Jaranowski <[hidden email]>
> 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 <[hidden email]> 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 <[hidden email]>
>>> 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
>>
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven Sign Plugin

rfscholte
In reply to this post by Slawomir Jaranowski
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 <[hidden email]> 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