ppkarwasz commented on issue #614: URL: https://github.com/apache/tooling-trusted-releases/issues/614#issuecomment-3917250400
> 1. How is the `uuid` generated? That is pretty much up to the implementation. Right now the `uuid`s must be unique for each object type, but it would make sense to have uniqueness at the TEA server level. Note that both the Component and each Component Release have a `uuid`. For the Component Release this would allow for each RC to have the same version number, but a different `uuid`. > 2. Is there room for extended metadata as is currently in DOAP. (See [Project metadata to add to project database #455](https://github.com/apache/tooling-trusted-releases/issues/455) and others I lack a clear rewrite of the schema.) Currently not, but feel free to open an issue. Each Component Release has a collection of [attachments](https://github.com/CycloneDX/transparency-exchange-api/blob/main/tea-collection/tea-collection.md#tea-artifact-object) (TEA Artifacts: SBOMs, VEXes, etc.), so additional metadata could be added that way. > 3. There is nothing in your example about signatures. You mean PURLs for signature files? I don't believe signature files should be addressable as PURL. In my opinion, they are part of the transport layer. Each distribution object has a `signatureUrl` field to point to a server, where a signature can be downloaded. If you a referring to signature of the JSON file: we have discussed it, but we haven't reached an agreement yet. We were also talking about some API to distribute trust roots for each project/component, but that part is also missing from the draft. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
