Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: deferral dates #68

Open
vc5047 opened this issue May 2, 2024 · 2 comments
Open

Feature Request: deferral dates #68

vc5047 opened this issue May 2, 2024 · 2 comments

Comments

@vc5047
Copy link

vc5047 commented May 2, 2024

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
Copy link
Collaborator

arubdesu commented May 2, 2024

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
Copy link
Author

vc5047 commented May 2, 2024

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 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants