diff mbox series

[bug#50814,5/5] tests: Add test for .guix-authorizations and channel intro.

Message ID 20211018155734.5175-5-attila@lendvai.name
State New
Headers show
Series [bug#50814,1/5] tests: Smarten up git repository testing framework. | expand

Checks

Context Check Description
cbaines/comparison success View comparision
cbaines/git branch success View Git branch
cbaines/applying patch success View Laminar job
cbaines/issue success View issue

Commit Message

Attila Lendvai Oct. 18, 2021, 3:57 p.m. UTC
This test used to fail before a recent fix to authenticate-repository.

* tests/git-authenticate.scm: New test "signed commits, .guix-authorizations,
channel-introduction".
---
 tests/git-authenticate.scm | 150 +++++++++++++++++++++++++++++++++++++
 1 file changed, 150 insertions(+)

Comments

Ludovic Courtès Jan. 10, 2022, 2:53 p.m. UTC | #1
Hi Attila,

Sorry for dropping the ball.  On the private guix-security mailing list,
I just sent an analysis showing why the bug reported there was, AFAICS,
not a bug; however, the test here is different and seems to be poised to
expose a different problem.

Attila Lendvai <attila@lendvai.name> skribis:

> This test used to fail before a recent fix to authenticate-repository.
>
> * tests/git-authenticate.scm: New test "signed commits, .guix-authorizations,
> channel-introduction".

I won’t comment on the whole test for now, because it’s too complex, but
here’s what I noticed:


[...]

> +            (checkout "main" orphan)
> +            (add "noise0")
> +            (add ".guix-authorizations"
> +                 ,(object->string
> +                   `(authorizations
> +                     (version 0)
> +                     ((,(key-fingerprint key1) (name "Alice"))
> +                      ;; Notice that key2 is not authorized at this point.
> +                      (,(key-fingerprint key3) (name "Charlie"))))))
> +            (commit "commit 0" (signer ,(key-fingerprint key3)))
> +            (add "noise1")
> +            (commit "commit 1" (signer ,(key-fingerprint key1)))
> +            (add "noise2")
> +            (commit "commit 2" (signer ,(key-fingerprint key1))))
> +        (with-repository dir repo
> +          (let* ((commit-0 (find-commit repo "commit 0"))
> +                 (check-from
> +                  (lambda* (commit #:key (should-fail? #false) (key key1)
> +                                   (historical-authorizations
> +                                    ;; Let's mark key3 to be trusted
> +                                    ;; unconditionally, so that it authorizes
> +                                    ;; commit 0.
> +                                    (list (key-fingerprint-vector key3))))

This is exercising support for “historical authorizations”, which works
slightly differently than the regular ‘.guix-authorizations’-process
used by ‘guix pull’ & co.

> +                      (set! commit (find-commit repo commit))

Mutation is making it harder for me to understand what the test does.

> +            (with-git-repository dir
> +                ;; Drop the faulty commit 3
> +                `((reset ,(oid->string (commit-id (find-commit repo "commit 2"))))
> +                  (add "noise 4")
> +                  (add ".guix-authorizations"
> +                       ,(object->string
> +                         ;; Remove key3, add key2.
> +                         `(authorizations
> +                           (version 0)
> +                           ((,(key-fingerprint key1) (name "Alice"))
> +                            (,(key-fingerprint key2) (name "Bob"))))))
> +                  (commit "commit 4" (signer ,(key-fingerprint key2))))

Due to ‘reset’ here, the intro commit that ‘check-from’ passes to
‘authenticate-repository’ is no longer the right one (IIUC).

> +              ;; This should fail because even though commit 4 adds key2 to
> +              ;; .guix-authorizations, but commit 1 was created prior to that,
> +              ;; therefore it is not authorized.
> +              (check-from "commit 1" #:should-fail? #true)
> +              ;; This should pass, because it's a valid channel intro at commit 4
> +              (check-from "commit 4" #:key key2))
> +            (with-git-repository dir
> +                `((add "noise 5")
> +                  (commit "commit 5" (signer ,(key-fingerprint key2))))
> +              ;; It is not very intuitive why commit 1 and 2 should be trusted
> +              ;; at this point: commit 4 has previously been used as a channel
> +              ;; intro, thus it got marked as trusted in the ~/.cache/.
> +              ;; Because commit 1 and 2 are among its parents, it should also
> +              ;; be trusted at this point because of the cache.  Note that
> +              ;; it's debatable whether this semantics is a good idea, but
> +              ;; this is how git-authenticate is and has been implemented for
> +              ;; a while (modulo failing to update the cache in the past when
> +              ;; taking certain code paths).

Any commit in the closure of one of those listed in
~/.cache/guix/authentication is considered authentic.

So, if you arrange to populate that file with IDs of commits that were
not authenticated, then yes, you’ll find that ‘authenticate-repository’
reports surprising things.  But that’s because fundamentally, we cannot
protect the user from self-inflicted attacks.

To summarize, I do not see a bug here, but I’m also not sure what the
test was trying to demonstrate.

Could you boil it down?  (Keep in mind that it takes a lot of time to
merely review and under the test and claim.)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

On guix-security (in your Dec. 22, 2021, message), you provided a
different test case, showing that the introductory commit’s signature is
not verified when ‘authenticate-repository’ is asked to authenticate an
empty commit range (introductory commit = tip of the branch).  This is
due to the (null? commit) condition in ‘authenticate-repository’:

  ;; When COMMITS is empty, it's because END-COMMIT is in the closure of
  ;; START-COMMIT and/or AUTHENTICATED-COMMITS, in which case it's known to
  ;; be authentic already.
  (if (null? commits)
      '()
      (let ((reporter (make-reporter start-commit end-commit commits)))
        ;; If it's our first time, verify START-COMMIT's signature.
        (when (null? authenticated-commits)
          (verify-introductory-commit repository keyring
                                      start-commit signer))

        …))

When START = END, the (null? commits) condition is true, and thus
‘verify-introductory-commit’ is not called.  This is the “bug”, although
START = END is a situation where there’s not much to do anyway.

As I wrote, we could move the ‘verify-introductory-commit’ call before
the ‘if’, specifically for this test case, but that doesn’t strike me as
useful; it may also have a visible performance impact on real cases.

Thanks,
Ludo’.
diff mbox series

Patch

diff --git a/tests/git-authenticate.scm b/tests/git-authenticate.scm
index f66ef191b0..25b4962ea4 100644
--- a/tests/git-authenticate.scm
+++ b/tests/git-authenticate.scm
@@ -18,6 +18,7 @@ 
 
 (define-module (test-git-authenticate)
   #:use-module (git)
+  #:use-module (guix diagnostics)
   #:use-module (guix git)
   #:use-module (guix git-authenticate)
   #:use-module (guix openpgp)
@@ -28,6 +29,10 @@  (define-module (test-git-authenticate)
   #:use-module (srfi srfi-34)
   #:use-module (srfi srfi-64)
   #:use-module (rnrs bytevectors)
+  #:use-module ((rnrs conditions)
+                #:select (warning?))
+  #:use-module ((rnrs exceptions)
+                #:select (with-exception-handler))
   #:use-module (rnrs io ports))
 
 ;; Test the (guix git-authenticate) tools.
@@ -226,6 +231,151 @@  (define (correct? c commit)
                                        #:keyring-reference "master")
                  #f)))))))
 
+(unless (gpg+git-available?) (test-skip 1))
+(test-assert "signed commits, .guix-authorizations, channel-introduction"
+  (let* ((result   #true)
+         (key1     %ed25519-public-key-file)
+         (key2     %ed25519-2-public-key-file)
+         (key3     %ed25519-3-public-key-file))
+    (with-fresh-gnupg-setup (list key1 %ed25519-secret-key-file
+                                  key2 %ed25519-2-secret-key-file
+                                  key3 %ed25519-3-secret-key-file)
+      (with-temporary-git-repository dir
+          `((checkout "keyring" orphan)
+            (add "signer1.key" ,(call-with-input-file key1 get-string-all))
+            (add "signer2.key" ,(call-with-input-file key2 get-string-all))
+            (add "signer3.key" ,(call-with-input-file key3 get-string-all))
+            (commit "keyring commit")
+
+            (checkout "main" orphan)
+            (add "noise0")
+            (add ".guix-authorizations"
+                 ,(object->string
+                   `(authorizations
+                     (version 0)
+                     ((,(key-fingerprint key1) (name "Alice"))
+                      ;; Notice that key2 is not authorized at this point.
+                      (,(key-fingerprint key3) (name "Charlie"))))))
+            (commit "commit 0" (signer ,(key-fingerprint key3)))
+            (add "noise1")
+            (commit "commit 1" (signer ,(key-fingerprint key1)))
+            (add "noise2")
+            (commit "commit 2" (signer ,(key-fingerprint key1))))
+        (with-repository dir repo
+          (let* ((commit-0 (find-commit repo "commit 0"))
+                 (check-from
+                  (lambda* (commit #:key (should-fail? #false) (key key1)
+                                   (historical-authorizations
+                                    ;; Let's mark key3 to be trusted
+                                    ;; unconditionally, so that it authorizes
+                                    ;; commit 0.
+                                    (list (key-fingerprint-vector key3))))
+                    (guard (c ((unauthorized-commit-error? c)
+                               (if should-fail?
+                                   c
+                                   (let ((port (current-output-port)))
+                                     (format port "FAILURE: Unexpected exception at commit '~s':~%"
+                                             commit)
+                                     (print-exception port (stack-ref (make-stack #t) 1)
+                                                      c (exception-args c))
+                                     (set! result #false)
+                                     '()))))
+                      (format #true "~%~%Checking ~s, should-fail? ~s, repo commits:~%"
+                              commit should-fail?)
+                      ;; To be able to inspect git's state in the logs.
+                      (invoke "git" "-C" dir "log" "--reverse" "--pretty=oneline" "main")
+                      (set! commit (find-commit repo commit))
+                      (authenticate-repository repo
+                                               (commit-id commit)
+                                               (key-fingerprint-vector key)
+                                               #:historical-authorizations
+                                               historical-authorizations)
+                      (when should-fail?
+                        (format #t "FAILURE: Authenticating commit '~s' should have failed.~%" commit)
+                        (set! result #false))
+                      '()))))
+            (check-from "commit 0" #:key key3)
+            (check-from "commit 1")
+            (check-from "commit 2")
+            (with-git-repository dir
+                `((add "noise 3")
+                  (commit "commit 3" (signer ,(key-fingerprint key2))))
+              ;; This should fail because it is signed by key2, i.e. an
+              ;; unauthorized key.
+              (check-from "commit 3" #:should-fail? #true)
+              ;; Specify commit 3 as a channel-introduction signed with
+              ;; key2. This is valid, but it should warn the user, because
+              ;; .guix-authorizations is not updated to include key2, which
+              ;; means that any subsequent commits with the same key will be
+              ;; rejected.
+              (set! result
+                    (and (let ((signalled? #false))
+                           (with-exception-handler
+                               (lambda (c)
+                                 (cond
+                                  ((not (warning? c))
+                                   (raise c))
+                                  ((formatted-message? c)
+                                   (format #true "warning (expected): ~a~%"
+                                           (apply format #false
+                                                  (formatted-message-string c)
+                                                  (formatted-message-arguments c)))
+                                   (set! signalled? #true)))
+                                 '())
+                             (lambda ()
+                               (check-from "commit 3" #:key key2)
+                               (unless signalled?
+                                 (format #t "FAILURE: No warning signalled for commit 3~%"))
+                               signalled?)))
+                         result)))
+            (with-git-repository dir
+                ;; Drop the faulty commit 3
+                `((reset ,(oid->string (commit-id (find-commit repo "commit 2"))))
+                  (add "noise 4")
+                  (add ".guix-authorizations"
+                       ,(object->string
+                         ;; Remove key3, add key2.
+                         `(authorizations
+                           (version 0)
+                           ((,(key-fingerprint key1) (name "Alice"))
+                            (,(key-fingerprint key2) (name "Bob"))))))
+                  (commit "commit 4" (signer ,(key-fingerprint key2))))
+              ;; This should fail because even though commit 4 adds key2 to
+              ;; .guix-authorizations, but commit 1 was created prior to that,
+              ;; therefore it is not authorized.
+              (check-from "commit 1" #:should-fail? #true)
+              ;; This should pass, because it's a valid channel intro at commit 4
+              (check-from "commit 4" #:key key2))
+            (with-git-repository dir
+                `((add "noise 5")
+                  (commit "commit 5" (signer ,(key-fingerprint key2))))
+              ;; It is not very intuitive why commit 1 and 2 should be trusted
+              ;; at this point: commit 4 has previously been used as a channel
+              ;; intro, thus it got marked as trusted in the ~/.cache/.
+              ;; Because commit 1 and 2 are among its parents, it should also
+              ;; be trusted at this point because of the cache.  Note that
+              ;; it's debatable whether this semantics is a good idea, but
+              ;; this is how git-authenticate is and has been implemented for
+              ;; a while (modulo failing to update the cache in the past when
+              ;; taking certain code paths).
+              (check-from "commit 1")
+              (check-from "commit 2")
+              ;; Should still be fine, but only when starting from commit 4
+              (check-from "commit 4" #:key key2))
+            (with-git-repository dir
+                `((add "noise 6")
+                  (commit "commit 6" (signer ,(key-fingerprint key1))))
+              (check-from "commit 1")
+              (check-from "commit 2")
+              (check-from "commit 4" #:key key2))
+            (with-git-repository dir
+                `((add "noise 7")
+                  (commit "commit 7" (signer ,(key-fingerprint key3))))
+              ;; This should fail because key3 is not among the authorized
+              ;; keys anymore, and commit 7 is signed by it.
+              (check-from "commit 6" #:should-fail? #true))))))
+    result))
+
 (unless (gpg+git-available?) (test-skip 1))
 (test-assert "signed commits, .guix-authorizations, authorized merge"
   (with-fresh-gnupg-setup (list %ed25519-public-key-file