Vladimir, this PR <https://github.com/apache/www-site/pull/235> merged by Legal updated the release policy as follows:
> It MUST be signed by either the Release Manager or the automated release > infrastructure, where the underlying implementation MUST follow the principles > [outlined](/dev/release-signing.html#automated-release-signing) by the Apache > Security Team. I presume your concerns regarding the signing process is addressed. On Mon, Jul 3, 2023 at 1:13 PM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > On Mon, Jul 3, 2023 at 1:13 PM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > -1, don't release, because... > > > Volkan, > > I have downloaded the release artifact apache-log4j-tools-0.4.0.zip, and I > fail to find the source package there. > Would you please advise? > > See > > https://www.apache.org/legal/release-policy.html#what-must-every-release-contain > > >Every ASF release must contain a source package, which must be sufficient > for a user to build and > >test the release provided they have access to the appropriate platform and > tools > > I performed unzip apache-log4j-tools-0.4.0.zip, and I find two jar files, > LICENSE, NOTICE, and RELEASE-NOTES there. > > The jar files contain binary/bytecode files, and the release contains no > signs of a source package. > > Please, correct me if I am wrong, but it sounds that "0.4.0 release of > Apache Log4j Tools" violates > "WHAT MUST EVERY ASF RELEASE CONTAIN?" policy. > > --- > > > I simplified the VOTE email to *only* include details necessary for an > > ASF-compliant release. > > It is unfair to omit the link to the published binary/bytecode packages. > For instance, if the version in maven publication was different from 0.4.0, > then it would > violate the ASF policy. > > The ASF policy does impose several MUST requirements on the released > binary/bytecode packages, see > https://www.apache.org/legal/release-policy.html#compiled-packages > > >the binary/bytecode package MUST have the same version number as the > source release > >and MUST only add binary/bytecode files that are the result of compiling > that version of > >the source code release and its dependencies. > > --- > > >Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0 > > Could you please clarify who owns and controls the key? > Correct me if I am wrong, however, the ASF release policy requires that > the releases MUST be signed by Release Manager: > https://www.apache.org/legal/release-policy.html#release-signing > > At the same time they say: > https://www.apache.org/legal/release-policy.html#owned-controlled-hardware > > >hardware owned and controlled by the committer. That means hardware the > committer has physical possession > >and control of and exclusively full administrative/superuser access to. > That's because only such hardware > >is qualified to hold a PGP private key, and the release should be verified > on the machine the private key lives on or on a machine as trusted as that > > It sounds to me that external systems, including GitHub Actions should not > be trusted to store signing private keys. > In other words, if the only PGP signature comes from a bot running in > GitHub Actions, > then it looks to me the release deviates from the ASF Release Policy. > > --- > > >This is a lazy vote to release > > Could you please clarify what do you mean by "This is a lazy vote to > release"? > The only thing coming to my mind is "lazy consensus", however I do not > think lazy consensus > can be used for release voting. > The ASF policy requires that every time a member of PMC votes, they are > REQUIRED to download all signed code > onto their hardware and verify it: > https://www.apache.org/legal/release-policy.html#release-approval > > Could you please clarify the meaning of "lazy" in both mail text and the > subject? > > > Vladimir >
