unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: Csepp <raingloom@riseup.net>
To: Vagrant Cascadian <vagrant@debian.org>
Cc: jgart <jgart@dismail.de>, help-guix@gnu.org
Subject: Re: How do I verify my hashes?
Date: Sun, 10 Jul 2022 12:09:29 +0200	[thread overview]
Message-ID: <87r12ti8c8.fsf@riseup.net> (raw)
In-Reply-To: <87wnclppuz.fsf@contorta>


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.


  reply	other threads:[~2022-07-10 10:13 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-10  2:12 How do I verify my hashes? jgart
2022-07-10  4:13 ` Vagrant Cascadian
2022-07-10 10:09   ` Csepp [this message]
2022-07-10 13:25 ` indieterminacy
2022-07-10 16:59   ` jgart
2022-07-14  8:52   ` Munyoki Kilyungi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r12ti8c8.fsf@riseup.net \
    --to=raingloom@riseup.net \
    --cc=help-guix@gnu.org \
    --cc=jgart@dismail.de \
    --cc=vagrant@debian.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).