keepassxc icon indicating copy to clipboard operation
keepassxc copied to clipboard

Add proper text/x-kde-passwordManagerHint MIME

Open hedgieinsocks opened this issue 1 month ago • 6 comments

Have you searched for an existing feature request?

  • [x] Yes, I tried searching

Brief Summary

The apps that use gtk bindings cannot see x-kde-passwordManagerHint MIME type set by KeePassXC because it is an invalid MIME - see discussion https://gitlab.gnome.org/GNOME/gtk/-/issues/4087

I suggest that we add text/x-kde-passwordManagerHint MIME without removing x-kde-passwordManagerHint MIME for backwards compatibility.

Example

The apps built on libraries that treat MIME types strictly, will be able to honor the intent.

Context

I want to teach https://github.com/murat-cileli/clyp to ignore clipboard change events when x-kde-passwordManagerHint MIME is present. But this MIME is currently stripped from events due to its invalid form. Once my feature request is implemented, I'll be able to update the referenced app.

hedgieinsocks avatar Nov 18 '25 21:11 hedgieinsocks

It's not so much "backwards" compatibility, but current KDE compatibility. KDE (specifically Klipper and KWalletManager) explicitly use x-kde-passwordManagerHint (not text/...) to mark sensitive data in the clipboard.

You're correct that it's technically not a MIME type, so adding a proper MIME type is not a bad idea. But since that wouldn't be compatible with KDE anyway, it makes little sense to maintain the "x-kde" part.

Assuming Gnome doesn't have its own MIME type for this yet, ideally this should be standardized in XDG. For example as text/password or text/xdg-password.

michaelk83 avatar Nov 18 '25 22:11 michaelk83

Per the mime type specification (from wayyy back when email was originally conceived) any custom subtype needs to start with X-. If there is already a registered password or sensitive data subtype then we can use that otherwise custom instances need to start with the X prefix. Registrations are held by IANA. https://www.iana.org/assignments/media-types/media-types.xhtml

droidmonkey avatar Nov 19 '25 01:11 droidmonkey

So without registration plans we could use text/x-secret. If we plan to register, then it will be text/vnd.keepassxc.secret or text/secret if we want to promote a new global standard.

I have no idea how hard or easy it would be to register a new type with IANA. Probably app specific would be faster and more feasible, when a global standard would benefit the whole of humanity but will probably take longer.

Perhaps, if we start to use text/x-secret and (optionally) notify other open source actors so they could adopt it, it will take on and will happen on its own naturally because good ideas stick?

hedgieinsocks avatar Nov 19 '25 06:11 hedgieinsocks

vnd.keepassxc. is also not necessary. This should ideally be a more general thing, denoting any security-sensitive text, particularly for clipboard use. Even without actual IANA registration, it's still better to go through XDG, so that it would at least be standardized across all Linux DEs.

michaelk83 avatar Nov 19 '25 16:11 michaelk83

@michaelk83 do you mean doing a pr like this one https://gitlab.freedesktop.org/xdg/shared-mime-info/-/merge_requests/338 after optionally discussing the idea in some xdg maillist?

hedgieinsocks avatar Nov 20 '25 11:11 hedgieinsocks

According to https://www.freedesktop.org/wiki/Specifications

If you would like to propose a new specification, or a change to an existing specification, please file an issue on the spec under the GitLab XDG project, or discuss it on the xdg@ mailing list.

The Gitlab for specifications is at https://gitlab.freedesktop.org/xdg/xdg-specs xdg/shared-mime-info looks more like specifically for file MIME types (it's also a package, not a specification).

michaelk83 avatar Nov 20 '25 12:11 michaelk83