I am still -1 on everything related with signatures in "Voting a release", but...
Checked the release policy <https://www.apache.org/legal/release-policy.html#host-rc>... *Projects SHOULD use the `/dev` tree of the `dist` repository or the staging features of repository.apache.org <http://repository.apache.org> to host release candidates posted for developer testing/voting...* Hence, we can indeed use the Git commit ID as the origin for an RC. Regarding replacing `pom.xml` snippet creating the distribution with a script... Why don't we instead make Log4cxx use Maven for releases and the website? For instance, Log4Net already uses Maven to generate the website and they are willing to use Maven for the entire release. These non-Java projects need to 1. Override the `distribution` Maven profile 1. Skip `nexus-staging-maven-plugin` 2. Run their custom build tool (Log4cxx can use `cmake-maven-plugin`, Log4net can use `frontend-maven-plugin` for `npm`, etc.) 3. Attach generated artifacts 2. Switch to Antora 3. Switch to Log4j Changelog 4. Activate `dependabot` workflows On Mon, Oct 14, 2024 at 8:25 PM Volkan Yazıcı <vol...@yazi.ci> wrote: > -1 > > - In "Staging a release", -1 for replacing a platform-independent > `pom.xml` snippet with OS-specific shell scripts > - In "Reviewing a release", you say "Since the de facto source archive > is the Git repository". On the contrary, as much as Legal is concerned, de > facto source archive is the one distributed with SVN. > - In "Voting a release", -1 for everything related with signatures. It > introduces complexity without any _practical_ benefit. > > There is the Artifact Distribution Platform project > <https://lists.apache.org/thread/bj68p377b6qvw1ms2x57x9l17pw5348l> of > INFRA – see its Slack channel > <https://app.slack.com/client/T4S1WH2J3/C049WADAAQG>. I think it is a > better place to improve the release process, ASF-wide. > > On Mon, Oct 14, 2024 at 4:31 PM Piotr P. Karwasz <piotr.karw...@gmail.com> > wrote: > >> 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 >> >
