Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create self-describing bottles #17838

Open
1 task done
justenstall opened this issue Jul 23, 2024 · 6 comments
Open
1 task done

Create self-describing bottles #17838

justenstall opened this issue Jul 23, 2024 · 6 comments
Labels
features New features help wanted We want help addressing this

Comments

@justenstall
Copy link

Verification

Provide a detailed description of the proposed feature

Update the bottle artifacts pushed to the homebrew/core container registry so they are self-describing. Currently the bottle artifacts do not contain the formula's API metadata.

This can be accomplished by uploading the formula's API JSON data and referencing the blob as the bottle manifests' config.

What is the motivation for the feature?

Combined with #17837, this would allow bottles to be installed without the API.

Two sets of metadata exist for a bottle, the tab contained in an annotation and the API data. The tab is a subset of the necessary information and could contain conflicting information.

How will the feature be relevant to at least 90% of Homebrew users?

Faster install times without downloading the full formula index from the API.

What alternatives to the feature have been considered?

Not implementing the feature.

@justenstall justenstall added the features New features label Jul 23, 2024
@Bo98
Copy link
Member

Bo98 commented Jul 24, 2024

On the surface, this seems reasonable and useful from at least a mirroring point of view (as it's a bit tricky to mirror currently).

However it is a bit more complicated. The data in the API allows many Homebrew commands to work offline and significantly faster, such as brew deps, brew info (--json), etc. As more concrete examples: the requirements list is useful to fail fast if something isn't supported on your OS, and dependency tree is ideal to know ahead of time as we fetch everything before parsing.

There's also a security element. We sign the API JSON so it cannot be tampered with by mirrors. No independent protection exists for manifests (it's covered by the bottle sha256s being included in the signed API JSON).

I would like to lean on the manifests more overall, but only if it doesn't degrade the above.

@MikeMcQuaid
Copy link
Member

There's also a security element. We sign the API JSON so it cannot be tampered with by mirrors. No independent protection exists for manifests (it's covered by the bottle sha256s being included in the signed API JSON).

This is my main concern here, too.

@justenstall
Copy link
Author

justenstall commented Jul 25, 2024

However it is a bit more complicated. The data in the API allows many Homebrew commands to work offline and significantly faster, such as brew deps, brew info (--json), etc. As more concrete examples: the requirements list is useful to fail fast if something isn't supported on your OS, and dependency tree is ideal to know ahead of time as we fetch everything before parsing.

I'm not proposing getting rid of the API or its data, I am proposing that the exact same data should be stored alongside the bottle in the container registry.

There's also a security element. We sign the API JSON so it cannot be tampered with by mirrors. No independent protection exists for manifests (it's covered by the bottle sha256s being included in the signed API JSON).

OCI artifacts can be signed and verified in a similar way to how Homebrew signs the API JSON, Notary and cosign are both established standards for signing and verifying OCI artifacts.

@MikeMcQuaid
Copy link
Member

I'm not proposing getting rid of the API or its data, I am proposing that the exact same data should be stored alongside the bottle in the container registry.

How would a client (e.g. Hops) know what formulae are available without using the API here?

Notary and cosign are both established standards for signing and verifying OCI artifacts.

TIL, thanks.

I think that signing would be a hard requirement on our end for either this or #17837. It might be the best first step, here.

@woodruffw
Copy link
Member

OCI artifacts can be signed and verified in a similar way to how Homebrew signs the API JSON, Notary and cosign are both established standards for signing and verifying OCI artifacts.

JFYI: We don't do it at the OCI layer, but Homebrew does indeed use Sigstore (the stack under cosign) to attest to all of its (core) bottles: https://github.com/Homebrew/homebrew-core/attestations.

(Not sure if this is relevant to you; I just noticed the cosign reference 🙂)

Copy link

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

@github-actions github-actions bot added the stale No recent activity label Aug 17, 2024
@MikeMcQuaid MikeMcQuaid added help wanted We want help addressing this and removed stale No recent activity labels Aug 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
features New features help wanted We want help addressing this
Projects
None yet
Development

No branches or pull requests

4 participants