GNOME Bugzilla – Bug 750049
Reading keyring directory '/usr/share/ostree/trusted.gpg.d' No such file or directory
Last modified: 2015-06-10 16:37:34 UTC
Using the latest master and working with the remote specific GPG keyrings. I'm getting an error that /usr/share/ostree/trusted.gpg.d does not exist (which it does not). When a remote specific keyring exists, should ostree still be trying to use keyrings in this directory? I built (master) and installed by RPM: ostree-2015.6.82.gad3a47d-3.fc21.x86_64 Here are some additional information: $ cat config [core] repo_version=1 mode=archive-z2 [remote "jeff"] url=file:///opt/content/ostree/el7 gpg-verify=true tls-permissive=true $ ll total 28 -rw-r--r-- 1 apache apache 126 May 27 11:12 config -rw-r--r-- 1 apache apache 2223 May 27 11:21 jeff.trustedkeys.gpg drwxr-sr-x 258 apache apache 4096 Mar 3 15:14 objects drwxr-sr-x 4 apache apache 4096 Mar 3 15:14 refs drwxr-sr-x 2 apache apache 4096 Mar 3 15:15 state drwxr-sr-x 3 apache apache 4096 May 27 11:21 tmp drwxr-sr-x 2 apache apache 4096 Mar 3 15:14 uncompressed-objects-cache $ sudo -u apache ostree --repo=content remote gpg-import jeff -k /tmp/j.asc Imported 1 GPG key to remote "jeff" $ sudo -u apache ostree --repo=content pull jeff rhel-atomic-host/7/x86_64/standard error: Reading keyring directory '/usr/share/ostree/trusted.gpg.d' No such file or directory
Created attachment 304201 [details] [review] Proposed patch Untested, but pretty sure this should fix it.
It would make sense indeed to skip adding the global trusted keyring if a remote-specific keyring exists. This patch looks fine to me, although I'll note that if you're using the Fedora RPM package, that directory should always exist: %{_datadir}/ostree/trusted.gpg.d If it doesn't, I'm assuming you installed via "sudo make install" or similar?
Comment on attachment 304201 [details] [review] Proposed patch I've pushed this, but let's keep the bug open for skipping the global keyring if a remote has a keyring.
Roger. I need a break from the other stuff anyway. :)
Created attachment 304661 [details] [review] Followup patch Changes the policy on when to use the global keyring.
Created attachment 304670 [details] [review] Followup patch Didn't get that quite right; forgot to actually check for a remote-specific keyring file.
Review of attachment 304670 [details] [review]: I don't understand the relationship between: - A remote not having a keyring - remote_name == NULL in this code. I'm not saying it's wrong, just that I don't understand =) Can you explain? So for example, let's pretend that OS vendor ExampleOS had been doing keys in /usr/share. Their system config has set up their OS by default to have a remote with gpg-verify=true, but no remote-specific keyring. AFAICS, scan_commit_object() will call _ostree_repo_verify_commit_internal() with a non-NULL pull_data->remote_name. So wouldn't that break? I'd have expected to see some call inside ostree-repo.c like remote_keyring = remote_get_keyring() if (remote_keyring != NULL) { verify_with(remote_keyring) } else { verify_with(global_keyring)
Review of attachment 304670 [details] [review]: Ah, you even said that, yet I somehow managed to read the wrong patch! The second patch makes more sense to me. Minor, but might as well skip calling _add_keyring if the file doesn't exist. Otherwise looks reasonable to me.
Sorry for the confusion. I forgot to mark the first patch as obsolete when I submitted the second patch, and then Bugzilla wouldn't let me do it afterward. (Aside: would you be willing to add Giuseppe and I as ostree developers in Bugzilla, if only for stupid crap like that?) > The second patch makes more sense to me. Minor, but might as well skip > calling _add_keyring if the file doesn't exist. Otherwise looks reasonable > to me. Makes sense, will fix.
(In reply to Matthew Barnes from comment #9) > Sorry for the confusion. I forgot to mark the first patch as obsolete when > I submitted the second patch, and then Bugzilla wouldn't let me do it > afterward. > > (Aside: would you be willing to add Giuseppe and I as ostree developers in > Bugzilla, if only for stupid crap like that?) Done.
(In reply to Colin Walters from comment #10) > Done. Thanks! Pushed with the suggested change: https://git.gnome.org/browse/ostree/commit/?id=9f1b50d41c2704653f78735bc678f80bbe192a63