Traditionally, the code for handling keyfile (and ifcfg-rh) is part of the daemon (and thus GPL licensed).

Already as an ongoing effort, the code for keyfile handling was extracted so that it can be used independently. Currently it is here ([1]):

[1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/tree/1a76141e66c9f7b8dc265955d3f3d149bc6c95ba/shared/nm-keyfile


Note that this code is GPL-2.0+, so it cannot be part of libnm (which is LGPL-2.1+). Maybe, with the relicensing effort ([2]), we could even change the license of the code. But that isn't simple, because of the long history of the file :( On the other hand, it's merely 5k of code, maybe we could just re-implement it from scratch under LGPL-2.1+... 

[2] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/1a76141e66c9f7b8dc265955d3f3d149bc6c95ba/RELICENSE.md


Anyway, we should provide an API for handling keyfile. If we can relicense (or reimplement it), this code could be part of libnm. Otherwise, we can just add a new GPL-2.0+ licensed libnm-keyfile.so.


This opens countless opportunities for nice features, e.g. bug 1361145 or connection import/export from nm-connection-editor.



One problem is, that the API needs to all special handling. For example,

  - it needs a hook for possibly removing passwords (or replacing them by ***)

  - it needs a hook for notifying about warnings and info messages

  - we may need to handle file names. For example, if the property is a relative path name, nmcli may want to complete that path based on the current working directory. Likewise, when loading a keyfile, relative paths probably should be based on the location of the file we are about to load.

  - certificates can also be blobs. The settings plugins converts blobs to files (persisting the files to disk) ([3]). But then a `nmcli connection show --keyfile "$PROFILE"` may just want to print the blob as binary array, etc.

[3] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/1a76141e66c9f7b8dc265955d3f3d149bc6c95ba/src/settings/plugins/keyfile/nms-keyfile-writer.c#L29

The point is, especially export is not as simple but it needs a flexible, extensible API. This API already exists with the NMKeyfileWriteHandler and NMKeyfileReadHandler structs. The problem is whether this is suitable public API, also w.r.t. how to use this API form python via GObject introspection.