Re: release signing policy?

[Shane Curcuru]

Great!  I'll keep an eye out so we can propose stealing what you come
up with for xml.apache.org as well...  8-)

Suggestions/comments/questions:
-- Focus on overall how-to steps for the release process and signing
'public' distribution units; I can volunteer to do QA on any
instructions you come up with.

-- The dev.apache.org stuff is a good start, but very C and
Unix-centric.  Plus very terse; hopefully over time we can come up with
a friendlier version.

-- PGP or GPG or either? (I'm pretty sure those are the two real
contenders).  In theory they're compatible with each other somehow, but
I've never been able to get it to work.  I prefer PGP since I like
having the flashy GUI in 6.x/7.x versions, but I could understand
someone philosophically or whatever wanting to use GPG.  As long as we
provide basic instructions for someone to verify a distro, either
should be fine.

-- As noted, a release signer's key must be in the KEYS file that was
previously checked in and gets stuck inside the distro.  We should also
suggest that release signers consider posting public keys to well-known
keyservers when possible.

-- Key management: We hashed this out on general@xml a while back (and
I'm sure other places): realistically, I think the only practical thing
is to have individual commiters use their own personal keys for
signing, and have each project manage their own keys.  Given how the
ASF works, I don't think we're going to have 'official' ASF master keys
anytime soon.  If there were a site-wide KEYS file in CVS that projects
could *choose* to use instead, that would be fine too.

-- Key signing: Since we're having individual committers sign releases,
we should encourage folks to sign each other's keys.  This way, when a
user tries to verify a release versus the .sig, even if they don't know
the individual who signed the distro, they might know someone else who
signed their key, establishing at least some level of trust.  
You should remember to allow your signature of someone else's public
key to be exportable too.  I've tried to cross-sign keys in xml-land;
if there are jakartaites who know me, I'd be happy to do the same here.

-- Separate out any discussion of signing .jar files.  Actually using
Java's jar signing abilities is both more complex and has a variety of
technical code issues that each project will probably have to consider
separately from signing the distros.

- Shane

 you Stefan Bodewig <[EMAIL PROTECTED]> wrote 
> Ted Husted <[EMAIL PROTECTED]> wrote: 
> > then I was volunteering to draft the general Release HOWTO, and
> > asking if anyone had any existing documentation about this that
they
> > wanted to share. 

> I'd start with this one .
> Stefan

=
mailto:[EMAIL PROTECTED]";
 .sig="2002 The palindromic year 2002"/>

__
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: release signing policy?

[Stefan Bodewig]

On Thu, 10 Jan 2002, Ted Husted <[EMAIL PROTECTED]> wrote:

> then I was volunteering to draft the general Release HOWTO, and
> asking if anyone had any existing documentation about this that they
> wanted to share.

I'd start with this one .

Stefan

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: release signing policy?

[Ted Husted]

"Geir Magnusson Jr." wrote:
> 
> On 1/10/02 8:18 AM, "Ted Husted" <[EMAIL PROTECTED]> wrote:
> 
> > Conor MacNeill wrote:
> >> Perhaps it could be part of a committer "howto" page
> >> dealing with how to put together a release.
> >
> > I can take the lead on this part. I have some notes, and if anyone want
> > to send along anything pertinent that they already have, please feel
> > free.
> >
> 
> I think Conor meant that 'it' referred to the stuff he would put together..

Yes. If Conor wants to take the lead (write the first draft) of the
Release signing HOWTO (if that's what we decided to do), then I was
volunteering to draft the general Release HOWTO, and asking if anyone
had any existing documentation about this that they wanted to share. 

I have a list of things to work on at the site, but I'm trying to budget
my time, and just do one of things each day. The Release HOWTO is one of
them, but it's behind some others. Of course, if someone else wants to
jump in, that would be great.

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Building Java web applications with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: release signing policy?

[Geir Magnusson Jr.]

On 1/10/02 8:18 AM, "Ted Husted" <[EMAIL PROTECTED]> wrote:

> Conor MacNeill wrote:
>> Perhaps it could be part of a committer "howto" page
>> dealing with how to put together a release.
> 
> I can take the lead on this part. I have some notes, and if anyone want
> to send along anything pertinent that they already have, please feel
> free. 
> 

I think Conor meant that 'it' referred to the stuff he would put together..

-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
"Now what do we do?"


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: release signing policy?

[Ted Husted]

Conor MacNeill wrote:
> Perhaps it could be part of a committer "howto" page
> dealing with how to put together a release. 

I can take the lead on this part. I have some notes, and if anyone want
to send along anything pertinent that they already have, please feel
free. 

-Ted.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: release signing policy?

[Ted Husted]

This has come up before. Would anyone be interesting in reviewing the
archives, and summarizing the past threads? At which point, we can come
to decision, or validate whatever we decided before, and post it as a
FAQ. 

Here's one for starters, but there's more:

http://www.mail-archive.com/general@jakarta.apache.org/msg00547.html

-Ted.


Conor MacNeill wrote:
> 
> Hi,
> 
> Having read all this stuff about what is Jakarta, what is the PMC's
> role, etc reminded me of something which I think should be addressed at
> PMC level, if not higher  - the policy of signing releases. We have put
> something in place at a subproject level for Ant but I think an overall
> policy is desirable.
> 
> I had a quick look at the latest release or beta of most project release
> directories. As far as I can tell, this is the status:
> 
> Ant, Avalon, Tomcat 3.3 are signed. Taglibs appears to be signed but I
> didn't check its vast array of release components.
> BCEL, ECS, ORO, Regexp, Velocity and XMLRpc have md5 files but no signatures
> All others do not appear to be signed.
> 
> Of the releases that are signed, all use .asc files for the signature
> except Avalon-Framework which uses .sig files (although its verify
> example uses .asc).
> 
> I think a consistent, Jakarta-wide policy of signing distributions would
> be a good thing.
> 
> Currently the subprojects that do sign their releases have their own
> KEYS file. Should there be a central Jakarta-wide KEYS file? Apache-wide?
> 
> I can write or draft some text on how to go about signing a
> distribution. Perhaps it could be part of a committer "howto" page
> dealing with how to put togther a release. I don't mean the subproject
> specific stuff but other stuff like where you put releases, adding
> README.html, maybe even tagging and branching suggestions. It may even
> be good to move the full CVS access info into this area - whatever.
> 
> Let me know your thoughts.
> 
> Conor
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Building Java web applications with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: release signing policy?

[Geir Magnusson Jr.]

On 1/10/02 8:03 AM, "Conor MacNeill" <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> Having read all this stuff about what is Jakarta, what is the PMC's
> role, etc reminded me of something which I think should be addressed at
> PMC level, if not higher  - the policy of signing releases. We have put
> something in place at a subproject level for Ant but I think an overall
> policy is desirable.
> 
> I had a quick look at the latest release or beta of most project release
> directories. As far as I can tell, this is the status:
> 
> Ant, Avalon, Tomcat 3.3 are signed. Taglibs appears to be signed but I
> didn't check its vast array of release components.
> BCEL, ECS, ORO, Regexp, Velocity and XMLRpc have md5 files but no signatures
> All others do not appear to be signed.
> 
> Of the releases that are signed, all use .asc files for the signature
> except Avalon-Framework which uses .sig files (although its verify
> example uses .asc).
> 
> I think a consistent, Jakarta-wide policy of signing distributions would
> be a good thing.
> 
> Currently the subprojects that do sign their releases have their own
> KEYS file. Should there be a central Jakarta-wide KEYS file? Apache-wide?
> 
> I can write or draft some text on how to go about signing a
> distribution. Perhaps it could be part of a committer "howto" page
> dealing with how to put togther a release. I don't mean the subproject
> specific stuff but other stuff like where you put releases, adding
> README.html, maybe even tagging and branching suggestions. It may even
> be good to move the full CVS access info into this area - whatever.
> 
> Let me know your thoughts.
> 

+1 - the write-up would be great.

We in velocity land will do it for the next release.

-- 
Geir Magnusson Jr.   [EMAIL PROTECTED]
System and Software Consulting
You're going to end up getting pissed at your software
anyway, so you might as well not pay for it. Try Open Source.



--
To unsubscribe, e-mail:   
For additional commands, e-mail: