Mastodawn

Hey #devops #git peeps, mind if I pick your brains for a bit?

I maintain a couple of internal GitHub repos at $Employer for various windows app install scripts (PowerShell), that are used to deploy our EDR, DLP, and other such tools. These all grew out of a script template (or if I’m feeling fancy, framework) that was meant to abstract away some differences in behavior between a couple legacy MDM platforms and our planned future platform.

Changes to these scripts fall into three gross categories:

Bumps of the app version, generally without any other changes.

Changes to the template logic.

Changes to the app-specific logic.

I’m gonna skip version changes, because they’re essentially a subclass of app-specific logic.

My workflow in developing the template generally goes something like this:

Work on an app-specific logic change.

Determine this is actually something more broadly usable than just that one app, and move the change out of the app-specific logic and into the template logic.

Increment the template version in the front-matter of the app-specific script.

Diff the app-specific script against the template, and merge in the changes in the template logic, ignoring the app specific logic (actual logic in the app script, placeholder in the template)

Diff the updated template script against each of the other app-specific scripts, and merge in the template logic, ignoring the app-specific logic (placeholder logic in the template, actual logic in the app script).

What I’m interested in is automating step 5, so that on push of an updated template version, all my scripts update too. Automating step 4, so that on push of an app-specific script containing updated template logic, the template repo gets updated would be pretty cool too.

What I don’t understand is how I could programmatically merge in only the desired changes (template logic) , and not undesirable ones (app-specific logic)?

Show thread

Buttered Jorts 6d ago

Particularly interested in anyone doing it without using Kolide. Our tech-stack at work is gonna be static for the foreseeable future, so new tooling is gonna be out. I’m most interested in doing the best we can using what’s described there as “dishonest” tools.

We’re also limited in some ways by “inheriting” security controls and implementation requirements from a couple layers of public entities, so we don’t have the freedom to say e.g. from their examples “actually it’s completely fine for you to self-manage your employer-owned device”, having an organization-controlled device management agent capable of doing lots of “dishonest” things is a hard requirement, and I think we’ll run into similar in many other cases.

Buttered Jorts 6d ago

Anybody out there actually practicing Kolide’s https://honest.security model?

Honest Security

A guide to endpoint security and device management that doesn't erode your values.

Show thread

Buttered Jorts 6d ago

To the surprise of absolutely no one who knows me, AuDHD… I think the only part that surprised them was me actually following through on the evaluation process…

Buttered Jorts Mar 24

Oh holy crap I got my diagnosis...

Buttered Jorts Mar 23

RE: https://infosec.exchange/@ajn142/116276854603521417

Click thru, Mastodon, you know you want the context…

Show thread

Buttered Jorts Mar 23

And finally, I resewed the tab of the strap that I took the old buckle off of, it’s unfair how much easier it is to push through the webbing when I’m sewing on top of the picked out machine stitches.

Show thread

Buttered Jorts Mar 23

I like you Mastodon, which is why I’ll let you see the test fit.

CW: chest hair

Show thread

Buttered Jorts Mar 23

The strap the G hook was harvested from ends with a box-stitched tab with Velcro (not pictured) sewn in so that the strap can be rolled to a fixed length. Cut the stitches there, removed the hook, and then rolled it all the way back up and Velcro’d it in place rather than do the complex stitch.

Show thread

Buttered Jorts Mar 23

The G hook fits the extended loop perfectly!