nudge: Multiple hashes in osVersionRequirements results in undefined behavior

This is somewhat similar to https://github.com/macadmins/nudge/issues/40 in that it will need major re-architecture changes to resolve.

So I found a bug with Nudge, but I’m not sure if anyone is even using Nudge in this way, and I’m debating dropping it entirely unless I can understand the benefit.

In the beginning @groob had mentioned creating a list of OS enforcements and having different rules for them, but thinking through it, I’m not sure if I like the complexity.

Let’s say you are on 11.2.1 and you set one nudge event for 11.2.2 and another event for 11.2.3. Which should we respect? Is anyone in here actually creating multiple nudge event windows right now? I just tried it and it doesn’t work. Nudge currently loops through the list and when it finds a nudge event in scope, it uses that for its logic.

What kind of use cases exist for dual nudge events? Perhaps I’m not thinking through it. I was curious to finally try it, but now that I realize it’s broken, I can’t imagine anyone has even used it.

{
  "osVersionRequirements": [
    {
      "requiredInstallationDate": "2021-03-29T00:00:00Z",
      "requiredMinimumOSVersion": "11.2.2",
      "targetedOSVersions": [
        "11.0",
        "11.0.1",
        "11.1",
        "11.2",
        "11.2.1"
      ]
    },
    {
      "requiredInstallationDate": "2021-03-15T00:00:00Z",
      "requiredMinimumOSVersion": "11.3",
      "targetedOSVersions": [
        "11.0",
        "11.0.1",
        "11.1",
        "11.2",
        "11.2.1",
        "11.2.2",
        "11.2.3"
      ]
    }
  ],
}

So in the example above, we have two different kinds of failures

If you’re on 11.2.3, since you meet or exceed the initial requiredMinimumOSVersion, you don’t get nudged - the second event doesn’t matter
If you’re on 11.2.1, you get the first Nudge event, since you’re in scope.

I keep trying to think of why you would want two nudge events and can’t really think why it would make sense, unless you you did something like this.

{
  "osVersionRequirements": [
    {
      "requiredInstallationDate": "2021-03-15T00:00:00Z",
      "requiredMinimumOSVersion": "11.1",
      "targetedOSVersions": [
        "11.0",
        "11.0.1"
      ]
    },
    {
      "requiredInstallationDate": "2021-03-17T00:00:00Z",
      "requiredMinimumOSVersion": "11.2.3",
      "targetedOSVersions": [
        "11.1",
        "11.2",
        "11.2.1",
        "11.2.2"
      ]
    }
  ],
}

But in a use case like this (say if it was March 18th), wouldn’t you really just want everyone on 11.2.3? You’d potentially punish users who are on 11.0/11.0.1, get on 11.1, only to then get nudged immediately when they login post 11.1.

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 43 (32 by maintainers)

Most upvoted comments

Ooh, I like that @natewalck!

At first I thought you’re duplicating the major version for no reason, but I realize you get a lot of flexibility if you want. To target a specific OS version with a custom rule. Maybe have a notes field or something to customize the alert for just that specific version.

groob on Aug 22, 2021

I think having a key to match on for the ruleset makes a lot of sense (Similar to what @groob mentioned).

For instance:

"updateRules": {
    "10": {
      "requiredMajorOSVersion": "12",
      "requiredInstallationDate": "2021-08-12T01:59:00Z",
    },
   "11": {
      "requiredMinimumOSVersion": "11.5.1",
      "requiredInstallationDate": "2021-08-13T01:59:00Z",
    },
   "12": {
      "requiredMinimumOSVersion": "12.0.1",
     "requiredInstallationDate": "2021-08-15T01:59:00Z",
    },
  } 
}

This could then be used for subversions too:

"updateRules": {
    "10": {
      "requiredMinimumOSVersion": "12.0",
      "requiredInstallationDate": "2021-08-12T01:59:00Z",
    },
   "11.4": {
      "requiredMinimumOSVersion": "11.5.2",
      "requiredInstallationDate": "2021-08-10T01:59:00Z",
    },
   "11.5.1": {
      "requiredMinimumOSVersion": "11.5.2",
      "requiredInstallationDate": "2021-08-24T01:59:00Z",
    },
   "12": {
      "requiredMinimumOSVersion": "12.0.1",
     "requiredInstallationDate": "2021-08-15T01:59:00Z",
    },
  } 
}

This would simplify the nudge code as you’d match against the version in the update rules dictionary and load the ruleset for that version. Then, you can have two rulesets, for instance going from 11.4 => 11.5.2 is more urgent than going 11.5.1 => 11.5.2.

For matching against the ruleset, it would be pretty straightforward too, in really janky pseudo-code:

## This should be a recursive function that either returns a ruleset or nil
curVersion = 11.4
rules = updateRules[curVersion]
if rules == nil {
  rules = rules.split('.')[-1]
}

rules = updateRules[curVersion]

Basically you try to find a ruleset for the full version, if it doesn’t exist, lop off the x.x.N number and try again. If no match, lop off x.N and try again. If you can’t match on a major version, its a configuration issue (or there is no ruleset).

There could be more fun here depending how silly the admin provided updateRules are, but it allows for more specific targeting of sub-versions of a given OS.

natewalck on Aug 22, 2021

The drawback to this approach is you can’t specify multiple requiredInstallationDate keys

What’s the advantage vs an array of dictionaries? IMO there’s a significant drawback to requiring config management/MDM to template the setting, when the client could easily decide which dictionary to pick from.

As far as major OS version deprecation, I’d be up for helping with this. We should open a different thread to discuss what that will look like.

groob on Aug 22, 2021

When you deploy new targetOS versions, the defer key is ignored and reset (as are the deferrals), so long as the new target is higher than the old target.

erikng on Aug 20, 2021