SPEC: Lifecycle dates in TEA leaf

[ppkarwasz]

The current OpenAPI spec only provides an end_of_life date for a TEA leaf. This single date might be a little bit reductive. While the CLE specification provides a lot of dates, for the purpose of TEA IMHO two dates should be reported:

• the end of security updates: after this date no further releases of the TEA leaf will appear. Users still can continue using that version with a slightly increased risk. If something happens, they will need to upgrade to a newer leaf of the same product.
• the end of security checks: after this date the producer will not even accept new security reports for that leaf nor check if this leaf is affected by CVEs of other leafs of the same product. This is the real End-of-Life.

In Apache Log4j leafs will correspond to MINOR versions (2.23.x, 2.24.x, …). Since we are very strict on what constitutes a minor version bump (a single new public method in a public package forces a minor version bump), we have minor releases every 3 to 6 months. Security updates are only published for the latest minor version. In practice this mean that 90% of our user base is on a TEA leaf with no security updates.

I think that it is fine for user to miss the end of security updates (especially when semver is involved), but tools like Dependency Track could take that into account and:

• warn a user, if he uses a TEA leaf with no security updates,
• warn a user, if he uses an outdated version of a TEA leaf with security updates (the patch release might be a security update not yet announced),
• don't warn a user, if he uses the latest patch release of a TEA leaf with security updates.

transparency-exchange-api/spec/openapi.json

Lines 997 to 1038 in 6b90fd4

	"tea_leaf": {
	"type": "object",
	"properties": {
	"identifier": {
	"$ref": "#/components/schemas/type_uuid"
	},
	"product_name": {
	"type": "string"
	},
	"product_version": {
	"type": "string"
	},
	"release_date": {
	"type": "string",
	"format": "date-time",
	"example": "2024-03-20T15:30:00Z"
	},
	"pre_release": {
	"type": "boolean"
	},
	"end_of_life": {
	"type": "string",
	"format": "date-time",
	"example": "2024-03-20T15:30:00Z"
	},
	"collection_references": {
	"type": "array",
	"items": {
	"$ref": "#/components/schemas/type_uuid"
	},
	"description": "Array of UUIDs referencing TEA Collection entries",
	"default": []
	}
	},
	"required": [
	"identifier",
	"product_name",
	"product_version",
	"release_date",
	"pre_release"
	]
	},

[madpah]

I think this is a fascinating observation @ppkarwasz.

I wonder whether this is restricted purely to "security" updates as you explained - for COTS (Commercial Of The Shelf) Software, this might be phrased more in terms of:

• Last date updates will be provided
• Extended Support End Date
• etc..

This possibly is a broader question to consider.

FYI @oej

[oej]

The work to enumerate this is happening elsewhere - in the CLE. We need to have a CLE object somewhere, I think it's in the leaf. It may also be an attestation. If so, I want a flag in the LEAF indicating something along the lines "STAY AWAY FROM USING THIS RELEASE!!!!"

[madpah]

Is there any output from the CLE Working Group at this time @oej ? Anywhere we can cross-reference yet?

[oej]

Not really. Need to jump into one of their meetings to check their time plan.

[ppkarwasz]

The CLE workgroup has a working Google Doc.

There is also a preregistered cdx:lifecycle Namespace Taxonomy that you can use in CycloneDX documents. The Taxonomy is administered by the CycloneDX Core Working Group.