Hi all, Recently on `security-discuss@community` Christopher Schultz posted a list[0] of security-related aspects that could be improved in Apache projects. After looking at the new Log4cxx release[1] and release review[2] instructions, that I tried to automatise in PR #414[3], I am wondering if we can come up with a release and release review procedure that is, as much as possible, common to all projects. The advantage of such a procedure would be to relieve PMC members from remembering (or reading) the steps required to verify a release.
Some ideas for a brainstorming session: ### Staging a release The Java projects have the most automatised release process: 1. It is started by a push to a `release/<version>` branch. 2. (Java specific) It publishes artifacts to Nexus. 3. It creates all the archives we need for `downloads.apache.org`, computes their hashes and signatures. 4. It sends those archives to Subversion. I think that this process could be generalized to all projects. We only need to replace the Java-specific part with something specific to each ecosystem. Do you agree? The current implementation of point 3 is Maven specific: we use a Groovy script started by a Maven plugin to package the files. Could we perhaps replace this with something more universal? A shell script should probably be enough. I have a prototype in [4], which only needs some massaging to work on MacOS and Windows and some generalization. ### Reviewing a release The release instructions for Java releases[5] start with some common steps. We probably agree that the verification of each Logging Services release should start with: 1. Downloading the artifacts in `downloads.apache.org`. 2. Verifying the hashes. 3. Verifying the signatures. After these steps the current Java verification procedure directly starts a build using the downloaded sources. IMHO there is a step missing (which is crucial for Log4cxx and Log4NET): the integrity and reproducibility of the source archive should be verified first! Since the _de facto_ source archive is the Git repository, we need to: 4. Make a (shallow) clone of the appropriate Git commit. 5. Package the source archive. For this step we can reuse the same script as in "Staging a release" 6. Verify the source archives using the hashes from Subversion. Currently we justify the absence of these steps by the reproducibility guarantees of our Java build. We should however consider that not all PMC members run the reproducibility checks, which are basically only guaranteed to work on Linux. ### Voting a release A long dream of mine was to record the names of PMC members that voted +1 on a release in a cryptographically verifiable way. We could adopt an (optional) procedure, where PMC members: 1. Reproduce all the artifacts that will be published to `downloads.apache.org`. 2. Sign the local artifacts (not those downloaded from Subversion). 3. Append the signatures to those in Subversion. 4. If the signatures are valid (which not only guarantees that the signer is who he claims to be, but also that the artifacts are reproducible) push the commit to Subversion. What do you think? Piotr [0] https://lists.apache.org/thread/4w27qvdxdc30mnt72sj98dhjmz2qq3z3 [1] https://github.com/apache/logging-log4cxx/blob/master/admin/releasing.md [2] https://github.com/apache/logging-log4cxx/blob/master/admin/release-review-instructions.md [3] https://github.com/apache/logging-log4cxx/pull/414 [4] https://github.com/apache/logging-log4cxx/blob/b1dfdf25289db7926db803eaaaf99607ee9e8829/package.sh [5] https://logging.apache.org/logging-parent/release-review-instructions.html#verify
