How do I verify my hashes?

How do I verify my hashes?

[jgart]

Hi Guixers,

Today Bonface mentioned to me that I should be cloning my packages and
verifying the hashes with `git hash-object` or `git hash` iirc?

Do others do this when packaging?

My workflow currently is the lazy way:

1. I change the version in the package definition.

2. build the package

3. package blows up on stdout

4. I retrieve the hash and add it

5. profit!

But how can I trust that computed hash?

wdyt

Am I committing a newbie sin with the above workflow?

I know `guix refresh` exists but sometimes it is slowwww (e.g. outdated *.go)

I know `make go-clean` exists but sometimes it breaks things in my tree...

Should I stop worrying and just `git send-email --to="guix-patches@gnu.org" -1`?

all best,

jgart

Re: How do I verify my hashes?

[Vagrant Cascadian]

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

On 2022-07-09, jgart@dismail.de wrote:
> Today Bonface mentioned to me that I should be cloning my packages and
> verifying the hashes with `git hash-object` or `git hash` iirc?

probably "guix hash"

> Do others do this when packaging?
>
> My workflow currently is the lazy way:
>
> 1. I change the version in the package definition.
>
> 2. build the package
>
> 3. package blows up on stdout
>
> 4. I retrieve the hash and add it
>
> 5. profit!

Profit, for whom? Whoever injected the cryptocurrency malware? :P


My workflow for git-based things is typically:

1. git clone https://example.org/someproject.git && cd someproject

2. git co -b VERSION-local VERSION

3. git diff OLDVERSION..NEWVERSION

4. git clean -dfx # make sure the working tree is totally clean

5. guix hash -rx .

Step 3, even if I don't completely understand the code, I can at least
check for (problematic) license changes or maybe something "obviously"
wrong.

Similar steps for tarballs-based projects, though you may need to unpack
and/or diffoscope the sources for step 3.


I don't have a good idea how to verify pypi or similar origins... but
you could at least double-check the sources of the old and new versions
with something like:

1. guix build --source # before you update the hash

2. update version, build, get new hash, update hash ...

3. guix build --source # after updating the hash

4. diffoscope OLDSOURCE NEWSOURCE

And do a best effort check for issues...


live well,
  vagrant

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

Re: How do I verify my hashes?

[Csepp]

Vagrant Cascadian <vagrant@debian.org> writes:

> [[PGP Signed Part:Undecided]]
> On 2022-07-09, jgart@dismail.de wrote:
>> Today Bonface mentioned to me that I should be cloning my packages and
>> verifying the hashes with `git hash-object` or `git hash` iirc?
>
> probably "guix hash"
>
>> Do others do this when packaging?
>>
>> My workflow currently is the lazy way:
>>
>> 1. I change the version in the package definition.
>>
>> 2. build the package
>>
>> 3. package blows up on stdout
>>
>> 4. I retrieve the hash and add it
>>
>> 5. profit!
>
> Profit, for whom? Whoever injected the cryptocurrency malware? :P
>
>
> My workflow for git-based things is typically:
>
> 1. git clone https://example.org/someproject.git && cd someproject
>
> 2. git co -b VERSION-local VERSION
>
> 3. git diff OLDVERSION..NEWVERSION
>
> 4. git clean -dfx # make sure the working tree is totally clean
>
> 5. guix hash -rx .
>
> Step 3, even if I don't completely understand the code, I can at least
> check for (problematic) license changes or maybe something "obviously"
> wrong.
>
> Similar steps for tarballs-based projects, though you may need to unpack
> and/or diffoscope the sources for step 3.
>
>
> I don't have a good idea how to verify pypi or similar origins... but
> you could at least double-check the sources of the old and new versions
> with something like:
>
> 1. guix build --source # before you update the hash
>
> 2. update version, build, get new hash, update hash ...
>
> 3. guix build --source # after updating the hash
>
> 4. diffoscope OLDSOURCE NEWSOURCE
>
> And do a best effort check for issues...
>
>
> live well,
>   vagrant
>
> [[End of PGP Signed Part]]

Hmm, would some sort of package history command be useful here?
Maybe something that would walk the git history (fine grained) or just
previous generations of guix pull (coarse grained) and try to present
some useful changelog.

Git repos can be ginormous (ever tried cloning LLVM? yikes.) so
something that was a bit smarter and did a shallow fetch with only the
commits that are packaged would save some storage and prolong the life
of SSDs.

Re: How do I verify my hashes?

[indieterminacy]

On 10-07-2022 04:12, jgart wrote:
> Hi Guixers,
> 
> Today Bonface mentioned to me that I should be cloning my packages and
> verifying the hashes with `git hash-object` or `git hash` iirc?
> 

Bonface gives very cogent demonstrations of workflow, encourage him to 
do a screencast!

> Do others do this when packaging?
> 
> My workflow currently is the lazy way:
> 
> 1. I change the version in the package definition.
> 
> 2. build the package
> 
> 3. package blows up on stdout
> 
> 4. I retrieve the hash and add it
> 
> 5. profit!
> 
> But how can I trust that computed hash?
> 
> wdyt

Im slowly moving up the value-chain with my usage of Emacs' Git 
porceline, Magit.

IMHO, the ultimate experience would be for everything operating from 
Magit's interface - for the beneficence of Guix.

> 
> Am I committing a newbie sin with the above workflow?
> 
> I know `guix refresh` exists but sometimes it is slowwww (e.g. outdated 
> *.go)
> 
> I know `make go-clean` exists but sometimes it breaks things in my 
> tree...
> 
> Should I stop worrying and just `git send-email 
> --to="guix-patches@gnu.org" -1`?
> 
> all best,
> 
> jgart

-- 
Jonathan McHugh
indieterminacy@libre.brussels

Re: How do I verify my hashes?

[jgart]

On Sun, 10 Jul 2022 15:25:36 +0200 indieterminacy <indieterminacy@libre.brussels> wrote:
> On 10-07-2022 04:12, jgart wrote:
> Bonface gives very cogent demonstrations of workflow, encourage him to 
> do a screencast!

Bonface gave us a great demo screencast on using call-with-prompt and abort-to-prompt yesterday at the nairobilug meetup.

See #nairobilug on libera

> IMHO, the ultimate experience would be for everything operating from 
> Magit's interface - for the beneficence of Guix.

I've started using emacs' built-in vc modules for git.

See in lisp/vc/* for what's available in the emacs source repository.

I've been using it with evil-collection bindings. It's not too bad:

https://github.com/emacs-evil/evil-collection/tree/master/modes/vc-git
https://github.com/emacs-evil/evil-collection/tree/master/modes/vc-annotate
https://github.com/emacs-evil/evil-collection/tree/master/modes/vc-dir

Maybe someday I'll learn magit properly.

`vc-region-history` is not a bad `git blame` wrapper.

Re: How do I verify my hashes?

[Munyoki Kilyungi]

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

indieterminacy <indieterminacy@libre.brussels>
anaandika:

> On 10-07-2022 04:12, jgart wrote:
>> Hi Guixers,
>> 
>> Today Bonface mentioned to me that I should be cloning my packages and
>> verifying the hashes with `git hash-object` or `git hash` iirc?
>> 
>
> Bonface gives very cogent demonstrations of workflow, encourage him to 
> do a screencast!
>

I want to start online packaging/lisp-y/emacs-y
hang-outs here in Nairobi packaging meet-up thing
where we have recorded BBB sessions.  Perhaps you
may find those helpful.

>> Do others do this when packaging?
>> 
>> My workflow currently is the lazy way:
>> 
>> 1. I change the version in the package definition.
>> 
>> 2. build the package
>> 
>> 3. package blows up on stdout
>> 
>> 4. I retrieve the hash and add it
>> 
>> 5. profit!
>> 
>> But how can I trust that computed hash?
>> 
>> wdyt
>
> Im slowly moving up the value-chain with my usage of Emacs' Git 
> porceline, Magit.
>
> IMHO, the ultimate experience would be for everything operating from 
> Magit's interface - for the beneficence of Guix.
>

FWIW, Magit runs on "transient" and IIRC you can
add anything to that interface.  It was built,
just like GNU Emacs, to be extensible.

-- 
(Life is like a pencil that will surely run out,
    but will leave the beautiful writing of life.)
(D4F09EB110177E03C28E2FE1F5BBAE1E0392253F
    (hkp://keys.gnupg.net))

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