Feature Request: deferral dates

[vc5047]

First off, I love this project. Great work! Thank you!

A lot of admins implement times deferrals via config profiles, to delay the availability of updates to end users, so that they (the admins) can regression test.

It would be really cool if Sofa could calculate availability dates and add these to it's data set. This could either be a predefined default (like 30d, 45d, 60d, 90d) or even a customizable feature for self-hosting.

The way I imagine this would like like this:

in the JSON:

                {
                    "UpdateName": "macOS Sonoma 14.4.1",
                    "ProductVersion": "14.4.1",
                    "ReleaseDate": "2024-03-25T00:00:00Z",
                    "SecurityInfo": "https://support.apple.com/kb/HT214096",
                    "CVEs": {
                        "CVE-2024-1580": false
                    },
                    "ActivelyExploitedCVEs": [],
                    "UniqueCVEsCount": 1,
                    "DaysSincePreviousRelease": 18,
                    "Deferral30": "2024-04-24T00:00:00Z",
                    "Deferral45": "2024-05-09T00:00:00Z",
                    "Deferral60": "2024-05-24T00:00:00Z",
                    "Deferral90": "2024-06-23T00:00:00Z",
                },

In the GUI similar items could be added to the individual "macOS Security Updates Overview" items.

[arubdesu]

Hey @vc5047 I understand the request and would tend to agree with 90 days as that's the maximum window, it's just we have no idea how many environments primarily use which delay and kind of want to stuff the feed with so much other info this might not be the best use of 'real estate' as it were? We currently just say how many days (I wonder if the postdate key I see in the feed sometimes is the most accurate signal of exact release time? but) since each release and then you could calculate it locally...
Would you mind sharing your use case, btw?

[vc5047]

Thanks for the quick response @arubdesu! I think your thought process makes total sense and the exact dates was something I pondered on while writing up the request as well, which is why I added the "or make it customizable for self hosters", but I agree that doesn't solve the need to have a default set that would be valuable to the majority of users.

My use case is primarily the need to have a quick and complete overview of when certain updates will hit certain release groups in my environment, so that my team and I are able to make decisions on when to take action on certain releases. For example, the 14.4.0 update was going to cause a ton of issues for a sub group of my users, so we decided to manually change our deferral profiles to make sure 14.4.0 would not be available to those users and 14.4.1 would be. We then needed to make sure to revert back to our standard deployment as soon as possible (the moment 14.4.1 was covered by our standard profiles), so that we didn't accidentally make the next version of macOS available too soon. We got there with a spreadsheet, but it would be great to just have all that information on a single page. Maybe this use case is too rare and I totally see it not making sense to include in the project. I could probably use the release date provided now and make something custom for that, but I figured let's see if anyone else has this need :)

[erikng]

I think it would be better to write a simple tool to assess the sofa feed yourself and compute these days. It would be pretty simple to do in bash/zsh/python/swift/etc.

I bring this up because we are dealing with #97 and the more we manipulate dates, the more we would run into this issue. Going to close this, focus on issue 97 and people can extend for their use cases as needed within their own domain.