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

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Ludovic Courtès <ludovic.courtes <at> inria.fr>
Subject: bug#43421: closed (Re: bug#43421: Encoding issue in exported
 archive signatures)
Date: Tue, 15 Sep 2020 15:43:01 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#43421: Encoding issue in exported archive signatures

which was filed against the guix package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 43421 <at> debbugs.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 <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’.

[Message part 3 (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

Previous Next

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