Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
AutoPkg and recipe parent trust info
AutoPkg 1.x expects you to verify and trust the recipes you run. This is new behavior compared to the 0.x releases.
Make overrides for every recipe you run. Run
autopkg update-trust-info override_name to add trust info to any existing override.
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.
An additional issue: Vendors make changes to their software, packages, and download sites, which can cause recipes to break over time. AutoPkg is designed to make it easy to "pull" updated shared recipes using the
autopkg repo-update command. Some admins run
autopkg repo-update all to easily update all of the recipes they may have added. But this could be risky.
A bad actor could initially share an innocuous recipe that behaves exactly as expected, and then later update the recipe to do something malicious, hoping you won't notice the changes. Ideally, AutoPkg admins should re-audit any changed recipes they use, but when doing
autopkg repo-update all might be overwhelmed with the huge number of mostly-irrelevant changes to sift through.
Parent Trust Info
AutoPkg 1.0 introduces a new mechanism and some new tools to help with these issues. When creating a recipe override, certain information about the parent recipe(s) and the processors they use is stored in the recipe override. If a parent recipe or the non-core processors used by the parent recipes change after the override is created, running the recipe override will fail with an error. This is your cue to audit the changes for that recipe to make sure nothing unexpected has been introduced.
Storing Trust Info
Parent recipe trust info is stored when creating a new recipe override with
autopkg make-override some_recipe_name. You can add or update parent recipe trust info for an existing recipe override with
autopkg update-trust-info some_recipe_name.
Verifying Trust Info
If there is trust information stored for a recipe, it is automatically verified every time you run the recipe. You can also manually verify trust information with
autopkg verify-trust-info some_recipe_name. The default output is very brief and simply indicates success or failure to verify. Add one or more
-v flags to the command to get additional detail about why verification fails. If you wish to verify a list of recipes that you have stored in a text file (e.g., AutoPkgr users), use the
--recipe-list option with the path to the text file.
Making trust verification more strict
By default, if a recipe override does not have any trust info stored (or you attempt to run a shared recipe without an override), it will run after printing a brief warning.
autopkg run MakeCatalogs.munki Processing MakeCatalogs.munki... WARNING: MakeCatalogs.munki is missing trust info and FAIL_RECIPES_WITHOUT_TRUST_INFO is not set. Proceeding...
You can make AutoPkg refuse to run shared recipes that do not have any trust info by setting FAIL_RECIPES_WITHOUT_TRUST_INFO. You can do that in AutoPkg's preferences:
defaults write com.github.autopkg FAIL_RECIPES_WITHOUT_TRUST_INFO -bool YES
or at the command-line using the
autopkg run OracleJava10.munki -k FAIL_RECIPES_WITHOUT_TRUST_INFO=yes
Note: If you have enabled FAIL_RECIPES_WITHOUT_TRUST_INFO using AutoPkg's preferences, you cannot override that setting when running a recipe from the command line using
-k FAIL_RECIPES_WITHOUT_TRUST_INFO=no. If you wish to turn off trust verification for a short while (e.g., while testing new or changed recipes), you may either disable the appropriate AutoPkg preference for the duration required:
defaults write com.github.autopkg FAIL_RECIPES_WITHOUT_TRUST_INFO -bool NO
or use this syntax at the command line on each run (substituting the recipe name in question):
autopkg run OracleJava10.munki -k FAIL_RECIPES_WITHOUT_TRUST_INFO=""
Here's the big picture, "normal" workflow using the new tools.
- Admin adds a new recipe repo because he/she is interested in running a specific recipe, which we'll call Foo.pkg.recipe. He or she examines and tests the recipe to be sure it behaves as expected.
- Admin creates an override for the recipe with
autopkg make-override Foo.pkg.recipe. This indicates the admin trusts the current set of parent recipes and custom processors used by Foo.pkg.recipe. He or she may optionally override some of the values in the INPUT dictionary of the override.
- Admin runs the override, either individually, or as part of a recipe list.
- Admin later updates one or more (or all) recipe repos, using
autopkg repo-update. The parent Foo.pkg.recipe has been updated by the original author.
- On the next run of Foo.pkg.recipe, the run is stopped with an error because the parent has changed since it was last trusted.
- The admin notes this trust verification error and uses
autopkg verify-trust-info -vv Foo.pkg.recipeto get additional detail. He or she uses this information, also possibly directly reviewing the recipe(s) and custom processors, to be sure nothing unexpected has been introduced into the recipe.
- The admin then updates the stored trust information for the recipe with
autopkg update-trust-info Foo.pkg.recipe.
- The admin can now once again successfully run Foo.pkg.recipe.
Parent trust info provides a mechanism by which the AutoPkg admin can be alerted to changes in the shared recipes he or she uses. AutoPkg will alert the admin upon any changes to the parent recipes and/or custom processors used by the recipe.