AutoPkgr for Dummies 2: Trust your recipes

So you've set up AutoPkgr. Good job! But now you're like "why do I keep getting these FAIL_RECIPES_WITHOUT_TRUST_INFO errors"? Something I didn't cover in my previous guide is the introduction of verifying and trusting recipes in autopkg 1.x (because that didn't exist at the time). From the introduction to this feature:

AutoPkg encourages the use of recipes created and shared by others. You can leverage the hard work done by other admins without having to re-invent the wheel yourself. You can add "repos" of other people's recipes using the autopkg repo-add command.

But there is an element of risk in using other people's recipes -- a bad actor could create a malicious recipe, or a well-meaning admin could introduce an error into a recipe that causes unexpected issues.

You should audit any third-party recipes you use, especially if you do not know the recipe creator/maintainer. This means becoming familiar enough with AutoPkg recipes to be able to read and understand them.

By default, AutoPkg (and by extension, AutoPkgr) will stop runs for recipes without trust info set. To set trust info, you need to create a recipe override and store that trust info in your override. The override recipes should then be the recipes you run on a schedule with AutoPkgr. Here's a quick overview on how that works.

For this example we'll set up a recipe override with trust info for a Google Chrome pkg recipe.



As you can see above, I have my AutoPkg folders set within /Users/Shared/AutoPkg for the Cache (where packages are store), repos (the source information of the recipes), and recipe overrides. These are the folders I'll want to keep an eye on when I create my recipe override.

We'll use the AutoPkg CLI to search for the Chrome recipe. You can also do this in AutoPkgr as I showed in my last AutoPkgr post. But why not try something new? A search for Chrome recipes is as simple as typing:

autopkg search googlechrome

There will be a lot of results, and in the middle column is the name of the repo that the recipe comes from.



And conveniently at the end of the results it mentions how to add the repo that houses the recipe. It looks like the primary recipes repo for AutoPkg has a GoogleChrome.pkg recipe, so we'll add that repo:

autopkg repo-add recipes



Now that we have the repo cloned, you'll see all of the recipes within the repo in your /RecipeRepos folder.



And at this point you have to ask yourself: do you feel lucky, punk? Err, do you trust this recipe? If so, it's time to make your override and set the trust info. First, create your override.

autopkg make-override GoogleChrome.pkg



Your recipe override will be in the /RecipeOverrides folder.



I would recommend taking this opportunity to rename your override recipe and update the identifier information inside. If you get hit by a bus or win the lottery and buy yourself an island make sure you leave a good legacy behind. If you name the recipes with an organizational title it'll help your future colleagues know that recipe override was established for organizational use. It's just a nice thing to do. The other bonus is renaming them something unique to you/your organization is that it makes those recipes easier to find in an AutoPkgr search.



I used nano because I didn't bother to install a text editor on my VM, but if you're a sane individual I'd recommend using an application like Atom or Sublime Text. Now that you have your recipe override, you can set your trust of the recipe.

autopkg update-trust-info YourRecipeOverride.pkg



You have now specified that you trust the recipe, and it will run and build for you. Good job, BUB.

If you close and reopen AutoPkgr, you'll be able to find your override in the app and add it to your scheduled runs.

And there you have it. 

Note that periodically the repos/parent recipes get updated, and when that happens you may need to reestablish the trust settings on the recipes. This is a good thing. You should be evaluating your recipes periodically to confirm they are building packages you are comfortable deploying in your environment. I still highly recommend evaluating the packages by either testing them in a VM/test machine or using something like Suspicious Package to check the contents prior to deployment.

Note: This more or less aligns with the general workflow described in the AutoPkg documentation. If you have other questions or run into issues please ask in the #autopkg channel on the MacAdmins Slack.