bug#58561: Source hash mismatch with aggregator + possible guix bug with hashes.

bug#58561: Source hash mismatch with aggregator + possible guix bug with hashes.

[Brendan Tildesley]

I'm getting this after the recent updates:

sha256 hash mismatch for 
/gnu/store/iv6ixlrvh0swq22fjal0cbfbr9ayaq7m-akregator-22.04.3.tar.xz:
   expected hash: 1yy5c29zxpli4cddknmdvjkgii3j7pvw6lhwqfrqjc8jh83gm8f8
   actual hash: 08n713271i7ifnbrgwrqmxvcpvj45wfqjiidw8zf9rpwxg2m2m9g


However what concerned me more is that when I look in the source code it 
looks like this:

(sha256
         (base32 "9yy5c29zxpli4cddknmdvjkgii3j7pvw6lhwqfrqjc8jh83gm8f8"))


Notice how at the start its a '9', not a '1'?

I've tried with both guix pull local repo and building from source.


Is there a bug with how guix is reading/writing sha256 hashes?

bug#58561: [PATCH 1/2] gnu: akregator: Correct source hash.

['Brendan Tildesley]

From: Brendan Tildesley <mail@brendan.scot>

* gnu/packages/kde.scm (akregator): Use correct hash.
---
 gnu/packages/kde.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gnu/packages/kde.scm b/gnu/packages/kde.scm
index 1d4321237a..37125b1d0b 100644
--- a/gnu/packages/kde.scm
+++ b/gnu/packages/kde.scm
@@ -158,7 +158,7 @@ (define-public akregator
        (uri (string-append "mirror://kde/stable/release-service/" version
                            "/src/akregator-" version ".tar.xz"))
        (sha256
-        (base32 "9yy5c29zxpli4cddknmdvjkgii3j7pvw6lhwqfrqjc8jh83gm8f8"))))
+        (base32 "08n713271i7ifnbrgwrqmxvcpvj45wfqjiidw8zf9rpwxg2m2m9g"))))
     (build-system qt-build-system)
     (arguments
      `(#:phases
-- 
2.37.2

bug#58561: [PATCH 2/2] gnu: akregator: Fix build.

['Brendan Tildesley]

From: Brendan Tildesley <mail@brendan.scot>

* gnu/packages/kde.scm (akregator)[phases]: Fix finding
QtWebEngineProcess path.
---
 gnu/packages/kde.scm | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/kde.scm b/gnu/packages/kde.scm
index 37125b1d0b..d0ffb28505 100644
--- a/gnu/packages/kde.scm
+++ b/gnu/packages/kde.scm
@@ -167,9 +167,8 @@ (define-public akregator
            (lambda* (#:key inputs outputs #:allow-other-keys)
              (let* ((out (assoc-ref outputs "out"))
                     (bin (string-append out "/bin/akregator"))
-                    (qt-process-path (string-append
-                                       (assoc-ref inputs "qtwebengine-5")
-                                       "/lib/qt5/libexec/QtWebEngineProcess")))
+                    (qt-process-path (search-input-file
+                                      inputs "/lib/qt5/libexec/QtWebEngineProcess")))
                (wrap-program bin
                  `("QTWEBENGINEPROCESS_PATH" = (,qt-process-path)))))))))
     (native-inputs
-- 
2.37.2

bug#58561: [PATCH 2/2] gnu: akregator: Fix build.

[phodina via Bug reports for GNU Guix]

Hi,

unfortunately incorrect hash was pushed in the last patchset.

The patch is already part of the next patch series [1].

Also it's tracked here [2].

1 https://github.com/phodina/guix/commit/4636279dfb3b96eb5836baad0d8ea36e58ff79ee
2 https://issues.guix.gnu.org/57608#8

----
Petr




Sent with Proton Mail secure email.

------- Original Message -------
On Sunday, October 16th, 2022 at 6:33 AM, 'Brendan Tildesley <mail@brendan.scot> wrote:


> From: Brendan Tildesley mail@brendan.scot
> 
> 
> * gnu/packages/kde.scm (akregator)[phases]: Fix finding
> QtWebEngineProcess path.
> ---
> gnu/packages/kde.scm | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/gnu/packages/kde.scm b/gnu/packages/kde.scm
> index 37125b1d0b..d0ffb28505 100644
> --- a/gnu/packages/kde.scm
> +++ b/gnu/packages/kde.scm
> @@ -167,9 +167,8 @@ (define-public akregator
> (lambda* (#:key inputs outputs #:allow-other-keys)
> (let* ((out (assoc-ref outputs "out"))
> (bin (string-append out "/bin/akregator"))
> - (qt-process-path (string-append
> - (assoc-ref inputs "qtwebengine-5")
> - "/lib/qt5/libexec/QtWebEngineProcess")))
> + (qt-process-path (search-input-file
> + inputs "/lib/qt5/libexec/QtWebEngineProcess")))
> (wrap-program bin
> `("QTWEBENGINEPROCESS_PATH" = (,qt-process-path)))))))))
> (native-inputs
> --
> 2.37.2

bug#58561: [PATCH 2/2] gnu: akregator: Fix build.

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 565 bytes --]

phodina via Bug reports for GNU Guix <bug-guix@gnu.org> skriver:

> Hi,
>
> unfortunately incorrect hash was pushed in the last patchset.
>
> The patch is already part of the next patch series [1].
>
> Also it's tracked here [2].
>
> 1 https://github.com/phodina/guix/commit/4636279dfb3b96eb5836baad0d8ea36e58ff79ee
> 2 https://issues.guix.gnu.org/57608#8

Whoops, I had missed these patches and pushed similar fixes to 'master':

  8681d90d50 gnu: akgregator: Fix source hash.
  3d8c243efb gnu: akgregator: Fix build.

Sorry for the duplicate work Brendan & Petr!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

bug#58561: [PATCH 2/2] gnu: akregator: Fix build.

[Brendan Tildesley]

[-- Attachment #1: Type: text/plain, Size: 1679 bytes --]

On October 16, 2022 4:39:16 PM GMT+11:00, phodina <phodina@protonmail.com> wrote:
>Hi,
>
>unfortunately incorrect hash was pushed in the last patchset.
>
>The patch is already part of the next patch series [1].
>
>Also it's tracked here [2].
>
>1 https://github.com/phodina/guix/commit/4636279dfb3b96eb5836baad0d8ea36e58ff79ee
>2 https://issues.guix.gnu.org/57608#8
>
>----
>Petr
>
>
>
>
>Sent with Proton Mail secure email.
>
>------- Original Message -------
>On Sunday, October 16th, 2022 at 6:33 AM, 'Brendan Tildesley <mail@brendan.scot> wrote:
>
>
>> From: Brendan Tildesley mail@brendan.scot
>> 
>> 
>> * gnu/packages/kde.scm (akregator)[phases]: Fix finding
>> QtWebEngineProcess path.
>> ---
>> gnu/packages/kde.scm | 5 ++---
>> 1 file changed, 2 insertions(+), 3 deletions(-)
>> 
>> diff --git a/gnu/packages/kde.scm b/gnu/packages/kde.scm
>> index 37125b1d0b..d0ffb28505 100644
>> --- a/gnu/packages/kde.scm
>> +++ b/gnu/packages/kde.scm
>> @@ -167,9 +167,8 @@ (define-public akregator
>> (lambda* (#:key inputs outputs #:allow-other-keys)
>> (let* ((out (assoc-ref outputs "out"))
>> (bin (string-append out "/bin/akregator"))
>> - (qt-process-path (string-append
>> - (assoc-ref inputs "qtwebengine-5")
>> - "/lib/qt5/libexec/QtWebEngineProcess")))
>> + (qt-process-path (search-input-file
>> + inputs "/lib/qt5/libexec/QtWebEngineProcess")))
>> (wrap-program bin
>> `("QTWEBENGINEPROCESS_PATH" = (,qt-process-path)))))))))
>> (native-inputs
>> --
>> 2.37.2

I think the correct way is to use something like search-input-file instead ungexping qtwebengine-5, right? Input transformations well not work otherwise?

[-- Attachment #2: Type: text/html, Size: 2208 bytes --]

bug#58561: Source hash mismatch with aggregator + possible guix bug with hashes.

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

[-- Attachment #1: Type: text/plain, Size: 1609 bytes --]

Hi Brendan,

Oh!  This is a fun one!

Brendan Tildesley 写道：
> However what concerned me more is that when I look in the source 
> code
> it looks like this:
>
> (sha256
>         (base32 
> "9yy5c29zxpli4cddknmdvjkgii3j7pvw6lhwqfrqjc8jh83gm8f8"))
>
>
> Notice how at the start its a '9', not a '1'?
[…]
> Is there a bug with how guix is reading/writing sha256 hashes?

It's… not a bug.  It's the opposite, kind of, although maybe 
(probably) Guix could (should) reject clearly bogus input like 
this.

What's happening is this:

In what can be described only as a bizarre coincidence, sha256 
produces hashes that are 256 bits long.

Base32¹ encodes 5 bits per character.  Our ‘hash’ strings are 
currently 52 characters long, meaning they encode 260 bits.

If you poke around Guix, you'll notice that every valid base32 
‘sha256’ hash starts with a 0 or a 1, because those 4 leftmost 
bits are never used, and hence set to zero.

In the case of this "9…" ‘hash’ (which was random data, I guess?), 
Guix still reads only 256 bits of the 260, and ignores those 4 
‘extra’ leftmost bits.

When it later prints the hash, it converts those 256 bits back to 
base32, now padded with zeroes, and you see a ‘hash’ starting with 
1.

What Guix could do is refuse to continue when it detects set 
higher bits, as they always indicate programmer error.

Kind regards,

T G-R

1: Guix uses ‘nix-base32’ which uses a slightly different alphabet 
from the more common base32 variant, but is otherwise identical in 
operation.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

bug#58561: Source hash mismatch with aggregator + possible guix bug with hashes.

[zimoun]

Hi Tobias,

On dim., 16 oct. 2022 at 11:45, Tobias Geerinckx-Rice via Bug reports for GNU Guix <bug-guix@gnu.org> wrote:

> Oh!  This is a fun one!

Oh, cool!  Thanks for explaining. 


> What Guix could do is refuse to continue when it detects set 
> higher bits, as they always indicate programmer error.

Do you mean another linter?  Or something else?  As a field checker?


Cheers,
simon

bug#58561: Source hash mismatch with aggregator + possible guix bug with hashes.

[zimoun]

Hi,

I am also confused.

On dim., 16 oct. 2022 at 14:42, Brendan Tildesley <mail@brendan.scot> wrote:

> sha256 hash mismatch for 
> /gnu/store/iv6ixlrvh0swq22fjal0cbfbr9ayaq7m-akregator-22.04.3.tar.xz:
>    expected hash: 1yy5c29zxpli4cddknmdvjkgii3j7pvw6lhwqfrqjc8jh83gm8f8
>    actual hash: 08n713271i7ifnbrgwrqmxvcpvj45wfqjiidw8zf9rpwxg2m2m9g
>
>
> However what concerned me more is that when I look in the source code it 
> looks like this:
>
> (sha256
>          (base32 "9yy5c29zxpli4cddknmdvjkgii3j7pvw6lhwqfrqjc8jh83gm8f8"))
>
> Notice how at the start its a '9', not a '1'?


Indeed, commit 6971feca53a19d60fdd2b39fb2a8966ccf1d6598 pushed on
core-updates reads,

--8<---------------cut here---------------start------------->8---
 (define-public akregator
   (package
     (name "akregator")
-    (version "21.12.3")
+    (version "22.04.3")
     (source
      (origin
        (method url-fetch)
        (uri (string-append "mirror://kde/stable/release-service/" version
                            "/src/akregator-" version ".tar.xz"))
        (sha256
-        (base32 "1yy5c29zxpli4cddknmdvjkgii3j7pvw6lhwqfrqjc8jh83gm8f8"))))
+        (base32 "9yy5c29zxpli4cddknmdvjkgii3j7pvw6lhwqfrqjc8jh83gm8f8"))))
     (build-system qt-build-system)
--8<---------------cut here---------------end--------------->8---

> Is there a bug with how guix is reading/writing sha256 hashes?

Is it a mistake here?  A human-typo replacing ’1’ by ’9’?  Or
something else?  Petr?


Then, indeed KDE did a in-place replacement since the hash is now,

--8<---------------cut here---------------start------------->8---
$ guix download https://mirrors.xtom.de/kde/stable/release-service/22.04.3/src/akregator-22.04.3.tar.xz

Starting download of /tmp/guix-file.JTZn04
From https://mirrors.xtom.de/kde/stable/release-service/22.04.3/src/akregator-22.04.3.tar.xz...
 ….04.3.tar.xz  2.2MiB                                                            22.2MiB/s 00:00 [##################] 100.0%
/gnu/store/w4jqrza9ffsflim5ilwq7jr75rxicn1g-akregator-22.04.3.tar.xz
08n713271i7ifnbrgwrqmxvcpvj45wfqjiidw8zf9rpwxg2m2m9g
--8<---------------cut here---------------end--------------->8---

as submitted in patch#57608 [1].

1: <https://issues.guix.gnu.org/57608#1>


Cheers,
simon

bug#58561: Source hash mismatch with aggregator + possible guix bug with hashes.

[phodina via Bug reports for GNU Guix]

Hi Simon,

> Indeed, commit 6971feca53a19d60fdd2b39fb2a8966ccf1d6598 pushed on
> core-updates reads,
> 
> --8<---------------cut here---------------start------------->8---
> 
> (define-public akregator
> (package
> (name "akregator")
> - (version "21.12.3")
> + (version "22.04.3")
> (source
> (origin
> (method url-fetch)
> (uri (string-append "mirror://kde/stable/release-service/" version
> "/src/akregator-" version ".tar.xz"))
> (sha256
> - (base32 "1yy5c29zxpli4cddknmdvjkgii3j7pvw6lhwqfrqjc8jh83gm8f8"))))
> + (base32 "9yy5c29zxpli4cddknmdvjkgii3j7pvw6lhwqfrqjc8jh83gm8f8"))))
> (build-system qt-build-system)
> --8<---------------cut here---------------end--------------->8---
> 
> > Is there a bug with how guix is reading/writing sha256 hashes?
> 
> 
> Is it a mistake here? A human-typo replacing ’1’ by ’9’? Or
> something else? Petr?

It's just typo. I used mostly guix refresh for large part of the packages. Guess I updated this one manually or somehow cast wrong incantation in Vim.

Sorry for my mistake. I tried to check most of the changes I made in the patch series but this one slipped through in the many rounds of rebuilding Qt and KDE.


----
Petr

bug#58561: Source hash mismatch with aggregator + possible guix bug with hashes.

[Brendan Tildesley]

Issue was fixed and Tobias explained the hash issue.