Handle non-bytevector hashes from guile-gcrypthandle-non-bytevector-hashes-from-gcrypt

The bytevector->hash-data from (gcrypt pk-crypto) returns a bytevector, symbol
or #f and currently when checking narinfo signatures Guix only handles the
bytevector case.

If the hash value represented as a string happens to contain only characters
that Guile recognises as letters, digits or some symbols,
bytevector->hash-data will return a symbol, and this would be treated as a
hash mismatch since the symbol doesn't equal? the computed hash
bytevector. This seems to be quite unlikely for real life narinfos, but can
happen.

To handle this, detect when a symbol is returned, and convert the symbol to
the equivalent bytevector before making the comparision. This can be fixed
upstream in guile-gcrypt by always returning a bytevector from
bytevector->hash-data.

This commit also adds a test which demonstrates this behaviour using the hash
value I was initially investigating when debugging substituting [1] from
data.guix.gnu.org.

1: /gnu/store/4rc8c5mzfj4j13yb002zd21s10z7yxgb-cl-spatial-trees-0-1.81fdad0-builder

* guix/pki.scm (%signature-status): Handle when hash-data->bytevector returns
a symbol.
* tests/pki.scm ("signature-case valid-signature for non bytevector hash
data"): New test case.

Change-Id: Ie1de05efa20b33128dbb7ab098fb9fb8e22ea407

0 files changed, 0 insertions, 0 deletions