Hi, Ludovic Courtès <ludovic.cour...@inria.fr> skribis:
> Following the ‘guix authenticate’ in commit > 64cf660f872fb7aaf0d2b463e45b4c756297f743¹, I’m observing encoding > issues: > > guix archive --export \ > /gnu/store/3p5wcw2a0844rbcmlrqfjx8bx7b7gq34-r-rvest-0.3.6-guile-builder > > yield an archive with this signature: > > (signature > (data > (flags rfc6979) > (hash sha256 > #1DEE0418AF5FD8A05D2142290BA03735176FA27BB68B3A02977C774EA3DBDAEC#) > ) > (sig-val > (ecdsa > (r #072B8E5C6B84D4ED469EC2CF63103621602E9AF3902E454CAD49CFA6BDE2FBF0#) > (s "~%*Øw2%YZ»+yvc*¤Ì44C;RM\t3EQIp<ü") > ) > ) > (public-key > (ecc > (curve Ed25519) > (q #8D156F295D24B0D9A86FA5741A840FF2D24F60F7B6C4134814AD55625971B394#) > ) > ) > ) > > Notice the ‘s’ field of the signature. > > The problem does not occur systematically: it depends on the byte string > (libgcrypt encodes Latin-1ish strings as strings and other strings as > hex sequences.) The problem is similar to > <https://issues.guix.gnu.org/17312>. Fixed in b911d6547444b5f8d17b224bafa5ee1b5aafaff5! > The interesting bit is that this archive can be correctly ingested by a > new daemon, but it fails signature verification with an older daemon. This is because when using the new daemon on both sides, we were encoding/decoding strings as UTF-8, which made no sense but worked well. Older implementations rightfully expect “raw strings” aka. ISO-8859-1. Ludo’.