Metadata for a package version can currently be replaced after changes to the repository.
Problem
Since Composer packages are mutable configurations stored per versions, developers can publish new development versions under the same name. However, this is also true for tagged versions.
When fetching a package there is currently no way of knowing what you’re going to receive or if it’s the same as the day before. This is inherit to Composer which simply resolves package metadata directly from a VCS repository. This makes Composer very versatile as you can fetch the package metadata from different sources, but comes at the price of increased attack vectors from the source.
- Loss of historical metadata makes debugging difficult
- No audit trail for metadata changes
- Consumers can't verify what metadata looked like at a specific point in time
- Compliance and reproducibility concerns for production deployments
Tasks
Metadata for a package version can currently be replaced after changes to the repository.
Problem
Since Composer packages are mutable configurations stored per versions, developers can publish new development versions under the same name. However, this is also true for tagged versions.
When fetching a package there is currently no way of knowing what you’re going to receive or if it’s the same as the day before. This is inherit to Composer which simply resolves package metadata directly from a VCS repository. This makes Composer very versatile as you can fetch the package metadata from different sources, but comes at the price of increased attack vectors from the source.
Tasks