Nope. I'd have to check, but they're signatures which are then zipped
up with the code.
What I'm realizing is that this may actually be irrelevant, as their
whole packaging ends up different than a typical jar, and they have
index files and signatures against each .class file, and then the
whole is also signed. It's very convoluted and what we've been doing
in the mavenization effort is to un-jar (in a packaging project) into
a folder, do the various signatures, then sign the collection, then
zip it up, and that's the artifact from the packaging project, as
opposed to the original.
So never mind, they have an edge-case we're handling with post-
processing the whole artifact into a new artifact. I can't solve
their problem without a lot of convolution in one project, and the new
signing stuff won't really be relevant. (They're constrained by an
industry specification that includes this wierd signing protocol)
Christian.
On 11-Jul-08, at 13:59 , Brian E. Fox wrote:
Christian, what kind of files are produced with the sig? Are they
still
.asc?
-----Original Message-----
From: Christian Edward Gruber [mailto:[EMAIL PROTECTED]
Sent: Friday, July 11, 2008 1:24 PM
To: Maven Developers List
Subject: Re: artifact signing feature branches
Incidentally, I presume that there is a provider for PGP that could be
replaced by an alternate signing system if a provider were written for
it? I didn't see it in the wiki, but I have a client with an
industry-
imposed signing regime that I don't think is based in PGP or md5/
shaXXX.
Christian.
On 11-Jul-08, at 12:56 , Brett Porter wrote:
The current signing mechanism actually works quite well and I had no
intention of changing that at this stage. I haven't seen any issues
with this, and adding such fine grained lifecycle stages would soon
get out of control (and frequent arguments as to the correct order).
If it were to be more built in, I would suggest making it a part of
<distributionManagement> and the deployment mechanism if anything,
but really the current plugin works fine for that.
Cheers,
Brett
On 12/07/2008, at 2:47 AM, Christian Edward Gruber wrote:
Can I suggest that a phase in the default lifecycle be added after
packaging for signing (somewhere). It can have no default binding
plugin (such as integration-test) but if it's there, it's easier to
hook in things at the correct time.
Or a pre-package and post-package phase which would amount to the
same thing, and be probably more appropriate.
Or pre-package, package, post-package, package-sign. Why not go
for broke and have a fairly articulated full lifecycle. :)
Christian.
On 11-Jul-08, at 12:42 , Brett Porter wrote:
Hi,
I've wanted to pick up my work on this for some time and was
prodded by the [EMAIL PROTECTED] threads to take another crack at
this.
http://docs.codehaus.org/display/MAVEN/Repository+Security (the
issue and related branches are linked)
I've created a couple of branches to try integrating the work
again in as simple and non-intrusive manner (both in code and to
the user) as possible. I already have commons-openpgp in the
sandbox from some time ago to deal with processing the signatures
(it doesn't have any external dependencies other than bouncy
castle), so I'll integrate that.
If anyone else wants to offer feedback or dive in, you're more
than welcome!
Cheers,
Brett
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
