"effectively list out the recipes that adhere to the best practices and ensure these are most visible to new autopkg users"
--
You received this message because you are subscribed to the Google Groups "autopkg-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to autopkg-discu...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Issue 1 - Code Signature validation
Most modern applications now have code signing, however many recipes are not validating the code signature. While some packages cannot be properly validated (*glares at Google Chrome*), authors should at minimum check for pkg/app code signatures.
Issue 2 - Original author no longer maintaining recipes
As I've audited recipes, I have sent many PR's to recipe authors. One in particular informed me that he is no longer actively maintaining the recipes, but would gladly accept PR's. https://github.com/autopkg/justinrummel-recipes/pull/9 While this is great, we cannot ensure that recipe authors will stay within our community nor accept PRs. Perhaps our current workflow needs to re-designed.
Issue 3 - Package downloaded from insecure location.
This particular issue is less of a problem so long as Code Signature validation is present, however many of the recipes I audited had neither. Some companies also had improper CDN/proxy configurations and I could not move to HTTPS. Regardless, an author should attempt to use encryption if possible.
Issue 4 - Cleanup
Many recipes do not include any cleanup of the files that were originally downloaded. While my audit did not send PR's for fixing this, I do think recipe authors should attempt to cleanup as much as possible. runs can download a significant amount of data and within a few weeks require pruning. Cleaning up after a run would greatly help with this.
Issue 5 - Old recipes that should be abandoned.
https://github.com/autopkg/recipes/blob/master/TextMate/TextMate.download.recipe is a perfect example of a recipe that should be abandoned and possibly removed. It has no Code Signature validation nor SSL and after reaching out to the vendor, I was told there are no plans to fix these issues. The software also has many errors on modern OS X/macOS versions.
Issue 6 - Duplicate recipes
I will admit that I am guilty of this as well (https://github.com/autopkg/autopkg/issues/288). While this issue is difficult to resolve, we do need to prune the duplicates and pick the one that adheres to the best standards.
On Jul 6, 2016, at 10:27 AM, Erik <eriknico...@gmail.com> wrote:
On Jul 7, 2016, at 4:22 PM, Nick McSpadden <nmcsp...@gmail.com> wrote:This is fantastic work, but I'd like to take it a step further and add a preference to automatically reject any recipe which doesn't meet these trust guidelines.
Summary:
878 recipes audited
665 recipes with audit issues
213 recipes with no issues to report
We have a lot of work ahead of us. :)
Issue 2 - Original author no longer maintaining recipesAs I've audited recipes, I have sent many PR's to recipe authors. One in particular informed me that he is no longer actively maintaining the recipes, but would gladly accept PR's. https://github.com/autopkg/justinrummel-recipes/pull/9 While this is great, we cannot ensure that recipe authors will stay within our community nor accept PRs. Perhaps our current workflow needs to re-designed.
Issue 3 - Package downloaded from insecure location.This particular issue is less of a problem so long as Code Signature validation is present, however many of the recipes I audited had neither. Some companies also had improper CDN/proxy configurations and I could not move to HTTPS. Regardless, an author should attempt to use encryption if possible.
Issue 4 - CleanupMany recipes do not include any cleanup of the files that were originally downloaded. While my audit did not send PR's for fixing this, I do think recipe authors should attempt to cleanup as much as possible. runs can download a significant amount of data and within a few weeks require pruning. Cleaning up after a run would greatly help with this.
Issue 5 - Old recipes that should be abandoned.https://github.com/autopkg/recipes/blob/master/TextMate/TextMate.download.recipe is a perfect example of a recipe that should be abandoned and possibly removed. It has no Code Signature validation nor SSL and after reaching out to the vendor, I was told there are no plans to fix these issues. The software also has many errors on modern OS X/macOS versions.
I think this goes back to the discussion about which elements of an audit are "obvious" fixes and which are just things the consumer of a given recipe should be aware of.
On Jul 8, 2016, at 10:04 AM, Mr. Alan Siu <as...@siprep.org> wrote:I think this goes back to the discussion about which elements of an audit are "obvious" fixes and which are just things the consumer of a given recipe should be aware of.Yes, I'd definitely want to know, of the recipes I could potentially use, which ones are essentially unfixable (there is no version 2 to use code signature verifier on and/or no available https download location) and which ones are just yet-to-be-fixed.For the latter, I'd have the option to even make a pull request. The former would just waste my time to investigate if the recipe maintainer had already looked into https and code signature verification.
I have rerun the audit and as of a few minutes ago here is the status of _all_ .download.recipes across the entire autopkg recipe base.
Summary:
1182 recipes audited
914 recipes with audit issues
268 recipes triggered no audit flags
On Jul 7, 2016, at 4:06 PM, Gregory Neagle <gregn...@mac.com> wrote:I have some ideas on how we could do this in a reasonably secure manner such that future changes to that processor would cause the warnings to resurface.Here's my thinking:The admin could add additional data to a recipe override (some of this might be done automatically by `autopkg make-override` eventually):1) Each parent recipe could be explicitly listed, along with a checksum. As long as the checksum for each parent recipe doesn't change, the parent recipes would be "trusted".2) Each non-core processor used by the recipe (or its parents) could be explicitly listed, also with a checksum. Again, as long as the checksum does not change, the non-core processor would be "trusted".Trusting the parents and the non-core processors would be a manual option -- the admin would use a command to add this information to a recipe override. When `autopkg audit` runs, it would use this additional data to decide whether or not to warn about a potential issue for a given recipe.Eventually, the audit mechanism might be tied into the `repo-add` and `repo-update` verbs to either automatically do an audit when repos are added or updated, or at least to remind the admin that it's a good idea to do an audit.
--
You received this message because you are subscribed to the Google Groups "autopkg-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to autopkg-discu...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
On Jul 21, 2016, at 4:40 PM, Gregory Neagle <gregn...@mac.com> wrote:My current experiments around parent recipe trust verification are available here:https://github.com/autopkg/autopkg/tree/recipe-checksumming`autopkg make-override Foo.recipe` "automagically" adds parent recipe trust verification info to the override.`autopkg verify-trust-info some.recipe` verifies the trust info`autopkg update-trust-info some.recipe` updates existing trust info or adds it if there is none. It's meant to be used on recipe overrides, but might be useful on any child recipe.`autopkg run some.recipe` will fail a given recipe if trust verification fails. this can be overridden by adding --ignore-parent-trust-verification-errors
autopkg update-trust-info ~/Library/AutoPkg/RecipeOverrides/*.recipe
autopkg repo-update all
autopkg verify-trust-info ~/Library/AutoPkg/RecipeOverrides/*.recipe
Parent trust info verification failed for /Users/gneagle/Library/AutoPkg/RecipeOverrides/LibreOffice.munki.recipe
Could not verify trust of parent recipes and custom processors:
Expected non-core processor list: [u'LibreOfficeURLProvider']Actual non-core processor list: []Our stored checksum for processor LibreOfficeURLProvider does not match the current content of that processor.Perhaps processor LibreOfficeURLProvider has been changed.Processor path: NoneOur stored checksum for parent recipe io.github.hjuutilainen.download.LibreOffice does not match the current content of that recipe.Perhaps parent recipe io.github.hjuutilainen.download.LibreOffice has been changed.Recipe path: /Users/gneagle/Library/AutoPkg/RecipeRepos/com.github.autopkg.hjuutilainen-recipes/LibreOffice/LibreOffice.download.recipediff --git a/LibreOffice/LibreOffice.download.recipe b/LibreOffice/LibreOffice.download.recipeindex d0ee986..16f0765 100644--- a/LibreOffice/LibreOffice.download.recipe+++ b/LibreOffice/LibreOffice.download.recipe@@ -3,17 +3,18 @@<plist version="1.0"><dict><key>Description</key>- <string>Downloads the latest LibreOffice.</string>+ <string>Downloads the latest LibreOffice. Set RELEASE to either "fresh" or "still".++LibreOffice Still is the stable version that has undergone more testing (over a longer time). It is usually recommended for more conservative use.+LibreOffice Fresh is the stable version with the most recent features. Users interested in taking advantage of our most innovative features should download and use our fresh version.</string><key>Identifier</key><string>io.github.hjuutilainen.download.LibreOffice</string><key>Input</key><dict><key>NAME</key><string>LibreOffice</string>- <key>TYPE</key>- <string>mac-x86_64</string>- <key>USER_AGENT</key>- <string>Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/536.28.10 (KHTML, like Gecko) Version/6.0.3 Safari/536.28.10</string>+ <key>RELEASE</key>+ <string>fresh</string></dict><key>MinimumVersion</key><string>0.2.0</string>@@ -21,11 +22,13 @@<array><dict><key>Processor</key>- <string>LibreOfficeURLProvider</string>+ <string>URLTextSearcher</string><key>Arguments</key><dict>- <key>type</key>- <string>%TYPE%</string>+ <key>re_pattern</key>+ <string>(?P<DOWNLOAD_URL>download.documentfoundation.org/libreoffice/stable/[\d\.]+/mac/x86_64/LibreOffice_(?P<version>[\d\.]+)_MacOS_x86-64.dmg)</string>+ <key>url</key></dict></dict><dict>@@ -33,11 +36,8 @@
<string>URLDownloader</string><key>Arguments</key><dict>
- <key>request_headers</key>- <dict>- <key>user-agent</key>- <string>%USER_AGENT%</string>- </dict>+ <key>url</key>+ <string>https://%DOWNLOAD_URL%</string></dict></dict><dict>Our stored checksum for parent recipe io.github.hjuutilainen.munki.LibreOffice does not match the current content of that recipe.Perhaps parent recipe io.github.hjuutilainen.munki.LibreOffice has been changed.Recipe path: /Users/gneagle/Library/AutoPkg/RecipeRepos/com.github.autopkg.hjuutilainen-recipes/LibreOffice/LibreOffice.munki.recipediff --git a/LibreOffice/LibreOffice.munki.recipe b/LibreOffice/LibreOffice.munki.recipeindex b60ec1c..6205d83 100644--- a/LibreOffice/LibreOffice.munki.recipe+++ b/LibreOffice/LibreOffice.munki.recipe@@ -3,13 +3,18 @@<plist version="1.0"><dict><key>Description</key>- <string>Downloads the current release version of LibreOffice and imports into Munki.</string>+ <string>Downloads the current release version of LibreOffice and imports into Munki. Set RELEASE to either "fresh" or "still".++LibreOffice Still is the stable version that has undergone more testing (over a longer time). It is usually recommended for more conservative use.+LibreOffice Fresh is the stable version with the most recent features. Users interested in taking advantage of our most innovative features should download and use our fresh version.</string><key>Identifier</key><string>io.github.hjuutilainen.munki.LibreOffice</string><key>Input</key><dict><key>NAME</key><string>LibreOffice</string>+ <key>RELEASE</key>+ <string>fresh</string><key>MUNKI_REPO_SUBDIR</key><string>apps/LibreOffice</string><key>MUNKI_CATEGORY</key>
autopkg run LibreOffice.munkiProcessing LibreOffice.munki...
Failed.The following recipes failed:
LibreOffice.munki
Could not verify trust of parent recipes and custom processors:
Expected non-core processor list: [u'LibreOfficeURLProvider']Actual non-core processor list: []<etc>
./autopkg verify-trust-info AdobeFlashPlayer.munki
AdobeFlashPlayer.munki: NO TRUST INFO
Currently an autopkg run will not warn the admin that the override doesn't contain trust information.
2. Perhaps a new preference: RequireOverrideTrustInfo. If someone attempts to remove the trust information from an override, autopkg will refuse to run that particular override. Perhaps this key would also require each recipe that is ran to have an override, containing the trust info. You would not be able to run the default recipes.
3. The git diffs will only work if you are using autopkg repo-add. If you are managing repos and ignoring each recipe repo's own git information, this information will not be generated. I think for the few people doing something like this, that will be OK.
Other than that, it looks really good.
-Greg