Bug 349282

Do you really use plasma-nm in version 0.9.3.4? I thought this has been fixed already. Any chance you can try at least 0.9.3.5 version where I did one more fix regarding OpenVPN import.

Yes, I'm running plasma-nm 0.9.3.4.  I can't test 0.9.3.5 at the moment but can do so as soon as it's packaged for openSUSE 13.2.

That is not the syntax our import code expects. The import code expects no ca, cert, key or ts-auth tags with '[inline]' as value when certificates are embedded. It expects only <ca>, <cert> <key> and <tls-auth> tags in that case. Besides, using '[inline]' as value is redundant in this case.

It may not be the syntax the plasma-nm import code expects, but it's one that the OpenVPN command-line client supports.  I've come across a few .ovpn files which use this syntax, and I've seen it recommended by OpenVPN experts such as Jan Just Keijser (see for example <http://openvpn-users.narkive.com/ZwzahkCv/embedding-key-cert-ca-into-client-config>).

It looks like this [inline] directive was never documented in the OpenVPN man pages.  However, given that it's in use, it might still be a good idea for plasma-nm to handle this syntax.

Git commit 599afdacd744a2d7785274687438a23f21617c34 by Lamarque V. Souza.
Committed on 28/06/2015 at 23:26.
Pushed by lvsouza into branch 'master'.

Add support to import .ovpn files with syntax described in
http://openvpn-users.narkive.com/ZwzahkCv/embedding-key-cert-ca-into-client-config
FIXED-IN: 0.9.3.7

M  +22   -5    vpn/openvpn/openvpn.cpp

http://commits.kde.org/plasma-nm/599afdacd744a2d7785274687438a23f21617c34

Git commit c6f0b9df0e1a78c4d54058136580104b5e5b22a7 by Lamarque V. Souza.
Committed on 29/06/2015 at 00:21.
Pushed by lvsouza into branch '0.9.3'.

Add support to import .ovpn files with syntax described in
http://openvpn-users.narkive.com/ZwzahkCv/embedding-key-cert-ca-into-client-config
FIXED-IN: 0.9.3.7

M  +22   -5    vpn/openvpn/openvpn.cpp

http://commits.kde.org/plasma-nm/c6f0b9df0e1a78c4d54058136580104b5e5b22a7

Still reproducible for me with plsma-nm 5.10.4.  I get the following error dialog when importing configuration files with inline certificates and agreeing with the prompt to copy the certificates to ~/.local:

Error copying certificate to /home/psy/.local/share/networkmanagement/certificates/ukp-vpn_[inline]: Cannot open /home/psy/vpn/UKP/[inline] for input

I should add that despite the error message, plasma-nm successfully extracted the certificates and copied them to ~.local/share/networkmanagement/certificates. So maybe the error message is spurious.

Hi. Hmmm QFile was not able to open the source file (/home/psy/vpn/UKP/[inline]). Does your user has permission to open that file for reading? That error message is shown only if QFile::copy returns false [1]

If the destination file already exists then QFile::copy returns false. That can be the problem too. In that case QFile::copy does not override the destination file. Probably we should ask the user if he/she wants to override it or keep the old one.

[1] http://doc.qt.io/qt-5/qfile.html#copy

OBS: since Plasma NM was not able to copy the file what it does is registering  the source file's path (/home/psy/vpn/UKP/[inline]) in NetworkManager. Since NetworkManager run as root it probably has permission to read that file.

OBS2: Plasma NM run as normal user.

(In reply to Lamarque V. Souza from comment #9)
> Hi. Hmmm QFile was not able to open the source file
> (/home/psy/vpn/UKP/[inline]). Does your user has permission to open that
> file for reading? That error message is shown only if QFile::copy returns
> false [1]

That's because the file doesn't exist.  As I already mentioned in the original report, plasma-nm is misinterpreting the [infile] header in the .ovpn file as a filename.  It should not be trying to open any new files; the certificates should be read from the .ovpn file it already has open.

Does your file name has any space in it? If it does then you must use quotation mark in the .ovpn to delimitate the file name.

(In reply to Lamarque V. Souza from comment #11)
> Does your file name has any space in it? If it does then you must use
> quotation mark in the .ovpn to delimitate the file name.

I'm telling you for the third time, there is no filename in the .ovpn file.  This bug report is about plasma-nm's failure to process .ovpn files which use the special identifier "[inline]" to indicate that the certificates and/or keys are included directly in the .ovpn file.

Still reproducible as discussed in Comment 7 and Comment 8 with plasma-nm 5.12.6.  That is, importing an OpenVPN configuration file with inline certificates and keys throws up a spurious error dialog about being unable to open the nonexistent file named "[inline]".  However, the certificates and keys get successfully copied anyway.

Does the import work when using nmcli (`nmcli connection import type openvpn file $FILENAME`)?

If nmcli works, I would think this is mostly caused by Plasma NM not using the NetworkManager OpenVPN code to import configuration files (bug #396530), but implements an own buggy version.

(In reply to Dennis Schridde from comment #14)
> Does the import work when using nmcli (`nmcli connection import type openvpn
> file $FILENAME`)?
> 
> If nmcli works, I would think this is mostly caused by Plasma NM not using
> the NetworkManager OpenVPN code to import configuration files (bug #396530),
> but implements an own buggy version.

I'm now using plasma-nm 5.12.8.  This version has the same behaviour as described for plasma-nm 5.12.6 in Comment 13: attempting to import an .ovpn file with inline certificates and keys results in a spurious error dialog, but the keys and certificates get successfully copied anyway.

I also tried using nmcli.  This seems to work without any problems:

$ nmcli connection import type openvpn file ~/vpn/ukp-vpn.ovpn 
Connection 'ukp-vpn' (c6cbabfe-f117-4af9-aca5-be9e8c88595c) successfully added.

When I open the NetworkManager plasma applet after doing this, I see the VPN connection listed there, with the keys and certificates copied into separate files under ~/.cert/nm-openvpn.

In Plasma 5.27 we changed the VPN  import to match what nmcli is doing, so this should be fixed

See https://invent.kde.org/plasma/plasma-nm/-/commit/9b22aa548f02ef43f7275ab2f9ffa48bde8a1ba8