Opened 3 months ago

Closed 3 months ago

Last modified 2 months ago

#25435 closed defect (fixed)

keyring/binutils.gpg modified by `make alpha`

Reported by: dcf Owned by: boklm
Priority: Medium Milestone:
Component: Applications/rbm Version:
Severity: Normal Keywords: tbb-rbm, boklm201803, TorBrowserTeam201803R
Cc: boklm, tbb-team Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

From commit 4bed9a85478b6fb16e0d654589d8cb8ed3865027, I ran make alpha. When it was finished, git status showed that the file keyring/binutils.gpg had changed, and left a backup file keyring/binutils.gpg~.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   keyring/binutils.gpg

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        keyring/binutils.gpg~

Child Tickets

Attachments (2)

binutils.gpg~ (25.2 KB) - added by dcf 3 months ago.
binutils.gpg (25.5 KB) - added by dcf 3 months ago.

Download all attachments as: .zip

Change History (10)

Changed 3 months ago by dcf

Attachment: binutils.gpg~ added

Changed 3 months ago by dcf

Attachment: binutils.gpg added

comment:1 Changed 3 months ago by dcf

I attached the two files. According to gpg --list-packets, the difference seems to be the addition of some :trust packet: (I don't know what that means).

$ diff -u <(gpg --list-packets binutils.gpg~) <(gpg --list-packets binutils.gpg)
--- /dev/fd/63  2018-03-05 22:01:07.388420103 -0800
+++ /dev/fd/62  2018-03-05 22:01:07.388420103 -0800
@@ -22,7 +22,9 @@
        subpkt 16 len 8 (issuer key ID C3126D3B4AE55E93)
        data: [160 bits]
        data: [157 bits]
-# off=558 ctb=89 tag=2 hlen=3 plen=289
+# off=558 ctb=b0 tag=12 hlen=2 plen=2
+:trust packet: flag=00 sigcache=03
+# off=562 ctb=89 tag=2 hlen=3 plen=289
 :signature packet: algo 1, keyid 9710B89BCA57AD7C
        version 4, created 1277536050, md5len 0, sigclass 0x10
        digest algo 2, begin of digest 57 f6
@@ -30,7 +32,9 @@
        hashed subpkt 3 len 4 (sig expires after 14d0h0m)
        subpkt 16 len 8 (issuer key ID 9710B89BCA57AD7C)
        data: [2039 bits]
-# off=850 ctb=89 tag=2 hlen=3 plen=290
+# off=854 ctb=b0 tag=12 hlen=2 plen=2
+:trust packet: flag=00 sigcache=00
+# off=858 ctb=89 tag=2 hlen=3 plen=290
 :signature packet: algo 1, keyid 9710B89BCA57AD7C
        version 4, created 1225721682, md5len 0, sigclass 0x10
        digest algo 2, begin of digest be 39
...

comment:2 Changed 3 months ago by gk

Cc: boklm added
Keywords: tbb-rbm added

comment:3 Changed 3 months ago by boklm

The only command we use with binutils.gpg should be something like this:

$ gpg --with-fingerprint --keyring ./keyring/binutils.gpg --no-default-keyring --verify ./out/binutils/binutils-2.24.tar.bz2.sig ./out/binutils/binutils-2.24.tar.bz2

Could you check if just running this command is enough to modify binutils.gpg ?

comment:4 in reply to:  3 Changed 3 months ago by dcf

Replying to boklm:

The cause seems to be the automatic --check-trustdb that gpg occasionally runs before executing a command. I think I got "lucky" and gpg decided to update the trustdb during the rbm build.

The only command we use with binutils.gpg should be something like this:

$ gpg --with-fingerprint --keyring ./keyring/binutils.gpg --no-default-keyring --verify ./out/binutils/binutils-2.24.tar.bz2.sig ./out/binutils/binutils-2.24.tar.bz2

Could you check if just running this command is enough to modify binutils.gpg ?

I did another make alpha, and this time there was no change to binutils.gpg. Likewise, with your suggested --verify command, there is no change. But if I run --check-trustdb, I get the same modified binutils.gpg and backup file.

$ gpg --with-fingerprint --keyring ./keyring/binutils.gpg --no-default-keyring --check-trustdb

The gpg manual says this:

--update-trustdb
Do trust database maintenance. This command iterates over all keys and builds the Web of Trust. This is an interactive command because it may have to ask for the "ownertrust" values for keys.
--check-trustdb
Do trust database maintenance without user interaction. From time to time the trust database must be updated so that expired keys or signatures and the resulting changes in the Web of Trust can be tracked. Normally, GnuPG will calculate when this is required and do it automatically unless --no-auto-check-trustdb is set. This command can be used to force a trust database check at any time. The processing is identical to that of --update-trustdb but it skips keys with a not yet defined "ownertrust".

So, it appears that you can use the --no-auto-check-trustdb option to avoid modifying keyring files.

comment:5 Changed 3 months ago by boklm

Cc: tbb-team added
Component: Applications/Tor BrowserApplications/rbm
Keywords: boklm201803 TorBrowserTeam201803R added
Owner: changed from tbb-team to boklm
Status: newneeds_review

There is a patch for review in branch bug_25435:
https://gitweb.torproject.org/user/boklm/rbm.git/commit/?h=bug_25435&id=ddccb0de3cceee4fc83f4508ad7cf14f3b4461c1

In this patch we add the --no-auto-check-trustdb option. At the same time, we add --trust-model always as we are not using the Web of Trust when using a keyring file.

The trust-model always options means:

Skip key validation and assume that used keys are always fully valid. You generally won’t use this unless you are using some external validation scheme. This option also suppresses the "[uncertain]" tag printed with signature checks when there is no evidence that the user ID is bound to the key. Note that this trust model still does not allow the use of expired, revoked, or disabled keys.

comment:6 Changed 3 months ago by gk

Resolution: fixed
Status: needs_reviewclosed

Looks good to me. Applied to rbm (commit db41d8e754ed8cd6cee7bca18d76d59f8f7f369b, as I fixed a typo in the commit description) and available in tor-browser-build (with commit 058b6520125e57161753d3357fcab6ecd67496bf).

comment:7 Changed 3 months ago by gk

This is commit 10b6ffd8b1168797a24934ae28944faf60d327c9 on maint-7.5.

comment:8 Changed 2 months ago by dcf

Hmm, I just had this problem again, this time with keyring/tor.gpg. These are the commits I was using:

tor-browser-build b8bae5882eac6159c8a6ad466b9dc4a7b18ba27b (actually one commit ahead, for #25579)
rbm db41d8e754ed8cd6cee7bca18d76d59f8f7f369b

I think I'll just ignore this for now, as I'm not 100% sure that the file was not modified before I started. I'll post again if it happens again.

Note: See TracTickets for help on using tickets.