ansible_windows_working_group
LOGS
19:59:59 <nitzmahone> #startmeeting Ansible Windows Working Group
19:59:59 <zodbot> Meeting started Tue May 17 19:59:59 2022 UTC.
19:59:59 <zodbot> This meeting is logged and archived in a public location.
19:59:59 <zodbot> The chair is nitzmahone. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
19:59:59 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:59:59 <zodbot> The meeting name has been set to 'ansible_windows_working_group'
20:00:03 <nitzmahone> doh
20:00:06 <nitzmahone> #chair jborean93
20:00:06 <zodbot> Current chairs: jborean93 nitzmahone
20:00:08 <briantist> hey
20:00:11 <nitzmahone> howdy
20:00:14 <jborean93> yo
20:00:16 <nitzmahone> #info agenda https://github.com/ansible/community/issues/644
20:00:43 <nitzmahone> Nothing new there- and I haven't had time to go try to break the docs PR build isolation yet :(
20:00:49 <nitzmahone> #topic open floor
20:00:52 <briantist> 😢
20:01:19 <briantist> well, offer still stands if you want to try to pair on it or whatever, async is fine too
20:02:51 <jborean93> I've got nothing new as well, the `1.10.0` version of both collections went out last week. They are online in Galaxy and `a.w` is waiting approval on AH
20:03:32 <nitzmahone> My primary concerns are around the various pluggable behaviors in some of the tools and things like package init's in the collection loader, since "don't allow code to run" is kinda the opposite intent of the entire mechanism
20:04:26 <briantist> nitzmahone: is that related to docs build or something else?
20:04:35 <nitzmahone> yeah, docs build
20:05:29 <briantist> it's using `antsibull-docs` so not veering away from the tool currently used for building, or do you mean you have concerns with that tool?
20:05:52 <nitzmahone> Well ultimately Sphinx is still involved, yeah?
20:06:21 <briantist> ah yeah it is, though only configurable through antsibull options
20:07:46 <briantist> I do think I've put together the workflows in a way where it's safe (anything that could conceivably run arbitrary code does so with a read-only token), but I'm definitely glad to have another set of eyes on it and test those assumptions
20:07:46 <nitzmahone> I can't remember if that tool is still using the collection loader under the covers, but it used to, which also means anything that's poking around that causes a package import will also run any associated code in the package init
20:08:10 <briantist> I haven't been able to get anyone else to care about the security aspects I thought so hard about, so truly I'm glad for the scrutiny :)
20:08:48 <nitzmahone> I used to have a special mode for the collection loader that wouldn't allow it to run code at all, but it was too gnarly to configure and had some other issues, so I removed it before it got merged
20:09:25 <nitzmahone> (which would've been handy for cases like this, unfortunately)
20:11:00 <briantist> IIRC doc fragments are imported and not only AST parsed anyway, so to make a full docsite some execution has to be done unfortunately
20:11:42 <nitzmahone> Yeah, so it's even worse there- just ignoring package inits wouldn't cut it then
20:12:20 <nitzmahone> So basically any code in anything that gets imported will execute
20:12:24 <briantist> it was the doc frag part that made me originally only do the docsite sub pages (the ones written in RST already), and then to later split the process up into workflows so that a full site could be done in a way that didn't allow PR authors to execute code with a read/write token
20:13:54 <briantist> anyway, take a look when you have some time, I'm around to answer any additional questions or walk through whatever
20:14:03 <nitzmahone> Cool, thanks for your patience
20:14:19 <briantist> I don't have anything else ansible-related. Got back to making some progress on `CcgVault`, shored up testing, finished the last piece of the MSI installer, just about ready for release: https://github.com/briantist/CcgVault
20:14:45 <jborean93> nice, did you solve the repair problem you had?
20:15:49 <briantist> oh yeah I worked around the repair problem, the latest was that allow-listing a CCG plugin means making a registry entry in a key that's under Windows Resource Protection, and MSI will refuse to do so even if it has permission
20:15:58 <briantist> so that was yet another custom action needed..
20:16:23 <briantist> in the end it's not SO bad because it means I've added enough CLI commands to this thing to configure it without an installer, which could be useful... but like...
20:16:59 <jborean93> yea it doesn't sound like a fun ride
20:17:00 <briantist> what was a single line of XML to create a registry key become code modifying token privileges so I could change ownership of the parent key and all that
20:17:51 <nitzmahone> been there, done that ;)
20:17:57 <jborean93> story of my life
20:17:58 <briantist> heh yeah... was really hoping not to need p/invoke in this project
20:18:41 <briantist> truly, I think it's a mistake on Microsoft's part for that key to be under WRP but they clearly barely care about this thing being extensible to third parties
20:18:43 <jborean93> if you prefer reflection there are some nice functions you can poke at to enable privileges rather than writing it yourself
20:19:03 <jborean93> technically uses internal stuff but .NET Framework is pretty much static these days
20:19:24 <nitzmahone> Don't get me started on how trying to get a 3rd party stylus working on my Surface Pro X this weekend ended up with me tiptoeing around SFP to get the dumb thing to boot again
20:19:37 <briantist> well.. it's already written, but curious what those .net APIs are..
20:19:52 <jborean93> the latest one I found was in `System.Diagnostics.Process`
20:20:04 <jborean93> It has code to enable `SeDebugPrivilege` and can just call what that calls
20:20:17 <briantist> ahh interesting
20:20:34 <nitzmahone> I'm a little amazed that WIX et al haven't just made that standard utility code- it's come up in probably 1:3 installers I've ever had to do
20:20:55 <briantist> it's a slow moving project
20:21:01 <nitzmahone> It *never* has enough privilege to do exactly what's needed
20:21:11 <briantist> it seems like v4 has been in development/testing for many years now
20:21:33 <nitzmahone> (and keeping yourself 100% in the MSI sandbox basically doesn't work for anything but the most brain-dead projects)
20:21:47 <jborean93> maybe they've given up now that msix is being pushed by MS?
20:21:51 <briantist> the COM+ parts were cool because I thought I'd be able to just use them.. but it turns out they were never updated for dotnet 4 and just crash if your app uses it
20:21:58 <nitzmahone> Still beats the crap out of InstallShield and its ilk
20:22:42 <briantist> jborean93: maybe but it seems like one of those in-between situations where the "new" thing has a fraction of the capability but the old thing is abandoned
20:22:54 <jborean93> yea not surprising
20:23:07 <jborean93> seems like the MS Azure cmdlets go through that cycle yearly
20:23:12 <nitzmahone> (since at least the last time I tried it, it was nearly impossible to get it to give you a "clean" installer that wasn't totally bloated with all their "value-add" that makes it impossible to reason about what's happening)
20:24:24 <nitzmahone> I've never even looked at what it takes to do appx/msix packaging- thankfully hasn't come up since those didn't exist the last time I had to deal with it
20:25:34 <nitzmahone> (to date that: the last time I had to deal with it, Silverlight was still a thing people cared about)
20:26:23 <nitzmahone> Welp, if nothing else for today, we'll close in 2min
20:26:44 <briantist> silverlight... :sideye:
20:26:51 <jborean93> my only experience for msix is creating the stub packages for win_package tests
20:27:35 <nitzmahone> Yeah, though being able to run .NET code in a browser was pretty damn powerful back in the day
20:28:30 <nitzmahone> (and have it interact with JS objects and DOM objects in the page itself)
20:29:25 <nitzmahone> Alrighty, til next week- thanks all!
20:29:26 <briantist> yeah it seemed like one of the few good web developer experiences
20:29:29 <nitzmahone> #endmeeting