USN dashboard page lists related USNs for USN-4754-4. Can related USNs be made available security/notices.json and/or security/notices/{notice_id}.json

[blackboxsw]

Summary

Looking to inform ua fix <USN> callers about related USNs in the event they try fixing an inapplicable USN for their environment but where a related USN did affect their system.

In the case where a customer tries to fix `usn-4754-4 on a trusty/hirsute/groovy system, USN..-4 only represents Xenial and Bionic fixes. But USN-4754-1 does represent T, X, B, F, G,H releases and we could better inform them to check related USNs or ua client could check this itself to better fix this USN on a system.

USN-4754-4 vs USN-4754-1 are examples of partial ubuntu support matrices curl -X GET curl https://ubuntu.com/security/notices/USN-4754-4.json | jq .

Trusty, hirsute, groovy components are represented here

curl -X GET curl https://ubuntu.com/security/notices/USN-4754-1.json | jq .

Without this USN relationship response from the USN API routes, API consumers would need to make additional API requests to each CVE in order to obtain the related USNs from the CVE.

Process

[List the steps to replicate the issue.]

Current and expected result

Would like to see a something like a related_notices key in usn responses.

This related is already published somehow on USN landing pages under "Related notices" https://ubuntu.com/security/notices/USN-4754-1

[albertkol]

@blackboxsw

On the website we do have the notion of related notices, which for the API I decided not to include.

I can add related_notices, but before that I want to explain how the thing works on the ubuntu.com website, to confirm that that's what you want.

related_notices is a list of all notices of all the cves affected by the USN you are looking at. So it's not only USN-4754-X. It does not pattern check the id of the USN.

Are you happy with how the related_notices works on ubuntu.com, should I just copy that implementation? Or... would you want me to send all USNs that have similar id? Ex: If you look at USN-1234-1, I send you all USNs whose ids follow the pattern USN-1234-X?

[blackboxsw]

Thanks @albertkol I talked with Rick and our ultimate goal is to fix any and all packages related to a usn (or all it's remotely related USNs). Since we need to query the CVE directly anyway from a USN to get package release status information. The UA client can relay on CVE.notices in metadata and won't necessarily need to have a USN.related_notices list. I see this feature request as a nice optimization, but might be unnecessary in practce.

Feel free to address or close as you see fit, having a full set of all USNs regardless of pattern is reasonable in either case. UA client will plan on filtering to the proper subset if the need arises.

[albertkol]

@blackboxsw

It seems like related_notices is not that necessary and I do not want to add it just for the sake of adding it.

But it sounds like it would be useful for the USN to return you all its CVEs payload. Would that not spare you from making those additional api calls?

I was thinking that maybe I can change the current cves to return you the complete CVE payload... and not sure if you would still need an array for CVE ids, but if you do I can have a separate cves_ids array. Similarly for CVEs I can have notices return all the Notices' payload and notices_ids the array of the ids.

Would that be helpful?

[blackboxsw]

@albertkol yes definitely good suggestion. If we can get the full CVEs payload instead of just the IDs, that would save the client a significant set of round trips.

[albertkol]

@blackboxsw

I have the PR ready to be merged, but I hesitate on merging it because I think it will break stuff on your end.

I changed it so that cve.notices and notice.cves return you the full payload. I added cve.notices_ids and notice.cves_ids to return the array of ids (what cve.notices and notice.cves used to return)

How much would this solution impact you guys?

Would you rather have me keep cve.notices and notice.cves as they are and provide you the full payload under not sure.. cve.notices_details and notice.cves_details?

I thought the key names would look nicer as I implemented them, but if it's too much work on your end then it's maybe not worth it.

======

Separately, I have added as part of this PR a show_hidden flag for CVE endpoints. The feature 1 we discussed a while ago.

[blackboxsw]

This PR looks good @albertkol if there is a way to land it an only roll out the change to staging.ubuntu.com that would be great and we can test it against the changes we need on our side. Just let us know here, in email or Matter Most when you have landed the related PR in staging. +1

[blackboxsw]

@albertkol sorry, to answer specifcally,

How much would this solution impact you guys?

UA Client at the moment only uses the notices.json?details= first and then and the specifically the cve/.json based on USN.cve [, ]

So, adding anything to cve/*json metadata won't break anything. Changing output of USN.cves to be dicts of CVE data instead of CVEIDs would break us, but this is a breaking change in this API prior to any public release and I'd like to see us fix that before first release.

Would you rather have me keep cve.notices and notice.cves as they are and provide you the full payload under not sure.. cve.notices_details and notice.cves_details?

I thought the key names would look nicer as I implemented them, but if it's too much work on your end then it's maybe not worth it.

Like you, I also prefer the simple USN.cves and CVE.notices being the full payload of each related cve or notice, it makes sense to me.

We can worry about breaking API changes once UA fix is SRU'd into Xenial/Bionic/Focal etc :). Thanks for the heads up and blocking on landing this until we were ready. Either way you decide to go with this just let us know when we can test on staging.ubuntu.com and we'll validate and get a quick fix in place before we roll to production.