[bug#41425] [PATCH 0/5] Have 'guix pull' protect against downgrade attacks

[zimoun]

On Fri, 22 May 2020 at 15:56, Ludovic Courtès <address@hidden> wrote:

> > It is not easy -- nor impossible -- to evaluate such cost at the level
> > of "guix pull".  And I failed to evaluate it using 'commit-relation'
> > with "guix repl" -- Segmentation fault with commit
> > c81457a5883ea43950eb2ecdcbb58a5b144bcd11 and
> > 4bdf4182fe080c3409f6ef9b410146b67cfa2595; probably because I did used
> > correctly the API.

Obviously, one had to read "probably I did *not* used correctly the API". :-)

> How can I reproduce the issue?

--8<---------------cut here---------------start------------->8---
(use-modules (guix git) (guix channels) (guix tests git) (git))
(define url-cache-directory (@@ (guix git) url-cache-directory))
(define dir (url-cache-directory (channel-url (car %default-channels))))
(define merge (with-repository dir repo (find-commit repo "Merge")))
merge
;; $1 = #<git-commit 4bdf4182fe080c3409f6ef9b410146b67cfa2595>
(define left (car (commit-parents merge)))
left
;; $2 = #<git-commit c81457a5883ea43950eb2ecdcbb58a5b144bcd11>
(commit-relation left merge)
Segmentation fault
--8<---------------cut here---------------end--------------->8---

Because of 'commit-closure'.
I do not know if it is the correct use of the API; and because I do
not know how to get easily a commit, I use 'find-commit' which is not
nice.


> > Well, what will be the timing impact of checking the "fast-fowardness"?
>
> I haven’t measured it, but it’s small compared to the cost of fetching
> the new revisions and performing the checkout.  It’s roughly what ‘git
> pull’ does, although ‘git pull’ is probably faster because it’s in C and
> has been well optimized over the years.

My "worry" is about the complexity of the graph because
'commit-relation' walks somehow the graph of commits.


Cheers,
simon