The changes to their whatsits are likely certificate expiration related.
For the longest time the rumor was that backward compatibility was mandated (through certificate gymnastics) by Jeff because Mackenzie had a 1st gen Kindle that she adored. I reckon nobody any longer gives a shit about that.
It's important to consider that an online service's poor behavior is amortized over it's user base (or all of the users who subscribe via the service's local copy of a given feed), so it _could_ be worse, if all those users were fetching the feed themselves.
It's also the case that a service wants to ensure they have the freshest copy or impatient users could bail somewhere else, or just do it themselves.
But, there's certainly an opportunity for a service to perform analysis on feeds to see the rate at which they're likely to have more content, as well as take cues from metadata.
At the end of the day, RSS isn't a protocol, and feed providers are just as wild west as consumers.
Tangent: I have an earnest interest in learning about methods for installing software obtained from the internet which would be any more secure than this.
The lack of consensus is on what an SBOM is for. Even the NIST recommendation which came out of Executive Order 14028 had little guidance on how to apply SBOM .
At any sort of scale, it isn't clear how an SBOM shipped with each package can be consumed to any great effect.
A central database of all dependencies, on which queries and analysis can be performed, however, can be very useful, and in a large software shop, I've seen it used to rapidly get a very real sense of the company's exposure to events like the Log4j debacle.
A Debian/Ubuntu status file is a good start (of course you need to dig further for build depends) and helpful enough for "provenance" that I've found it useful at a couple of startups to deploy code as debs packages specifically to be part of that graph - obviously not perfect, but often good enough to go automatically from CVE -> USM -> upstream package -> what part of our code cares about that - someone still has to think about the vulnerability, but it reduces a lot of obvious noise and helps drill down quicker.
A SBOM is for the producer at this time, not the consumer. It is about requiring the producers to at least try to figure out what they put into your soup. The sort of engineering 101 processes that almost all software development lacks. It is about making it possible, though not necessarily easy, for somebody to know what they are making.
The next step is exhaustiveness and automated production. At this point it will be accurate and exhaustive, but not necessarily easy to use. This is about making it possible, though not necessarily easy, for the consumer to know what they are getting.
The next step is then regularity and consistency to make it easy for the consumer to know what they are getting since it follows common, standard rules.
After that point we may get to a full reproducible build/linking manifest that allows automated validation that the SBOM matches the delivery. But this step has a good chance of fizzling out as a standard practice in general industry.
The first three are clearly where this is all going and constitute a very minor cost relative to a very outsized benefit. We might not even get to the third step, but even then at least general software development would have reached engineering 101 process sophistication which is a massive improvement over the status quo.
> A SBOM is for the producer at this time, not the consumer. It is about requiring the producers to at least try to figure out what they put into your soup.
> The next step is exhaustiveness and automated production.
There are lots of vendors selling automated SBOM generation tools/services, my company's security team is using it. Is the output correct? I don't know, they don't know, nobody looks at it. But we have SBOMs [checkmark]
Yep, that is the point of the first phase. The next phase is going to be attaching liability for incomplete SBOMs.
The way it will likely play out is that if you were breached due to a undisclosed component in a purchased product the product will either be deemed defective or the vendor will be liable. If CISA succeeds at pushing that you will see the SBOMs becoming correct and exhaustive real fast, though likely excessive due to ass-covering.
But at this point the goal is clearly just establishing a paper trail so that it can eventually be audited for consequences. Maybe they will fail at the next step due to industry pushback against actual consequences for shoddy work, but that is clearly where it is trying to go.
I'll go out on a limb and propose that end-to-end encryption and many-to-many real-time multimedia communication are two things that aren't often combined in a single product.
For the longest time the rumor was that backward compatibility was mandated (through certificate gymnastics) by Jeff because Mackenzie had a 1st gen Kindle that she adored. I reckon nobody any longer gives a shit about that.