For password-manager-service - it allows to grab all passwords, so it’s rather advised to try to use portals whether possible to just interact in smallest way possible.
pulseaudio is deprecated in favour of audio-record and audio-playback and so should not be needed.
audio-record seems reasonable since the snap clearly states that it translates audio. +1 from me for auto-connect of audio-record.
The use of password-manager-service is not recommended as it provides access to the entire users keyring and so exposes any secrets stored by a snap to any other snaps with such access (and to any other applications on the system as well). Instead, as mentioned by @KhazAkar, if you use something like libsecret to access the keyring and plug the desktop interface then your snap should automatically store the secret locally via the secret portal without needing access to the system keyring.
Finally, as per the Process for aliases, auto-connections and tracks, auto-connect of removable-media is appropriate for applications that are media editors etc - and I think buzz likely fits into this category. Then the other question is the following criteria:
the application itself is a mature, well-known application
the snap’s (vetted) publisher is a mature, well-known entity
the snap’s (vetted) publisher is the upstream of the software
if the snap is published by someone other than upstream, the publisher must be vetted and either be an established committer to the upstream or the wider snap ecosystem (eg, an established well-known contributor to the software itself, a member of the snapcrafters group, etc)
if the publisher doesn’t meet these criteria, other options may or may not be considered such as the publisher joining snapcrafters, snapcrafters becoming a collaborator on the snap, auto-connection granted conditional on the snap packaging being accepted upstream, upstream stating they trust the publisher with the packaging, etc.
Can you please let me know which of these you fit into as the publisher of this snap? Thanks (I am guessing you are the upstream author based on your username but it would be good to get explicit confirmation and then we will need to verify that as well).
I also find the auto-connection of audio-record and removable-media reasonable. Could you please respond @alexmurray question? If I’m right, you (the publisher) are the upstream of the software, is that right?
Regarding password-manager-service interface, we don’t grant auto-connection to it in most cases. In newer OS systems your snap can rely on libsecret using the secret-portal as @alexmurray said. Considering that Buzz upstream looks properly maintained, I will also support manual connection to the password-manager-service (unless other @reviewers oppose) to keep compatibility with older releases that may not implement the secret-portal.
A non-reviewer -1 for granting auto-connection to the removable-media interface. You should instead detect the connection at runtime and inform the user to manually allow its access.
This application seems to be generating captions from existing media files instead of editing the media files themselves. IMHO it does not fit into that category.
audio-record, audio-playback, removable-media, and libsecret for the keyring all sound reasonable.
Correct, I am both the upstream author and publisher of the snap.
Lin-Buo-Ren: The removable media guide seemed to suggest media players/viewers are also appropriate for auto-connect of removable-media, but I’m happy to pass on that.
@chidiw there is no libsecret interface - do you mean password-manager-service? If this is the case, then this would only be able to be granted use-of this interface, not auto-connect due to the sensitive nature of it.
