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