You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@otava.apache.org by Henrik Ingo <he...@nyrkio.com> on 2025/04/19 19:48:10 UTC
On verifying releases before voting
This is a question mainly to mentors I guess:
https://www.apache.org/legal/release-policy.html
...emphasises that:
> Before casting +1 binding votes, individuals are REQUIRED to download all
signed source code packages onto their own hardware, verify that they meet
all requirements of ASF policy on releases as described below, validate all
cryptographic signatures, compile as provided, and test the result on their
own platform.
Question: Is it frowned upon if project committers distribute to each other
bash scripts to automate the individually performed review? I mean do we
expect each individual to contribute some randomness and diversity, beyond
just another hw and os platform?
henrik
Re: On verifying releases before voting
Posted by Henrik Ingo <he...@nyrkio.com>.
On Sat, Apr 19, 2025 at 10:57 PM Enrico Olivelli <eo...@gmail.com>
wrote:
>
> Usually everyone tests more the features that they use, for instance they
> may try the release candidate against their code.
>
>
That makes sense. I guess in this case there is a bit of a gap to get
there, because what happens in practice for a python/pip module is that you
install it directly from the GitHub repository. Yet the official ASF
releases are tar archives with the python and other project files. And to
verify those is extra work, because it's not how a python/pip module is
consumed ordinarily.
henrik
Re: On verifying releases before voting
Posted by Enrico Olivelli <eo...@gmail.com>.
Il Sab 19 Apr 2025, 21:49 Henrik Ingo <he...@nyrkio.com> ha scritto:
> This is a question mainly to mentors I guess:
>
> https://www.apache.org/legal/release-policy.html
>
> ...emphasises that:
>
> > Before casting +1 binding votes, individuals are REQUIRED to download all
> signed source code packages onto their own hardware, verify that they meet
> all requirements of ASF policy on releases as described below, validate all
> cryptographic signatures, compile as provided, and test the result on their
> own platform.
>
> Question: Is it frowned upon if project committers distribute to each other
> bash scripts to automate the individually performed review? I mean do we
> expect each individual to contribute some randomness and diversity, beyond
> just another hw and os platform?
>
Usually everyone tests more the features that they use, for instance they
may try the release candidate against their code.
Enrico
> henrik
>
Re: On verifying releases before voting
Posted by Mick Semb Wever <mc...@apache.org>.
On Sat, 19 Apr 2025 at 21:48, Henrik Ingo <he...@nyrkio.com> wrote:
> This is a question mainly to mentors I guess:
>
> https://www.apache.org/legal/release-policy.html
>
> ...emphasises that:
>
> > Before casting +1 binding votes, individuals are REQUIRED to download all
> signed source code packages onto their own hardware, verify that they meet
> all requirements of ASF policy on releases as described below, validate all
> cryptographic signatures, compile as provided, and test the result on their
> own platform.
>
> Question: Is it frowned upon if project committers distribute to each other
> bash scripts to automate the individually performed review? I mean do we
> expect each individual to contribute some randomness and diversity, beyond
> just another hw and os platform?
>
Sharing scripts is fine IMHO. So long as each committer has eyeballed the
script and trusts what it does.
Verifying signatures on the releases is the most important aspect of the
vote (even if it's not what's most typical in practice).
For example cassandra's release verification script is in this PR
https://github.com/apache/cassandra-builds/pull/32
Re: On verifying releases before voting
Posted by Dave Fisher <wa...@apache.org>.
> On Apr 19, 2025, at 12:48 PM, Henrik Ingo <he...@nyrkio.com> wrote:
>
> This is a question mainly to mentors I guess:
>
> https://www.apache.org/legal/release-policy.html
>
> ...emphasises that:
>
>> Before casting +1 binding votes, individuals are REQUIRED to download all
> signed source code packages onto their own hardware, verify that they meet
> all requirements of ASF policy on releases as described below, validate all
> cryptographic signatures, compile as provided, and test the result on their
> own platform.
>
> Question: Is it frowned upon if project committers distribute to each other
> bash scripts to automate the individually performed review?
You can certainly share bash scripts.
Here’s one I often use:
#!/bin/bash
export DISTURL='https://dist.apache.org/repos/dist/dev'
export PROJECT=${1}
export ARTIFACT=${2}
export DISTRO=${DISTURL}/${PROJECT}/${ARTIFACT}
echo ${DISTRO}
export TMPDIR=/tmp/${PROJECT}
mkdir -p $TMPDIR
cd $TMPDIR
pwd
curl -f -L ${DISTRO} --output ${ARTIFACT}
curl -f -L ${DISTRO}.asc --output ${ARTIFACT}.asc
curl -f -L ${DISTRO}.sha256 --output ${ARTIFACT}.sha256
curl -f -L ${DISTRO}.sha512 --output ${ARTIFACT}.sha512
echo 'Check signature'
gpg --verify ${ARTIFACT}.asc
echo 'Compare checksum to sha256'
cat ${ARTIFACT}.sha256
shasum -a 256 ${ARTIFACT}
echo 'Compare checksum to sha512'
cat ${ARTIFACT}.sha512
shasum -a 512 ${ARTIFACT}
echo
———
I also do a RAT_CHECK, but I think that poetry can do license checks as well.
#!/bin/bash
java -jar ~/Development/apache-rat-0.12.jar -E .rat-excludes .
Best,
Dave
> I mean do we
> expect each individual to contribute some randomness and diversity, beyond
> just another hw and os platform?
>
> henrik