GNU bug report logs - #43421
Encoding issue in exported archive signatures

Previous Next

Package: guix;

Reported by: Ludovic Courtès <ludovic.courtes <at> inria.fr>

Date: Tue, 15 Sep 2020 12:19:02 UTC

Severity: normal

Done: Ludovic Courtès <ludo <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#43421: closed (Encoding issue in exported archive signatures)
Date: Tue, 15 Sep 2020 15:43:01 +0000
[Message part 1 (text/plain, inline)]
Your message dated Tue, 15 Sep 2020 17:42:24 +0200
with message-id <87pn6nrqqn.fsf <at> gnu.org>
and subject line Re: bug#43421: Encoding issue in exported archive signatures
has caused the debbugs.gnu.org bug report #43421,
regarding Encoding issue in exported archive signatures
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
43421: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=43421
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
From: Ludovic Courtès <ludovic.courtes <at> inria.fr>
To: <bug-guix <at> gnu.org>
Subject: Encoding issue in exported archive signatures
Date: Tue, 15 Sep 2020 14:18:17 +0200
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:

--8<---------------cut here---------------start------------->8---
(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#)
   )
  )
 )
--8<---------------cut here---------------end--------------->8---

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>.

The interesting bit is that this archive can be correctly ingested by a
new daemon, but it fails signature verification with an older daemon.

Ludo’.

¹ https://issues.guix.gnu.org/43340


[Message part 3 (message/rfc822, inline)]
From: Ludovic Courtès <ludo <at> gnu.org>
To: 43421-done <at> debbugs.gnu.org
Subject: Re: bug#43421: Encoding issue in exported archive signatures
Date: Tue, 15 Sep 2020 17:42:24 +0200
Hi,

Ludovic Courtès <ludovic.courtes <at> 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’.


This bug report was last modified 4 years and 312 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.