Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updating Trust Info for Override not working in AutoPkgr 1.6.1 #720

Open
jelockwood opened this issue Dec 3, 2024 · 7 comments
Open

Updating Trust Info for Override not working in AutoPkgr 1.6.1 #720

jelockwood opened this issue Dec 3, 2024 · 7 comments

Comments

@jelockwood
Copy link

If one selects an individual (override) recipe in the list of active recipes in AutoPkgr, there is a choice in the resulting drop down menu to update the trust for that override.

I have in the past used this successfully - likely for older versions of AutoPkgr but for a while now it has failed to work in that re-running the supposedly updated recipe will still result in a failure due to the recipe still not passing the trust test.

If however I use a command in Terminal as follows for the same override recipe it works correctly and re-running the same override recipe in AutoPkgr then passes and works as expected.

autopkg update-trust-info ~/Library/AutoPkg/RecipeOverrides/DuckDuckGo.munki.recipe 
Wrote updated /Users/myuser/Library/AutoPkg/RecipeOverrides/DuckDuckGo.munki.recipe

This suggests a problem in the current version of AutoPkgr - I am running version 1.6.1 (1509) on an Intel Mac mini using macOS 12.7.6

@shawnhonsberger
Copy link
Contributor

Thank you @jelockwood. Do you see an error message in the gui, or in the Console logs for AutoPkgr?

@jelockwood
Copy link
Author

I see the error in multiple places.

First as part of the automated email report sent by AutoPkgr

The following failures occurred:

RECIPE	MESSAGE
local.munki.DuckDuckGo	Parent recipe com.github.gilburns.download.DuckDuckGo contents differ from expected. Path: /Users/myuser/Library/AutoPkg/RecipeRepos/com.github.autopkg.gilburns-recipes/Duck Duck Go/DuckDuckGo.download.recipe
The following errors occurred:

Failed local trust verification.

Second as a dialog box displayed by the AutoPkgr GUI app.

I believe there would be a third place which would be the autopkg_results.plist file but as I have done a successful run since, this has been overwritten.

@shawnhonsberger
Copy link
Contributor

Apologies, what I meant by my question is the following: Do you see an error message when you actually the update the trust info in AutoPkgr - either in the AutoPkgr GUI, or in the Console logs for AutoPkgr?

Not when you try to run the recipe, but when you try to update the trust info. Thanks.

@jelockwood
Copy link
Author

@shawnhonsberger
Nope no errors showed in the GUI when I originally try doing the trust update in the GUI.

I did try doing the update in the GUI again just now whilst I had the (awful) Console.app running and streaming output for AutoPkgr. (I am an old fashioned syslog person.)

The only entry I spotted that seemed relevant was as follows.

default	18:24:28.187800+0000	AutoPkgr	[DEBUG] Completed AutoPkg Task:
  /usr/local/autopkg/python /usr/local/bin/autopkg update-trust-info local.munki.DuckDuckGo

However as mentioned currently the recipe is already updated via the CLI and hence 'good' so this maybe misleading.

I don't know if this would apply, the override recipe is of course a plist file, if one manipulates a plist other than via the defaults command then the cfprefsd binary may not immediately recognise a change. The defaults command when used to make changes to plist files ensures that changes are flushed to cfprefsd. (I believe an alternative less desirable approach is to kill and hence relaunch cfprefsd.)

As discussed here -

https://eclecticlight.co/2022/11/25/changing-preferences-isnt-so-simple/

@shawnhonsberger
Copy link
Contributor

Okay thank you @jelockwood. If you update an out of date repo, then update trust info for a recipe override with out-of-date trust info, then restart the computer, do you still get a trust error when running the recipe?

@jelockwood
Copy link
Author

I have not tried rebooting the Mac in this scenario. If it is related to cfprefsd then rebooting should clear the cache and resolve the problem. Next time I have this happen I will try some additional tests to see if I can test whether the values have been flushed from the cache.

A few of more things occur to me -

  1. Re-reading the entry I found from the Console debug log, it looks like you are using the AutoPkg command line to actually update the trust info, is this correct? If so I have shown manually running the AutoPkg command line to update the trust works for me.
  2. The same log entry mentioned above shows it as /usr/local/autopkg/python /usr/local/bin/autopkg update-trust-info local.munki.DuckDuckGo does this mean you are explicitly telling Python to execute the AutoPkg tool? When I do it via the command line I merely call autopkg directly and not via Python, I see the autopkg command is a python file so in theory this should not make a difference since the autopkg file via its shebang line implicitly indicates this but…
  3. Regardless of how you are updating the trust info in the recipe, do you re-read the updated recipe afterwards - ideally you would re-read every recipe when instructed to run a recipe, in my scenario I am using AutoPkgr to update the trust of that individual recipe, then using AutoPkgr to tell it to re-run that individual recipe and at that point it should re-read it. If you simply tell AutoPkg to run that recipe file then AutoPkg should be reading it fresh at that point anyway.

Is there any other log info or test you can suggest?

@shawnhonsberger
Copy link
Contributor

Thanks @jelockwood. I'd be curious what happens after a reboot.

  1. Yes, that is correct.
  2. Yes, same here when I run it on my own. However, it is not implicit in Obj-C (which AutoPkgr is built in), so we do so explicitly because it needs the full path. Agreed that it does not matter in this case.
  3. Re-reading the trust info is not done before running a recipe, because autopkg will already do so and report that back to AutoPkgr. Further, based on one's autopkg settings, this may not be desired. There may be configurations where a failure should stop a run in its tracks so that the administrator can explicitly inspect and approve or disprove the recipe override before updating trust info. Note this section from the Wiki:

When you update recipe repos, you'll also need to update the trust information in some recipe overrides. AutoPkgr now provides a way to add trust information to existing recipe overrides, however, we still recommend manually using the update-trust-info verb in AutoPkg 1.0+ for that purpose. Please note that this should only be done after inspecting the changes to the parent recipe. You can read more about recipe trust information on the AutoPkg wiki.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants