[ClusterLabs] [Announce] clufter v0.77.2 released

[Jan Pokorný]

On 14/08/19 16:26 +0200, Jan Pokorný wrote:
> I am happy to announce that clufter, a tool/library for transforming
> and analyzing cluster configuration formats, got its version 0.77.2
> tagged and released (incl. signature using my 60BCBB4F5CD7F9EF key):
> <https://pagure.io/releases/clufter/clufter-0.77.2.tar.gz>
> <https://pagure.io/releases/clufter/clufter-0.77.2.tar.gz.asc>
> or alternative (original) location:
> <https://people.redhat.com/jpokorny/pkgs/clufter/clufter-0.77.2.tar.gz>
> <https://people.redhat.com/jpokorny/pkgs/clufter/clufter-0.77.2.tar.gz.asc>
> 
> The updated test suite for this version is also provided:
> <https://pagure.io/releases/clufter/clufter-0.77.2-tests.tar.xz>
> or alternatively:
> <https://people.redhat.com/jpokorny/pkgs/clufter/clufter-0.77.2-tests.tar.xz>

Later on, I've found out that Fedora now mandates packagers to run
the OpenPGP signature verification as an initial step in the build
process whenever upstream publishes such signatures.  Preferably in
this scenario, upstream would also publish the key(s) as a publicly
available key ring (this is something immutable and easily shareable
in a truly distributed manner, also independent of a fragile
-- as we could learn recently -- key servers infrastructure).

In addition, I've realized that using my general signing key
associated with my work life identity (and used to sign this very
message, for instance) is not the best choice for any sort of
long-term contingency.

Therefore, I am now killing two birds with one stone with following:

1. I am hereby publishing such a keyring as:
   <https://releases.pagure.org/clufter/clufter-2019-08-15-5CD7F9EF.keyring>
   <https://people.redhat.com/jpokorny/pkgs/clufter/clufter-2019-08-15-5CD7F9EF.keyring>
   with following digests:
   SHA256 (clufter-2019-08-15-5CD7F9EF.keyring) = b2917412ed6d15206235ad98a14f4b51cbe15c66f534965bd31a13c01984305b
   SHA512 (clufter-2019-08-15-5CD7F9EF.keyring) = beedc493a04e3bd13c88792b0d9c0b9667a3a182416524c755ef1a2d60328c049d79a9ee88648eaf3f5965f8819221667fbb6d7fe2b5c92cd38b96226d44ea31

2. I am hereby and ahead-of-time detailing how the rollover be
   conducted should I decide to swap the signing key/related signing
   identity, barring a disaster (the purpose is to render any rough
   tampering attempts self-evident, since they would not follow the
   protocol set forth here):

       the first clufter release following such change will be signed
       with both the above specified key and the new/non-identical one
       (concatenated detached signatures in one file as usual) that
       will be present at distribution site/mirror likewise in a form
       "clufter-<date-of-publishing>-<short-primary-keyid>.keyring",
       where <date-of-publishing> is to correspond to the closest
       date prior to such release (in case there are more);
       once this "transaction is committed", default assumption for
       any subsequent one remains along the same lines, just with
       the newly established key as an origin

(Rationale for encoding the date hints in the file names: shall be
trivial to pick the correct keyring[s] related to the timestamp
of the the tarball -- or of the newest file within the tarball).

-- 
Jan (Poki)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20190815/42943857/attachment.sig>