-
Notifications
You must be signed in to change notification settings - Fork 659
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
Should the descriptor urls field be deprecated #1201
Comments
I've personally used it for large layers that canonically exist elsewhere (so mirroring them to another registry doesn't add a ton of value for me), but it's also a bit of an unexpected privacy breach. |
I remember @jonjohnsonjr had some input on when we had this discussion about URLs field. |
url field as it is used currently is potentially dangerous if pointing to a malicious source. |
If it's content addressable (with a verified digest) how would a URL be malicious in a way that a registry hosted blob isn't? |
Privacy/tracking is the thing that comes to mind for me right away. Another potential concern (theoretical) is that my registry provider may be taking measures to detect and block collision attacks (like GitHub does! ❤️), but this could be used to bypass that in a way that doesn't even notify the user it fetched content from an unexpected place (and not unexpected in the "my registry redirected me to S3 or somewhere else inside their trust boundary" way but rather in a "content author was able to redirect me to a malicious place"). |
With the deprecation of nondistributable layers, I'm curious if the descriptor urls field should also be deprecated. Are there existing uses of this field outside of nondistributable layers? If so, I'm curious if those uses break any clients or registries?
The text was updated successfully, but these errors were encountered: