Script AutoPkg trust verification and trust update process


Starting with version 1, AutoPkg began evaluating trust info for recipes, so you could see what changes were made to a recipe (if changes were made) and then accept the changes if you wanted to. Here is what the typical trust verification workflow looks like.

Whether running a list of recipes via script or via AutoPkgr schedule, I’d occasionally get error’ed recipes when trust was broken, have to manually run

autopkg verify-trust-info -vv NAMEOFRECIPE
and then, after review, run
autopkg update-trust-info NAMEOFRECIPE
and then run the recipe after updating the trust info:
autopkg run -v NAMEOFRECIPE
So I thought I’d take a stab at scripting the whole process. Basically my script updates all the repos (to see if there are changes), verifies trust info on each of the recipes in the recipe list, and then prompts the user to review changes and approve them or not, before running all the approved or unchanged recipes.

It’s still in the early testing phase, but it seems to work so far….


17 responses to “Script AutoPkg trust verification and trust update process”

  1. I really like this script! But not knowing python is there a way to output the information to a log file?
    What I am currently testing is running this script daily through launchd as I took out the confirmation part so it will just run entirely through. But it would be great to save the output to a log file and then have that send to an email daily.
    So for example:
    —–
    The following recipes failed:
    local.jss.Microsoft_Office_2016_Suite_override
    Error in local.jss.Microsoft_Office_2016_Suite_override: Processor: JSSImporter: Error: Error mounting url “smb://xxxxxxxxx”
    The following packages were copied:
    Pkg Path
    ——–
    /Users/autopkgr/Library/AutoPkg/Cache/local.jss.Skype_For_Business_override/Skype For Business-16.11.149.pkg
    The following changes were made to the JSS:
    Package Categories Groups Scripts Extension Attributes Policy Icon
    ——- ———- —— ——- ——————– —— —-
    VMWare Fusion-update-smart Install Latest VMWare Fusion
    Skype For Business-update-smart Install Latest Skype For Business
    Firefox-update-smart Install Latest Firefox
    ——
    Is this possible? I have tried many different ways by researching online but still have not had any luck making it work. I know AutoPkgr has the ability to send emails, etc but at least having a log file that could be created would be great!

    Thanks in advance.

    • If you don’t do the confirmation part, there’s no reason to use this script. There’s also no reason to create your own launchd. Just install AutoPkgr, and you can use it to create a launchd that runs the list of recipes, and it has its own log.

      That said, I would highly recommend using my script with confirmation of changes. You don’t want to potentially automate malware into your software repositories, in case a recipe ever gets compromised or changed accidentally.

      • Actually to clarify while I took the confirmation part out, it is set to automatically update trust info every time it is run. My thought was to have it run every day using the launchd update.
        So right now it:
        1) Ejects any ghost drives (SMB)
        2) Updates Trust Info
        3) Runs autopkg recipes

        and then hopefully I would like to add:
        4) Output results to a log file.

        I honestly have not turned on the notification part of AutoPkgr, so I will try that to see if I can achieve the same results. I just really like how your script updates trust info. It may be overkill to always update trust info on a daily basis, but it I could run your script daily with an output of results to a log file that would be pretty awesome.

        • I’m still going to push back on this. The entire point of my script is to allow you to review new trust info and then update if necessary. If you’re never going to review the trust info, why bother updating trust info at all?

          The best thing to do then would be to revert to the default behavior of not failing recipes that don’t have trust info:

          defaults write com.github.autopkg FAIL_RECIPES_WITHOUT_TRUST_INFO -bool NO

          You’re basically doing the equivalent of “I’m never going to put dishes in the dishwasher or even run the dishwasher, but once a day, I just want the dishwasher to display a light indicating to me that it’s done not washing the dishes.”

    • Yeah, I’m really not trying to dodge here—just trying to think what would make the most sense given your situation, and if an existing tool does exactly what you want, no need to re-invent the wheel. I definitely recommend using AutoPkgr for what you want.

  2. Maybe showing my ignorance. I am using AutoPkgr to update my Munki_repo. How do I implement this script? I currently get the “WARNING: is missing trust info and FAIL_RECIPES_WITHOUT_TRUST_INFO is not set. Proceeding…” for every recipe I run.

    Suggestions greatly appreciated.

    Rick

    • Hey, Rick. Here’s what you do:

      1. Go ahead and download the script.

      2. Using a text editor like BBEdit, edit line 10 to be your actual recipe list path (for example,

      recipe_list='/Users/rick/Library/Application Support/AutoPkgr/recipe_list.txt'

      )

      3. Open up /Applications/Utilities/Terminal.app

      4. Make sure recipes fail if the trust hasn’t been verified (right now all you’re getting is a warning and not an error):

      defaults write com.github.autopkg FAIL_RECIPES_WITHOUT_TRUST_INFO -bool YES

      5. Then just go ahead and run the script:

      python /PATH/TO/SCRIPT/AutoPkgReviewAndRun.py
      • Thanks Alan. Do I then need to run the script every time I update repos or recipes? Or can I set something in AutoPkgr to run the script?

        • Well, the script itself checks for updates on the repos and runs whatever recipes are in your recipe list, but you should run the script every time you want to run all your recipes.

          There is nothing in AutoPkgr that does that allows you to approve trust changes at the moment.

          And it really isn’t something you can run in the background. The whole point of the script is to present you with recipe changes and have you double-check them before approving them.

          If you don’t want to approve changes (I highly recommend against this approach), there’s no point in running this script. You’re better off staying with the warnings (not errors) and using AutoPkgr’s built-in scheduled run.

          • I agree, I do want to approve changes. I only use the scheduled runs at my smaller installations and then only move updated packages to my approved catalog after I get the email notification from AutoPkgr. So I would run this script instead of AutoPkgr.

          • Well, I kind of try to get the best of both worlds.

            I set AutoPkg to fail recipes without verified trust info, and then I also have AutoPkgr does its regularly scheduled runs. That way, recipes that haven’t changed will still just run in the background. Recipes that have changed will just fail.

            Then, when I have a chance (several times a week or every day, depending on how busy I am), I run my script manually to see if there are any changes I need to approve, and then approve them.

  3. Hey Alan,

    I’m finally finding some time to try out the script and I think maybe I need to understand AutoPkg recipes better. When I first started using munki and autopkg I assumed that the GitHub Repo star ratings were telling me I could trust recipes in these repo’s as they all seemed to be from people that are active in the community and were trustworthy. I considered any repo with a low star rating to be “proceed with caution” and would basically only apply these recipes to my test clients before moving them to the “approved” catalog in munki.

    Then the FAIL_RECIPES_WITHOUT_TRUST_INFO change in autopkg was implemented and I’m not sure what a trusted workflow is now. When I run the script and the recipes fail. Do I then need to respond “y” and trust info will be added by the script? Or an override will be created? Or do I respond “n” and then look at the recipe and make some changes and run the script again? If so, what would I be looking for and/or change?

    At the end of the script I am getting “No trust information present.” for each recipe and “Nothing downloaded, packaged or imported.”

    I know you are busy and I have lots of questions, I’m really liking munki and all it can do for me and hope to learn from your experience. So I am going back to read more of your articles. Please feel free to point me to documentation or other resources.

    Thanks.

    • Hi, Rick.

      No, a star doesn’t indicate quality. And even for the repos that are popular and have trusted primary contributors, the whole point of the trust verification is to guard against accounts being compromised (maybe you trust me, but someone hacked into my GitHub account, for example).

      The script I have doesn’t make overrides. It just allows you to review and update trust for all the recipes in your recipe list.

      See here: https://github.com/autopkg/autopkg/wiki/Autopkg-and-recipe-parent-trust-info#general-workflow

      You do step #2, which has to happen only once per recipe.

      My script takes care of steps #3-8.

  4. I wasn’t aware that autopkg created a txt file list with every recipe I need to run. If I’m missing something, please advise. If it doesn’t do this, then every time I change recipes, I then ALSO have to update a textfile to run your script, yes?

    • AutoPkg does not create a text file list with every recipe you need to run. AutoPkgr does that, though. If you don’t want to install AutoPkgr (seems a lot to configure just to generate a list), just create a list yourself—it’s just one recipe name per line.

      And, yes, if you ran my script, you’d have to keep that recipe list updated if you wanted to add or remove recipes.

Leave a Reply to Rick Davis Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.