Include app functions in the module, or move outside of the module

[aaronparker]

All application functions are currently included in the module, meaning that new apps, updates and fixes for apps require a new version of the module. This can be useful for sticking to a specific version of the module if there's an issue with an app function.

However, including app functions in the module increases the time to add new apps or fix existing apps. If app functions were separating from the core Evergreen function, and downloaded as required, updates to apps should, in theory, be faster. Apps could be synchronised from a repository with something like Update-Evergreen.

Either approach works and has advantages and disadvantages.

[chezzer64]

I currently customise Evergreen Apps (create additional Get-xxx.ps1 + corresponding manifest) so that I can benefit from Evergreen Libraries for all my managed apps. This allows me to have Evergreen Library support for all the apps supported by the Nevergreen module, along with my own list of non-Evergreen (Static) Apps. Assuming that moving the App Functions outside of the Module wouldn't mean that my use case was no longer supported, then I'd be happy for the proposal to go ahead.

[BornToBeRoot]

Some thoughts from me...

1. I run a script in Azure Automation Runbook that checks my Intune Apps agains Evergreen for available updates and send a notifcation to a teams channel.

In Azure Automation you install the module inside the Automation Account. I'm not sure how the application files are cached in such a scenario. Or you need to always update it in the script... this would be a breaking change?!
Similar if you use something like GitLab Runner / GitHub Actions... but here you have the option to configure a cache.

2. You may have a security risk if you download the manifest and especially powershell script files. It is possible that code could be executed here via man-in-the-middle. The download process must be secured accordingly (signing?).

---

I think it's a good idea in principle. Makes updating / adding applications faster. Winget or choco work in a similar way.

[aaronparker]

I need to look at a code signing certificate at some stage. Otherwise, my current thought so far is to sync via a GitHub repo so that hashes can be compared the repo and what's downloaded.

[BornToBeRoot]

For code signing, I am currently testing SignPath.io for my own app, which provides a certificate for OSS.
https://about.signpath.io/
https://signpath.org/
You need to build the artifacts via AppVeyor and then sign it with a webhook agains signpath.

---

Certum also provides a cheap (compared to other vendors...) certificate for OSS.

[aaronparker]

Thanks