Bug 424068

SUMMARY

Orphan keys and certificates are not cleaned up.

STEPS TO REPRODUCE
1. Add OpenVPN connection
2. Remove connection added in step 1.
3. Check the directory `$HOME/.local/share/networkmanagement/certificates/$connection`

OBSERVED RESULT

Keys and certificates which are no longer needed are still there.

EXPECTED RESULT

Clean up relevant files under $HOME/.local/share/networkmanagement/certificates/$connection when removing a connection.

SOFTWARE/OS VERSIONS

> Arch Linux, KDE/Plasma
> lib32-libnm-glib 1.18.5dev+12+ga8746f48ca-1
> libnm 1.24.2-1
> libnm-glib 1.18.5dev+12+ga8746f48ca-1
> networkmanager 1.24.2-1

ADDITIONAL INFORMATION

There are incompatibilities with NetworkManager and GNOME that arise from using custom
re-implementation of `nmcli`. People are working on it here:
https://bugs.kde.org/show_bug.cgi?id=396530. In the meantime, we might attempt to fix
the issue with plasma-nm's implementation ourselves.

Originally posted at GNOME GitLab: https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/issues/53.

Original issue text:

=== ratijas:

Using:

 * NetworkManager as in Connections — System Settings Module.
 * OpenVPN plugin for NetworkManager as in this repository.


# Problem

During import of *.ovpn profile via "+" -> "Import VPN connection..." this plugin parses its content, stores recognized options somewhere and _extracts inline keys & certificates_ into files under `$HOME/.local/share/networkmanagement/certificates/$connection`. Upon removal via corresponding "-", leftover files are left intact, thus polluting the directory and leaking credentials.

# Solution

Clean up relevant files under `$HOME/.local/share/networkmanagement/certificates/$connection` when removing a connection.

=== ratijas:

I acknowledge it may be more of an issue with NetworkManager itself, but it might need integrations steps from openvpn plugin as well.

=== Thomas Haller:

when a profile gets deleted, NetworkManager doesn't know whether the referenced files are still relevant to the user. How would it? Hence, it does not delete them.

While this should be improved, it's not clear how exactly.

Do you think NetworkManager should always delete all referenced files when deleting a profile? That doesn't seem desirable, and dangerous.

Yes, files have severe downsides, that's why we would better use a certificate store and PKCS#11 URLs.


=== ratijas:

It creates them itself — Of course it is in charge of deleting them!

It knows exactly that files are managed by NetworkManager himself because referenced files are stored inside special directory which I mentioned twice in the original post.

> That doesn't seem desirable, and dangerous.

Danger is leaving sensitive data behind and misleading user into believing that it was cleared. Moreover, When I recreated network with the same name but different profile, it might create different set of files (e.g.: `tls-crypt.key` instead of `tls-auth.key` except that the former is not supported at the moment #54 (closed)) leading to clashes and overlaps.

Now that I think about it, naming connections based on their display name is not good enough. Consider using UUID instead. (Should I open separate issue?)

**Removing to trash** might be a better options, if it can be implemented in reasonably compatible cross-platform way. Seems like freedesktop.org has a standard or two on this matter.

> PKCS#11 URLs

Never heard of those. I am not an expert in this field. Looks promising.

=== Thomas Haller:

> It creates them itself

NetworkManager didn't create them. When you do nmcli connection import  or click import in nm-connection-editor (or gnome-control-center), then those tools create the file.

You could also create the very same profile without using import. Just have the files on disk, and set the paths accordingly.

NetworkManager doesn't know how the profile was created, or what the user wants to do with the certificate files when deleting the profile.

=== ratijas:

Well then, if there is an import, then there must be 'unimport'.

In general — "that's why we can't have nice things" on Linux: no integration whatsoever. Or as the proverb says, "*left hand doesn't know what the right hand is doing*". :(

I won't go much into technical details, but whenever there is a **set up**, there will be a need for **tear down**. If there is no such concept in mncli at the moment, then *maybe* it should be introduced.

But then again, as a user, I don't care much for how it is implemented. As an open source developer though, I *might* get involved and contribute, but don't rely on my words any time soon.

=== ratijas:

I've played around with `nmcli` and `nm-connection-editor`. To no surprise, both are doing exactly same thing. KDE/Plasma's plasma-nm applet is slightly different, but people are working on a fix: https://bugs.kde.org/show_bug.cgi?id=396530.

So, `nmcli` has two commands I am interested in: `import` and `delete`. Just like with plasma-nm's "+" -> "Import" and "Delete", they are **not complementary** commands.

> Not to mention, both tools export my ovpn profile as heavily modified with externally linked files (instead of in-line keys and certificates).

The only major difference though is the storage for extracted credentials:
 - plasma-nm stores files `$HOME/.local/share/networkmanagement/certificates/$connection/{{ca,cert}.crt,{private,tls-auth}.key}`
 - `nmcli` imports into `$HOME/.cert/nm-openvpn/$connection-$cred.pem`

Neither tool cleans up credentials upon deletion / removal of a connection, and I think it should be fixed. Now that we know two managed locations, we just have to check that other connection entries do not refer to the same keys/certificates, and if not — remove orphans to trash.

I will proceed to duplicate this issue at https://bugs.kde.org for plasma-nm. Binary `nmcli`, on the other hand, belongs to NetworkManager package on ArchLinux, so I assume this is still the correct place to talk about it.