Removing/hiding Specific Charm Revisions in the Store

There is currently no way to remove or revoke read permissions for a specific charm revision. Read permissions can be removed for everyone but at the charm level, not revision level.

From what I can see in the charm store code this is an API-level limitation:
https://github.com/juju/charmstore/blob/693c346/internal/charmstore/addentity.go#L487-L543 (there’s code for adding charms but not removing).

This functionality would be useful in cases where unwanted information went into the store by accident (such as credentials or some other type of information).

Is there any reason this functionality was not implemented and could this be taken into consideration?

1 Like

@rick_h @uros-jovanovic @martin-hilton

This isn’t done because I don’t think folks want to maintain/debug permissions on a per-revision level. There is a delete function that the charmstore folks can help with. The idea being if you leaked a credential/etc you don’t want to just hide it with permissions but you want to remove it entirely. Maybe @uros-jovanovic and team can help out with getting things removed directly. I’d ping them, maybe via a bug, to have something removed.

1 Like

Being able to remove a charm altogether from charmstore helps in the use-case where someone reflects on the ability to use the charmstore to deploy “private” assets in a public cloud.

For example, I would feel very uncomfortable to release/push charms to charmstore which would contain - lets say - code to control breaks to a autonomous car (possibly under heavy IP restrictions or even regulatory demands) . In the IoT domain, this is a valid use-case.

Oh, not to mention “accidental” pushes =D

The ability to provide a guaranteed way to remove all traces of a charm is a strong case.

1 Like