Note: This is for the public instance only. Private deployments will be unaffected as the code will not be removed at this time.
Background
Rekor supports a variety of entry types, or "kinds", so that clients do not need to know how to parse and canonicalize a signed artifact. The most commonly used kind is "hashedrekord", which is simply a hash of the artifact along with its signature and public key or certificate. Types like "jar" are supported so that a client can simply send a JAR and Rekor will extract the artifact hash, signature and verifier from the object.
Data
As of 4/11/2023, out of ~85 million entries in the public instance, we have:
- 4 alpine entries
- 33 rpm entries
- 112 jar entries
- 221 rfc3161 entries
- 1406 tuf entries
Checking the last integrated timestamp for each of the above kinds:
- alpine = 2022-09-23
- rpm = 2023-08-11, before that 2022-09-23
- jar = 2024-01-29, before that 2023-08-21
- rfc3161 = 2022-09-22
- tuf = 2024-04-11, it appears to be one entry every day
Alpine, RPM, and RFC3161 are effectively unused.
The last JAR upload was a test JAR, and before that, appears to have been by @sabre1041. @sabre1041, are you aware of any need to support JARs in the public infrastructure?
Based on searching GitHub for matching key IDs, the TUF file appears to be from Datadog, matching this file. @trishankatdatadog, are you aware of any reliance on the TUF metadata?
Proposed Deprecation Timeline for Public Instance
In a month or so, we will temporarily disable new entry uploads for these types and wait a week to see if there's any impact reported by the community.
Following that, we will permanently disable uploads for new entries.
Note it will still be possible to retrieve and verify old entries, just not upload new ones.
What to do instead
Move parsing logic client-side and upload hashedrekord records.
Continued code support
We won't remove these kinds from the codebase or else this would break verification for older entries. Also note that it will still be possible to deploy a private instance with these kinds enabled.
We will revisit the need for all of these types as part of a simplification of the API as part of a V2 design.
Note: This is for the public instance only. Private deployments will be unaffected as the code will not be removed at this time.
Background
Rekor supports a variety of entry types, or "kinds", so that clients do not need to know how to parse and canonicalize a signed artifact. The most commonly used kind is "hashedrekord", which is simply a hash of the artifact along with its signature and public key or certificate. Types like "jar" are supported so that a client can simply send a JAR and Rekor will extract the artifact hash, signature and verifier from the object.
Data
As of 4/11/2023, out of ~85 million entries in the public instance, we have:
Checking the last integrated timestamp for each of the above kinds:
Alpine, RPM, and RFC3161 are effectively unused.
The last JAR upload was a test JAR, and before that, appears to have been by @sabre1041. @sabre1041, are you aware of any need to support JARs in the public infrastructure?
Based on searching GitHub for matching key IDs, the TUF file appears to be from Datadog, matching this file. @trishankatdatadog, are you aware of any reliance on the TUF metadata?
Proposed Deprecation Timeline for Public Instance
In a month or so, we will temporarily disable new entry uploads for these types and wait a week to see if there's any impact reported by the community.
Following that, we will permanently disable uploads for new entries.
Note it will still be possible to retrieve and verify old entries, just not upload new ones.
What to do instead
Move parsing logic client-side and upload
hashedrekordrecords.Continued code support
We won't remove these kinds from the codebase or else this would break verification for older entries. Also note that it will still be possible to deploy a private instance with these kinds enabled.
We will revisit the need for all of these types as part of a simplification of the API as part of a V2 design.