fdo-mirrors/NetworkManager
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git synced 2025-12-20 22:10:08 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
NetworkManager/libnm-core/tests/test-keyfile.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

910 lines
38 KiB
C
Raw Normal View History

all: update deprecated SPDX license identifiers These SPDX license identifiers are deprecated ([1]). Update them. [1] https://spdx.org/licenses/ sed \ -e '1 s%^/\* SPDX-License-Identifier: \(GPL-2.0\|LGPL-2.1\)+ \*/$%/* SPDX-License-Identifier: \1-or-later */%' \ -e '1,2 s%^\(--\|#\|//\) SPDX-License-Identifier: \(GPL-2.0\|LGPL-2.1\)+$%\1 SPDX-License-Identifier: \2-or-later%' \ -i \ $(git grep -l SPDX-License-Identifier -- \ ':(exclude)shared/c-*/' \ ':(exclude)shared/n-*/' \ ':(exclude)shared/systemd/src' \ ':(exclude)src/systemd/src')
2020-12-23 22:21:36 +01:00
/* SPDX-License-Identifier: GPL-2.0-or-later */
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
/*
all: unify format of our Copyright source code comments ```bash readarray -d '' FILES < <( git ls-files -z \ ':(exclude)po' \ ':(exclude)shared/c-rbtree' \ ':(exclude)shared/c-list' \ ':(exclude)shared/c-siphash' \ ':(exclude)shared/c-stdaux' \ ':(exclude)shared/n-acd' \ ':(exclude)shared/n-dhcp4' \ ':(exclude)src/systemd/src' \ ':(exclude)shared/systemd/src' \ ':(exclude)m4' \ ':(exclude)COPYING*' ) sed \ -e 's/^\(--\|#\| \*\) *\(([cC]) *\)\?Copyright \+\(\(([cC])\) \+\)\?\(\(20\|19\)[0-9][0-9]\) *[-–] *\(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/\1 C1pyright#\5 - \7#\9/' \ -e 's/^\(--\|#\| \*\) *\(([cC]) *\)\?Copyright \+\(\(([cC])\) \+\)\?\(\(20\|19\)[0-9][0-9]\) *[,] *\(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/\1 C2pyright#\5, \7#\9/' \ -e 's/^\(--\|#\| \*\) *\(([cC]) *\)\?Copyright \+\(\(([cC])\) \+\)\?\(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/\1 C3pyright#\5#\7/' \ -e 's/^Copyright \(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/C4pyright#\1#\3/' \ -i \ "${FILES[@]}" echo ">>> untouched Copyright lines" git grep Copyright "${FILES[@]}" echo ">>> Copyright lines with unusual extra" git grep '\<C[0-9]pyright#' "${FILES[@]}" | grep -i reserved sed \ -e 's/\<C[0-9]pyright#\([^#]*\)#\(.*\)$/Copyright (C) \1 \2/' \ -i \ "${FILES[@]}" ``` https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/298
2019-10-01 09:20:35 +02:00
* Copyright (C) 2015 Red Hat, Inc.
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
*/
build: cleanup default includes - "gsystem-local-alloc.h" and <gio/gio.h> are already included via "nm-default.h". No need to include them separately. - include "nm-macros-internal.h" via "nm-default.h" and drop all explict includes. - in the modified files, ensure that we always include "config.h" and "nm-default.h" first. As second, include the header file for the current source file (if applicable). Then follow external includes and finally internal nm includes. - include nm headers inside source code files with quotes - internal header files don't need to include default headers. They can savely assume that "nm-default.h" is already included and with it glib, nm-glib.h, nm-macros-internal.h, etc.
2016-02-12 14:44:52 +01:00
#include "nm-default.h"
shared: merge nm-glib-aux/nm-json.[hc] into nm-json-aux.[hc] They serve a similar purpose. Previously, nm-json-aux.h contained the virtual function table for accessing the dynamically loaded libjansson. But there is no reason why our own helper functions from nm-json.h cannot be there too.
2020-07-01 19:26:33 +02:00
#include "nm-glib-aux/nm-json-aux.h"
libnm/keyfile: build keyfile code as separate GPL licensed internal library Keyfile support was initially added under GPL-2.0+ license as part of core. It was moved to "libnm-core" in commit 59eb5312a5d6 ('keyfile: merge branch 'th/libnm-keyfile-bgo744699''). "libnm-core" is statically linked with by core and "libnm". In the former case under terms of GPL-2.0+ (good) and in the latter case under terms of LGPL-2.1+ (bad). In fact, to this day, "libnm" doesn't actually use the code. The linker will probably remove all the GPL-2.0+ symbols when compiled with gc-sections or LTO. Still, linking them together in the first place makes "libnm" only available under GPL code (despite the code not actually being used). Instead, move the GPL code to a separate static library "shared/nm-keyfile/libnm-keyfile.la" and only link it to the part that actually uses the code (and which is GPL licensed too). This fixes the license violation. Eventually, it would be very useful to be able to expose keyfile handling via "libnm". However that is not straight forward due to the licensing conflict. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/381
2020-01-02 07:37:59 +01:00
#include "nm-keyfile/nm-keyfile-utils.h"
#include "nm-keyfile/nm-keyfile-internal.h"
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
#include "nm-simple-connection.h"
#include "nm-setting-connection.h"
#include "nm-setting-wired.h"
#include "nm-setting-8021x.h"
team: normalize invalid configuration during load Now that we validate the JSON syntax of a team/team-port configuration, any existing connection with invalid JSON configuration would fail to load and disappear upon upgrade. Instead, modify the setting plugins to emit a warning but still load the connection with empty configuration.
2016-08-30 15:21:16 +02:00
#include "nm-setting-team.h"
libnm/keyfile: properly read user data from keyfile Hack keyfile reader support for NMSettingUser. Writer support already works. (cherry picked from commit 22fd7d2e39327c9f288dd8f17529c1898bc20e47)
2017-05-04 14:50:07 +02:00
#include "nm-setting-user.h"
libnm/proxy: add proxy setting for non-slave connection during normalization And reject slave settings with proxies.
2016-10-04 16:44:39 +02:00
#include "nm-setting-proxy.h"
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
shared: move shared files to subdirectory "shared/nm-utils/" The "shared" directory contains files that are possibly used by all components of NetworkManager repository. Some of these files are even copied as-is to other projects (VPN plugins, nm-applet) and used there without modification. Move those files to a separate directory. By moving them to a common directory, it is clearer that they belong together. Also, you can easier compare the copied versions to their original via $ diff -r ./shared/nm-utils/ /path/to/nm-vpn-plugin/shared/nm-utils/
2016-06-15 15:29:10 +02:00
#include "nm-utils/nm-test-utils.h"
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
build: use default NM_BUILD_* defines for tests Use two common defines NM_BUILD_SRCDIR and NM_BUILD_BUILDDIR for specifying the location of srcdir and builddir. Note that this is only relevant for tests, as they expect a certain layout of the directories, to find files that concern them.
2018-05-30 10:23:17 +02:00
#define TEST_CERT_DIR NM_BUILD_SRCDIR "/libnm-core/tests/certs"
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
#define TEST_WIRED_TLS_CA_CERT TEST_CERT_DIR "/test-ca-cert.pem"
#define TEST_WIRED_TLS_PRIVKEY TEST_CERT_DIR "/test-key-and-cert.pem"
libnm/crypto: accept TPM2-wrapped PEM keys Some tools that NM can interact with (eg. openconnect) have added automated support to handle TPM2-wrapped PEM keys as drop-in replacements for ordinary key files. Make sure that NM doesn't reject these keys upfront. We cannot reliably assume NM to be able to unwrap and validate the key. Therefore, accept any key as long as the PEM header and trailer look ok.
2019-06-24 12:09:12 +02:00
#define TEST_WIRED_TLS_TPM2KEY TEST_CERT_DIR "/test-tpm2wrapped-key.pem"
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
keyfile: fix handling unsupported characters in keys vpn.data, bond.options, and user.data encode their values directly as keys in keyfile. However, keys for GKeyFile may not contain characters like '='. We need to escape such special characters, otherwise an assertion is hit on the server: $ nmcli connection modify "$VPN_NAME" +vpn.data 'aa[=value' Another example of encountering the assertion is when setting user-data key with an invalid character "my.this=key=is=causes=a=crash". (cherry picked from commit 8ef57d0f7ef26247bf53b4d07f712a1bf4de4bb2)
2017-05-05 12:01:17 +02:00
/*****************************************************************************/
static void
do_test_encode_key_full(GKeyFile * kf,
const char *name,
const char *key,
const char *key_decode_encode)
{
gs_free char *to_free1 = NULL;
gs_free char *to_free2 = NULL;
const char * key2;
const char * name2;
g_assert(key);
if (name) {
key2 = nm_keyfile_key_encode(name, &to_free1);
g_assert(key2);
g_assert(NM_STRCHAR_ALL(key2, ch, (guchar) ch < 127));
g_assert_cmpstr(key2, ==, key);
/* try to add the encoded key to the keyfile. We expect
* no g_critical warning about invalid key. */
g_key_file_set_value(kf, "group", key, "dummy");
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: fix handling unsupported characters in keys vpn.data, bond.options, and user.data encode their values directly as keys in keyfile. However, keys for GKeyFile may not contain characters like '='. We need to escape such special characters, otherwise an assertion is hit on the server: $ nmcli connection modify "$VPN_NAME" +vpn.data 'aa[=value' Another example of encountering the assertion is when setting user-data key with an invalid character "my.this=key=is=causes=a=crash". (cherry picked from commit 8ef57d0f7ef26247bf53b4d07f712a1bf4de4bb2)
2017-05-05 12:01:17 +02:00
name2 = nm_keyfile_key_decode(key, &to_free2);
if (name)
g_assert_cmpstr(name2, ==, name);
else {
key2 = nm_keyfile_key_encode(name2, &to_free1);
g_assert(key2);
g_assert(NM_STRCHAR_ALL(key2, ch, (guchar) ch < 127));
if (key_decode_encode)
g_assert_cmpstr(key2, ==, key_decode_encode);
g_key_file_set_value(kf, "group", key2, "dummy");
}
}
#define do_test_encode_key_bijection(kf, name, key) \
do_test_encode_key_full(kf, "" name, "" key, NULL)
#define do_test_encode_key_identity(kf, name) do_test_encode_key_full(kf, "" name, "" name, NULL)
#define do_test_encode_key_decode_surjection(kf, key, key_decode_encode) \
do_test_encode_key_full(kf, NULL, "" key, "" key_decode_encode)
static void
test_encode_key(void)
{
all: replace cleanup macro "gs_unref_keyfile" by "nm_auto_unref_keyfile"
2020-09-02 17:36:08 +02:00
nm_auto_unref_keyfile GKeyFile *kf = g_key_file_new();
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: fix handling unsupported characters in keys vpn.data, bond.options, and user.data encode their values directly as keys in keyfile. However, keys for GKeyFile may not contain characters like '='. We need to escape such special characters, otherwise an assertion is hit on the server: $ nmcli connection modify "$VPN_NAME" +vpn.data 'aa[=value' Another example of encountering the assertion is when setting user-data key with an invalid character "my.this=key=is=causes=a=crash". (cherry picked from commit 8ef57d0f7ef26247bf53b4d07f712a1bf4de4bb2)
2017-05-05 12:01:17 +02:00
do_test_encode_key_identity(kf, "a");
do_test_encode_key_bijection(kf, "", "\\00");
do_test_encode_key_bijection(kf, " ", "\\20");
do_test_encode_key_bijection(kf, "\\ ", "\\\\20");
do_test_encode_key_identity(kf, "\\0");
do_test_encode_key_identity(kf, "\\a");
do_test_encode_key_identity(kf, "\\0g");
do_test_encode_key_bijection(kf, "\\0f", "\\5C0f");
do_test_encode_key_bijection(kf, "\\0f ", "\\5C0f\\20");
do_test_encode_key_bijection(kf, " \\0f ", "\\20\\5C0f\\20");
do_test_encode_key_bijection(kf, "\xF5", "\\F5");
do_test_encode_key_bijection(kf, "\x7F", "\\7F");
do_test_encode_key_bijection(kf, "\x1f", "\\1F");
do_test_encode_key_bijection(kf, " ", "\\20\\20");
do_test_encode_key_bijection(kf, " ", "\\20 \\20");
do_test_encode_key_decode_surjection(kf, "f\\20c", "f c");
do_test_encode_key_decode_surjection(kf, "\\20\\20\\20", "\\20 \\20");
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: fix escaping ascii control characters in nm_keyfile_key_encode() Matters when backslash escaping ascii charaters <= 0xF, to produce "\\XX" instead of "\\ X". For example tabulator is "\\09". This also can trigger an nm_assert() failure, when building with --with-more-asserts=5 (or higher).
2017-11-20 15:30:36 +01:00
do_test_encode_key_bijection(kf, "\t", "\\09");
do_test_encode_key_bijection(kf, "\t=x", "\\09\\3Dx");
do_test_encode_key_bijection(
kf,
"(nm-openvpn-auth-dialog:10283): GdkPixbuf-DEBUG: \tCopy pixels == false",
"(nm-openvpn-auth-dialog:10283): GdkPixbuf-DEBUG: \\09Copy pixels \\3D\\3D false");
keyfile: fix handling unsupported characters in keys vpn.data, bond.options, and user.data encode their values directly as keys in keyfile. However, keys for GKeyFile may not contain characters like '='. We need to escape such special characters, otherwise an assertion is hit on the server: $ nmcli connection modify "$VPN_NAME" +vpn.data 'aa[=value' Another example of encountering the assertion is when setting user-data key with an invalid character "my.this=key=is=causes=a=crash". (cherry picked from commit 8ef57d0f7ef26247bf53b4d07f712a1bf4de4bb2)
2017-05-05 12:01:17 +02:00
}
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
#define CLEAR(con, keyfile) \
G_STMT_START \
{ \
NMConnection **_con = (con); \
GKeyFile ** _keyfile = (keyfile); \
\
g_clear_object(_con); \
all: use nm_clear_pointer() instead of g_clear_pointer() g_clear_pointer() would always cast the destroy notify function pointer to GDestroyNotify. That means, it lost some type safety, like GPtrArray *ptr_arr = ... g_clear_pointer (&ptr_arr, g_array_unref); Since glib 2.58 ([1]), g_clear_pointer() is also more type safe. But this is not used by NetworkManager, because we don't set GLIB_VERSION_MIN_REQUIRED to 2.58. [1] https://gitlab.gnome.org/GNOME/glib/-/commit/f9a9902aac826ab4aecc25f6eb533a418a4fa559 We have nm_clear_pointer() to avoid this issue for a long time (pre 1.12.0). Possibly we should redefine in our source tree g_clear_pointer() as nm_clear_pointer(). However, I don't like to patch glib functions with our own variant. Arguably, we do patch g_clear_error() in such a manner. But there the point is to make the function inlinable. Also, nm_clear_pointer() returns a boolean that indicates whether anything was cleared. That is sometimes useful. I think we should just consistently use nm_clear_pointer() instead, which does always the preferable thing. Replace: sed 's/\<g_clear_pointer *(\([^;]*\), *\([a-z_A-Z0-9]\+\) *)/nm_clear_pointer (\1, \2)/g' $(git grep -l g_clear_pointer) -i
2020-03-23 11:09:24 +01:00
nm_clear_pointer(_keyfile, g_key_file_unref); \
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
} \
G_STMT_END
static void
_assert_gbytes(GBytes *bytes, gconstpointer data, gssize len)
{
g_assert((data && len > 0) || !len || (data && len == -1));
if (len == -1)
len = strlen(data);
if (!len)
g_assert(!bytes);
all: use nm_utils_gbytes_equal_mem()
2018-08-22 20:49:43 +02:00
g_assert(nm_utils_gbytes_equal_mem(bytes, data, len));
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
}
static GKeyFile *
_keyfile_load_from_data(const char *str)
{
GError * error = NULL;
gboolean success;
GKeyFile *keyfile;
g_assert(str);
keyfile = g_key_file_new();
success = g_key_file_load_from_data(keyfile, str, strlen(str), G_KEY_FILE_NONE, &error);
g_assert_no_error(error);
g_assert(success);
return keyfile;
}
keyfile/test: refactor and cleanup _keyfile_convert() _keyfile_convert() should really test for successful round-trip conversion of keyfile-connection and vice versa.
2015-03-13 14:22:38 +01:00
static GKeyFile *
_nm_keyfile_write(NMConnection *connection, NMKeyfileWriteHandler handler, void *user_data)
{
GError * error = NULL;
GKeyFile *kf;
g_assert(NM_IS_CONNECTION(connection));
keyfile: add NMKeyfileHandlerFlags nm_keyfile_read() and nm_keyfile_write() will be public API. As such, it must be flexible and extendible for future needs. There is already the handler callback that fully solves this (e.g. a future handler event could request whether a certain behavior is enabled or not). As additional possibility for future extension, add a flags argument. Currently no flags are implemented.
2020-05-26 09:55:40 +02:00
kf = nm_keyfile_write(connection, NM_KEYFILE_HANDLER_FLAGS_NONE, handler, user_data, &error);
keyfile/test: refactor and cleanup _keyfile_convert() _keyfile_convert() should really test for successful round-trip conversion of keyfile-connection and vice versa.
2015-03-13 14:22:38 +01:00
g_assert_no_error(error);
g_assert(kf);
return kf;
}
static NMConnection *
_nm_keyfile_read(GKeyFile * keyfile,
const char * keyfile_name,
NMKeyfileReadHandler read_handler,
void * read_data,
gboolean needs_normalization)
{
GError * error = NULL;
NMConnection *con;
keyfile: split automatically setting ID/UUID for keyfile keyfile already supports omitting the "connection.id" and "connection.uuid". In that case, the ID would be taken from the keyfile's name, and the UUID was generated by md5 hashing the full filename. No longer do this during nm_keyfile_read(), instead let all callers call nm_keyfile_read_ensure_*() to their liking. This is done for two reasons: - a minor reason is, that one day we want to expose keyfile API as public API. That means, we also want to read keyfiles from stdin, where there is no filename available. The implementation which parses stdio needs to define their own way of auto-generating ID and UUID. Note how nm_keyfile_read()'s API no longer takes a filename as argument, which would be awkward for the stdin case. - Currently, we only support one keyfile directory, which (configurably) is "/etc/NetworkManager/system-connections". In the future, we want to support multiple keyfile dirctories, like "/var/run/NetworkManager/profiles" or "/usr/lib/NetworkManager/profiles". Here we want that a file "foo" (which does not specify a UUID) gets the same UUID regardless of the directory it is in. That seems better, because then the UUID won't change as you move the file between directories. Yes, that means, that the same UUID will be provided by multiple files, but NetworkManager must already cope with that situation anyway. Unfortunately, the UUID generation scheme hashes the full path. That means, we must hash the path name of the file "foo" inside the original "system-connections" directory. Refactor the code so that it accounds for a difference between the filename of the keyfile, and the profile_dir used for generating the UUID.
2018-10-02 19:53:54 +02:00
gs_free char *filename = NULL;
gs_free char *base_dir = NULL;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile/test: refactor and cleanup _keyfile_convert() _keyfile_convert() should really test for successful round-trip conversion of keyfile-connection and vice versa.
2015-03-13 14:22:38 +01:00
g_assert(keyfile);
keyfile: split automatically setting ID/UUID for keyfile keyfile already supports omitting the "connection.id" and "connection.uuid". In that case, the ID would be taken from the keyfile's name, and the UUID was generated by md5 hashing the full filename. No longer do this during nm_keyfile_read(), instead let all callers call nm_keyfile_read_ensure_*() to their liking. This is done for two reasons: - a minor reason is, that one day we want to expose keyfile API as public API. That means, we also want to read keyfiles from stdin, where there is no filename available. The implementation which parses stdio needs to define their own way of auto-generating ID and UUID. Note how nm_keyfile_read()'s API no longer takes a filename as argument, which would be awkward for the stdin case. - Currently, we only support one keyfile directory, which (configurably) is "/etc/NetworkManager/system-connections". In the future, we want to support multiple keyfile dirctories, like "/var/run/NetworkManager/profiles" or "/usr/lib/NetworkManager/profiles". Here we want that a file "foo" (which does not specify a UUID) gets the same UUID regardless of the directory it is in. That seems better, because then the UUID won't change as you move the file between directories. Yes, that means, that the same UUID will be provided by multiple files, but NetworkManager must already cope with that situation anyway. Unfortunately, the UUID generation scheme hashes the full path. That means, we must hash the path name of the file "foo" inside the original "system-connections" directory. Refactor the code so that it accounds for a difference between the filename of the keyfile, and the profile_dir used for generating the UUID.
2018-10-02 19:53:54 +02:00
g_assert(!keyfile_name || (keyfile_name[0] == '/'));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: split automatically setting ID/UUID for keyfile keyfile already supports omitting the "connection.id" and "connection.uuid". In that case, the ID would be taken from the keyfile's name, and the UUID was generated by md5 hashing the full filename. No longer do this during nm_keyfile_read(), instead let all callers call nm_keyfile_read_ensure_*() to their liking. This is done for two reasons: - a minor reason is, that one day we want to expose keyfile API as public API. That means, we also want to read keyfiles from stdin, where there is no filename available. The implementation which parses stdio needs to define their own way of auto-generating ID and UUID. Note how nm_keyfile_read()'s API no longer takes a filename as argument, which would be awkward for the stdin case. - Currently, we only support one keyfile directory, which (configurably) is "/etc/NetworkManager/system-connections". In the future, we want to support multiple keyfile dirctories, like "/var/run/NetworkManager/profiles" or "/usr/lib/NetworkManager/profiles". Here we want that a file "foo" (which does not specify a UUID) gets the same UUID regardless of the directory it is in. That seems better, because then the UUID won't change as you move the file between directories. Yes, that means, that the same UUID will be provided by multiple files, but NetworkManager must already cope with that situation anyway. Unfortunately, the UUID generation scheme hashes the full path. That means, we must hash the path name of the file "foo" inside the original "system-connections" directory. Refactor the code so that it accounds for a difference between the filename of the keyfile, and the profile_dir used for generating the UUID.
2018-10-02 19:53:54 +02:00
base_dir = g_path_get_dirname(keyfile_name);
filename = g_path_get_basename(keyfile_name);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: add NMKeyfileHandlerFlags nm_keyfile_read() and nm_keyfile_write() will be public API. As such, it must be flexible and extendible for future needs. There is already the handler callback that fully solves this (e.g. a future handler event could request whether a certain behavior is enabled or not). As additional possibility for future extension, add a flags argument. Currently no flags are implemented.
2020-05-26 09:55:40 +02:00
con = nm_keyfile_read(keyfile,
base_dir,
NM_KEYFILE_HANDLER_FLAGS_NONE,
read_handler,
read_data,
&error);
keyfile/test: refactor and cleanup _keyfile_convert() _keyfile_convert() should really test for successful round-trip conversion of keyfile-connection and vice versa.
2015-03-13 14:22:38 +01:00
g_assert_no_error(error);
g_assert(NM_IS_CONNECTION(con));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: split automatically setting ID/UUID for keyfile keyfile already supports omitting the "connection.id" and "connection.uuid". In that case, the ID would be taken from the keyfile's name, and the UUID was generated by md5 hashing the full filename. No longer do this during nm_keyfile_read(), instead let all callers call nm_keyfile_read_ensure_*() to their liking. This is done for two reasons: - a minor reason is, that one day we want to expose keyfile API as public API. That means, we also want to read keyfiles from stdin, where there is no filename available. The implementation which parses stdio needs to define their own way of auto-generating ID and UUID. Note how nm_keyfile_read()'s API no longer takes a filename as argument, which would be awkward for the stdin case. - Currently, we only support one keyfile directory, which (configurably) is "/etc/NetworkManager/system-connections". In the future, we want to support multiple keyfile dirctories, like "/var/run/NetworkManager/profiles" or "/usr/lib/NetworkManager/profiles". Here we want that a file "foo" (which does not specify a UUID) gets the same UUID regardless of the directory it is in. That seems better, because then the UUID won't change as you move the file between directories. Yes, that means, that the same UUID will be provided by multiple files, but NetworkManager must already cope with that situation anyway. Unfortunately, the UUID generation scheme hashes the full path. That means, we must hash the path name of the file "foo" inside the original "system-connections" directory. Refactor the code so that it accounds for a difference between the filename of the keyfile, and the profile_dir used for generating the UUID.
2018-10-02 19:53:54 +02:00
nm_keyfile_read_ensure_id(con, filename);
nm_keyfile_read_ensure_uuid(con, keyfile_name);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
nmtst: add nmtst_assert_connection_verify() and don't normalize connection in assert It is ugly that nmtst_assert_connection_verifies_after_normalization() would normalize the argument and modify it. An assertion should not have side-effects.
2016-02-15 00:37:22 +01:00
if (needs_normalization) {
keyfile/test: refactor and cleanup _keyfile_convert() _keyfile_convert() should really test for successful round-trip conversion of keyfile-connection and vice versa.
2015-03-13 14:22:38 +01:00
nmtst_assert_connection_verifies_after_normalization(con, 0, 0);
nmtst: add nmtst_assert_connection_verify() and don't normalize connection in assert It is ugly that nmtst_assert_connection_verifies_after_normalization() would normalize the argument and modify it. An assertion should not have side-effects.
2016-02-15 00:37:22 +01:00
nmtst_connection_normalize(con);
libnm/proxy: add proxy setting for non-slave connection during normalization And reject slave settings with proxies.
2016-10-04 16:44:39 +02:00
} else {
{
NMSettingConnection *s_con;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm/proxy: add proxy setting for non-slave connection during normalization And reject slave settings with proxies.
2016-10-04 16:44:39 +02:00
/* a non-slave connection must have a proxy setting, but
* keyfile reader does not add that (unless a [proxy] section
* is present. */
s_con = nm_connection_get_setting_connection(con);
if (s_con && !nm_setting_connection_get_master(s_con)
&& !nm_connection_get_setting_proxy(con))
nm_connection_add_setting(con, nm_setting_proxy_new());
}
keyfile/test: refactor and cleanup _keyfile_convert() _keyfile_convert() should really test for successful round-trip conversion of keyfile-connection and vice versa.
2015-03-13 14:22:38 +01:00
nmtst_assert_connection_verifies_without_normalization(con);
libnm/proxy: add proxy setting for non-slave connection during normalization And reject slave settings with proxies.
2016-10-04 16:44:39 +02:00
}
keyfile/test: refactor and cleanup _keyfile_convert() _keyfile_convert() should really test for successful round-trip conversion of keyfile-connection and vice versa.
2015-03-13 14:22:38 +01:00
return con;
}
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
static void
_keyfile_convert(NMConnection ** con,
GKeyFile ** keyfile,
const char * keyfile_name,
NMKeyfileReadHandler read_handler,
void * read_data,
NMKeyfileWriteHandler write_handler,
void * write_data,
gboolean needs_normalization)
{
keyfile/test: refactor and cleanup _keyfile_convert() _keyfile_convert() should really test for successful round-trip conversion of keyfile-connection and vice versa.
2015-03-13 14:22:38 +01:00
NMConnection * c0;
GKeyFile * k0;
gs_unref_object NMConnection *c0_k1_c2 = NULL, *k0_c1 = NULL, *k0_c1_k2_c3 = NULL;
all: replace cleanup macro "gs_unref_keyfile" by "nm_auto_unref_keyfile"
2020-09-02 17:36:08 +02:00
nm_auto_unref_keyfile GKeyFile *k0_c1_k2 = NULL, *c0_k1 = NULL, *c0_k1_c2_k3 = NULL;
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
/* convert from @con to @keyfile and check that we can make
* full round trips and obtaining the same result. */
g_assert(con);
g_assert(keyfile);
g_assert(*con || *keyfile);
keyfile/test: refactor and cleanup _keyfile_convert() _keyfile_convert() should really test for successful round-trip conversion of keyfile-connection and vice versa.
2015-03-13 14:22:38 +01:00
c0 = *con;
k0 = *keyfile;
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
keyfile/test: refactor and cleanup _keyfile_convert() _keyfile_convert() should really test for successful round-trip conversion of keyfile-connection and vice versa.
2015-03-13 14:22:38 +01:00
if (c0) {
c0_k1 = _nm_keyfile_write(c0, write_handler, write_data);
keyfile: split automatically setting ID/UUID for keyfile keyfile already supports omitting the "connection.id" and "connection.uuid". In that case, the ID would be taken from the keyfile's name, and the UUID was generated by md5 hashing the full filename. No longer do this during nm_keyfile_read(), instead let all callers call nm_keyfile_read_ensure_*() to their liking. This is done for two reasons: - a minor reason is, that one day we want to expose keyfile API as public API. That means, we also want to read keyfiles from stdin, where there is no filename available. The implementation which parses stdio needs to define their own way of auto-generating ID and UUID. Note how nm_keyfile_read()'s API no longer takes a filename as argument, which would be awkward for the stdin case. - Currently, we only support one keyfile directory, which (configurably) is "/etc/NetworkManager/system-connections". In the future, we want to support multiple keyfile dirctories, like "/var/run/NetworkManager/profiles" or "/usr/lib/NetworkManager/profiles". Here we want that a file "foo" (which does not specify a UUID) gets the same UUID regardless of the directory it is in. That seems better, because then the UUID won't change as you move the file between directories. Yes, that means, that the same UUID will be provided by multiple files, but NetworkManager must already cope with that situation anyway. Unfortunately, the UUID generation scheme hashes the full path. That means, we must hash the path name of the file "foo" inside the original "system-connections" directory. Refactor the code so that it accounds for a difference between the filename of the keyfile, and the profile_dir used for generating the UUID.
2018-10-02 19:53:54 +02:00
c0_k1_c2 = _nm_keyfile_read(c0_k1, keyfile_name, read_handler, read_data, FALSE);
keyfile/test: refactor and cleanup _keyfile_convert() _keyfile_convert() should really test for successful round-trip conversion of keyfile-connection and vice versa.
2015-03-13 14:22:38 +01:00
c0_k1_c2_k3 = _nm_keyfile_write(c0_k1_c2, write_handler, write_data);
libnm: consider ordering for _nm_keyfile_equals() GKeyFile considers the order of the files, so add a possibility to check whether to keyfiles are equal -- also with respect to the order of the elements.
2015-06-11 21:12:00 +02:00
g_assert(_nm_keyfile_equals(c0_k1, c0_k1_c2_k3, TRUE));
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
}
keyfile/test: refactor and cleanup _keyfile_convert() _keyfile_convert() should really test for successful round-trip conversion of keyfile-connection and vice versa.
2015-03-13 14:22:38 +01:00
if (k0) {
NMSetting8021x *s1, *s2;
keyfile: split automatically setting ID/UUID for keyfile keyfile already supports omitting the "connection.id" and "connection.uuid". In that case, the ID would be taken from the keyfile's name, and the UUID was generated by md5 hashing the full filename. No longer do this during nm_keyfile_read(), instead let all callers call nm_keyfile_read_ensure_*() to their liking. This is done for two reasons: - a minor reason is, that one day we want to expose keyfile API as public API. That means, we also want to read keyfiles from stdin, where there is no filename available. The implementation which parses stdio needs to define their own way of auto-generating ID and UUID. Note how nm_keyfile_read()'s API no longer takes a filename as argument, which would be awkward for the stdin case. - Currently, we only support one keyfile directory, which (configurably) is "/etc/NetworkManager/system-connections". In the future, we want to support multiple keyfile dirctories, like "/var/run/NetworkManager/profiles" or "/usr/lib/NetworkManager/profiles". Here we want that a file "foo" (which does not specify a UUID) gets the same UUID regardless of the directory it is in. That seems better, because then the UUID won't change as you move the file between directories. Yes, that means, that the same UUID will be provided by multiple files, but NetworkManager must already cope with that situation anyway. Unfortunately, the UUID generation scheme hashes the full path. That means, we must hash the path name of the file "foo" inside the original "system-connections" directory. Refactor the code so that it accounds for a difference between the filename of the keyfile, and the profile_dir used for generating the UUID.
2018-10-02 19:53:54 +02:00
k0_c1 = _nm_keyfile_read(k0, keyfile_name, read_handler, read_data, needs_normalization);
keyfile/test: refactor and cleanup _keyfile_convert() _keyfile_convert() should really test for successful round-trip conversion of keyfile-connection and vice versa.
2015-03-13 14:22:38 +01:00
k0_c1_k2 = _nm_keyfile_write(k0_c1, write_handler, write_data);
keyfile: split automatically setting ID/UUID for keyfile keyfile already supports omitting the "connection.id" and "connection.uuid". In that case, the ID would be taken from the keyfile's name, and the UUID was generated by md5 hashing the full filename. No longer do this during nm_keyfile_read(), instead let all callers call nm_keyfile_read_ensure_*() to their liking. This is done for two reasons: - a minor reason is, that one day we want to expose keyfile API as public API. That means, we also want to read keyfiles from stdin, where there is no filename available. The implementation which parses stdio needs to define their own way of auto-generating ID and UUID. Note how nm_keyfile_read()'s API no longer takes a filename as argument, which would be awkward for the stdin case. - Currently, we only support one keyfile directory, which (configurably) is "/etc/NetworkManager/system-connections". In the future, we want to support multiple keyfile dirctories, like "/var/run/NetworkManager/profiles" or "/usr/lib/NetworkManager/profiles". Here we want that a file "foo" (which does not specify a UUID) gets the same UUID regardless of the directory it is in. That seems better, because then the UUID won't change as you move the file between directories. Yes, that means, that the same UUID will be provided by multiple files, but NetworkManager must already cope with that situation anyway. Unfortunately, the UUID generation scheme hashes the full path. That means, we must hash the path name of the file "foo" inside the original "system-connections" directory. Refactor the code so that it accounds for a difference between the filename of the keyfile, and the profile_dir used for generating the UUID.
2018-10-02 19:53:54 +02:00
k0_c1_k2_c3 = _nm_keyfile_read(k0_c1_k2, keyfile_name, read_handler, read_data, FALSE);
keyfile/test: refactor and cleanup _keyfile_convert() _keyfile_convert() should really test for successful round-trip conversion of keyfile-connection and vice versa.
2015-03-13 14:22:38 +01:00
docs: misc. typos pt2 Remainder of typos found using `codespell -q 3 --skip="./shared,./src/systemd,*.po" -I ../NetworkManager-word-whitelist.txt` whereby whitelist consists of: ``` ans busses cace cna conexant crasher iff liftime creat nd sav technik uint ``` https://github.com/NetworkManager/NetworkManager/pull/205
2018-09-15 07:20:54 -04:00
/* It is a expected behavior, that if @k0 contains a relative path ca-cert, @k0_c1 will
keyfile/test: refactor and cleanup _keyfile_convert() _keyfile_convert() should really test for successful round-trip conversion of keyfile-connection and vice versa.
2015-03-13 14:22:38 +01:00
* contain that path as relative. But @k0_c1_k2 and @k0_c1_k2_c3 will have absolute paths.
* In this case, hack up @k0_c1_k2_c3 to contain the same relative path. */
s1 = nm_connection_get_setting_802_1x(k0_c1);
s2 = nm_connection_get_setting_802_1x(k0_c1_k2_c3);
if (s1 || s2) {
g_assert_cmpint(nm_setting_802_1x_get_ca_cert_scheme(s1),
==,
nm_setting_802_1x_get_ca_cert_scheme(s2));
switch (nm_setting_802_1x_get_ca_cert_scheme(s1)) {
case NM_SETTING_802_1X_CK_SCHEME_PATH:
{
const char *p1 = nm_setting_802_1x_get_ca_cert_path(s1);
const char *p2 = nm_setting_802_1x_get_ca_cert_path(s2);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile/test: refactor and cleanup _keyfile_convert() _keyfile_convert() should really test for successful round-trip conversion of keyfile-connection and vice versa.
2015-03-13 14:22:38 +01:00
nmtst_assert_resolve_relative_path_equals(p1, p2);
if (strcmp(p1, p2) != 0) {
gs_free char * puri = NULL;
gs_unref_bytes GBytes *pfile = NULL;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile/test: refactor and cleanup _keyfile_convert() _keyfile_convert() should really test for successful round-trip conversion of keyfile-connection and vice versa.
2015-03-13 14:22:38 +01:00
g_assert(p1[0] != '/' && p2[0] == '/');
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile/test: refactor and cleanup _keyfile_convert() _keyfile_convert() should really test for successful round-trip conversion of keyfile-connection and vice versa.
2015-03-13 14:22:38 +01:00
/* one of the paths is a relative path and the other is absolute. This is an
* expected difference.
* Make the paths of s2 identical to s1... */
puri = g_strconcat(NM_SETTING_802_1X_CERT_SCHEME_PREFIX_PATH, p1, NULL);
pfile = g_bytes_new(puri, strlen(puri) + 1);
g_object_set(s2, NM_SETTING_802_1X_CA_CERT, pfile, NULL);
}
} break;
case NM_SETTING_802_1X_CK_SCHEME_BLOB:
{
GBytes *b1, *b2;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile/test: refactor and cleanup _keyfile_convert() _keyfile_convert() should really test for successful round-trip conversion of keyfile-connection and vice versa.
2015-03-13 14:22:38 +01:00
b1 = nm_setting_802_1x_get_ca_cert_blob(s1);
b2 = nm_setting_802_1x_get_ca_cert_blob(s2);
tests: minor code cleanup in tests Use nmtst_assert_success(), nm_auto() macros, and minor cleanups.
2018-08-22 21:35:33 +02:00
g_assert(b1);
g_assert(b2);
g_assert(g_bytes_equal(b1, b2));
keyfile/test: refactor and cleanup _keyfile_convert() _keyfile_convert() should really test for successful round-trip conversion of keyfile-connection and vice versa.
2015-03-13 14:22:38 +01:00
break;
}
default:
break;
}
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile/test: refactor and cleanup _keyfile_convert() _keyfile_convert() should really test for successful round-trip conversion of keyfile-connection and vice versa.
2015-03-13 14:22:38 +01:00
nmtst_assert_connection_equals(k0_c1, FALSE, k0_c1_k2_c3, FALSE);
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile/test: refactor and cleanup _keyfile_convert() _keyfile_convert() should really test for successful round-trip conversion of keyfile-connection and vice versa.
2015-03-13 14:22:38 +01:00
if (!k0)
*keyfile = g_key_file_ref(c0_k1);
else if (!c0)
*con = g_object_ref(k0_c1);
else {
/* finally, if both a keyfile and a connection are given, assert that they are equal
* after a round of conversion. */
libnm: consider ordering for _nm_keyfile_equals() GKeyFile considers the order of the files, so add a possibility to check whether to keyfiles are equal -- also with respect to the order of the elements.
2015-06-11 21:12:00 +02:00
g_assert(_nm_keyfile_equals(c0_k1, k0_c1_k2, TRUE));
keyfile/test: refactor and cleanup _keyfile_convert() _keyfile_convert() should really test for successful round-trip conversion of keyfile-connection and vice versa.
2015-03-13 14:22:38 +01:00
nmtst_assert_connection_equals(k0_c1, FALSE, c0_k1_c2, FALSE);
}
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
static void
_test_8021x_cert_check(NMConnection * con,
NMSetting8021xCKScheme expected_scheme,
const void * value,
gssize val_len)
{
GKeyFile * keyfile = NULL;
NMSetting8021x *s_8021x;
gs_free char * kval = NULL;
keyfile: split automatically setting ID/UUID for keyfile keyfile already supports omitting the "connection.id" and "connection.uuid". In that case, the ID would be taken from the keyfile's name, and the UUID was generated by md5 hashing the full filename. No longer do this during nm_keyfile_read(), instead let all callers call nm_keyfile_read_ensure_*() to their liking. This is done for two reasons: - a minor reason is, that one day we want to expose keyfile API as public API. That means, we also want to read keyfiles from stdin, where there is no filename available. The implementation which parses stdio needs to define their own way of auto-generating ID and UUID. Note how nm_keyfile_read()'s API no longer takes a filename as argument, which would be awkward for the stdin case. - Currently, we only support one keyfile directory, which (configurably) is "/etc/NetworkManager/system-connections". In the future, we want to support multiple keyfile dirctories, like "/var/run/NetworkManager/profiles" or "/usr/lib/NetworkManager/profiles". Here we want that a file "foo" (which does not specify a UUID) gets the same UUID regardless of the directory it is in. That seems better, because then the UUID won't change as you move the file between directories. Yes, that means, that the same UUID will be provided by multiple files, but NetworkManager must already cope with that situation anyway. Unfortunately, the UUID generation scheme hashes the full path. That means, we must hash the path name of the file "foo" inside the original "system-connections" directory. Refactor the code so that it accounds for a difference between the filename of the keyfile, and the profile_dir used for generating the UUID.
2018-10-02 19:53:54 +02:00
_keyfile_convert(&con, &keyfile, "/_test_8021x_cert_check/foo", NULL, NULL, NULL, NULL, FALSE);
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
s_8021x = nm_connection_get_setting_802_1x(con);
g_assert(nm_setting_802_1x_get_ca_cert_scheme(s_8021x) == expected_scheme);
if (expected_scheme == NM_SETTING_802_1X_CK_SCHEME_PATH) {
const char *path = nm_setting_802_1x_get_ca_cert_path(s_8021x);
g_assert_cmpstr(path, ==, value);
g_assert(val_len == -1 || strlen(path) == val_len);
kval = g_key_file_get_string(keyfile, "802-1x", "ca-cert", NULL);
g_assert(kval);
g_assert_cmpstr(kval, ==, value);
} else if (expected_scheme == NM_SETTING_802_1X_CK_SCHEME_BLOB) {
GBytes * blob = nm_setting_802_1x_get_ca_cert_blob(s_8021x);
gs_free char *file_blob = NULL;
if (val_len == -1) {
gsize l;
gboolean success;
success = g_file_get_contents(value, &file_blob, &l, NULL);
g_assert(success);
value = file_blob;
val_len = l;
}
g_assert(blob);
all: use nm_utils_gbytes_equal_mem()
2018-08-22 20:49:43 +02:00
g_assert(nm_utils_gbytes_equal_mem(blob, value, val_len));
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
kval = g_key_file_get_string(keyfile, "802-1x", "ca-cert", NULL);
g_assert(kval);
g_assert(g_str_has_prefix(kval, NM_KEYFILE_CERT_SCHEME_PREFIX_BLOB));
}
g_key_file_unref(keyfile);
}
static void
_test_8021x_cert_check_blob_full(NMConnection *con, const void *data, gsize len)
{
GBytes * bytes;
NMSetting8021x *s_8021x = nm_connection_get_setting_802_1x(con);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
bytes = g_bytes_new(data, len);
g_object_set(s_8021x, NM_SETTING_802_1X_CA_CERT, bytes, NULL);
_test_8021x_cert_check(con,
NM_SETTING_802_1X_CK_SCHEME_BLOB,
g_bytes_get_data(bytes, NULL),
g_bytes_get_size(bytes));
g_bytes_unref(bytes);
}
all/trivial: rename STRLEN() macro to NM_STRLEN() We should not have defines/macros in header files without a nm/NM prefix. STRLEN() was one of the few offenders. https://mail.gnome.org/archives/networkmanager-list/2016-February/msg00048.html
2016-02-12 12:34:43 +01:00
#define _test_8021x_cert_check_blob(con, data) \
_test_8021x_cert_check_blob_full(con, data, NM_STRLEN(data))
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
static void
libnm/crypto: accept TPM2-wrapped PEM keys Some tools that NM can interact with (eg. openconnect) have added automated support to handle TPM2-wrapped PEM keys as drop-in replacements for ordinary key files. Make sure that NM doesn't reject these keys upfront. We cannot reliably assume NM to be able to unwrap and validate the key. Therefore, accept any key as long as the PEM header and trailer look ok.
2019-06-24 12:09:12 +02:00
_test_8021x_cert_from_files(const char *cert, const char *key)
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
{
NMSetting8021x *s_8021x;
gs_unref_object NMConnection *con =
nmtst_create_minimal_connection("test-cert", NULL, NM_SETTING_WIRED_SETTING_NAME, NULL);
GError * error = NULL;
gboolean success;
NMSetting8021xCKScheme scheme = NM_SETTING_802_1X_CK_SCHEME_PATH;
libnm/crypto: accept TPM2-wrapped PEM keys Some tools that NM can interact with (eg. openconnect) have added automated support to handle TPM2-wrapped PEM keys as drop-in replacements for ordinary key files. Make sure that NM doesn't reject these keys upfront. We cannot reliably assume NM to be able to unwrap and validate the key. Therefore, accept any key as long as the PEM header and trailer look ok.
2019-06-24 12:09:12 +02:00
gs_free char *full_TEST_WIRED_TLS_CA_CERT = nmtst_file_resolve_relative_path(cert, NULL);
gs_free char *full_TEST_WIRED_TLS_PRIVKEY = nmtst_file_resolve_relative_path(key, NULL);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
/* test writing/reading of certificates of NMSetting8021x */
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
/* create a valid connection with NMSetting8021x */
s_8021x = (NMSetting8021x *) nm_setting_802_1x_new();
nm_setting_802_1x_add_eap_method(s_8021x, "tls");
g_object_set(s_8021x, NM_SETTING_802_1X_IDENTITY, "Bill Smith", NULL);
success =
nm_setting_802_1x_set_ca_cert(s_8021x, full_TEST_WIRED_TLS_CA_CERT, scheme, NULL, &error);
g_assert_no_error(error);
g_assert(success);
success = nm_setting_802_1x_set_client_cert(s_8021x,
full_TEST_WIRED_TLS_CA_CERT,
scheme,
NULL,
&error);
g_assert_no_error(error);
g_assert(success);
success = nm_setting_802_1x_set_private_key(s_8021x,
full_TEST_WIRED_TLS_PRIVKEY,
"test1",
scheme,
NULL,
&error);
g_assert_no_error(error);
g_assert(success);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
docs: misc. typos pt2 Remainder of typos found using `codespell -q 3 --skip="./shared,./src/systemd,*.po" -I ../NetworkManager-word-whitelist.txt` whereby whitelist consists of: ``` ans busses cace cna conexant crasher iff liftime creat nd sav technik uint ``` https://github.com/NetworkManager/NetworkManager/pull/205
2018-09-15 07:20:54 -04:00
/* test resetting ca-cert to different values and see whether we can write/read. */
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
nm_connection_add_setting(con, NM_SETTING(s_8021x));
nmtst_assert_connection_verifies_and_normalizable(con);
nmtst: add nmtst_assert_connection_verify() and don't normalize connection in assert It is ugly that nmtst_assert_connection_verifies_after_normalization() would normalize the argument and modify it. An assertion should not have side-effects.
2016-02-15 00:37:22 +01:00
nmtst_connection_normalize(con);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
_test_8021x_cert_check(con, scheme, full_TEST_WIRED_TLS_CA_CERT, -1);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
scheme = NM_SETTING_802_1X_CK_SCHEME_BLOB;
success =
nm_setting_802_1x_set_ca_cert(s_8021x, full_TEST_WIRED_TLS_CA_CERT, scheme, NULL, &error);
g_assert_no_error(error);
g_assert(success);
_test_8021x_cert_check(con, scheme, full_TEST_WIRED_TLS_CA_CERT, -1);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
_test_8021x_cert_check_blob(con, "a");
_test_8021x_cert_check_blob(con, "\0");
_test_8021x_cert_check_blob(con, "10");
_test_8021x_cert_check_blob(con, "data:;base64,a");
all/trivial: rename STRLEN() macro to NM_STRLEN() We should not have defines/macros in header files without a nm/NM prefix. STRLEN() was one of the few offenders. https://mail.gnome.org/archives/networkmanager-list/2016-February/msg00048.html
2016-02-12 12:34:43 +01:00
_test_8021x_cert_check_blob_full(con, "data:;base64,a", NM_STRLEN("data:;base64,a") + 1);
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
_test_8021x_cert_check_blob(con, "data:;base64,file://a");
_test_8021x_cert_check_blob(con, "123");
}
libnm/crypto: accept TPM2-wrapped PEM keys Some tools that NM can interact with (eg. openconnect) have added automated support to handle TPM2-wrapped PEM keys as drop-in replacements for ordinary key files. Make sure that NM doesn't reject these keys upfront. We cannot reliably assume NM to be able to unwrap and validate the key. Therefore, accept any key as long as the PEM header and trailer look ok.
2019-06-24 12:09:12 +02:00
static void
test_8021x_cert(void)
{
_test_8021x_cert_from_files(TEST_WIRED_TLS_CA_CERT, TEST_WIRED_TLS_PRIVKEY);
}
static void
test_8021x_cert_tpm2key(void)
{
_test_8021x_cert_from_files(TEST_WIRED_TLS_CA_CERT, TEST_WIRED_TLS_TPM2KEY);
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
static void
test_8021x_cert_read(void)
{
GKeyFile * keyfile = NULL;
gs_unref_object NMConnection *con = NULL;
NMSetting8021x * s_8021x;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
test: add nmtst_create_connection_from_keyfile()
2015-02-27 10:24:09 +01:00
con = nmtst_create_connection_from_keyfile("[connection]\n"
"type=ethernet",
keyfile: split automatically setting ID/UUID for keyfile keyfile already supports omitting the "connection.id" and "connection.uuid". In that case, the ID would be taken from the keyfile's name, and the UUID was generated by md5 hashing the full filename. No longer do this during nm_keyfile_read(), instead let all callers call nm_keyfile_read_ensure_*() to their liking. This is done for two reasons: - a minor reason is, that one day we want to expose keyfile API as public API. That means, we also want to read keyfiles from stdin, where there is no filename available. The implementation which parses stdio needs to define their own way of auto-generating ID and UUID. Note how nm_keyfile_read()'s API no longer takes a filename as argument, which would be awkward for the stdin case. - Currently, we only support one keyfile directory, which (configurably) is "/etc/NetworkManager/system-connections". In the future, we want to support multiple keyfile dirctories, like "/var/run/NetworkManager/profiles" or "/usr/lib/NetworkManager/profiles". Here we want that a file "foo" (which does not specify a UUID) gets the same UUID regardless of the directory it is in. That seems better, because then the UUID won't change as you move the file between directories. Yes, that means, that the same UUID will be provided by multiple files, but NetworkManager must already cope with that situation anyway. Unfortunately, the UUID generation scheme hashes the full path. That means, we must hash the path name of the file "foo" inside the original "system-connections" directory. Refactor the code so that it accounds for a difference between the filename of the keyfile, and the profile_dir used for generating the UUID.
2018-10-02 19:53:54 +02:00
"/test_8021x_cert_read/test0");
test: add nmtst_create_connection_from_keyfile()
2015-02-27 10:24:09 +01:00
CLEAR(&con, &keyfile);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
keyfile = _keyfile_load_from_data("[connection]\n"
"type=ethernet");
keyfile: split automatically setting ID/UUID for keyfile keyfile already supports omitting the "connection.id" and "connection.uuid". In that case, the ID would be taken from the keyfile's name, and the UUID was generated by md5 hashing the full filename. No longer do this during nm_keyfile_read(), instead let all callers call nm_keyfile_read_ensure_*() to their liking. This is done for two reasons: - a minor reason is, that one day we want to expose keyfile API as public API. That means, we also want to read keyfiles from stdin, where there is no filename available. The implementation which parses stdio needs to define their own way of auto-generating ID and UUID. Note how nm_keyfile_read()'s API no longer takes a filename as argument, which would be awkward for the stdin case. - Currently, we only support one keyfile directory, which (configurably) is "/etc/NetworkManager/system-connections". In the future, we want to support multiple keyfile dirctories, like "/var/run/NetworkManager/profiles" or "/usr/lib/NetworkManager/profiles". Here we want that a file "foo" (which does not specify a UUID) gets the same UUID regardless of the directory it is in. That seems better, because then the UUID won't change as you move the file between directories. Yes, that means, that the same UUID will be provided by multiple files, but NetworkManager must already cope with that situation anyway. Unfortunately, the UUID generation scheme hashes the full path. That means, we must hash the path name of the file "foo" inside the original "system-connections" directory. Refactor the code so that it accounds for a difference between the filename of the keyfile, and the profile_dir used for generating the UUID.
2018-10-02 19:53:54 +02:00
_keyfile_convert(&con, &keyfile, "/test_8021x_cert_read/test1", NULL, NULL, NULL, NULL, TRUE);
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
CLEAR(&con, &keyfile);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
keyfile = _keyfile_load_from_data(
"[connection]\n"
"type=802-3-ethernet\n"
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
"[802-1x]\n"
"eap=tls;\n"
"identity=Bill Smith\n"
"ca-cert=48;130;2;52;48;130;1;161;2;16;2;173;102;126;78;69;254;94;87;111;60;152;25;94;221;"
"192;48;13;6;9;42;134;72;134;247;13;1;1;2;5;0;48;95;49;11;48;9;6;3;85;4;6;19;2;85;83;49;32;"
"48;30;6;3;85;4;10;19;23;82;83;65;32;68;97;116;97;32;83;101;99;117;114;105;116;121;44;32;"
"73;110;99;46;49;46;48;44;6;3;85;4;11;19;37;83;101;99;117;114;101;32;83;101;114;118;101;"
"114;32;67;101;114;116;105;102;105;99;97;116;105;111;110;32;65;117;116;104;111;114;105;116;"
"121;48;30;23;13;57;52;49;49;48;57;48;48;48;48;48;48;90;23;13;49;48;48;49;48;55;50;51;53;"
"57;53;57;90;48;95;49;11;48;9;6;3;85;4;6;19;2;85;83;49;32;48;30;6;3;85;4;10;19;23;82;83;65;"
"32;68;97;116;97;32;83;101;99;117;114;105;116;121;44;32;73;110;99;46;49;46;48;44;6;3;85;4;"
"11;19;37;83;101;99;117;114;101;32;83;101;114;118;101;114;32;67;101;114;116;105;102;105;99;"
"97;116;105;111;110;32;65;117;116;104;111;114;105;116;121;48;129;155;48;13;6;9;42;134;72;"
"134;247;13;1;1;1;5;0;3;129;137;0;48;129;133;2;126;0;146;206;122;193;174;131;62;90;170;137;"
"131;87;172;37;1;118;12;173;174;142;44;55;206;235;53;120;100;84;3;229;132;64;81;201;191;"
"143;8;226;138;130;8;210;22;134;55;85;233;177;33;2;173;118;104;129;154;5;162;75;201;75;37;"
"102;34;86;108;136;7;143;247;129;89;109;132;7;101;112;19;113;118;62;155;119;76;227;80;137;"
"86;152;72;185;29;167;41;26;19;46;74;17;89;156;30;21;213;73;84;44;115;58;105;130;177;151;"
"57;156;109;112;103;72;229;221;45;214;200;30;123;2;3;1;0;1;48;13;6;9;42;134;72;134;247;13;"
"1;1;2;5;0;3;126;0;101;221;126;225;178;236;176;226;58;224;236;113;70;154;25;17;184;211;199;"
"160;180;3;64;38;2;62;9;156;225;18;179;209;90;246;55;165;183;97;3;182;91;22;105;59;198;68;"
"8;12;136;83;12;107;151;73;199;62;53;220;108;185;187;170;223;92;187;58;47;147;96;182;169;"
"75;77;242;32;247;205;95;127;100;123;142;220;0;92;215;250;119;202;57;22;89;111;14;234;211;"
"181;131;127;77;77;66;86;118;180;201;95;4;248;56;248;235;210;95;117;95;205;123;252;229;142;"
"128;124;252;80;\n"
"client-cert=102;105;108;101;58;47;47;47;104;111;109;101;47;100;99;98;119;47;68;101;115;"
"107;116;111;112;47;99;101;114;116;105;110;102;114;97;47;99;108;105;101;110;116;46;112;101;"
"109;0;\n"
"private-key=102;105;108;101;58;47;47;47;104;111;109;101;47;100;99;98;119;47;68;101;115;"
"107;116;111;112;47;99;101;114;116;105;110;102;114;97;47;99;108;105;101;110;116;46;112;101;"
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
"109;0;\n"
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
"private-key-password=12345testing\n");
keyfile: split automatically setting ID/UUID for keyfile keyfile already supports omitting the "connection.id" and "connection.uuid". In that case, the ID would be taken from the keyfile's name, and the UUID was generated by md5 hashing the full filename. No longer do this during nm_keyfile_read(), instead let all callers call nm_keyfile_read_ensure_*() to their liking. This is done for two reasons: - a minor reason is, that one day we want to expose keyfile API as public API. That means, we also want to read keyfiles from stdin, where there is no filename available. The implementation which parses stdio needs to define their own way of auto-generating ID and UUID. Note how nm_keyfile_read()'s API no longer takes a filename as argument, which would be awkward for the stdin case. - Currently, we only support one keyfile directory, which (configurably) is "/etc/NetworkManager/system-connections". In the future, we want to support multiple keyfile dirctories, like "/var/run/NetworkManager/profiles" or "/usr/lib/NetworkManager/profiles". Here we want that a file "foo" (which does not specify a UUID) gets the same UUID regardless of the directory it is in. That seems better, because then the UUID won't change as you move the file between directories. Yes, that means, that the same UUID will be provided by multiple files, but NetworkManager must already cope with that situation anyway. Unfortunately, the UUID generation scheme hashes the full path. That means, we must hash the path name of the file "foo" inside the original "system-connections" directory. Refactor the code so that it accounds for a difference between the filename of the keyfile, and the profile_dir used for generating the UUID.
2018-10-02 19:53:54 +02:00
_keyfile_convert(&con, &keyfile, "/test_8021x_cert_read/test2", NULL, NULL, NULL, NULL, TRUE);
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
CLEAR(&con, &keyfile);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
keyfile =
_keyfile_load_from_data("[connection]\n"
"type=802-3-ethernet\n"
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
"[802-1x]\n"
"eap=tls;\n"
"identity=Bill Smith\n"
/* unqualified strings are only recognized as path up to 500 chars*/
"ca-cert="
"/11111111111111111111111111111111111111111111111111111111111111111"
"1111111111111111111111111111111111"
"/11111111111111111111111111111111111111111111111111111111111111111"
"1111111111111111111111111111111111"
"/11111111111111111111111111111111111111111111111111111111111111111"
"1111111111111111111111111111111111"
"/11111111111111111111111111111111111111111111111111111111111111111"
"1111111111111111111111111111111111"
"/11111111111111111111111111111111111111111111111111111111111111111"
"111111111111111111111111111111111\n"
"client-cert=/"
"222222222222222222222222222222222222222222222222222222222222222222"
"222222222222222222222222222222221"
"/22222222222222222222222222222222222222222222222222222222222222222"
"2222222222222222222222222222222221"
keyfile: split automatically setting ID/UUID for keyfile keyfile already supports omitting the "connection.id" and "connection.uuid". In that case, the ID would be taken from the keyfile's name, and the UUID was generated by md5 hashing the full filename. No longer do this during nm_keyfile_read(), instead let all callers call nm_keyfile_read_ensure_*() to their liking. This is done for two reasons: - a minor reason is, that one day we want to expose keyfile API as public API. That means, we also want to read keyfiles from stdin, where there is no filename available. The implementation which parses stdio needs to define their own way of auto-generating ID and UUID. Note how nm_keyfile_read()'s API no longer takes a filename as argument, which would be awkward for the stdin case. - Currently, we only support one keyfile directory, which (configurably) is "/etc/NetworkManager/system-connections". In the future, we want to support multiple keyfile dirctories, like "/var/run/NetworkManager/profiles" or "/usr/lib/NetworkManager/profiles". Here we want that a file "foo" (which does not specify a UUID) gets the same UUID regardless of the directory it is in. That seems better, because then the UUID won't change as you move the file between directories. Yes, that means, that the same UUID will be provided by multiple files, but NetworkManager must already cope with that situation anyway. Unfortunately, the UUID generation scheme hashes the full path. That means, we must hash the path name of the file "foo" inside the original "system-connections" directory. Refactor the code so that it accounds for a difference between the filename of the keyfile, and the profile_dir used for generating the UUID.
2018-10-02 19:53:54 +02:00
"/22222222222222222222222222222222222222222222222222222222222222222"
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
"2222222222222222222222222222222221"
"/22222222222222222222222222222222222222222222222222222222222222222"
"2222222222222222222222222222222221"
"/22222222222222222222222222222222222222222222222222222222222222222"
"2222222222222222222222222222222222\n"
"private-key=file://"
"/33333333333333333333333333333333333333333333333333333333333333333"
"3333333333333333333333333333333331"
"/33333333333333333333333333333333333333333333333333333333333333333"
"3333333333333333333333333333333331"
"/33333333333333333333333333333333333333333333333333333333333333333"
"3333333333333333333333333333333331"
"/33333333333333333333333333333333333333333333333333333333333333333"
"3333333333333333333333333333333331"
"/33333333333333333333333333333333333333333333333333333333333333333"
"333333333333333333333333333333333111111\n"
"private-key-password=12345testing\n");
_keyfile_convert(&con, &keyfile, "/test_8021x_cert_read/test2", NULL, NULL, NULL, NULL, TRUE);
s_8021x = nm_connection_get_setting_802_1x(con);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
g_assert(nm_setting_802_1x_get_ca_cert_scheme(s_8021x) == NM_SETTING_802_1X_CK_SCHEME_PATH);
g_assert(g_str_has_prefix(nm_setting_802_1x_get_ca_cert_path(s_8021x), "/111111111111"));
g_assert_cmpint(strlen(nm_setting_802_1x_get_ca_cert_path(s_8021x)), ==, 499);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
g_assert(nm_setting_802_1x_get_client_cert_scheme(s_8021x) == NM_SETTING_802_1X_CK_SCHEME_BLOB);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
g_assert(
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
g_str_has_prefix(g_bytes_get_data(nm_setting_802_1x_get_client_cert_blob(s_8021x), NULL),
"/2222222222"));
g_assert_cmpint(g_bytes_get_size(nm_setting_802_1x_get_client_cert_blob(s_8021x)),
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
==,
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
500 + 1 /* keyfile reader adds a trailing NUL */);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
g_assert(nm_setting_802_1x_get_private_key_scheme(s_8021x) == NM_SETTING_802_1X_CK_SCHEME_PATH);
g_assert(g_str_has_prefix(nm_setting_802_1x_get_private_key_path(s_8021x), "/333333333"));
g_assert_cmpint(strlen(nm_setting_802_1x_get_private_key_path(s_8021x)), ==, 505);
CLEAR(&con, &keyfile);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
keyfile = _keyfile_load_from_data("[connection]\n"
"type=802-3-ethernet\n"
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
"[802-1x]\n"
"eap=tls;\n"
"identity=Bill Smith\n"
"ca-cert=/\n"
"client-cert=a.pem\n"
"private-key=data:;base64,aGFsbG8=\n" // hallo
"private-key-password=12345testing\n");
_keyfile_convert(&con, &keyfile, "/test_8021x_cert_read/test2", NULL, NULL, NULL, NULL, TRUE);
s_8021x = nm_connection_get_setting_802_1x(con);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
g_assert(nm_setting_802_1x_get_ca_cert_scheme(s_8021x) == NM_SETTING_802_1X_CK_SCHEME_PATH);
g_assert_cmpstr(nm_setting_802_1x_get_ca_cert_path(s_8021x), ==, "/");
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
g_assert(nm_setting_802_1x_get_client_cert_scheme(s_8021x) == NM_SETTING_802_1X_CK_SCHEME_PATH);
g_assert_cmpstr(nm_setting_802_1x_get_client_cert_path(s_8021x),
==,
"/test_8021x_cert_read/a.pem");
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
g_assert(nm_setting_802_1x_get_private_key_scheme(s_8021x) == NM_SETTING_802_1X_CK_SCHEME_BLOB);
_assert_gbytes(nm_setting_802_1x_get_private_key_blob(s_8021x), "hallo", -1);
CLEAR(&con, &keyfile);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
keyfile = _keyfile_load_from_data("[connection]\n"
"type=802-3-ethernet\n"
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
"[802-1x]\n"
"eap=tls;\n"
"identity=Bill Smith\n"
"ca-cert=file://data:;base64,x\n"
"client-cert=abc.der\n"
"private-key=abc.deR\n"
"private-key-password=12345testing\n");
keyfile: split automatically setting ID/UUID for keyfile keyfile already supports omitting the "connection.id" and "connection.uuid". In that case, the ID would be taken from the keyfile's name, and the UUID was generated by md5 hashing the full filename. No longer do this during nm_keyfile_read(), instead let all callers call nm_keyfile_read_ensure_*() to their liking. This is done for two reasons: - a minor reason is, that one day we want to expose keyfile API as public API. That means, we also want to read keyfiles from stdin, where there is no filename available. The implementation which parses stdio needs to define their own way of auto-generating ID and UUID. Note how nm_keyfile_read()'s API no longer takes a filename as argument, which would be awkward for the stdin case. - Currently, we only support one keyfile directory, which (configurably) is "/etc/NetworkManager/system-connections". In the future, we want to support multiple keyfile dirctories, like "/var/run/NetworkManager/profiles" or "/usr/lib/NetworkManager/profiles". Here we want that a file "foo" (which does not specify a UUID) gets the same UUID regardless of the directory it is in. That seems better, because then the UUID won't change as you move the file between directories. Yes, that means, that the same UUID will be provided by multiple files, but NetworkManager must already cope with that situation anyway. Unfortunately, the UUID generation scheme hashes the full path. That means, we must hash the path name of the file "foo" inside the original "system-connections" directory. Refactor the code so that it accounds for a difference between the filename of the keyfile, and the profile_dir used for generating the UUID.
2018-10-02 19:53:54 +02:00
_keyfile_convert(&con, &keyfile, "/test_8021x_cert_read/test2", NULL, NULL, NULL, NULL, TRUE);
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
s_8021x = nm_connection_get_setting_802_1x(con);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
g_assert(nm_setting_802_1x_get_ca_cert_scheme(s_8021x) == NM_SETTING_802_1X_CK_SCHEME_PATH);
g_assert_cmpstr(nm_setting_802_1x_get_ca_cert_path(s_8021x), ==, "data:;base64,x");
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
g_assert(nm_setting_802_1x_get_client_cert_scheme(s_8021x) == NM_SETTING_802_1X_CK_SCHEME_PATH);
g_assert_cmpstr(nm_setting_802_1x_get_client_cert_path(s_8021x),
==,
"/test_8021x_cert_read/abc.der");
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
g_assert(nm_setting_802_1x_get_private_key_scheme(s_8021x) == NM_SETTING_802_1X_CK_SCHEME_BLOB);
_assert_gbytes(nm_setting_802_1x_get_private_key_blob(s_8021x), "abc.deR\0", 8);
CLEAR(&con, &keyfile);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
keyfile =
_keyfile_load_from_data("[connection]\n"
"type=802-3-ethernet\n"
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
"[802-1x]\n"
"eap=tls;\n"
"identity=Bill Smith\n"
"ca-cert=104;97;108;108;111;\n" /* "hallo" without trailing NUL */
"client-cert=104;097;108;108;111;0;\n"
"private-key=hallo\n"
"private-key-password=12345testing\n");
keyfile: split automatically setting ID/UUID for keyfile keyfile already supports omitting the "connection.id" and "connection.uuid". In that case, the ID would be taken from the keyfile's name, and the UUID was generated by md5 hashing the full filename. No longer do this during nm_keyfile_read(), instead let all callers call nm_keyfile_read_ensure_*() to their liking. This is done for two reasons: - a minor reason is, that one day we want to expose keyfile API as public API. That means, we also want to read keyfiles from stdin, where there is no filename available. The implementation which parses stdio needs to define their own way of auto-generating ID and UUID. Note how nm_keyfile_read()'s API no longer takes a filename as argument, which would be awkward for the stdin case. - Currently, we only support one keyfile directory, which (configurably) is "/etc/NetworkManager/system-connections". In the future, we want to support multiple keyfile dirctories, like "/var/run/NetworkManager/profiles" or "/usr/lib/NetworkManager/profiles". Here we want that a file "foo" (which does not specify a UUID) gets the same UUID regardless of the directory it is in. That seems better, because then the UUID won't change as you move the file between directories. Yes, that means, that the same UUID will be provided by multiple files, but NetworkManager must already cope with that situation anyway. Unfortunately, the UUID generation scheme hashes the full path. That means, we must hash the path name of the file "foo" inside the original "system-connections" directory. Refactor the code so that it accounds for a difference between the filename of the keyfile, and the profile_dir used for generating the UUID.
2018-10-02 19:53:54 +02:00
_keyfile_convert(&con, &keyfile, "/test_8021x_cert_read/test2", NULL, NULL, NULL, NULL, TRUE);
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
s_8021x = nm_connection_get_setting_802_1x(con);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
g_assert(nm_setting_802_1x_get_ca_cert_scheme(s_8021x) == NM_SETTING_802_1X_CK_SCHEME_BLOB);
_assert_gbytes(nm_setting_802_1x_get_ca_cert_blob(s_8021x), "hallo", 5);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
g_assert(nm_setting_802_1x_get_client_cert_scheme(s_8021x) == NM_SETTING_802_1X_CK_SCHEME_BLOB);
_assert_gbytes(nm_setting_802_1x_get_client_cert_blob(s_8021x), "hallo\0", 6);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
g_assert(nm_setting_802_1x_get_private_key_scheme(s_8021x) == NM_SETTING_802_1X_CK_SCHEME_BLOB);
_assert_gbytes(nm_setting_802_1x_get_private_key_blob(s_8021x), "hallo\0", 6);
CLEAR(&con, &keyfile);
}
team: normalize invalid configuration during load Now that we validate the JSON syntax of a team/team-port configuration, any existing connection with invalid JSON configuration would fail to load and disappear upon upgrade. Instead, modify the setting plugins to emit a warning but still load the connection with empty configuration.
2016-08-30 15:21:16 +02:00
static void
test_team_conf_read_valid(void)
{
GKeyFile * keyfile = NULL;
gs_unref_object NMConnection *con = NULL;
NMSettingTeam * s_team;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
team: normalize invalid configuration during load Now that we validate the JSON syntax of a team/team-port configuration, any existing connection with invalid JSON configuration would fail to load and disappear upon upgrade. Instead, modify the setting plugins to emit a warning but still load the connection with empty configuration.
2016-08-30 15:21:16 +02:00
con = nmtst_create_connection_from_keyfile("[connection]\n"
"type=team\n"
"interface-name=nm-team1\n"
"[team]\n"
"config={\"foo\":\"bar\"}",
keyfile: split automatically setting ID/UUID for keyfile keyfile already supports omitting the "connection.id" and "connection.uuid". In that case, the ID would be taken from the keyfile's name, and the UUID was generated by md5 hashing the full filename. No longer do this during nm_keyfile_read(), instead let all callers call nm_keyfile_read_ensure_*() to their liking. This is done for two reasons: - a minor reason is, that one day we want to expose keyfile API as public API. That means, we also want to read keyfiles from stdin, where there is no filename available. The implementation which parses stdio needs to define their own way of auto-generating ID and UUID. Note how nm_keyfile_read()'s API no longer takes a filename as argument, which would be awkward for the stdin case. - Currently, we only support one keyfile directory, which (configurably) is "/etc/NetworkManager/system-connections". In the future, we want to support multiple keyfile dirctories, like "/var/run/NetworkManager/profiles" or "/usr/lib/NetworkManager/profiles". Here we want that a file "foo" (which does not specify a UUID) gets the same UUID regardless of the directory it is in. That seems better, because then the UUID won't change as you move the file between directories. Yes, that means, that the same UUID will be provided by multiple files, but NetworkManager must already cope with that situation anyway. Unfortunately, the UUID generation scheme hashes the full path. That means, we must hash the path name of the file "foo" inside the original "system-connections" directory. Refactor the code so that it accounds for a difference between the filename of the keyfile, and the profile_dir used for generating the UUID.
2018-10-02 19:53:54 +02:00
"/test_team_conf_read/valid");
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
team: normalize invalid configuration during load Now that we validate the JSON syntax of a team/team-port configuration, any existing connection with invalid JSON configuration would fail to load and disappear upon upgrade. Instead, modify the setting plugins to emit a warning but still load the connection with empty configuration.
2016-08-30 15:21:16 +02:00
g_assert(con);
s_team = nm_connection_get_setting_team(con);
g_assert(s_team);
g_assert_cmpstr(nm_setting_team_get_config(s_team), ==, "{\"foo\":\"bar\"}");
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
team: normalize invalid configuration during load Now that we validate the JSON syntax of a team/team-port configuration, any existing connection with invalid JSON configuration would fail to load and disappear upon upgrade. Instead, modify the setting plugins to emit a warning but still load the connection with empty configuration.
2016-08-30 15:21:16 +02:00
CLEAR(&con, &keyfile);
}
static void
test_team_conf_read_invalid(void)
{
GKeyFile * keyfile = NULL;
gs_unref_object NMConnection *con = NULL;
NMSettingTeam * s_team;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: always build libnm with JSON validation We anyway load libjansson with dlopen(), and already before it could happen that libjansson is not available. In that case, we would not crash, but simply proceed without json validation. Since libnm-core no longer uses libjansson directly, but only via "nm-glib-aux/nm-json.h", we can just always compile with that, and use it at runtime. That means, libjansson is not a build dependency for libnm anymore, so we don't need a compile time check. Note that if you build without libjansson, then JANSSON_SONAME is undefined, and loading it will still fail at runtime. So, even if we now always build with all our code enabled, it only works if you actually build with libjansson. Still, it's simpler to drop the conditional build, as the only benefit is a (minimally) smaller build.
2020-07-01 18:38:22 +02:00
if (!nm_json_vt()) {
libnm/tests: mark team tests as skipped without JSON validation We should not just disable tests with an #if. Instead, mark them as skipped. This way, we still compile them, and we even run them (showing a message why they are skipped).
2019-05-22 16:11:16 +02:00
g_test_skip("team test requires JSON validation");
return;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
team: normalize invalid configuration during load Now that we validate the JSON syntax of a team/team-port configuration, any existing connection with invalid JSON configuration would fail to load and disappear upon upgrade. Instead, modify the setting plugins to emit a warning but still load the connection with empty configuration.
2016-08-30 15:21:16 +02:00
con = nmtst_create_connection_from_keyfile("[connection]\n"
"type=team\n"
"interface-name=nm-team1\n"
"[team]\n"
"config={foobar}",
keyfile: split automatically setting ID/UUID for keyfile keyfile already supports omitting the "connection.id" and "connection.uuid". In that case, the ID would be taken from the keyfile's name, and the UUID was generated by md5 hashing the full filename. No longer do this during nm_keyfile_read(), instead let all callers call nm_keyfile_read_ensure_*() to their liking. This is done for two reasons: - a minor reason is, that one day we want to expose keyfile API as public API. That means, we also want to read keyfiles from stdin, where there is no filename available. The implementation which parses stdio needs to define their own way of auto-generating ID and UUID. Note how nm_keyfile_read()'s API no longer takes a filename as argument, which would be awkward for the stdin case. - Currently, we only support one keyfile directory, which (configurably) is "/etc/NetworkManager/system-connections". In the future, we want to support multiple keyfile dirctories, like "/var/run/NetworkManager/profiles" or "/usr/lib/NetworkManager/profiles". Here we want that a file "foo" (which does not specify a UUID) gets the same UUID regardless of the directory it is in. That seems better, because then the UUID won't change as you move the file between directories. Yes, that means, that the same UUID will be provided by multiple files, but NetworkManager must already cope with that situation anyway. Unfortunately, the UUID generation scheme hashes the full path. That means, we must hash the path name of the file "foo" inside the original "system-connections" directory. Refactor the code so that it accounds for a difference between the filename of the keyfile, and the profile_dir used for generating the UUID.
2018-10-02 19:53:54 +02:00
"/test_team_conf_read/invalid");
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
team: normalize invalid configuration during load Now that we validate the JSON syntax of a team/team-port configuration, any existing connection with invalid JSON configuration would fail to load and disappear upon upgrade. Instead, modify the setting plugins to emit a warning but still load the connection with empty configuration.
2016-08-30 15:21:16 +02:00
g_assert(con);
s_team = nm_connection_get_setting_team(con);
g_assert(s_team);
g_assert(nm_setting_team_get_config(s_team) == NULL);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
team: normalize invalid configuration during load Now that we validate the JSON syntax of a team/team-port configuration, any existing connection with invalid JSON configuration would fail to load and disappear upon upgrade. Instead, modify the setting plugins to emit a warning but still load the connection with empty configuration.
2016-08-30 15:21:16 +02:00
CLEAR(&con, &keyfile);
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
libnm/keyfile: properly read user data from keyfile Hack keyfile reader support for NMSettingUser. Writer support already works. (cherry picked from commit 22fd7d2e39327c9f288dd8f17529c1898bc20e47)
2017-05-04 14:50:07 +02:00
static void
test_user_1(void)
{
all: replace cleanup macro "gs_unref_keyfile" by "nm_auto_unref_keyfile"
2020-09-02 17:36:08 +02:00
nm_auto_unref_keyfile GKeyFile *keyfile = NULL;
libnm/keyfile: properly read user data from keyfile Hack keyfile reader support for NMSettingUser. Writer support already works. (cherry picked from commit 22fd7d2e39327c9f288dd8f17529c1898bc20e47)
2017-05-04 14:50:07 +02:00
gs_unref_object NMConnection *con = NULL;
NMSettingUser * s_user;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm/keyfile: properly read user data from keyfile Hack keyfile reader support for NMSettingUser. Writer support already works. (cherry picked from commit 22fd7d2e39327c9f288dd8f17529c1898bc20e47)
2017-05-04 14:50:07 +02:00
con = nmtst_create_connection_from_keyfile("[connection]\n"
"id=t\n"
"type=ethernet\n"
"\n"
"[user]\n"
"my-value.x=value1\n"
"",
keyfile: split automatically setting ID/UUID for keyfile keyfile already supports omitting the "connection.id" and "connection.uuid". In that case, the ID would be taken from the keyfile's name, and the UUID was generated by md5 hashing the full filename. No longer do this during nm_keyfile_read(), instead let all callers call nm_keyfile_read_ensure_*() to their liking. This is done for two reasons: - a minor reason is, that one day we want to expose keyfile API as public API. That means, we also want to read keyfiles from stdin, where there is no filename available. The implementation which parses stdio needs to define their own way of auto-generating ID and UUID. Note how nm_keyfile_read()'s API no longer takes a filename as argument, which would be awkward for the stdin case. - Currently, we only support one keyfile directory, which (configurably) is "/etc/NetworkManager/system-connections". In the future, we want to support multiple keyfile dirctories, like "/var/run/NetworkManager/profiles" or "/usr/lib/NetworkManager/profiles". Here we want that a file "foo" (which does not specify a UUID) gets the same UUID regardless of the directory it is in. That seems better, because then the UUID won't change as you move the file between directories. Yes, that means, that the same UUID will be provided by multiple files, but NetworkManager must already cope with that situation anyway. Unfortunately, the UUID generation scheme hashes the full path. That means, we must hash the path name of the file "foo" inside the original "system-connections" directory. Refactor the code so that it accounds for a difference between the filename of the keyfile, and the profile_dir used for generating the UUID.
2018-10-02 19:53:54 +02:00
"/test_user_1/invalid");
libnm/keyfile: properly read user data from keyfile Hack keyfile reader support for NMSettingUser. Writer support already works. (cherry picked from commit 22fd7d2e39327c9f288dd8f17529c1898bc20e47)
2017-05-04 14:50:07 +02:00
g_assert(con);
s_user = NM_SETTING_USER(nm_connection_get_setting(con, NM_TYPE_SETTING_USER));
g_assert(s_user);
g_assert_cmpstr(nm_setting_user_get_data(s_user, "my-value.x"), ==, "value1");
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm/keyfile: properly read user data from keyfile Hack keyfile reader support for NMSettingUser. Writer support already works. (cherry picked from commit 22fd7d2e39327c9f288dd8f17529c1898bc20e47)
2017-05-04 14:50:07 +02:00
CLEAR(&con, &keyfile);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm/keyfile: properly read user data from keyfile Hack keyfile reader support for NMSettingUser. Writer support already works. (cherry picked from commit 22fd7d2e39327c9f288dd8f17529c1898bc20e47)
2017-05-04 14:50:07 +02:00
con = nmtst_create_minimal_connection("user-2",
"8b85fb8d-3070-48ba-93d9-53eee231d9a2",
NM_SETTING_WIRED_SETTING_NAME,
NULL);
s_user = NM_SETTING_USER(nm_setting_user_new());
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm/keyfile: properly read user data from keyfile Hack keyfile reader support for NMSettingUser. Writer support already works. (cherry picked from commit 22fd7d2e39327c9f288dd8f17529c1898bc20e47)
2017-05-04 14:50:07 +02:00
#define _USER_SET_DATA(s_user, key, val) \
G_STMT_START \
{ \
GError * _error = NULL; \
gboolean _success; \
\
_success = nm_setting_user_set_data((s_user), (key), (val), &_error); \
nmtst_assert_success(_success, _error); \
} \
G_STMT_END
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm/keyfile: properly read user data from keyfile Hack keyfile reader support for NMSettingUser. Writer support already works. (cherry picked from commit 22fd7d2e39327c9f288dd8f17529c1898bc20e47)
2017-05-04 14:50:07 +02:00
#define _USER_SET_DATA_X(s_user, key) _USER_SET_DATA(s_user, key, "val=" key "")
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm/keyfile: properly read user data from keyfile Hack keyfile reader support for NMSettingUser. Writer support already works. (cherry picked from commit 22fd7d2e39327c9f288dd8f17529c1898bc20e47)
2017-05-04 14:50:07 +02:00
_USER_SET_DATA(s_user, "my.val1", "");
_USER_SET_DATA_X(s_user, "my.val2");
_USER_SET_DATA_X(s_user, "my.v__al3");
_USER_SET_DATA_X(s_user, "my._v");
_USER_SET_DATA_X(s_user, "my.v+");
_USER_SET_DATA_X(s_user, "my.Av");
_USER_SET_DATA_X(s_user, "MY.AV");
_USER_SET_DATA_X(s_user, "MY.8V");
_USER_SET_DATA_X(s_user, "MY.8-V");
_USER_SET_DATA_X(s_user, "MY.8_V");
_USER_SET_DATA_X(s_user, "MY.8+V");
_USER_SET_DATA_X(s_user, "MY.8/V");
_USER_SET_DATA_X(s_user, "MY.8=V");
_USER_SET_DATA_X(s_user, "MY.-");
_USER_SET_DATA_X(s_user, "MY._");
_USER_SET_DATA_X(s_user, "MY.+");
_USER_SET_DATA_X(s_user, "MY./");
_USER_SET_DATA_X(s_user, "MY.=");
_USER_SET_DATA_X(s_user, "my.keys.1");
_USER_SET_DATA_X(s_user, "my.other.KEY.42");
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm/keyfile: properly read user data from keyfile Hack keyfile reader support for NMSettingUser. Writer support already works. (cherry picked from commit 22fd7d2e39327c9f288dd8f17529c1898bc20e47)
2017-05-04 14:50:07 +02:00
nm_connection_add_setting(con, NM_SETTING(s_user));
nmtst_connection_normalize(con);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: split automatically setting ID/UUID for keyfile keyfile already supports omitting the "connection.id" and "connection.uuid". In that case, the ID would be taken from the keyfile's name, and the UUID was generated by md5 hashing the full filename. No longer do this during nm_keyfile_read(), instead let all callers call nm_keyfile_read_ensure_*() to their liking. This is done for two reasons: - a minor reason is, that one day we want to expose keyfile API as public API. That means, we also want to read keyfiles from stdin, where there is no filename available. The implementation which parses stdio needs to define their own way of auto-generating ID and UUID. Note how nm_keyfile_read()'s API no longer takes a filename as argument, which would be awkward for the stdin case. - Currently, we only support one keyfile directory, which (configurably) is "/etc/NetworkManager/system-connections". In the future, we want to support multiple keyfile dirctories, like "/var/run/NetworkManager/profiles" or "/usr/lib/NetworkManager/profiles". Here we want that a file "foo" (which does not specify a UUID) gets the same UUID regardless of the directory it is in. That seems better, because then the UUID won't change as you move the file between directories. Yes, that means, that the same UUID will be provided by multiple files, but NetworkManager must already cope with that situation anyway. Unfortunately, the UUID generation scheme hashes the full path. That means, we must hash the path name of the file "foo" inside the original "system-connections" directory. Refactor the code so that it accounds for a difference between the filename of the keyfile, and the profile_dir used for generating the UUID.
2018-10-02 19:53:54 +02:00
_keyfile_convert(&con, &keyfile, "/test_user_1/foo", NULL, NULL, NULL, NULL, FALSE);
libnm/keyfile: properly read user data from keyfile Hack keyfile reader support for NMSettingUser. Writer support already works. (cherry picked from commit 22fd7d2e39327c9f288dd8f17529c1898bc20e47)
2017-05-04 14:50:07 +02:00
}
/*****************************************************************************/
keyfile/tests: add test reading VPN profile
2018-04-16 14:56:55 +02:00
static void
test_vpn_1(void)
{
all: replace cleanup macro "gs_unref_keyfile" by "nm_auto_unref_keyfile"
2020-09-02 17:36:08 +02:00
nm_auto_unref_keyfile GKeyFile *keyfile = NULL;
keyfile/tests: add test reading VPN profile
2018-04-16 14:56:55 +02:00
gs_unref_object NMConnection *con = NULL;
NMSettingVpn * s_vpn;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile/tests: add test reading VPN profile
2018-04-16 14:56:55 +02:00
con = nmtst_create_connection_from_keyfile("[connection]\n"
"id=t\n"
"type=vpn\n"
"\n"
"[vpn]\n"
"service-type=a.b.c\n"
"vpn-key-1=value1\n"
"",
keyfile: split automatically setting ID/UUID for keyfile keyfile already supports omitting the "connection.id" and "connection.uuid". In that case, the ID would be taken from the keyfile's name, and the UUID was generated by md5 hashing the full filename. No longer do this during nm_keyfile_read(), instead let all callers call nm_keyfile_read_ensure_*() to their liking. This is done for two reasons: - a minor reason is, that one day we want to expose keyfile API as public API. That means, we also want to read keyfiles from stdin, where there is no filename available. The implementation which parses stdio needs to define their own way of auto-generating ID and UUID. Note how nm_keyfile_read()'s API no longer takes a filename as argument, which would be awkward for the stdin case. - Currently, we only support one keyfile directory, which (configurably) is "/etc/NetworkManager/system-connections". In the future, we want to support multiple keyfile dirctories, like "/var/run/NetworkManager/profiles" or "/usr/lib/NetworkManager/profiles". Here we want that a file "foo" (which does not specify a UUID) gets the same UUID regardless of the directory it is in. That seems better, because then the UUID won't change as you move the file between directories. Yes, that means, that the same UUID will be provided by multiple files, but NetworkManager must already cope with that situation anyway. Unfortunately, the UUID generation scheme hashes the full path. That means, we must hash the path name of the file "foo" inside the original "system-connections" directory. Refactor the code so that it accounds for a difference between the filename of the keyfile, and the profile_dir used for generating the UUID.
2018-10-02 19:53:54 +02:00
"/test_vpn_1/invalid");
keyfile/tests: add test reading VPN profile
2018-04-16 14:56:55 +02:00
g_assert(con);
s_vpn = NM_SETTING_VPN(nm_connection_get_setting(con, NM_TYPE_SETTING_VPN));
g_assert(s_vpn);
g_assert_cmpstr(nm_setting_vpn_get_data_item(s_vpn, "vpn-key-1"), ==, "value1");
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile/tests: add test reading VPN profile
2018-04-16 14:56:55 +02:00
CLEAR(&con, &keyfile);
}
/*****************************************************************************/
keyfile: support bridge vlans
2019-03-19 17:33:40 +01:00
static void
test_bridge_vlans(void)
{
all: replace cleanup macro "gs_unref_keyfile" by "nm_auto_unref_keyfile"
2020-09-02 17:36:08 +02:00
nm_auto_unref_keyfile GKeyFile *keyfile = NULL;
keyfile: support bridge vlans
2019-03-19 17:33:40 +01:00
gs_unref_object NMConnection *con = NULL;
NMSettingBridge * s_bridge;
NMBridgeVlan * vlan;
all: support bridge vlan ranges In some cases it is convenient to specify ranges of bridge vlans, as already supported by iproute2 and natively by kernel. With this commit it becomes possible to add a range in this way: nmcli connection modify eth0-slave +bridge-port.vlans "100-200 untagged" vlan ranges can't be PVIDs because only one PVID vlan can exist. https://bugzilla.redhat.com/show_bug.cgi?id=1652910 (cherry picked from commit 70935157771b1de39f27d20e50112efcc50d1f5c)
2019-04-15 15:14:33 +02:00
guint16 vid, vid_end;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: support bridge vlans
2019-03-19 17:33:40 +01:00
con = nmtst_create_connection_from_keyfile("[connection]\n"
"id=t\n"
"type=bridge\n"
"interface-name=br4\n"
"\n"
"[bridge]\n"
all: support bridge vlan ranges In some cases it is convenient to specify ranges of bridge vlans, as already supported by iproute2 and natively by kernel. With this commit it becomes possible to add a range in this way: nmcli connection modify eth0-slave +bridge-port.vlans "100-200 untagged" vlan ranges can't be PVIDs because only one PVID vlan can exist. https://bugzilla.redhat.com/show_bug.cgi?id=1652910 (cherry picked from commit 70935157771b1de39f27d20e50112efcc50d1f5c)
2019-04-15 15:14:33 +02:00
"vlans=900 , 1 pvid untagged, 100-123 untagged\n"
keyfile: support bridge vlans
2019-03-19 17:33:40 +01:00
"",
"/test_bridge_port/vlans");
s_bridge = NM_SETTING_BRIDGE(nm_connection_get_setting(con, NM_TYPE_SETTING_BRIDGE));
g_assert(s_bridge);
all: support bridge vlan ranges In some cases it is convenient to specify ranges of bridge vlans, as already supported by iproute2 and natively by kernel. With this commit it becomes possible to add a range in this way: nmcli connection modify eth0-slave +bridge-port.vlans "100-200 untagged" vlan ranges can't be PVIDs because only one PVID vlan can exist. https://bugzilla.redhat.com/show_bug.cgi?id=1652910 (cherry picked from commit 70935157771b1de39f27d20e50112efcc50d1f5c)
2019-04-15 15:14:33 +02:00
g_assert_cmpuint(nm_setting_bridge_get_num_vlans(s_bridge), ==, 3);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: support bridge vlans
2019-03-19 17:33:40 +01:00
vlan = nm_setting_bridge_get_vlan(s_bridge, 0);
g_assert(vlan);
all: support bridge vlan ranges In some cases it is convenient to specify ranges of bridge vlans, as already supported by iproute2 and natively by kernel. With this commit it becomes possible to add a range in this way: nmcli connection modify eth0-slave +bridge-port.vlans "100-200 untagged" vlan ranges can't be PVIDs because only one PVID vlan can exist. https://bugzilla.redhat.com/show_bug.cgi?id=1652910 (cherry picked from commit 70935157771b1de39f27d20e50112efcc50d1f5c)
2019-04-15 15:14:33 +02:00
nm_bridge_vlan_get_vid_range(vlan, &vid, &vid_end);
g_assert_cmpuint(vid, ==, 1);
g_assert_cmpuint(vid_end, ==, 1);
keyfile: support bridge vlans
2019-03-19 17:33:40 +01:00
g_assert_cmpint(nm_bridge_vlan_is_pvid(vlan), ==, TRUE);
g_assert_cmpint(nm_bridge_vlan_is_untagged(vlan), ==, TRUE);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: support bridge vlans
2019-03-19 17:33:40 +01:00
vlan = nm_setting_bridge_get_vlan(s_bridge, 1);
g_assert(vlan);
all: support bridge vlan ranges In some cases it is convenient to specify ranges of bridge vlans, as already supported by iproute2 and natively by kernel. With this commit it becomes possible to add a range in this way: nmcli connection modify eth0-slave +bridge-port.vlans "100-200 untagged" vlan ranges can't be PVIDs because only one PVID vlan can exist. https://bugzilla.redhat.com/show_bug.cgi?id=1652910 (cherry picked from commit 70935157771b1de39f27d20e50112efcc50d1f5c)
2019-04-15 15:14:33 +02:00
nm_bridge_vlan_get_vid_range(vlan, &vid, &vid_end);
g_assert_cmpuint(vid, ==, 100);
g_assert_cmpuint(vid_end, ==, 123);
keyfile: support bridge vlans
2019-03-19 17:33:40 +01:00
g_assert_cmpint(nm_bridge_vlan_is_pvid(vlan), ==, FALSE);
g_assert_cmpint(nm_bridge_vlan_is_untagged(vlan), ==, TRUE);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
all: support bridge vlan ranges In some cases it is convenient to specify ranges of bridge vlans, as already supported by iproute2 and natively by kernel. With this commit it becomes possible to add a range in this way: nmcli connection modify eth0-slave +bridge-port.vlans "100-200 untagged" vlan ranges can't be PVIDs because only one PVID vlan can exist. https://bugzilla.redhat.com/show_bug.cgi?id=1652910 (cherry picked from commit 70935157771b1de39f27d20e50112efcc50d1f5c)
2019-04-15 15:14:33 +02:00
vlan = nm_setting_bridge_get_vlan(s_bridge, 2);
g_assert(vlan);
nm_bridge_vlan_get_vid_range(vlan, &vid, &vid_end);
g_assert_cmpuint(vid, ==, 900);
g_assert_cmpuint(vid_end, ==, 900);
g_assert_cmpint(nm_bridge_vlan_is_pvid(vlan), ==, FALSE);
g_assert_cmpint(nm_bridge_vlan_is_untagged(vlan), ==, FALSE);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: support bridge vlans
2019-03-19 17:33:40 +01:00
CLEAR(&con, &keyfile);
}
static void
test_bridge_port_vlans(void)
{
all: replace cleanup macro "gs_unref_keyfile" by "nm_auto_unref_keyfile"
2020-09-02 17:36:08 +02:00
nm_auto_unref_keyfile GKeyFile *keyfile = NULL;
keyfile: support bridge vlans
2019-03-19 17:33:40 +01:00
gs_unref_object NMConnection *con = NULL;
NMSettingBridgePort * s_port;
NMBridgeVlan * vlan;
all: support bridge vlan ranges In some cases it is convenient to specify ranges of bridge vlans, as already supported by iproute2 and natively by kernel. With this commit it becomes possible to add a range in this way: nmcli connection modify eth0-slave +bridge-port.vlans "100-200 untagged" vlan ranges can't be PVIDs because only one PVID vlan can exist. https://bugzilla.redhat.com/show_bug.cgi?id=1652910 (cherry picked from commit 70935157771b1de39f27d20e50112efcc50d1f5c)
2019-04-15 15:14:33 +02:00
guint16 vid_start, vid_end;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: support bridge vlans
2019-03-19 17:33:40 +01:00
con = nmtst_create_connection_from_keyfile("[connection]\n"
"id=t\n"
"type=dummy\n"
"interface-name=dummy1\n"
"master=br0\n"
"slave-type=bridge\n"
"\n"
"[bridge-port]\n"
all: support bridge vlan ranges In some cases it is convenient to specify ranges of bridge vlans, as already supported by iproute2 and natively by kernel. With this commit it becomes possible to add a range in this way: nmcli connection modify eth0-slave +bridge-port.vlans "100-200 untagged" vlan ranges can't be PVIDs because only one PVID vlan can exist. https://bugzilla.redhat.com/show_bug.cgi?id=1652910 (cherry picked from commit 70935157771b1de39f27d20e50112efcc50d1f5c)
2019-04-15 15:14:33 +02:00
"vlans=4094 pvid , 10-20 untagged\n"
keyfile: support bridge vlans
2019-03-19 17:33:40 +01:00
"",
"/test_bridge_port/vlans");
s_port = NM_SETTING_BRIDGE_PORT(nm_connection_get_setting(con, NM_TYPE_SETTING_BRIDGE_PORT));
g_assert(s_port);
all: support bridge vlan ranges In some cases it is convenient to specify ranges of bridge vlans, as already supported by iproute2 and natively by kernel. With this commit it becomes possible to add a range in this way: nmcli connection modify eth0-slave +bridge-port.vlans "100-200 untagged" vlan ranges can't be PVIDs because only one PVID vlan can exist. https://bugzilla.redhat.com/show_bug.cgi?id=1652910 (cherry picked from commit 70935157771b1de39f27d20e50112efcc50d1f5c)
2019-04-15 15:14:33 +02:00
g_assert_cmpuint(nm_setting_bridge_port_get_num_vlans(s_port), ==, 2);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: support bridge vlans
2019-03-19 17:33:40 +01:00
vlan = nm_setting_bridge_port_get_vlan(s_port, 0);
g_assert(vlan);
all: support bridge vlan ranges In some cases it is convenient to specify ranges of bridge vlans, as already supported by iproute2 and natively by kernel. With this commit it becomes possible to add a range in this way: nmcli connection modify eth0-slave +bridge-port.vlans "100-200 untagged" vlan ranges can't be PVIDs because only one PVID vlan can exist. https://bugzilla.redhat.com/show_bug.cgi?id=1652910 (cherry picked from commit 70935157771b1de39f27d20e50112efcc50d1f5c)
2019-04-15 15:14:33 +02:00
nm_bridge_vlan_get_vid_range(vlan, &vid_start, &vid_end);
g_assert_cmpuint(vid_start, ==, 10);
g_assert_cmpuint(vid_end, ==, 20);
keyfile: support bridge vlans
2019-03-19 17:33:40 +01:00
g_assert_cmpint(nm_bridge_vlan_is_pvid(vlan), ==, FALSE);
g_assert_cmpint(nm_bridge_vlan_is_untagged(vlan), ==, TRUE);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: support bridge vlans
2019-03-19 17:33:40 +01:00
vlan = nm_setting_bridge_port_get_vlan(s_port, 1);
g_assert(vlan);
all: support bridge vlan ranges In some cases it is convenient to specify ranges of bridge vlans, as already supported by iproute2 and natively by kernel. With this commit it becomes possible to add a range in this way: nmcli connection modify eth0-slave +bridge-port.vlans "100-200 untagged" vlan ranges can't be PVIDs because only one PVID vlan can exist. https://bugzilla.redhat.com/show_bug.cgi?id=1652910 (cherry picked from commit 70935157771b1de39f27d20e50112efcc50d1f5c)
2019-04-15 15:14:33 +02:00
nm_bridge_vlan_get_vid_range(vlan, &vid_start, &vid_end);
g_assert_cmpuint(vid_start, ==, 4094);
g_assert_cmpuint(vid_end, ==, 4094);
keyfile: support bridge vlans
2019-03-19 17:33:40 +01:00
g_assert_cmpint(nm_bridge_vlan_is_pvid(vlan), ==, TRUE);
g_assert_cmpint(nm_bridge_vlan_is_untagged(vlan), ==, FALSE);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: support bridge vlans
2019-03-19 17:33:40 +01:00
CLEAR(&con, &keyfile);
}
/*****************************************************************************/
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
NMTST_DEFINE();
int
main(int argc, char **argv)
{
nmtst_init(&argc, &argv, TRUE);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: fix handling unsupported characters in keys vpn.data, bond.options, and user.data encode their values directly as keys in keyfile. However, keys for GKeyFile may not contain characters like '='. We need to escape such special characters, otherwise an assertion is hit on the server: $ nmcli connection modify "$VPN_NAME" +vpn.data 'aa[=value' Another example of encountering the assertion is when setting user-data key with an invalid character "my.this=key=is=causes=a=crash". (cherry picked from commit 8ef57d0f7ef26247bf53b4d07f712a1bf4de4bb2)
2017-05-05 12:01:17 +02:00
g_test_add_func("/core/keyfile/encode_key", test_encode_key);
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
g_test_add_func("/core/keyfile/test_8021x_cert", test_8021x_cert);
libnm/crypto: accept TPM2-wrapped PEM keys Some tools that NM can interact with (eg. openconnect) have added automated support to handle TPM2-wrapped PEM keys as drop-in replacements for ordinary key files. Make sure that NM doesn't reject these keys upfront. We cannot reliably assume NM to be able to unwrap and validate the key. Therefore, accept any key as long as the PEM header and trailer look ok.
2019-06-24 12:09:12 +02:00
g_test_add_func("/core/keyfile/test_8021x_cert_tpm2key", test_8021x_cert_tpm2key);
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
g_test_add_func("/core/keyfile/test_8021x_cert_read", test_8021x_cert_read);
team: normalize invalid configuration during load Now that we validate the JSON syntax of a team/team-port configuration, any existing connection with invalid JSON configuration would fail to load and disappear upon upgrade. Instead, modify the setting plugins to emit a warning but still load the connection with empty configuration.
2016-08-30 15:21:16 +02:00
g_test_add_func("/core/keyfile/test_team_conf_read/valid", test_team_conf_read_valid);
g_test_add_func("/core/keyfile/test_team_conf_read/invalid", test_team_conf_read_invalid);
libnm/keyfile: properly read user data from keyfile Hack keyfile reader support for NMSettingUser. Writer support already works. (cherry picked from commit 22fd7d2e39327c9f288dd8f17529c1898bc20e47)
2017-05-04 14:50:07 +02:00
g_test_add_func("/core/keyfile/test_user/1", test_user_1);
keyfile/tests: add test reading VPN profile
2018-04-16 14:56:55 +02:00
g_test_add_func("/core/keyfile/test_vpn/1", test_vpn_1);
keyfile: support bridge vlans
2019-03-19 17:33:40 +01:00
g_test_add_func("/core/keyfile/bridge/vlans", test_bridge_vlans);
g_test_add_func("/core/keyfile/bridge-port/vlans", test_bridge_port_vlans);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
keyfile: support writing certificates as blob inside the keyfile keyfile should become our main import/export format. It is desirable, that a keyfile can contain every aspect of a connection. For blob certificates, the writer in core daemon would always write them to a file and convert the scheme to path. This behavior is not great for a (hyptetical) `nmcli connection export` command because it would have to export them somehow outside of keyfile, e.g. by writing them to temporary files. Instead, if the write handler does not handle a certificate, use a default implementation in nm_keyfile_write() which adds the blob inside the keyfile. Interestingly, keyfile reader already supported reading certificate blobs. But this legacy format accepts the blob as arbitrary binary without marking the format and without scheme prefix. Instead of writing the binary data directly, write it with a new uri scheme "data:;base64," and encode it in base64. Also go through some lengths to make sure that whatever path keyfile plugin writes, can be read back again. That is, because keyfile writer preferably writes relative paths without prefix. Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate the detection of pathnames without file:// prefix and use it to check whether the path name must be fully qualified.
2015-02-24 22:22:14 +01:00
return g_test_run();
}
Reference in a new issue Copy permalink