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)
pgpf4BgI3Mi3s.pgp
Description: PGP signature
_______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
