You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ws.apache.org by ac...@apache.org on 2004/06/04 19:21:47 UTC
cvs commit: ws-site/targets/juddi committers.html committers.pdf site.html site.pdf
acutright 2004/06/04 10:21:47
Modified: targets/juddi committers.html committers.pdf site.html
site.pdf
Log:
update for release information
Revision Changes Path
1.3 +94 -27 ws-site/targets/juddi/committers.html
Index: committers.html
===================================================================
RCS file: /home/cvs/ws-site/targets/juddi/committers.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- committers.html 18 May 2004 04:13:13 -0000 1.2
+++ committers.html 4 Jun 2004 17:21:47 -0000 1.3
@@ -226,37 +226,104 @@
<p>You'll need the appropriate version of <a href="http://xml.apache.org/forrest/">forrest</a> as
- well as the appropriate version of <a href="http://ant.apache.org/">ant</a>. This document
- assumes you generally understand how to use these tools.
+ well as the appropriate version of <a href="http://ant.apache.org/">ant</a>. This document
+ assumes you generally understand how to use these tools.
</p>
<p>
- The site source is located under our source tree at ws-juddi/site. To build the site, simply invoke
- forrest in ws-juddi/site. The built sources will be located at ws-juddi/build/site. You should
- get a clean build, and no broken links. There aren't any known issues with the site.
- </p>
-
-<p>
- You must test your builds locally by running forrest on your local box. You can do this by invoking
- 'forrest run' in ws-juddi/site.
- </p>
-
-<p>
- The commit process is a bit complicated.
- The live site is hosted under the ws-site source tree, -not- the ws-juddi src tree. The ws-juddi/build/site
- directory hierarchy maps to the ws-site/targets/juddi directory hierarchy.
- Once you've built the site copy the latter hierarchy to the former, and then commit the
- changes. The live site is updated about every 6 hours from cvs.
- </p>
-
-<p>
- You must -also- commit the changes you've made under ws-juddi/site to persist the changes for the next
- committer to be able to reproduce your modifications.
- </p>
-
+ The site source is located under our source tree at ws-juddi/site. To build the site, simply invoke
+ forrest in ws-juddi/site. The built sources will be located at ws-juddi/build/site. You should
+ get a clean build, and no broken links. There aren't any known issues with the site.
+ </p>
+
<p>
- To fully clean any site build you've created, you can safely delete everything under ws-juddi/site/build.
- </p>
+ You must test your builds locally by running forrest on your local box. You can do this by invoking
+ 'forrest run' in ws-juddi/site.
+ </p>
+
+<p>
+ The commit process is a bit complicated.
+ The live site is hosted under the ws-site source tree, -not- the ws-juddi src tree. The ws-juddi/build/site
+ directory hierarchy maps to the ws-site/targets/juddi directory hierarchy.
+ Once you've built the site copy the latter hierarchy to the former, and then commit the
+ changes. The live site is updated about every 6 hours from cvs.
+ </p>
+
+<p>
+ You must -also- commit the changes you've made under ws-juddi/site to persist the changes for the next
+ committer to be able to reproduce your modifications.
+ </p>
+
+<p>
+ To fully clean any site build you've created, you can safely delete everything under ws-juddi/site/build.
+ </p>
+
+
+<div class="h3">
+<h3>Release Process</h3>
+</div>
+
+
+<p>
+<strong>Release Manager</strong>
+</p>
+
+<p>
+ One committer will be elected or hopefully volunteer to assemble the binary releases and label the source tree.
+ </p>
+
+<p>
+<strong>Digitally Signing Releases</strong>
+</p>
+
+<p>
+ Apache policy requires binary releases be digitaly signed. The Apache process has not been formalized, but a general discussion about creating digital signatures
+ and signing releases is available at
+ <a href="http://nagoya.apache.org/wiki/apachewiki.cgi?SigningReleases">http://nagoya.apache.org/wiki/apachewiki.cgi?SigningReleases</a>.
+ This covers some basics about using <a href="http://www.gnupg.org">GnuPG</a> to create key pairs and sign releases. Our goal here is to
+ discuss jUDDI signing requirements, and provide some useful examples to release managers, not discuss digital signatures or encryption technology.
+ Our discussion uses <a href="http://www.gnupg.org">GnuPG</a>, but any compliant software could be used. The examples below come from the
+ <a href="http://www.gnupg.org/gph/en/manual.html">GnuPG manual</a>. This discussion is not a subsitute for reading that manual.
+ </p>
+
+<p>
+ Creating a key pair is pretty simple using <a href="http://www.gnupg.org/gph/en/manual.html#AEN26">gpg</a>. Simply invoke gpg and take all the defaults when prompted. You
+ will have to provide a passphrase. Be sure to remember the passphrase since you'll need it anytime you use the key pair. The passphrase should itself be sufficiently
+ secure; it shouldn't simply be a word in a dictionary, should include a mix of digits and alphanumeric characters, etc.
+ <pre class="code">
+ gpg --gen-key
+ </pre>
+
+</p>
+
+<p>
+ You should also generate a <a href="http://www.gnupg.org/gph/en/manual.html#AEN26">revocation certificate</a>. This allows you to declare the key
+ pair invalid publically, if you ever lose your private key, or it becomes compromised.
+ <pre class="code">
+ gpg --output revoke.as --gen-revoke mykey
+ </pre>
+
+
+</p>
+
+<p>
+ The release manager is responsible for signing the binaries. The release manager must have a public key listed in the 'KEYS' file at the root of our source tree.
+ The release manager must create a <a href="http://www.gnupg.org/gph/en/manual.html#AEN161">detached signature</a> for each binary. This detached
+ signature must be posted along with our binaries, and allow our users to verify the binary's integrity.
+ <pre class="code">
+ gpg --output jUDDI.tar.gzip.asc --detach-sig jUDDI.tar.gzip
+ </pre>
+
+</p>
+
+<p>All jUDDI committers are encouraged to create public/ private key pairs and place the public half into our 'KEYS'
+ file at the root of our source tree. jUDDI committers are also encouraged to verify one another's keys and sign them, to help
+ create a web of trust. Verifying a signature and a binary guarantees (in any real sense) the binary was assembled by the person
+ that signed it. However, it does not prove the person signing it can be trusted.
+ <a href="http://www.gnupg.org/gph/en/manual.html#AEN335">A web of trust</a> can be created by signing one another's keys.
+ This allows users and developers to 'trust' the person who created the document-signature pair to provide a secure, safe
+ binary.
+ </p>
1.2 +186 -35 ws-site/targets/juddi/committers.pdf
<<Binary file>>
1.10 +94 -27 ws-site/targets/juddi/site.html
Index: site.html
===================================================================
RCS file: /home/cvs/ws-site/targets/juddi/site.html,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- site.html 4 Jun 2004 01:06:56 -0000 1.9
+++ site.html 4 Jun 2004 17:21:47 -0000 1.10
@@ -1471,37 +1471,104 @@
<p xmlns:cinclude="http://apache.org/cocoon/include/1.0">You'll need the appropriate version of <a href="http://xml.apache.org/forrest/">forrest</a> as
- well as the appropriate version of <a href="http://ant.apache.org/">ant</a>. This document
- assumes you generally understand how to use these tools.
+ well as the appropriate version of <a href="http://ant.apache.org/">ant</a>. This document
+ assumes you generally understand how to use these tools.
</p>
<p xmlns:cinclude="http://apache.org/cocoon/include/1.0">
- The site source is located under our source tree at ws-juddi/site. To build the site, simply invoke
- forrest in ws-juddi/site. The built sources will be located at ws-juddi/build/site. You should
- get a clean build, and no broken links. There aren't any known issues with the site.
- </p>
-
-<p xmlns:cinclude="http://apache.org/cocoon/include/1.0">
- You must test your builds locally by running forrest on your local box. You can do this by invoking
- 'forrest run' in ws-juddi/site.
- </p>
-
-<p xmlns:cinclude="http://apache.org/cocoon/include/1.0">
- The commit process is a bit complicated.
- The live site is hosted under the ws-site source tree, -not- the ws-juddi src tree. The ws-juddi/build/site
- directory hierarchy maps to the ws-site/targets/juddi directory hierarchy.
- Once you've built the site copy the latter hierarchy to the former, and then commit the
- changes. The live site is updated about every 6 hours from cvs.
- </p>
-
-<p xmlns:cinclude="http://apache.org/cocoon/include/1.0">
- You must -also- commit the changes you've made under ws-juddi/site to persist the changes for the next
- committer to be able to reproduce your modifications.
- </p>
-
+ The site source is located under our source tree at ws-juddi/site. To build the site, simply invoke
+ forrest in ws-juddi/site. The built sources will be located at ws-juddi/build/site. You should
+ get a clean build, and no broken links. There aren't any known issues with the site.
+ </p>
+
<p xmlns:cinclude="http://apache.org/cocoon/include/1.0">
- To fully clean any site build you've created, you can safely delete everything under ws-juddi/site/build.
- </p>
+ You must test your builds locally by running forrest on your local box. You can do this by invoking
+ 'forrest run' in ws-juddi/site.
+ </p>
+
+<p xmlns:cinclude="http://apache.org/cocoon/include/1.0">
+ The commit process is a bit complicated.
+ The live site is hosted under the ws-site source tree, -not- the ws-juddi src tree. The ws-juddi/build/site
+ directory hierarchy maps to the ws-site/targets/juddi directory hierarchy.
+ Once you've built the site copy the latter hierarchy to the former, and then commit the
+ changes. The live site is updated about every 6 hours from cvs.
+ </p>
+
+<p xmlns:cinclude="http://apache.org/cocoon/include/1.0">
+ You must -also- commit the changes you've made under ws-juddi/site to persist the changes for the next
+ committer to be able to reproduce your modifications.
+ </p>
+
+<p xmlns:cinclude="http://apache.org/cocoon/include/1.0">
+ To fully clean any site build you've created, you can safely delete everything under ws-juddi/site/build.
+ </p>
+
+
+<div class="h2">
+<h2>Release Process</h2>
+</div>
+
+
+<p xmlns:cinclude="http://apache.org/cocoon/include/1.0">
+<strong>Release Manager</strong>
+</p>
+
+<p xmlns:cinclude="http://apache.org/cocoon/include/1.0">
+ One committer will be elected or hopefully volunteer to assemble the binary releases and label the source tree.
+ </p>
+
+<p xmlns:cinclude="http://apache.org/cocoon/include/1.0">
+<strong>Digitally Signing Releases</strong>
+</p>
+
+<p xmlns:cinclude="http://apache.org/cocoon/include/1.0">
+ Apache policy requires binary releases be digitaly signed. The Apache process has not been formalized, but a general discussion about creating digital signatures
+ and signing releases is available at
+ <a href="http://nagoya.apache.org/wiki/apachewiki.cgi?SigningReleases">http://nagoya.apache.org/wiki/apachewiki.cgi?SigningReleases</a>.
+ This covers some basics about using <a href="http://www.gnupg.org">GnuPG</a> to create key pairs and sign releases. Our goal here is to
+ discuss jUDDI signing requirements, and provide some useful examples to release managers, not discuss digital signatures or encryption technology.
+ Our discussion uses <a href="http://www.gnupg.org">GnuPG</a>, but any compliant software could be used. The examples below come from the
+ <a href="#http://www.gnupg.org/gph/en/manual.html">GnuPG manual</a>. This discussion is not a subsitute for reading that manual.
+ </p>
+
+<p xmlns:cinclude="http://apache.org/cocoon/include/1.0">
+ Creating a key pair is pretty simple using <a href="#http://www.gnupg.org/gph/en/manual.html#AEN26">gpg</a>. Simply invoke gpg and take all the defaults when prompted. You
+ will have to provide a passphrase. Be sure to remember the passphrase since you'll need it anytime you use the key pair. The passphrase should itself be sufficiently
+ secure; it shouldn't simply be a word in a dictionary, should include a mix of digits and alphanumeric characters, etc.
+ <pre class="code">
+ gpg --gen-key
+ </pre>
+
+</p>
+
+<p xmlns:cinclude="http://apache.org/cocoon/include/1.0">
+ You should also generate a <a href="#http://www.gnupg.org/gph/en/manual.html#AEN26">revocation certificate</a>. This allows you to declare the key
+ pair invalid publically, if you ever lose your private key, or it becomes compromised.
+ <pre class="code">
+ gpg --output revoke.as --gen-revoke mykey
+ </pre>
+
+
+</p>
+
+<p xmlns:cinclude="http://apache.org/cocoon/include/1.0">
+ The release manager is responsible for signing the binaries. The release manager must have a public key listed in the 'KEYS' file at the root of our source tree.
+ The release manager must create a <a href="#http://www.gnupg.org/gph/en/manual.html#AEN161">detached signature</a> for each binary. This detached
+ signature must be posted along with our binaries, and allow our users to verify the binary's integrity.
+ <pre class="code">
+ gpg --output jUDDI.tar.gzip.asc --detach-sig jUDDI.tar.gzip
+ </pre>
+
+</p>
+
+<p xmlns:cinclude="http://apache.org/cocoon/include/1.0">All jUDDI committers are encouraged to create public/ private key pairs and place the public half into our 'KEYS'
+ file at the root of our source tree. jUDDI committers are also encouraged to verify one another's keys and sign them, to help
+ create a web of trust. Verifying a signature and a binary guarantees (in any real sense) the binary was assembled by the person
+ that signed it. However, it does not prove the person signing it can be trusted.
+ <a href="#http://www.gnupg.org/gph/en/manual.html#AEN335">A web of trust</a> can be created by signing one another's keys.
+ This allows users and developers to 'trust' the person who created the document-signature pair to provide a secure, safe
+ binary.
+ </p>
1.10 +661 -495 ws-site/targets/juddi/site.pdf
<<Binary file>>