WARING

This is currently copied from the Edgent project and we will have to build our own tooling as this was initially created for Gradle and Ant builds. We can simplify a lot here ...


Once a release candidate has been staged to https://dist.apache.org/repos/dist/dev/plc4x/ it must be validated and voted on in order to proceed.

Team members must do the following.  

Only the Release Manager need perform the items tagged with '[RM]' though all are encouraged to.

  1. download staged artifacts. Check their signature and hashes.
    1. cd ~/tmp
    2. .../tools/download_staged_release.sh 0.4.0 1  # <version> <rc-num>
    3. [RM] verify the reported signature is for an "apache.org" address ("gpg: Good signature from ...")
      1. gpg --verify apache-plc4x-0.8.0-source-release.zip.asc apache-plc4x-0.8.0-source-release.zip

    4. [RM] verify the reported hashes:
      1. shasum -a512 apache-plc4x-0.8.0-source-release.zip

      2. Compare the checksum printed out with the one of the corresponding SHA512 file
  2. extract src bundle
    1. cd downloaded-plc4x-0.4.0rc1
    2. unzip 0.4.0/rc1/apache-plc4x-0.4.0-source-release.zip
    3. verify the existence of LICENSE, NOTICE, README, RELEASE_NOTES files in the extracted source bundle
    4. [RM] verify the staged source README, RELEASE_NOTE files correspond to those in the extracted source bundle
  3. staged src bundle items: content, can compile & test
    1. cd apache-plc4x-0.4.0
    2. check the contents of LICENSE, NOTICE, README, RELEASE_NOTES
      1. Check the any year references (NOTICE file contains at least one in the Copyright notice, that could need updating)
    3. build from directions in README
      1. In addition to the build directions it it advisable to ensure building with an empty maven local repo, as this ensures all dependencies are currently available, by adding the following argument to the maven execution: "-Dmaven.repo.local=../.m2"
    4. [RM] review target/rat.txt (though the build should fail if RAT constraints aren't met)
      1. Find and files containing binary content with this command:

        1. find . -type f -name 'rat.txt' -exec grep -l " B " {} \;
      2. Then review for B (binary) content in those files:   grep " B " target/rat.txt

    5. Search for SNAPSHOT references
      1. find . -type f -name 'pom.xml' -exec grep -l "SNAPSHOT" {} \;
    6. ./mvnw install 
      1. the tests should all pass
    7. NOTE: can't do this in a source-bundle (only in a repo) ./mvnw site:site  # generate reports
      1. the tests should all pass
  4. staged jars/wars in Nexus
    1. [RM] We're currently lacking a way to download all of the staged jars to verify them. For now, verify the jars that were uploaded from the management clone used to create the RC
  5. TODO: We should add information on how to run the examples against the PLCs in the IoT Lab VPN 

Verifying the signature (ASC)

In order to check the signature (ASC) of the release:

gpg --verify apache-plc4x-0.8.0-source-release.zip.asc apache-plc4x-0.8.0-source-release.zip

This should produce something like this:

gpg: Signatur vom Fr  2 Aug 14:30:42 2019 CEST
gpg:                mittels RSA-Schlüssel ADBD428CB5BF6C9FFC77B907C336E0143A553B89
gpg: Korrekte Signatur von "Julian Feinauer <jfeinauer@apache.org>" [ultimativ]

The important part is that it's a "correct signature" (Above is on my German Mac Book). And that the email assigned to the signature is an Apache email. The "ultimativ" at the end depends on your PGP trust environment. If you are not yet trusting any Apache people, this might be different.

If you get the following error,  it means you don't have the public key of the person who signed the message.

gpg: Signature made 一 10/14 13:04:42 2019 CST
gpg:                using RSA key BA45CDBB87E8B146A81F5BBE2206EF8F64C35889
gpg: Can't check signature: No public key


Then you can use the RSA key provided to receive the public key to verify and verify again.

gpg2 --receive-keys BA45CDBB87E8B146A81F5BBE2206EF8F64C35889
 
gpg: key 2206EF8F64C35889: public key "Xiangdong Huang (Apache IoTDB release signing key) <hxd@apache.org>" imported
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   2  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 2u
gpg: Total number processed: 1
gpg:               imported: 1

Verifying the hashes (SHA512)

Unfortunately checking the hashes isn't as automatic as checking the signatures. 

shasum -a512 apache-plc4x-0.8.0-source-release.zip

This will print out the hash ... unfortunately I haven't found a tool that you could pass along the SHA512 file and it just says: OK or NOT OK, so you have to manually compare the output with the output in the SHA512 file. 

You however don't have to check everything. I usually check the first 8 chars and the last 8 ... the probability of the rest in the middle being different is minimal..

Running RAT

Before building it might be a good idea to run RAT on the unpacked sources. This will find all binaries and files without headers completely ignoring any "exclusions" in the pom.

Download the latest version of RAT from here: https://creadur.apache.org/rat/download_rat.cgi

Unpack it somewhere and change into the unpacked source-directory and run the following command:

java -Xms1024m -Xmx1024m -jar {path-to-apache-rat-0.13.jar} .

  • No labels