src/site/xdoc/committers.xml - juddi - Git at Google

 <?xml version="1.0" encoding="UTF-8"?>
 <!--
  * Copyright 2001-2009 The Apache Software Foundation.
  *
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.
  * You may obtain a copy of the License at
  *
  *      http://www.apache.org/licenses/LICENSE-2.0
  *
  * Unless required by applicable law or agreed to in writing, software
  * distributed under the License is distributed on an "AS IS" BASIS,
  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  * See the License for the specific language governing permissions and
  * limitations under the License.
  *
  */ -->
 <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.2//EN" "http://forrest.apache.org/dtd/document-v12.dtd">
 <document>
   <properties>
     <title>Committer Notes</title>
   </properties>
   <body>
     <section name="Updating the jUDDI Web Site">
       <p>
        The site source is located under our source tree at juddi/src/site. To build the site, simply invoke
         mvn site in juddi/site. The built sources will be located at juddi/target/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 mvn site on your local box. You can do this by invoking
         'mvn site' in the juddi root directory.
         </p>
         <p>
         The commit process is a bit complicated.
         The live site is hosted under the site source tree, -not- the juddi src tree. The juddi/target/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 juddi/src/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 juddi/target.
         </p>
     </section>
     <section name="Release Process">
       <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
         <link href="http://nagoya.apache.org/wiki/apachewiki.cgi?SigningReleases">http://nagoya.apache.org/wiki/apachewiki.cgi?SigningReleases</link>.
         This covers some basics about using <link href="http://www.gnupg.org">GnuPG</link> 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 <link href="http://www.gnupg.org">GnuPG</link>, but any compliant software could be used. The examples below come from the
         <link href="http://www.gnupg.org/gph/en/manual.html">GnuPG manual</link>. This discussion is not a subsitute for reading that manual.
       </p>
       <p>
         Creating a key pair is pretty simple using <link href="http://www.gnupg.org/gph/en/manual.html#AEN26">gpg</link>. 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.
        </p>
         <source>
           gpg --gen-key
         </source>
         <p>
         You should also generate a <link href="http://www.gnupg.org/gph/en/manual.html#AEN26">revocation certificate</link>. This allows you to declare the key
         pair invalid publically, if you ever lose your private key, or it becomes compromised.
       </p>
         <source>
           gpg --output revoke.as --gen-revoke mykey
         </source>

       <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 <link href="http://www.gnupg.org/gph/en/manual.html#AEN161">detached signature</link> for each binary. This detached
         signature must be posted along with our binaries, and allow our users to verify the binary's integrity.
       </p>
         <source>
           gpg --output jUDDI.tar.gzip.asc --detach-sig jUDDI.tar.gzip
         </source>
       <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.
         <link href="http://www.gnupg.org/gph/en/manual.html#AEN335">A web of trust</link> 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>
     </section>
   </body>
 </document>
	<?xml version="1.0" encoding="UTF-8"?>
	<!--
	* Copyright 2001-2009 The Apache Software Foundation.
	*
	* Licensed under the Apache License, Version 2.0 (the "License");
	* you may not use this file except in compliance with the License.
	* You may obtain a copy of the License at
	*
	* http://www.apache.org/licenses/LICENSE-2.0
	*
	* Unless required by applicable law or agreed to in writing, software
	* distributed under the License is distributed on an "AS IS" BASIS,
	* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
	* See the License for the specific language governing permissions and
	* limitations under the License.
	*
	*/ -->
	<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.2//EN" "http://forrest.apache.org/dtd/document-v12.dtd">
	<document>
	<properties>
	<title>Committer Notes</title>
	</properties>
	<body>
	<section name="Updating the jUDDI Web Site">
	<p>
	The site source is located under our source tree at juddi/src/site. To build the site, simply invoke
	mvn site in juddi/site. The built sources will be located at juddi/target/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 mvn site on your local box. You can do this by invoking
	'mvn site' in the juddi root directory.
	</p>
	<p>
	The commit process is a bit complicated.
	The live site is hosted under the site source tree, -not- the juddi src tree. The juddi/target/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 juddi/src/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 juddi/target.
	</p>
	</section>
	<section name="Release Process">
	<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
	<link href="http://nagoya.apache.org/wiki/apachewiki.cgi?SigningReleases">http://nagoya.apache.org/wiki/apachewiki.cgi?SigningReleases</link>.
	This covers some basics about using <link href="http://www.gnupg.org">GnuPG</link> 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 <link href="http://www.gnupg.org">GnuPG</link>, but any compliant software could be used. The examples below come from the
	<link href="http://www.gnupg.org/gph/en/manual.html">GnuPG manual</link>. This discussion is not a subsitute for reading that manual.
	</p>
	<p>
	Creating a key pair is pretty simple using <link href="http://www.gnupg.org/gph/en/manual.html#AEN26">gpg</link>. 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.
	</p>
	<source>
	gpg --gen-key
	</source>
	<p>
	You should also generate a <link href="http://www.gnupg.org/gph/en/manual.html#AEN26">revocation certificate</link>. This allows you to declare the key
	pair invalid publically, if you ever lose your private key, or it becomes compromised.
	</p>
	<source>
	gpg --output revoke.as --gen-revoke mykey
	</source>

	<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 <link href="http://www.gnupg.org/gph/en/manual.html#AEN161">detached signature</link> for each binary. This detached
	signature must be posted along with our binaries, and allow our users to verify the binary's integrity.
	</p>
	<source>
	gpg --output jUDDI.tar.gzip.asc --detach-sig jUDDI.tar.gzip
	</source>
	<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.
	<link href="http://www.gnupg.org/gph/en/manual.html#AEN335">A web of trust</link> 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>
	</section>
	</body>
	</document>