luc14n0/glib
1
0
Fork 0
mirror of https://gitlab.gnome.org/GNOME/glib.git synced 2024-11-06 09:26:17 +01:00
Code Issues Packages Projects Releases Wiki Activity
1bbf500fb8
glib/gio/tests/tls-certificate.c

731 lines
24 KiB
C
Raw Normal View History

Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
/* GLib testing framework examples and tests
*
* Copyright (C) 2011 Collabora Ltd.
*
tests: Add SPDX license headers automatically Add SPDX license (but not copyright) headers to all files which follow a certain pattern in their existing non-machine-readable header comment. This commit was entirely generated using the command: ``` git ls-files gio/tests/*.c | xargs perl -0777 -pi -e 's/\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/\n \*\n \* SPDX-License-Identifier: LGPL-2.1-or-later\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/igs' ``` Signed-off-by: Philip Withnall <pwithnall@endlessos.org> Helps: #1415
2022-05-18 10:20:07 +02:00
* SPDX-License-Identifier: LGPL-2.1-or-later
*
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
gio/tests/: LGPLv2+ -> LGPLv2.1+ A lot of tests in gio/tests/ don't have a license header. https://bugzilla.gnome.org/show_bug.cgi?id=776504
2017-05-27 17:19:21 +02:00
* version 2.1 of the License, or (at your option) any later version.
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General
Updated FSF's address
2014-01-23 12:58:29 +01:00
* Public License along with this library; if not, see <http://www.gnu.org/licenses/>.
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
*
* Author: Nicolas Dufresne <nicolas.dufresne@collabora.com>
*/
#include "config.h"
#include <gio/gio.h>
#include "gtesttlsbackend.h"
typedef struct
{
gchar *cert_pems[3];
tests/tls-certificate: Add PEM files containing CRLF Add test case to ensure correct parsing of PEM files containing CRLF (\r\n) line endings.
2018-12-18 11:21:19 +01:00
gchar *cert_crlf_pem;
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
gchar *key_pem;
tests/tls-certificate: Add PEM files containing CRLF Add test case to ensure correct parsing of PEM files containing CRLF (\r\n) line endings.
2018-12-18 11:21:19 +01:00
gchar *key_crlf_pem;
GTlsCertificate: support unencrypted PKCS#8 private keys PKCS#8 is the "right" way to encode private keys. Although the APIs do not currently support encrypted keys, we should at least support unencrypted PKCS#8 keys. https://bugzilla.gnome.org/show_bug.cgi?id=664321
2011-11-18 21:05:34 +01:00
gchar *key8_pem;
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
} Reference;
static void
pem_parser (const Reference *ref)
{
GTlsCertificate *cert;
gchar *pem;
gtlscertificate: Fix bug in PEM private key parser Make sure to not go outside of PEM data buffer when looking for private key. Also adding test case that triggers this bug.
2018-12-14 11:46:27 +01:00
gsize pem_len = 0;
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
gchar *parsed_cert_pem = NULL;
gtlscertificate: make private key properties readable WebKit wants these private key properties to be readable in order to implement a deserialization function. Currently they are read-only because at the time GTlsCertificate was originally designed, the plan was to support PKCS#11-backed private keys: private keys that are stored on a smartcard, where the private key is completely unreadable. The design goal was to support both memory-backed and smartcard-backed private keys with the same GTlsCertificate API, abstracting away the implementation differences such that code using GTlsCertificate doesn't need to know the difference. The original PKCS#11 implementation was never fully baked and at some point in the past I deleted it all. It has since been replaced with a new implementation, including a GTlsCertificate:private-key-pkcs11-uri property, which is readable. So our current API already exposes the differences between normal private keys and PKCS#11-backed private keys. The point of making the private-key and private-key-pem properties write-only was to avoid exposing this difference. Do we have to make this API function readable? No, because WebKit could be just as well served if we were to expose serialize and deserialize functions instead. But WebKit needs to support serializing and deserializing the non-private portion of GTlsCertificate with older versions of GLib anyway, so we can do whatever is nicest for GLib. And I think making this property readable is nicest, since the original design reason for it to not be readable is now obsolete. The disadvantage to this approach is that it's now possible for an application to read the private-key or private-key-pem property, receive NULL, and think "this certificate must not have a private key," which would be incorrect if the private-key-pkcs11-uri property is set. That seems like a minor risk, but it should be documented.
2021-05-06 19:04:29 +02:00
gchar *parsed_key_pem = NULL;
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
GError *error = NULL;
/* Check PEM parsing in certificate, private key order. */
gtlscertificate: Fix bug in PEM private key parser Make sure to not go outside of PEM data buffer when looking for private key. Also adding test case that triggers this bug.
2018-12-14 11:46:27 +01:00
g_file_get_contents (g_test_get_filename (G_TEST_DIST, "cert-tests", "cert-key.pem", NULL), &pem, &pem_len, &error);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
g_assert_no_error (error);
tests/tls-certificate: Change to g_assert_null/nonnull Use g_assert_null/g_assert_nonnull instead of g_assert since g_assert can be compiled out with G_DISABLE_ASSERT.
2018-12-18 10:39:01 +01:00
g_assert_nonnull (pem);
gtlscertificate: Fix bug in PEM private key parser Make sure to not go outside of PEM data buffer when looking for private key. Also adding test case that triggers this bug.
2018-12-14 11:46:27 +01:00
g_assert_cmpuint (pem_len, >=, 10);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
cert = g_tls_certificate_new_from_pem (pem, -1, &error);
g_assert_no_error (error);
tests/tls-certificate: Change to g_assert_null/nonnull Use g_assert_null/g_assert_nonnull instead of g_assert since g_assert can be compiled out with G_DISABLE_ASSERT.
2018-12-18 10:39:01 +01:00
g_assert_nonnull (cert);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
g_object_get (cert,
"certificate-pem", &parsed_cert_pem,
gtlscertificate: make private key properties readable WebKit wants these private key properties to be readable in order to implement a deserialization function. Currently they are read-only because at the time GTlsCertificate was originally designed, the plan was to support PKCS#11-backed private keys: private keys that are stored on a smartcard, where the private key is completely unreadable. The design goal was to support both memory-backed and smartcard-backed private keys with the same GTlsCertificate API, abstracting away the implementation differences such that code using GTlsCertificate doesn't need to know the difference. The original PKCS#11 implementation was never fully baked and at some point in the past I deleted it all. It has since been replaced with a new implementation, including a GTlsCertificate:private-key-pkcs11-uri property, which is readable. So our current API already exposes the differences between normal private keys and PKCS#11-backed private keys. The point of making the private-key and private-key-pem properties write-only was to avoid exposing this difference. Do we have to make this API function readable? No, because WebKit could be just as well served if we were to expose serialize and deserialize functions instead. But WebKit needs to support serializing and deserializing the non-private portion of GTlsCertificate with older versions of GLib anyway, so we can do whatever is nicest for GLib. And I think making this property readable is nicest, since the original design reason for it to not be readable is now obsolete. The disadvantage to this approach is that it's now possible for an application to read the private-key or private-key-pem property, receive NULL, and think "this certificate must not have a private key," which would be incorrect if the private-key-pkcs11-uri property is set. That seems like a minor risk, but it should be documented.
2021-05-06 19:04:29 +02:00
"private-key-pem", &parsed_key_pem,
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
NULL);
g_assert_cmpstr (parsed_cert_pem, ==, ref->cert_pems[0]);
gtlscertificate: make private key properties readable WebKit wants these private key properties to be readable in order to implement a deserialization function. Currently they are read-only because at the time GTlsCertificate was originally designed, the plan was to support PKCS#11-backed private keys: private keys that are stored on a smartcard, where the private key is completely unreadable. The design goal was to support both memory-backed and smartcard-backed private keys with the same GTlsCertificate API, abstracting away the implementation differences such that code using GTlsCertificate doesn't need to know the difference. The original PKCS#11 implementation was never fully baked and at some point in the past I deleted it all. It has since been replaced with a new implementation, including a GTlsCertificate:private-key-pkcs11-uri property, which is readable. So our current API already exposes the differences between normal private keys and PKCS#11-backed private keys. The point of making the private-key and private-key-pem properties write-only was to avoid exposing this difference. Do we have to make this API function readable? No, because WebKit could be just as well served if we were to expose serialize and deserialize functions instead. But WebKit needs to support serializing and deserializing the non-private portion of GTlsCertificate with older versions of GLib anyway, so we can do whatever is nicest for GLib. And I think making this property readable is nicest, since the original design reason for it to not be readable is now obsolete. The disadvantage to this approach is that it's now possible for an application to read the private-key or private-key-pem property, receive NULL, and think "this certificate must not have a private key," which would be incorrect if the private-key-pkcs11-uri property is set. That seems like a minor risk, but it should be documented.
2021-05-06 19:04:29 +02:00
g_clear_pointer (&parsed_cert_pem, g_free);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
g_assert_cmpstr (parsed_key_pem, ==, ref->key_pem);
gtlscertificate: make private key properties readable WebKit wants these private key properties to be readable in order to implement a deserialization function. Currently they are read-only because at the time GTlsCertificate was originally designed, the plan was to support PKCS#11-backed private keys: private keys that are stored on a smartcard, where the private key is completely unreadable. The design goal was to support both memory-backed and smartcard-backed private keys with the same GTlsCertificate API, abstracting away the implementation differences such that code using GTlsCertificate doesn't need to know the difference. The original PKCS#11 implementation was never fully baked and at some point in the past I deleted it all. It has since been replaced with a new implementation, including a GTlsCertificate:private-key-pkcs11-uri property, which is readable. So our current API already exposes the differences between normal private keys and PKCS#11-backed private keys. The point of making the private-key and private-key-pem properties write-only was to avoid exposing this difference. Do we have to make this API function readable? No, because WebKit could be just as well served if we were to expose serialize and deserialize functions instead. But WebKit needs to support serializing and deserializing the non-private portion of GTlsCertificate with older versions of GLib anyway, so we can do whatever is nicest for GLib. And I think making this property readable is nicest, since the original design reason for it to not be readable is now obsolete. The disadvantage to this approach is that it's now possible for an application to read the private-key or private-key-pem property, receive NULL, and think "this certificate must not have a private key," which would be incorrect if the private-key-pkcs11-uri property is set. That seems like a minor risk, but it should be documented.
2021-05-06 19:04:29 +02:00
g_clear_pointer (&parsed_key_pem, g_free);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
g_object_unref (cert);
gtlscertificate: Fix bug in PEM private key parser Make sure to not go outside of PEM data buffer when looking for private key. Also adding test case that triggers this bug.
2018-12-14 11:46:27 +01:00
/* Make sure length is respected and parser detect invalid PEM
* when cert is truncated. */
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
cert = g_tls_certificate_new_from_pem (pem, 10, &error);
g_assert_error (error, G_TLS_ERROR, G_TLS_ERROR_BAD_CERTIFICATE);
g_clear_error (&error);
gtlscertificate: Fix bug in PEM private key parser Make sure to not go outside of PEM data buffer when looking for private key. Also adding test case that triggers this bug.
2018-12-14 11:46:27 +01:00
/* Make sure length is respected and parser detect invalid PEM
* when cert exists but key is truncated. */
cert = g_tls_certificate_new_from_pem (pem, pem_len - 10, &error);
g_assert_error (error, G_TLS_ERROR, G_TLS_ERROR_BAD_CERTIFICATE);
g_clear_error (&error);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
g_free (pem);
/* Check PEM parsing in private key, certificate order */
Rename G_TEST_DISTED to G_TEST_DIST Since this feature is so utterly automake-centric, we may as well be using the same terminology as automake itself (ie: although it's BUILT_SOURCES, it's DIST_EXTRA, not DISTED). Also add some comments to the enum explaining that these terms are really corresponding directly to the automake terms. https://bugzilla.gnome.org/show_bug.cgi?id=549783
2013-05-29 14:49:16 +02:00
g_file_get_contents (g_test_get_filename (G_TEST_DIST, "cert-tests", "key-cert.pem", NULL), &pem, NULL, &error);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
g_assert_no_error (error);
tests/tls-certificate: Change to g_assert_null/nonnull Use g_assert_null/g_assert_nonnull instead of g_assert since g_assert can be compiled out with G_DISABLE_ASSERT.
2018-12-18 10:39:01 +01:00
g_assert_nonnull (pem);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
cert = g_tls_certificate_new_from_pem (pem, -1, &error);
g_assert_no_error (error);
tests/tls-certificate: Change to g_assert_null/nonnull Use g_assert_null/g_assert_nonnull instead of g_assert since g_assert can be compiled out with G_DISABLE_ASSERT.
2018-12-18 10:39:01 +01:00
g_assert_nonnull (cert);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
g_object_get (cert,
"certificate-pem", &parsed_cert_pem,
gtlscertificate: make private key properties readable WebKit wants these private key properties to be readable in order to implement a deserialization function. Currently they are read-only because at the time GTlsCertificate was originally designed, the plan was to support PKCS#11-backed private keys: private keys that are stored on a smartcard, where the private key is completely unreadable. The design goal was to support both memory-backed and smartcard-backed private keys with the same GTlsCertificate API, abstracting away the implementation differences such that code using GTlsCertificate doesn't need to know the difference. The original PKCS#11 implementation was never fully baked and at some point in the past I deleted it all. It has since been replaced with a new implementation, including a GTlsCertificate:private-key-pkcs11-uri property, which is readable. So our current API already exposes the differences between normal private keys and PKCS#11-backed private keys. The point of making the private-key and private-key-pem properties write-only was to avoid exposing this difference. Do we have to make this API function readable? No, because WebKit could be just as well served if we were to expose serialize and deserialize functions instead. But WebKit needs to support serializing and deserializing the non-private portion of GTlsCertificate with older versions of GLib anyway, so we can do whatever is nicest for GLib. And I think making this property readable is nicest, since the original design reason for it to not be readable is now obsolete. The disadvantage to this approach is that it's now possible for an application to read the private-key or private-key-pem property, receive NULL, and think "this certificate must not have a private key," which would be incorrect if the private-key-pkcs11-uri property is set. That seems like a minor risk, but it should be documented.
2021-05-06 19:04:29 +02:00
"private-key-pem", &parsed_key_pem,
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
NULL);
g_assert_cmpstr (parsed_cert_pem, ==, ref->cert_pems[0]);
gtlscertificate: make private key properties readable WebKit wants these private key properties to be readable in order to implement a deserialization function. Currently they are read-only because at the time GTlsCertificate was originally designed, the plan was to support PKCS#11-backed private keys: private keys that are stored on a smartcard, where the private key is completely unreadable. The design goal was to support both memory-backed and smartcard-backed private keys with the same GTlsCertificate API, abstracting away the implementation differences such that code using GTlsCertificate doesn't need to know the difference. The original PKCS#11 implementation was never fully baked and at some point in the past I deleted it all. It has since been replaced with a new implementation, including a GTlsCertificate:private-key-pkcs11-uri property, which is readable. So our current API already exposes the differences between normal private keys and PKCS#11-backed private keys. The point of making the private-key and private-key-pem properties write-only was to avoid exposing this difference. Do we have to make this API function readable? No, because WebKit could be just as well served if we were to expose serialize and deserialize functions instead. But WebKit needs to support serializing and deserializing the non-private portion of GTlsCertificate with older versions of GLib anyway, so we can do whatever is nicest for GLib. And I think making this property readable is nicest, since the original design reason for it to not be readable is now obsolete. The disadvantage to this approach is that it's now possible for an application to read the private-key or private-key-pem property, receive NULL, and think "this certificate must not have a private key," which would be incorrect if the private-key-pkcs11-uri property is set. That seems like a minor risk, but it should be documented.
2021-05-06 19:04:29 +02:00
g_clear_pointer (&parsed_cert_pem, g_free);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
g_assert_cmpstr (parsed_key_pem, ==, ref->key_pem);
gtlscertificate: make private key properties readable WebKit wants these private key properties to be readable in order to implement a deserialization function. Currently they are read-only because at the time GTlsCertificate was originally designed, the plan was to support PKCS#11-backed private keys: private keys that are stored on a smartcard, where the private key is completely unreadable. The design goal was to support both memory-backed and smartcard-backed private keys with the same GTlsCertificate API, abstracting away the implementation differences such that code using GTlsCertificate doesn't need to know the difference. The original PKCS#11 implementation was never fully baked and at some point in the past I deleted it all. It has since been replaced with a new implementation, including a GTlsCertificate:private-key-pkcs11-uri property, which is readable. So our current API already exposes the differences between normal private keys and PKCS#11-backed private keys. The point of making the private-key and private-key-pem properties write-only was to avoid exposing this difference. Do we have to make this API function readable? No, because WebKit could be just as well served if we were to expose serialize and deserialize functions instead. But WebKit needs to support serializing and deserializing the non-private portion of GTlsCertificate with older versions of GLib anyway, so we can do whatever is nicest for GLib. And I think making this property readable is nicest, since the original design reason for it to not be readable is now obsolete. The disadvantage to this approach is that it's now possible for an application to read the private-key or private-key-pem property, receive NULL, and think "this certificate must not have a private key," which would be incorrect if the private-key-pkcs11-uri property is set. That seems like a minor risk, but it should be documented.
2021-05-06 19:04:29 +02:00
g_clear_pointer (&parsed_key_pem, g_free);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
g_free (pem);
g_object_unref (cert);
/* Check certificate only PEM */
Rename G_TEST_DISTED to G_TEST_DIST Since this feature is so utterly automake-centric, we may as well be using the same terminology as automake itself (ie: although it's BUILT_SOURCES, it's DIST_EXTRA, not DISTED). Also add some comments to the enum explaining that these terms are really corresponding directly to the automake terms. https://bugzilla.gnome.org/show_bug.cgi?id=549783
2013-05-29 14:49:16 +02:00
g_file_get_contents (g_test_get_filename (G_TEST_DIST, "cert-tests", "cert1.pem", NULL), &pem, NULL, &error);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
g_assert_no_error (error);
tests/tls-certificate: Change to g_assert_null/nonnull Use g_assert_null/g_assert_nonnull instead of g_assert since g_assert can be compiled out with G_DISABLE_ASSERT.
2018-12-18 10:39:01 +01:00
g_assert_nonnull (pem);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
cert = g_tls_certificate_new_from_pem (pem, -1, &error);
g_assert_no_error (error);
tests/tls-certificate: Change to g_assert_null/nonnull Use g_assert_null/g_assert_nonnull instead of g_assert since g_assert can be compiled out with G_DISABLE_ASSERT.
2018-12-18 10:39:01 +01:00
g_assert_nonnull (cert);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
g_object_get (cert,
"certificate-pem", &parsed_cert_pem,
gtlscertificate: make private key properties readable WebKit wants these private key properties to be readable in order to implement a deserialization function. Currently they are read-only because at the time GTlsCertificate was originally designed, the plan was to support PKCS#11-backed private keys: private keys that are stored on a smartcard, where the private key is completely unreadable. The design goal was to support both memory-backed and smartcard-backed private keys with the same GTlsCertificate API, abstracting away the implementation differences such that code using GTlsCertificate doesn't need to know the difference. The original PKCS#11 implementation was never fully baked and at some point in the past I deleted it all. It has since been replaced with a new implementation, including a GTlsCertificate:private-key-pkcs11-uri property, which is readable. So our current API already exposes the differences between normal private keys and PKCS#11-backed private keys. The point of making the private-key and private-key-pem properties write-only was to avoid exposing this difference. Do we have to make this API function readable? No, because WebKit could be just as well served if we were to expose serialize and deserialize functions instead. But WebKit needs to support serializing and deserializing the non-private portion of GTlsCertificate with older versions of GLib anyway, so we can do whatever is nicest for GLib. And I think making this property readable is nicest, since the original design reason for it to not be readable is now obsolete. The disadvantage to this approach is that it's now possible for an application to read the private-key or private-key-pem property, receive NULL, and think "this certificate must not have a private key," which would be incorrect if the private-key-pkcs11-uri property is set. That seems like a minor risk, but it should be documented.
2021-05-06 19:04:29 +02:00
"private-key-pem", &parsed_key_pem,
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
NULL);
g_assert_cmpstr (parsed_cert_pem, ==, ref->cert_pems[0]);
gtlscertificate: make private key properties readable WebKit wants these private key properties to be readable in order to implement a deserialization function. Currently they are read-only because at the time GTlsCertificate was originally designed, the plan was to support PKCS#11-backed private keys: private keys that are stored on a smartcard, where the private key is completely unreadable. The design goal was to support both memory-backed and smartcard-backed private keys with the same GTlsCertificate API, abstracting away the implementation differences such that code using GTlsCertificate doesn't need to know the difference. The original PKCS#11 implementation was never fully baked and at some point in the past I deleted it all. It has since been replaced with a new implementation, including a GTlsCertificate:private-key-pkcs11-uri property, which is readable. So our current API already exposes the differences between normal private keys and PKCS#11-backed private keys. The point of making the private-key and private-key-pem properties write-only was to avoid exposing this difference. Do we have to make this API function readable? No, because WebKit could be just as well served if we were to expose serialize and deserialize functions instead. But WebKit needs to support serializing and deserializing the non-private portion of GTlsCertificate with older versions of GLib anyway, so we can do whatever is nicest for GLib. And I think making this property readable is nicest, since the original design reason for it to not be readable is now obsolete. The disadvantage to this approach is that it's now possible for an application to read the private-key or private-key-pem property, receive NULL, and think "this certificate must not have a private key," which would be incorrect if the private-key-pkcs11-uri property is set. That seems like a minor risk, but it should be documented.
2021-05-06 19:04:29 +02:00
g_clear_pointer (&parsed_cert_pem, g_free);
tests/tls-certificate: Change to g_assert_null/nonnull Use g_assert_null/g_assert_nonnull instead of g_assert since g_assert can be compiled out with G_DISABLE_ASSERT.
2018-12-18 10:39:01 +01:00
g_assert_null (parsed_key_pem);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
g_free (pem);
g_object_unref (cert);
/* Check error with private key only PEM */
Rename G_TEST_DISTED to G_TEST_DIST Since this feature is so utterly automake-centric, we may as well be using the same terminology as automake itself (ie: although it's BUILT_SOURCES, it's DIST_EXTRA, not DISTED). Also add some comments to the enum explaining that these terms are really corresponding directly to the automake terms. https://bugzilla.gnome.org/show_bug.cgi?id=549783
2013-05-29 14:49:16 +02:00
g_file_get_contents (g_test_get_filename (G_TEST_DIST, "cert-tests", "key.pem", NULL), &pem, NULL, &error);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
g_assert_no_error (error);
tests/tls-certificate: Change to g_assert_null/nonnull Use g_assert_null/g_assert_nonnull instead of g_assert since g_assert can be compiled out with G_DISABLE_ASSERT.
2018-12-18 10:39:01 +01:00
g_assert_nonnull (pem);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
cert = g_tls_certificate_new_from_pem (pem, -1, &error);
g_assert_error (error, G_TLS_ERROR, G_TLS_ERROR_BAD_CERTIFICATE);
g_clear_error (&error);
tests/tls-certificate: Change to g_assert_null/nonnull Use g_assert_null/g_assert_nonnull instead of g_assert since g_assert can be compiled out with G_DISABLE_ASSERT.
2018-12-18 10:39:01 +01:00
g_assert_null (cert);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
g_free (pem);
}
Add certificate chain construction test Enhance GTestTlsBackend to allow setting the issuer property of GTlsCertificates, and add a test to ensure certificate chain construction with g_tls_certificate_new_from_pem() works as expected. https://bugzilla.gnome.org/show_bug.cgi?id=754264
2015-08-29 02:47:19 +02:00
static void
pem_parser_handles_chain (const Reference *ref)
{
GTlsCertificate *cert;
GTlsCertificate *issuer;
GTlsCertificate *original_cert;
gchar *pem;
gchar *parsed_cert_pem = NULL;
gtlscertificate: make private key properties readable WebKit wants these private key properties to be readable in order to implement a deserialization function. Currently they are read-only because at the time GTlsCertificate was originally designed, the plan was to support PKCS#11-backed private keys: private keys that are stored on a smartcard, where the private key is completely unreadable. The design goal was to support both memory-backed and smartcard-backed private keys with the same GTlsCertificate API, abstracting away the implementation differences such that code using GTlsCertificate doesn't need to know the difference. The original PKCS#11 implementation was never fully baked and at some point in the past I deleted it all. It has since been replaced with a new implementation, including a GTlsCertificate:private-key-pkcs11-uri property, which is readable. So our current API already exposes the differences between normal private keys and PKCS#11-backed private keys. The point of making the private-key and private-key-pem properties write-only was to avoid exposing this difference. Do we have to make this API function readable? No, because WebKit could be just as well served if we were to expose serialize and deserialize functions instead. But WebKit needs to support serializing and deserializing the non-private portion of GTlsCertificate with older versions of GLib anyway, so we can do whatever is nicest for GLib. And I think making this property readable is nicest, since the original design reason for it to not be readable is now obsolete. The disadvantage to this approach is that it's now possible for an application to read the private-key or private-key-pem property, receive NULL, and think "this certificate must not have a private key," which would be incorrect if the private-key-pkcs11-uri property is set. That seems like a minor risk, but it should be documented.
2021-05-06 19:04:29 +02:00
gchar *parsed_key_pem = NULL;
Add certificate chain construction test Enhance GTestTlsBackend to allow setting the issuer property of GTlsCertificates, and add a test to ensure certificate chain construction with g_tls_certificate_new_from_pem() works as expected. https://bugzilla.gnome.org/show_bug.cgi?id=754264
2015-08-29 02:47:19 +02:00
GError *error = NULL;
/* Check that a chain with exactly three certificates is returned */
g_file_get_contents (g_test_get_filename (G_TEST_DIST, "cert-tests", "cert-list.pem", NULL), &pem, NULL, &error);
g_assert_no_error (error);
tests/tls-certificate: Change to g_assert_null/nonnull Use g_assert_null/g_assert_nonnull instead of g_assert since g_assert can be compiled out with G_DISABLE_ASSERT.
2018-12-18 10:39:01 +01:00
g_assert_nonnull (pem);
Add certificate chain construction test Enhance GTestTlsBackend to allow setting the issuer property of GTlsCertificates, and add a test to ensure certificate chain construction with g_tls_certificate_new_from_pem() works as expected. https://bugzilla.gnome.org/show_bug.cgi?id=754264
2015-08-29 02:47:19 +02:00
cert = original_cert = g_tls_certificate_new_from_pem (pem, -1, &error);
g_free (pem);
g_assert_no_error (error);
tests/tls-certificate: Change to g_assert_null/nonnull Use g_assert_null/g_assert_nonnull instead of g_assert since g_assert can be compiled out with G_DISABLE_ASSERT.
2018-12-18 10:39:01 +01:00
g_assert_nonnull (cert);
Add certificate chain construction test Enhance GTestTlsBackend to allow setting the issuer property of GTlsCertificates, and add a test to ensure certificate chain construction with g_tls_certificate_new_from_pem() works as expected. https://bugzilla.gnome.org/show_bug.cgi?id=754264
2015-08-29 02:47:19 +02:00
g_object_get (cert,
"certificate-pem", &parsed_cert_pem,
gtlscertificate: make private key properties readable WebKit wants these private key properties to be readable in order to implement a deserialization function. Currently they are read-only because at the time GTlsCertificate was originally designed, the plan was to support PKCS#11-backed private keys: private keys that are stored on a smartcard, where the private key is completely unreadable. The design goal was to support both memory-backed and smartcard-backed private keys with the same GTlsCertificate API, abstracting away the implementation differences such that code using GTlsCertificate doesn't need to know the difference. The original PKCS#11 implementation was never fully baked and at some point in the past I deleted it all. It has since been replaced with a new implementation, including a GTlsCertificate:private-key-pkcs11-uri property, which is readable. So our current API already exposes the differences between normal private keys and PKCS#11-backed private keys. The point of making the private-key and private-key-pem properties write-only was to avoid exposing this difference. Do we have to make this API function readable? No, because WebKit could be just as well served if we were to expose serialize and deserialize functions instead. But WebKit needs to support serializing and deserializing the non-private portion of GTlsCertificate with older versions of GLib anyway, so we can do whatever is nicest for GLib. And I think making this property readable is nicest, since the original design reason for it to not be readable is now obsolete. The disadvantage to this approach is that it's now possible for an application to read the private-key or private-key-pem property, receive NULL, and think "this certificate must not have a private key," which would be incorrect if the private-key-pkcs11-uri property is set. That seems like a minor risk, but it should be documented.
2021-05-06 19:04:29 +02:00
"private-key-pem", &parsed_key_pem,
Add certificate chain construction test Enhance GTestTlsBackend to allow setting the issuer property of GTlsCertificates, and add a test to ensure certificate chain construction with g_tls_certificate_new_from_pem() works as expected. https://bugzilla.gnome.org/show_bug.cgi?id=754264
2015-08-29 02:47:19 +02:00
NULL);
g_assert_cmpstr (parsed_cert_pem, ==, ref->cert_pems[0]);
g_clear_pointer (&parsed_cert_pem, g_free);
/* Make sure the private key was parsed */
g_assert_cmpstr (parsed_key_pem, ==, ref->key_pem);
gtlscertificate: make private key properties readable WebKit wants these private key properties to be readable in order to implement a deserialization function. Currently they are read-only because at the time GTlsCertificate was originally designed, the plan was to support PKCS#11-backed private keys: private keys that are stored on a smartcard, where the private key is completely unreadable. The design goal was to support both memory-backed and smartcard-backed private keys with the same GTlsCertificate API, abstracting away the implementation differences such that code using GTlsCertificate doesn't need to know the difference. The original PKCS#11 implementation was never fully baked and at some point in the past I deleted it all. It has since been replaced with a new implementation, including a GTlsCertificate:private-key-pkcs11-uri property, which is readable. So our current API already exposes the differences between normal private keys and PKCS#11-backed private keys. The point of making the private-key and private-key-pem properties write-only was to avoid exposing this difference. Do we have to make this API function readable? No, because WebKit could be just as well served if we were to expose serialize and deserialize functions instead. But WebKit needs to support serializing and deserializing the non-private portion of GTlsCertificate with older versions of GLib anyway, so we can do whatever is nicest for GLib. And I think making this property readable is nicest, since the original design reason for it to not be readable is now obsolete. The disadvantage to this approach is that it's now possible for an application to read the private-key or private-key-pem property, receive NULL, and think "this certificate must not have a private key," which would be incorrect if the private-key-pkcs11-uri property is set. That seems like a minor risk, but it should be documented.
2021-05-06 19:04:29 +02:00
g_clear_pointer (&parsed_key_pem, g_free);
Add certificate chain construction test Enhance GTestTlsBackend to allow setting the issuer property of GTlsCertificates, and add a test to ensure certificate chain construction with g_tls_certificate_new_from_pem() works as expected. https://bugzilla.gnome.org/show_bug.cgi?id=754264
2015-08-29 02:47:19 +02:00
/* Now test the second cert */
issuer = g_tls_certificate_get_issuer (cert);
tests/tls-certificate: Change to g_assert_null/nonnull Use g_assert_null/g_assert_nonnull instead of g_assert since g_assert can be compiled out with G_DISABLE_ASSERT.
2018-12-18 10:39:01 +01:00
g_assert_nonnull (issuer);
Add certificate chain construction test Enhance GTestTlsBackend to allow setting the issuer property of GTlsCertificates, and add a test to ensure certificate chain construction with g_tls_certificate_new_from_pem() works as expected. https://bugzilla.gnome.org/show_bug.cgi?id=754264
2015-08-29 02:47:19 +02:00
cert = issuer;
issuer = g_tls_certificate_get_issuer (cert);
tests/tls-certificate: Change to g_assert_null/nonnull Use g_assert_null/g_assert_nonnull instead of g_assert since g_assert can be compiled out with G_DISABLE_ASSERT.
2018-12-18 10:39:01 +01:00
g_assert_nonnull (issuer);
Add certificate chain construction test Enhance GTestTlsBackend to allow setting the issuer property of GTlsCertificates, and add a test to ensure certificate chain construction with g_tls_certificate_new_from_pem() works as expected. https://bugzilla.gnome.org/show_bug.cgi?id=754264
2015-08-29 02:47:19 +02:00
g_object_get (cert,
"certificate-pem", &parsed_cert_pem,
gtlscertificate: make private key properties readable WebKit wants these private key properties to be readable in order to implement a deserialization function. Currently they are read-only because at the time GTlsCertificate was originally designed, the plan was to support PKCS#11-backed private keys: private keys that are stored on a smartcard, where the private key is completely unreadable. The design goal was to support both memory-backed and smartcard-backed private keys with the same GTlsCertificate API, abstracting away the implementation differences such that code using GTlsCertificate doesn't need to know the difference. The original PKCS#11 implementation was never fully baked and at some point in the past I deleted it all. It has since been replaced with a new implementation, including a GTlsCertificate:private-key-pkcs11-uri property, which is readable. So our current API already exposes the differences between normal private keys and PKCS#11-backed private keys. The point of making the private-key and private-key-pem properties write-only was to avoid exposing this difference. Do we have to make this API function readable? No, because WebKit could be just as well served if we were to expose serialize and deserialize functions instead. But WebKit needs to support serializing and deserializing the non-private portion of GTlsCertificate with older versions of GLib anyway, so we can do whatever is nicest for GLib. And I think making this property readable is nicest, since the original design reason for it to not be readable is now obsolete. The disadvantage to this approach is that it's now possible for an application to read the private-key or private-key-pem property, receive NULL, and think "this certificate must not have a private key," which would be incorrect if the private-key-pkcs11-uri property is set. That seems like a minor risk, but it should be documented.
2021-05-06 19:04:29 +02:00
"private-key-pem", &parsed_key_pem,
Add certificate chain construction test Enhance GTestTlsBackend to allow setting the issuer property of GTlsCertificates, and add a test to ensure certificate chain construction with g_tls_certificate_new_from_pem() works as expected. https://bugzilla.gnome.org/show_bug.cgi?id=754264
2015-08-29 02:47:19 +02:00
NULL);
g_assert_cmpstr (parsed_cert_pem, ==, ref->cert_pems[1]);
g_clear_pointer (&parsed_cert_pem, g_free);
/* Only the first cert should have a private key */
tests/tls-certificate: Change to g_assert_null/nonnull Use g_assert_null/g_assert_nonnull instead of g_assert since g_assert can be compiled out with G_DISABLE_ASSERT.
2018-12-18 10:39:01 +01:00
g_assert_null (parsed_key_pem);
Add certificate chain construction test Enhance GTestTlsBackend to allow setting the issuer property of GTlsCertificates, and add a test to ensure certificate chain construction with g_tls_certificate_new_from_pem() works as expected. https://bugzilla.gnome.org/show_bug.cgi?id=754264
2015-08-29 02:47:19 +02:00
/* Now test the final cert */
cert = issuer;
issuer = g_tls_certificate_get_issuer (cert);
tests/tls-certificate: Change to g_assert_null/nonnull Use g_assert_null/g_assert_nonnull instead of g_assert since g_assert can be compiled out with G_DISABLE_ASSERT.
2018-12-18 10:39:01 +01:00
g_assert_null (issuer);
Add certificate chain construction test Enhance GTestTlsBackend to allow setting the issuer property of GTlsCertificates, and add a test to ensure certificate chain construction with g_tls_certificate_new_from_pem() works as expected. https://bugzilla.gnome.org/show_bug.cgi?id=754264
2015-08-29 02:47:19 +02:00
g_object_get (cert,
"certificate-pem", &parsed_cert_pem,
gtlscertificate: make private key properties readable WebKit wants these private key properties to be readable in order to implement a deserialization function. Currently they are read-only because at the time GTlsCertificate was originally designed, the plan was to support PKCS#11-backed private keys: private keys that are stored on a smartcard, where the private key is completely unreadable. The design goal was to support both memory-backed and smartcard-backed private keys with the same GTlsCertificate API, abstracting away the implementation differences such that code using GTlsCertificate doesn't need to know the difference. The original PKCS#11 implementation was never fully baked and at some point in the past I deleted it all. It has since been replaced with a new implementation, including a GTlsCertificate:private-key-pkcs11-uri property, which is readable. So our current API already exposes the differences between normal private keys and PKCS#11-backed private keys. The point of making the private-key and private-key-pem properties write-only was to avoid exposing this difference. Do we have to make this API function readable? No, because WebKit could be just as well served if we were to expose serialize and deserialize functions instead. But WebKit needs to support serializing and deserializing the non-private portion of GTlsCertificate with older versions of GLib anyway, so we can do whatever is nicest for GLib. And I think making this property readable is nicest, since the original design reason for it to not be readable is now obsolete. The disadvantage to this approach is that it's now possible for an application to read the private-key or private-key-pem property, receive NULL, and think "this certificate must not have a private key," which would be incorrect if the private-key-pkcs11-uri property is set. That seems like a minor risk, but it should be documented.
2021-05-06 19:04:29 +02:00
"private-key-pem", &parsed_key_pem,
Add certificate chain construction test Enhance GTestTlsBackend to allow setting the issuer property of GTlsCertificates, and add a test to ensure certificate chain construction with g_tls_certificate_new_from_pem() works as expected. https://bugzilla.gnome.org/show_bug.cgi?id=754264
2015-08-29 02:47:19 +02:00
NULL);
g_assert_cmpstr (parsed_cert_pem, ==, ref->cert_pems[2]);
g_clear_pointer (&parsed_cert_pem, g_free);
tests/tls-certificate: Change to g_assert_null/nonnull Use g_assert_null/g_assert_nonnull instead of g_assert since g_assert can be compiled out with G_DISABLE_ASSERT.
2018-12-18 10:39:01 +01:00
g_assert_null (parsed_key_pem);
Add certificate chain construction test Enhance GTestTlsBackend to allow setting the issuer property of GTlsCertificates, and add a test to ensure certificate chain construction with g_tls_certificate_new_from_pem() works as expected. https://bugzilla.gnome.org/show_bug.cgi?id=754264
2015-08-29 02:47:19 +02:00
g_object_unref (original_cert);
}
tests/tls-certificate: Add a unit test Test whether g_tls_certificate_new_from_pem() can handle a non-nul-terminated PEM. Helps https://gitlab.gnome.org/GNOME/glib/-/issues/2416
2021-06-03 22:24:47 +02:00
static void
pem_parser_no_sentinel (void)
{
GTlsCertificate *cert;
gchar *pem;
gsize pem_len = 0;
gchar *pem_copy;
GError *error = NULL;
/* Check certificate from not-nul-terminated PEM */
g_file_get_contents (g_test_get_filename (G_TEST_DIST, "cert-tests", "cert1.pem", NULL), &pem, &pem_len, &error);
g_assert_no_error (error);
g_assert_nonnull (pem);
g_assert_cmpuint (pem_len, >=, 10);
pem_copy = g_new (char, pem_len);
/* Do not copy the terminating nul: */
memmove (pem_copy, pem, pem_len);
g_free (pem);
tests/tls-certificate: Add context to the new test Add a comment to `pem_parser_no_sentinel()` to explain what it is testing and how it works.
2021-06-05 16:14:24 +02:00
/* Check whether the parser respects the @length parameter.
* pem_copy is allocated exactly pem_len bytes, so accessing memory
* outside its bounds will be detected by, for example, valgrind or
* asan. */
tests/tls-certificate: Add a unit test Test whether g_tls_certificate_new_from_pem() can handle a non-nul-terminated PEM. Helps https://gitlab.gnome.org/GNOME/glib/-/issues/2416
2021-06-03 22:24:47 +02:00
cert = g_tls_certificate_new_from_pem (pem_copy, pem_len, &error);
g_assert_no_error (error);
g_assert_nonnull (cert);
g_free (pem_copy);
g_object_unref (cert);
}
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
static void
from_file (const Reference *ref)
{
GTlsCertificate *cert;
gchar *parsed_cert_pem = NULL;
gtlscertificate: make private key properties readable WebKit wants these private key properties to be readable in order to implement a deserialization function. Currently they are read-only because at the time GTlsCertificate was originally designed, the plan was to support PKCS#11-backed private keys: private keys that are stored on a smartcard, where the private key is completely unreadable. The design goal was to support both memory-backed and smartcard-backed private keys with the same GTlsCertificate API, abstracting away the implementation differences such that code using GTlsCertificate doesn't need to know the difference. The original PKCS#11 implementation was never fully baked and at some point in the past I deleted it all. It has since been replaced with a new implementation, including a GTlsCertificate:private-key-pkcs11-uri property, which is readable. So our current API already exposes the differences between normal private keys and PKCS#11-backed private keys. The point of making the private-key and private-key-pem properties write-only was to avoid exposing this difference. Do we have to make this API function readable? No, because WebKit could be just as well served if we were to expose serialize and deserialize functions instead. But WebKit needs to support serializing and deserializing the non-private portion of GTlsCertificate with older versions of GLib anyway, so we can do whatever is nicest for GLib. And I think making this property readable is nicest, since the original design reason for it to not be readable is now obsolete. The disadvantage to this approach is that it's now possible for an application to read the private-key or private-key-pem property, receive NULL, and think "this certificate must not have a private key," which would be incorrect if the private-key-pkcs11-uri property is set. That seems like a minor risk, but it should be documented.
2021-05-06 19:04:29 +02:00
gchar *parsed_key_pem = NULL;
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
GError *error = NULL;
Rename G_TEST_DISTED to G_TEST_DIST Since this feature is so utterly automake-centric, we may as well be using the same terminology as automake itself (ie: although it's BUILT_SOURCES, it's DIST_EXTRA, not DISTED). Also add some comments to the enum explaining that these terms are really corresponding directly to the automake terms. https://bugzilla.gnome.org/show_bug.cgi?id=549783
2013-05-29 14:49:16 +02:00
cert = g_tls_certificate_new_from_file (g_test_get_filename (G_TEST_DIST, "cert-tests", "key-cert.pem", NULL),
tests: move tests to new _get_filename() API This API was introduced to save a few lines of code here and there, so let's start by removing a bunch from our own tests. https://bugzilla.gnome.org/show_bug.cgi?id=549783
2013-05-28 20:24:47 +02:00
&error);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
g_assert_no_error (error);
tests/tls-certificate: Change to g_assert_null/nonnull Use g_assert_null/g_assert_nonnull instead of g_assert since g_assert can be compiled out with G_DISABLE_ASSERT.
2018-12-18 10:39:01 +01:00
g_assert_nonnull (cert);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
g_object_get (cert,
"certificate-pem", &parsed_cert_pem,
gtlscertificate: make private key properties readable WebKit wants these private key properties to be readable in order to implement a deserialization function. Currently they are read-only because at the time GTlsCertificate was originally designed, the plan was to support PKCS#11-backed private keys: private keys that are stored on a smartcard, where the private key is completely unreadable. The design goal was to support both memory-backed and smartcard-backed private keys with the same GTlsCertificate API, abstracting away the implementation differences such that code using GTlsCertificate doesn't need to know the difference. The original PKCS#11 implementation was never fully baked and at some point in the past I deleted it all. It has since been replaced with a new implementation, including a GTlsCertificate:private-key-pkcs11-uri property, which is readable. So our current API already exposes the differences between normal private keys and PKCS#11-backed private keys. The point of making the private-key and private-key-pem properties write-only was to avoid exposing this difference. Do we have to make this API function readable? No, because WebKit could be just as well served if we were to expose serialize and deserialize functions instead. But WebKit needs to support serializing and deserializing the non-private portion of GTlsCertificate with older versions of GLib anyway, so we can do whatever is nicest for GLib. And I think making this property readable is nicest, since the original design reason for it to not be readable is now obsolete. The disadvantage to this approach is that it's now possible for an application to read the private-key or private-key-pem property, receive NULL, and think "this certificate must not have a private key," which would be incorrect if the private-key-pkcs11-uri property is set. That seems like a minor risk, but it should be documented.
2021-05-06 19:04:29 +02:00
"private-key-pem", &parsed_key_pem,
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
NULL);
g_assert_cmpstr (parsed_cert_pem, ==, ref->cert_pems[0]);
gtlscertificate: make private key properties readable WebKit wants these private key properties to be readable in order to implement a deserialization function. Currently they are read-only because at the time GTlsCertificate was originally designed, the plan was to support PKCS#11-backed private keys: private keys that are stored on a smartcard, where the private key is completely unreadable. The design goal was to support both memory-backed and smartcard-backed private keys with the same GTlsCertificate API, abstracting away the implementation differences such that code using GTlsCertificate doesn't need to know the difference. The original PKCS#11 implementation was never fully baked and at some point in the past I deleted it all. It has since been replaced with a new implementation, including a GTlsCertificate:private-key-pkcs11-uri property, which is readable. So our current API already exposes the differences between normal private keys and PKCS#11-backed private keys. The point of making the private-key and private-key-pem properties write-only was to avoid exposing this difference. Do we have to make this API function readable? No, because WebKit could be just as well served if we were to expose serialize and deserialize functions instead. But WebKit needs to support serializing and deserializing the non-private portion of GTlsCertificate with older versions of GLib anyway, so we can do whatever is nicest for GLib. And I think making this property readable is nicest, since the original design reason for it to not be readable is now obsolete. The disadvantage to this approach is that it's now possible for an application to read the private-key or private-key-pem property, receive NULL, and think "this certificate must not have a private key," which would be incorrect if the private-key-pkcs11-uri property is set. That seems like a minor risk, but it should be documented.
2021-05-06 19:04:29 +02:00
g_clear_pointer (&parsed_cert_pem, g_free);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
g_assert_cmpstr (parsed_key_pem, ==, ref->key_pem);
gtlscertificate: make private key properties readable WebKit wants these private key properties to be readable in order to implement a deserialization function. Currently they are read-only because at the time GTlsCertificate was originally designed, the plan was to support PKCS#11-backed private keys: private keys that are stored on a smartcard, where the private key is completely unreadable. The design goal was to support both memory-backed and smartcard-backed private keys with the same GTlsCertificate API, abstracting away the implementation differences such that code using GTlsCertificate doesn't need to know the difference. The original PKCS#11 implementation was never fully baked and at some point in the past I deleted it all. It has since been replaced with a new implementation, including a GTlsCertificate:private-key-pkcs11-uri property, which is readable. So our current API already exposes the differences between normal private keys and PKCS#11-backed private keys. The point of making the private-key and private-key-pem properties write-only was to avoid exposing this difference. Do we have to make this API function readable? No, because WebKit could be just as well served if we were to expose serialize and deserialize functions instead. But WebKit needs to support serializing and deserializing the non-private portion of GTlsCertificate with older versions of GLib anyway, so we can do whatever is nicest for GLib. And I think making this property readable is nicest, since the original design reason for it to not be readable is now obsolete. The disadvantage to this approach is that it's now possible for an application to read the private-key or private-key-pem property, receive NULL, and think "this certificate must not have a private key," which would be incorrect if the private-key-pkcs11-uri property is set. That seems like a minor risk, but it should be documented.
2021-05-06 19:04:29 +02:00
g_clear_pointer (&parsed_key_pem, g_free);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
g_object_unref (cert);
}
static void
from_files (const Reference *ref)
{
GTlsCertificate *cert;
gchar *parsed_cert_pem = NULL;
gtlscertificate: make private key properties readable WebKit wants these private key properties to be readable in order to implement a deserialization function. Currently they are read-only because at the time GTlsCertificate was originally designed, the plan was to support PKCS#11-backed private keys: private keys that are stored on a smartcard, where the private key is completely unreadable. The design goal was to support both memory-backed and smartcard-backed private keys with the same GTlsCertificate API, abstracting away the implementation differences such that code using GTlsCertificate doesn't need to know the difference. The original PKCS#11 implementation was never fully baked and at some point in the past I deleted it all. It has since been replaced with a new implementation, including a GTlsCertificate:private-key-pkcs11-uri property, which is readable. So our current API already exposes the differences between normal private keys and PKCS#11-backed private keys. The point of making the private-key and private-key-pem properties write-only was to avoid exposing this difference. Do we have to make this API function readable? No, because WebKit could be just as well served if we were to expose serialize and deserialize functions instead. But WebKit needs to support serializing and deserializing the non-private portion of GTlsCertificate with older versions of GLib anyway, so we can do whatever is nicest for GLib. And I think making this property readable is nicest, since the original design reason for it to not be readable is now obsolete. The disadvantage to this approach is that it's now possible for an application to read the private-key or private-key-pem property, receive NULL, and think "this certificate must not have a private key," which would be incorrect if the private-key-pkcs11-uri property is set. That seems like a minor risk, but it should be documented.
2021-05-06 19:04:29 +02:00
gchar *parsed_key_pem = NULL;
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
GError *error = NULL;
Rename G_TEST_DISTED to G_TEST_DIST Since this feature is so utterly automake-centric, we may as well be using the same terminology as automake itself (ie: although it's BUILT_SOURCES, it's DIST_EXTRA, not DISTED). Also add some comments to the enum explaining that these terms are really corresponding directly to the automake terms. https://bugzilla.gnome.org/show_bug.cgi?id=549783
2013-05-29 14:49:16 +02:00
cert = g_tls_certificate_new_from_files (g_test_get_filename (G_TEST_DIST, "cert-tests", "cert1.pem", NULL),
g_test_get_filename (G_TEST_DIST, "cert-tests", "key.pem", NULL),
tests: move tests to new _get_filename() API This API was introduced to save a few lines of code here and there, so let's start by removing a bunch from our own tests. https://bugzilla.gnome.org/show_bug.cgi?id=549783
2013-05-28 20:24:47 +02:00
&error);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
g_assert_no_error (error);
tests/tls-certificate: Change to g_assert_null/nonnull Use g_assert_null/g_assert_nonnull instead of g_assert since g_assert can be compiled out with G_DISABLE_ASSERT.
2018-12-18 10:39:01 +01:00
g_assert_nonnull (cert);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
g_object_get (cert,
"certificate-pem", &parsed_cert_pem,
gtlscertificate: make private key properties readable WebKit wants these private key properties to be readable in order to implement a deserialization function. Currently they are read-only because at the time GTlsCertificate was originally designed, the plan was to support PKCS#11-backed private keys: private keys that are stored on a smartcard, where the private key is completely unreadable. The design goal was to support both memory-backed and smartcard-backed private keys with the same GTlsCertificate API, abstracting away the implementation differences such that code using GTlsCertificate doesn't need to know the difference. The original PKCS#11 implementation was never fully baked and at some point in the past I deleted it all. It has since been replaced with a new implementation, including a GTlsCertificate:private-key-pkcs11-uri property, which is readable. So our current API already exposes the differences between normal private keys and PKCS#11-backed private keys. The point of making the private-key and private-key-pem properties write-only was to avoid exposing this difference. Do we have to make this API function readable? No, because WebKit could be just as well served if we were to expose serialize and deserialize functions instead. But WebKit needs to support serializing and deserializing the non-private portion of GTlsCertificate with older versions of GLib anyway, so we can do whatever is nicest for GLib. And I think making this property readable is nicest, since the original design reason for it to not be readable is now obsolete. The disadvantage to this approach is that it's now possible for an application to read the private-key or private-key-pem property, receive NULL, and think "this certificate must not have a private key," which would be incorrect if the private-key-pkcs11-uri property is set. That seems like a minor risk, but it should be documented.
2021-05-06 19:04:29 +02:00
"private-key-pem", &parsed_key_pem,
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
NULL);
g_assert_cmpstr (parsed_cert_pem, ==, ref->cert_pems[0]);
gtlscertificate: make private key properties readable WebKit wants these private key properties to be readable in order to implement a deserialization function. Currently they are read-only because at the time GTlsCertificate was originally designed, the plan was to support PKCS#11-backed private keys: private keys that are stored on a smartcard, where the private key is completely unreadable. The design goal was to support both memory-backed and smartcard-backed private keys with the same GTlsCertificate API, abstracting away the implementation differences such that code using GTlsCertificate doesn't need to know the difference. The original PKCS#11 implementation was never fully baked and at some point in the past I deleted it all. It has since been replaced with a new implementation, including a GTlsCertificate:private-key-pkcs11-uri property, which is readable. So our current API already exposes the differences between normal private keys and PKCS#11-backed private keys. The point of making the private-key and private-key-pem properties write-only was to avoid exposing this difference. Do we have to make this API function readable? No, because WebKit could be just as well served if we were to expose serialize and deserialize functions instead. But WebKit needs to support serializing and deserializing the non-private portion of GTlsCertificate with older versions of GLib anyway, so we can do whatever is nicest for GLib. And I think making this property readable is nicest, since the original design reason for it to not be readable is now obsolete. The disadvantage to this approach is that it's now possible for an application to read the private-key or private-key-pem property, receive NULL, and think "this certificate must not have a private key," which would be incorrect if the private-key-pkcs11-uri property is set. That seems like a minor risk, but it should be documented.
2021-05-06 19:04:29 +02:00
g_clear_pointer (&parsed_cert_pem, g_free);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
g_assert_cmpstr (parsed_key_pem, ==, ref->key_pem);
gtlscertificate: make private key properties readable WebKit wants these private key properties to be readable in order to implement a deserialization function. Currently they are read-only because at the time GTlsCertificate was originally designed, the plan was to support PKCS#11-backed private keys: private keys that are stored on a smartcard, where the private key is completely unreadable. The design goal was to support both memory-backed and smartcard-backed private keys with the same GTlsCertificate API, abstracting away the implementation differences such that code using GTlsCertificate doesn't need to know the difference. The original PKCS#11 implementation was never fully baked and at some point in the past I deleted it all. It has since been replaced with a new implementation, including a GTlsCertificate:private-key-pkcs11-uri property, which is readable. So our current API already exposes the differences between normal private keys and PKCS#11-backed private keys. The point of making the private-key and private-key-pem properties write-only was to avoid exposing this difference. Do we have to make this API function readable? No, because WebKit could be just as well served if we were to expose serialize and deserialize functions instead. But WebKit needs to support serializing and deserializing the non-private portion of GTlsCertificate with older versions of GLib anyway, so we can do whatever is nicest for GLib. And I think making this property readable is nicest, since the original design reason for it to not be readable is now obsolete. The disadvantage to this approach is that it's now possible for an application to read the private-key or private-key-pem property, receive NULL, and think "this certificate must not have a private key," which would be incorrect if the private-key-pkcs11-uri property is set. That seems like a minor risk, but it should be documented.
2021-05-06 19:04:29 +02:00
g_clear_pointer (&parsed_key_pem, g_free);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
g_object_unref (cert);
/* Missing private key */
Rename G_TEST_DISTED to G_TEST_DIST Since this feature is so utterly automake-centric, we may as well be using the same terminology as automake itself (ie: although it's BUILT_SOURCES, it's DIST_EXTRA, not DISTED). Also add some comments to the enum explaining that these terms are really corresponding directly to the automake terms. https://bugzilla.gnome.org/show_bug.cgi?id=549783
2013-05-29 14:49:16 +02:00
cert = g_tls_certificate_new_from_files (g_test_get_filename (G_TEST_DIST, "cert-tests", "cert1.pem", NULL),
g_test_get_filename (G_TEST_DIST, "cert-tests", "cert2.pem", NULL),
tests: move tests to new _get_filename() API This API was introduced to save a few lines of code here and there, so let's start by removing a bunch from our own tests. https://bugzilla.gnome.org/show_bug.cgi?id=549783
2013-05-28 20:24:47 +02:00
&error);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
g_assert_error (error, G_TLS_ERROR, G_TLS_ERROR_BAD_CERTIFICATE);
g_clear_error (&error);
tests/tls-certificate: Change to g_assert_null/nonnull Use g_assert_null/g_assert_nonnull instead of g_assert since g_assert can be compiled out with G_DISABLE_ASSERT.
2018-12-18 10:39:01 +01:00
g_assert_null (cert);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
gtlscertificate: Allow any type of private key in PEM files Allow any type of private key in PEM files by treating PEM guards ending with "PRIVATE KEY-----" as a private key instead of looking for a pre-defined set of PEM guards. This enables the possibility for custom GTlsBackend to add support for new key types. Test cases have been expanded to ensure PEM parsing works for private key when either header or footer is missing. Encrypted PKCS#8 is still rejected. Test case has been added for this to ensure behaviour is the same before and after this change.
2018-12-10 08:48:45 +01:00
/* Missing header private key */
cert = g_tls_certificate_new_from_files (g_test_get_filename (G_TEST_DIST, "cert-tests", "cert1.pem", NULL),
g_test_get_filename (G_TEST_DIST, "cert-tests", "key_missing-header.pem", NULL),
&error);
g_assert_error (error, G_TLS_ERROR, G_TLS_ERROR_BAD_CERTIFICATE);
g_clear_error (&error);
g_assert_null (cert);
/* Missing footer private key */
cert = g_tls_certificate_new_from_files (g_test_get_filename (G_TEST_DIST, "cert-tests", "cert1.pem", NULL),
g_test_get_filename (G_TEST_DIST, "cert-tests", "key_missing-footer.pem", NULL),
&error);
g_assert_error (error, G_TLS_ERROR, G_TLS_ERROR_BAD_CERTIFICATE);
g_clear_error (&error);
g_assert_null (cert);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
/* Missing certificate */
Rename G_TEST_DISTED to G_TEST_DIST Since this feature is so utterly automake-centric, we may as well be using the same terminology as automake itself (ie: although it's BUILT_SOURCES, it's DIST_EXTRA, not DISTED). Also add some comments to the enum explaining that these terms are really corresponding directly to the automake terms. https://bugzilla.gnome.org/show_bug.cgi?id=549783
2013-05-29 14:49:16 +02:00
cert = g_tls_certificate_new_from_files (g_test_get_filename (G_TEST_DIST, "cert-tests", "key.pem", NULL),
g_test_get_filename (G_TEST_DIST, "cert-tests", "key.pem", NULL),
tests: move tests to new _get_filename() API This API was introduced to save a few lines of code here and there, so let's start by removing a bunch from our own tests. https://bugzilla.gnome.org/show_bug.cgi?id=549783
2013-05-28 20:24:47 +02:00
&error);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
g_assert_error (error, G_TLS_ERROR, G_TLS_ERROR_BAD_CERTIFICATE);
g_clear_error (&error);
tests/tls-certificate: Change to g_assert_null/nonnull Use g_assert_null/g_assert_nonnull instead of g_assert since g_assert can be compiled out with G_DISABLE_ASSERT.
2018-12-18 10:39:01 +01:00
g_assert_null (cert);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
/* Using this method twice with a file containing both private key and
tree: Fix various typos and outdated terminology This was mostly machine generated with the following command: ``` codespell \ --builtin clear,rare,usage \ --skip './po/*' --skip './.git/*' --skip './NEWS*' \ --write-changes . ``` using the latest git version of `codespell` as per [these instructions](https://github.com/codespell-project/codespell#user-content-updating). Then I manually checked each change using `git add -p`, made a few manual fixups and dropped a load of incorrect changes. There are still some outdated or loaded terms used in GLib, mostly to do with git branch terminology. They will need to be changed later as part of a wider migration of git terminology. If I’ve missed anything, please file an issue! Signed-off-by: Philip Withnall <withnall@endlessm.com>
2020-06-12 15:02:30 +02:00
* certificate as a way to enforce private key presence is a fair use
Convert some gio tests to installed tests
2013-05-20 12:38:41 +02:00
*/
Rename G_TEST_DISTED to G_TEST_DIST Since this feature is so utterly automake-centric, we may as well be using the same terminology as automake itself (ie: although it's BUILT_SOURCES, it's DIST_EXTRA, not DISTED). Also add some comments to the enum explaining that these terms are really corresponding directly to the automake terms. https://bugzilla.gnome.org/show_bug.cgi?id=549783
2013-05-29 14:49:16 +02:00
cert = g_tls_certificate_new_from_files (g_test_get_filename (G_TEST_DIST, "cert-tests", "key-cert.pem", NULL),
g_test_get_filename (G_TEST_DIST, "cert-tests", "key-cert.pem", NULL),
tests: move tests to new _get_filename() API This API was introduced to save a few lines of code here and there, so let's start by removing a bunch from our own tests. https://bugzilla.gnome.org/show_bug.cgi?id=549783
2013-05-28 20:24:47 +02:00
&error);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
g_assert_no_error (error);
tests/tls-certificate: Change to g_assert_null/nonnull Use g_assert_null/g_assert_nonnull instead of g_assert since g_assert can be compiled out with G_DISABLE_ASSERT.
2018-12-18 10:39:01 +01:00
g_assert_nonnull (cert);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
g_object_unref (cert);
}
GTlsCertificate: support unencrypted PKCS#8 private keys PKCS#8 is the "right" way to encode private keys. Although the APIs do not currently support encrypted keys, we should at least support unencrypted PKCS#8 keys. https://bugzilla.gnome.org/show_bug.cgi?id=664321
2011-11-18 21:05:34 +01:00
tests/tls-certificate: Add PEM files containing CRLF Add test case to ensure correct parsing of PEM files containing CRLF (\r\n) line endings.
2018-12-18 11:21:19 +01:00
static void
from_files_crlf (const Reference *ref)
{
GTlsCertificate *cert;
gchar *parsed_cert_pem = NULL;
gtlscertificate: make private key properties readable WebKit wants these private key properties to be readable in order to implement a deserialization function. Currently they are read-only because at the time GTlsCertificate was originally designed, the plan was to support PKCS#11-backed private keys: private keys that are stored on a smartcard, where the private key is completely unreadable. The design goal was to support both memory-backed and smartcard-backed private keys with the same GTlsCertificate API, abstracting away the implementation differences such that code using GTlsCertificate doesn't need to know the difference. The original PKCS#11 implementation was never fully baked and at some point in the past I deleted it all. It has since been replaced with a new implementation, including a GTlsCertificate:private-key-pkcs11-uri property, which is readable. So our current API already exposes the differences between normal private keys and PKCS#11-backed private keys. The point of making the private-key and private-key-pem properties write-only was to avoid exposing this difference. Do we have to make this API function readable? No, because WebKit could be just as well served if we were to expose serialize and deserialize functions instead. But WebKit needs to support serializing and deserializing the non-private portion of GTlsCertificate with older versions of GLib anyway, so we can do whatever is nicest for GLib. And I think making this property readable is nicest, since the original design reason for it to not be readable is now obsolete. The disadvantage to this approach is that it's now possible for an application to read the private-key or private-key-pem property, receive NULL, and think "this certificate must not have a private key," which would be incorrect if the private-key-pkcs11-uri property is set. That seems like a minor risk, but it should be documented.
2021-05-06 19:04:29 +02:00
gchar *parsed_key_pem = NULL;
tests/tls-certificate: Add PEM files containing CRLF Add test case to ensure correct parsing of PEM files containing CRLF (\r\n) line endings.
2018-12-18 11:21:19 +01:00
GError *error = NULL;
cert = g_tls_certificate_new_from_files (g_test_get_filename (G_TEST_DIST, "cert-tests", "cert-crlf.pem", NULL),
g_test_get_filename (G_TEST_DIST, "cert-tests", "key-crlf.pem", NULL),
&error);
g_assert_no_error (error);
g_assert_nonnull (cert);
g_object_get (cert,
"certificate-pem", &parsed_cert_pem,
gtlscertificate: make private key properties readable WebKit wants these private key properties to be readable in order to implement a deserialization function. Currently they are read-only because at the time GTlsCertificate was originally designed, the plan was to support PKCS#11-backed private keys: private keys that are stored on a smartcard, where the private key is completely unreadable. The design goal was to support both memory-backed and smartcard-backed private keys with the same GTlsCertificate API, abstracting away the implementation differences such that code using GTlsCertificate doesn't need to know the difference. The original PKCS#11 implementation was never fully baked and at some point in the past I deleted it all. It has since been replaced with a new implementation, including a GTlsCertificate:private-key-pkcs11-uri property, which is readable. So our current API already exposes the differences between normal private keys and PKCS#11-backed private keys. The point of making the private-key and private-key-pem properties write-only was to avoid exposing this difference. Do we have to make this API function readable? No, because WebKit could be just as well served if we were to expose serialize and deserialize functions instead. But WebKit needs to support serializing and deserializing the non-private portion of GTlsCertificate with older versions of GLib anyway, so we can do whatever is nicest for GLib. And I think making this property readable is nicest, since the original design reason for it to not be readable is now obsolete. The disadvantage to this approach is that it's now possible for an application to read the private-key or private-key-pem property, receive NULL, and think "this certificate must not have a private key," which would be incorrect if the private-key-pkcs11-uri property is set. That seems like a minor risk, but it should be documented.
2021-05-06 19:04:29 +02:00
"private-key-pem", &parsed_key_pem,
tests/tls-certificate: Add PEM files containing CRLF Add test case to ensure correct parsing of PEM files containing CRLF (\r\n) line endings.
2018-12-18 11:21:19 +01:00
NULL);
g_assert_cmpstr (parsed_cert_pem, ==, ref->cert_crlf_pem);
gtlscertificate: make private key properties readable WebKit wants these private key properties to be readable in order to implement a deserialization function. Currently they are read-only because at the time GTlsCertificate was originally designed, the plan was to support PKCS#11-backed private keys: private keys that are stored on a smartcard, where the private key is completely unreadable. The design goal was to support both memory-backed and smartcard-backed private keys with the same GTlsCertificate API, abstracting away the implementation differences such that code using GTlsCertificate doesn't need to know the difference. The original PKCS#11 implementation was never fully baked and at some point in the past I deleted it all. It has since been replaced with a new implementation, including a GTlsCertificate:private-key-pkcs11-uri property, which is readable. So our current API already exposes the differences between normal private keys and PKCS#11-backed private keys. The point of making the private-key and private-key-pem properties write-only was to avoid exposing this difference. Do we have to make this API function readable? No, because WebKit could be just as well served if we were to expose serialize and deserialize functions instead. But WebKit needs to support serializing and deserializing the non-private portion of GTlsCertificate with older versions of GLib anyway, so we can do whatever is nicest for GLib. And I think making this property readable is nicest, since the original design reason for it to not be readable is now obsolete. The disadvantage to this approach is that it's now possible for an application to read the private-key or private-key-pem property, receive NULL, and think "this certificate must not have a private key," which would be incorrect if the private-key-pkcs11-uri property is set. That seems like a minor risk, but it should be documented.
2021-05-06 19:04:29 +02:00
g_clear_pointer (&parsed_cert_pem, g_free);
tests/tls-certificate: Add PEM files containing CRLF Add test case to ensure correct parsing of PEM files containing CRLF (\r\n) line endings.
2018-12-18 11:21:19 +01:00
g_assert_cmpstr (parsed_key_pem, ==, ref->key_crlf_pem);
gtlscertificate: make private key properties readable WebKit wants these private key properties to be readable in order to implement a deserialization function. Currently they are read-only because at the time GTlsCertificate was originally designed, the plan was to support PKCS#11-backed private keys: private keys that are stored on a smartcard, where the private key is completely unreadable. The design goal was to support both memory-backed and smartcard-backed private keys with the same GTlsCertificate API, abstracting away the implementation differences such that code using GTlsCertificate doesn't need to know the difference. The original PKCS#11 implementation was never fully baked and at some point in the past I deleted it all. It has since been replaced with a new implementation, including a GTlsCertificate:private-key-pkcs11-uri property, which is readable. So our current API already exposes the differences between normal private keys and PKCS#11-backed private keys. The point of making the private-key and private-key-pem properties write-only was to avoid exposing this difference. Do we have to make this API function readable? No, because WebKit could be just as well served if we were to expose serialize and deserialize functions instead. But WebKit needs to support serializing and deserializing the non-private portion of GTlsCertificate with older versions of GLib anyway, so we can do whatever is nicest for GLib. And I think making this property readable is nicest, since the original design reason for it to not be readable is now obsolete. The disadvantage to this approach is that it's now possible for an application to read the private-key or private-key-pem property, receive NULL, and think "this certificate must not have a private key," which would be incorrect if the private-key-pkcs11-uri property is set. That seems like a minor risk, but it should be documented.
2021-05-06 19:04:29 +02:00
g_clear_pointer (&parsed_key_pem, g_free);
tests/tls-certificate: Add PEM files containing CRLF Add test case to ensure correct parsing of PEM files containing CRLF (\r\n) line endings.
2018-12-18 11:21:19 +01:00
g_object_unref (cert);
}
GTlsCertificate: support unencrypted PKCS#8 private keys PKCS#8 is the "right" way to encode private keys. Although the APIs do not currently support encrypted keys, we should at least support unencrypted PKCS#8 keys. https://bugzilla.gnome.org/show_bug.cgi?id=664321
2011-11-18 21:05:34 +01:00
static void
from_files_pkcs8 (const Reference *ref)
{
GTlsCertificate *cert;
gchar *parsed_cert_pem = NULL;
gtlscertificate: make private key properties readable WebKit wants these private key properties to be readable in order to implement a deserialization function. Currently they are read-only because at the time GTlsCertificate was originally designed, the plan was to support PKCS#11-backed private keys: private keys that are stored on a smartcard, where the private key is completely unreadable. The design goal was to support both memory-backed and smartcard-backed private keys with the same GTlsCertificate API, abstracting away the implementation differences such that code using GTlsCertificate doesn't need to know the difference. The original PKCS#11 implementation was never fully baked and at some point in the past I deleted it all. It has since been replaced with a new implementation, including a GTlsCertificate:private-key-pkcs11-uri property, which is readable. So our current API already exposes the differences between normal private keys and PKCS#11-backed private keys. The point of making the private-key and private-key-pem properties write-only was to avoid exposing this difference. Do we have to make this API function readable? No, because WebKit could be just as well served if we were to expose serialize and deserialize functions instead. But WebKit needs to support serializing and deserializing the non-private portion of GTlsCertificate with older versions of GLib anyway, so we can do whatever is nicest for GLib. And I think making this property readable is nicest, since the original design reason for it to not be readable is now obsolete. The disadvantage to this approach is that it's now possible for an application to read the private-key or private-key-pem property, receive NULL, and think "this certificate must not have a private key," which would be incorrect if the private-key-pkcs11-uri property is set. That seems like a minor risk, but it should be documented.
2021-05-06 19:04:29 +02:00
gchar *parsed_key_pem = NULL;
GTlsCertificate: support unencrypted PKCS#8 private keys PKCS#8 is the "right" way to encode private keys. Although the APIs do not currently support encrypted keys, we should at least support unencrypted PKCS#8 keys. https://bugzilla.gnome.org/show_bug.cgi?id=664321
2011-11-18 21:05:34 +01:00
GError *error = NULL;
Rename G_TEST_DISTED to G_TEST_DIST Since this feature is so utterly automake-centric, we may as well be using the same terminology as automake itself (ie: although it's BUILT_SOURCES, it's DIST_EXTRA, not DISTED). Also add some comments to the enum explaining that these terms are really corresponding directly to the automake terms. https://bugzilla.gnome.org/show_bug.cgi?id=549783
2013-05-29 14:49:16 +02:00
cert = g_tls_certificate_new_from_files (g_test_get_filename (G_TEST_DIST, "cert-tests", "cert1.pem", NULL),
g_test_get_filename (G_TEST_DIST, "cert-tests", "key8.pem", NULL),
tests: move tests to new _get_filename() API This API was introduced to save a few lines of code here and there, so let's start by removing a bunch from our own tests. https://bugzilla.gnome.org/show_bug.cgi?id=549783
2013-05-28 20:24:47 +02:00
&error);
GTlsCertificate: support unencrypted PKCS#8 private keys PKCS#8 is the "right" way to encode private keys. Although the APIs do not currently support encrypted keys, we should at least support unencrypted PKCS#8 keys. https://bugzilla.gnome.org/show_bug.cgi?id=664321
2011-11-18 21:05:34 +01:00
g_assert_no_error (error);
tests/tls-certificate: Change to g_assert_null/nonnull Use g_assert_null/g_assert_nonnull instead of g_assert since g_assert can be compiled out with G_DISABLE_ASSERT.
2018-12-18 10:39:01 +01:00
g_assert_nonnull (cert);
GTlsCertificate: support unencrypted PKCS#8 private keys PKCS#8 is the "right" way to encode private keys. Although the APIs do not currently support encrypted keys, we should at least support unencrypted PKCS#8 keys. https://bugzilla.gnome.org/show_bug.cgi?id=664321
2011-11-18 21:05:34 +01:00
g_object_get (cert,
"certificate-pem", &parsed_cert_pem,
gtlscertificate: make private key properties readable WebKit wants these private key properties to be readable in order to implement a deserialization function. Currently they are read-only because at the time GTlsCertificate was originally designed, the plan was to support PKCS#11-backed private keys: private keys that are stored on a smartcard, where the private key is completely unreadable. The design goal was to support both memory-backed and smartcard-backed private keys with the same GTlsCertificate API, abstracting away the implementation differences such that code using GTlsCertificate doesn't need to know the difference. The original PKCS#11 implementation was never fully baked and at some point in the past I deleted it all. It has since been replaced with a new implementation, including a GTlsCertificate:private-key-pkcs11-uri property, which is readable. So our current API already exposes the differences between normal private keys and PKCS#11-backed private keys. The point of making the private-key and private-key-pem properties write-only was to avoid exposing this difference. Do we have to make this API function readable? No, because WebKit could be just as well served if we were to expose serialize and deserialize functions instead. But WebKit needs to support serializing and deserializing the non-private portion of GTlsCertificate with older versions of GLib anyway, so we can do whatever is nicest for GLib. And I think making this property readable is nicest, since the original design reason for it to not be readable is now obsolete. The disadvantage to this approach is that it's now possible for an application to read the private-key or private-key-pem property, receive NULL, and think "this certificate must not have a private key," which would be incorrect if the private-key-pkcs11-uri property is set. That seems like a minor risk, but it should be documented.
2021-05-06 19:04:29 +02:00
"private-key-pem", &parsed_key_pem,
GTlsCertificate: support unencrypted PKCS#8 private keys PKCS#8 is the "right" way to encode private keys. Although the APIs do not currently support encrypted keys, we should at least support unencrypted PKCS#8 keys. https://bugzilla.gnome.org/show_bug.cgi?id=664321
2011-11-18 21:05:34 +01:00
NULL);
g_assert_cmpstr (parsed_cert_pem, ==, ref->cert_pems[0]);
gtlscertificate: make private key properties readable WebKit wants these private key properties to be readable in order to implement a deserialization function. Currently they are read-only because at the time GTlsCertificate was originally designed, the plan was to support PKCS#11-backed private keys: private keys that are stored on a smartcard, where the private key is completely unreadable. The design goal was to support both memory-backed and smartcard-backed private keys with the same GTlsCertificate API, abstracting away the implementation differences such that code using GTlsCertificate doesn't need to know the difference. The original PKCS#11 implementation was never fully baked and at some point in the past I deleted it all. It has since been replaced with a new implementation, including a GTlsCertificate:private-key-pkcs11-uri property, which is readable. So our current API already exposes the differences between normal private keys and PKCS#11-backed private keys. The point of making the private-key and private-key-pem properties write-only was to avoid exposing this difference. Do we have to make this API function readable? No, because WebKit could be just as well served if we were to expose serialize and deserialize functions instead. But WebKit needs to support serializing and deserializing the non-private portion of GTlsCertificate with older versions of GLib anyway, so we can do whatever is nicest for GLib. And I think making this property readable is nicest, since the original design reason for it to not be readable is now obsolete. The disadvantage to this approach is that it's now possible for an application to read the private-key or private-key-pem property, receive NULL, and think "this certificate must not have a private key," which would be incorrect if the private-key-pkcs11-uri property is set. That seems like a minor risk, but it should be documented.
2021-05-06 19:04:29 +02:00
g_clear_pointer (&parsed_cert_pem, g_free);
GTlsCertificate: support unencrypted PKCS#8 private keys PKCS#8 is the "right" way to encode private keys. Although the APIs do not currently support encrypted keys, we should at least support unencrypted PKCS#8 keys. https://bugzilla.gnome.org/show_bug.cgi?id=664321
2011-11-18 21:05:34 +01:00
g_assert_cmpstr (parsed_key_pem, ==, ref->key8_pem);
gtlscertificate: make private key properties readable WebKit wants these private key properties to be readable in order to implement a deserialization function. Currently they are read-only because at the time GTlsCertificate was originally designed, the plan was to support PKCS#11-backed private keys: private keys that are stored on a smartcard, where the private key is completely unreadable. The design goal was to support both memory-backed and smartcard-backed private keys with the same GTlsCertificate API, abstracting away the implementation differences such that code using GTlsCertificate doesn't need to know the difference. The original PKCS#11 implementation was never fully baked and at some point in the past I deleted it all. It has since been replaced with a new implementation, including a GTlsCertificate:private-key-pkcs11-uri property, which is readable. So our current API already exposes the differences between normal private keys and PKCS#11-backed private keys. The point of making the private-key and private-key-pem properties write-only was to avoid exposing this difference. Do we have to make this API function readable? No, because WebKit could be just as well served if we were to expose serialize and deserialize functions instead. But WebKit needs to support serializing and deserializing the non-private portion of GTlsCertificate with older versions of GLib anyway, so we can do whatever is nicest for GLib. And I think making this property readable is nicest, since the original design reason for it to not be readable is now obsolete. The disadvantage to this approach is that it's now possible for an application to read the private-key or private-key-pem property, receive NULL, and think "this certificate must not have a private key," which would be incorrect if the private-key-pkcs11-uri property is set. That seems like a minor risk, but it should be documented.
2021-05-06 19:04:29 +02:00
g_clear_pointer (&parsed_key_pem, g_free);
GTlsCertificate: support unencrypted PKCS#8 private keys PKCS#8 is the "right" way to encode private keys. Although the APIs do not currently support encrypted keys, we should at least support unencrypted PKCS#8 keys. https://bugzilla.gnome.org/show_bug.cgi?id=664321
2011-11-18 21:05:34 +01:00
g_object_unref (cert);
}
gtlscertificate: Allow any type of private key in PEM files Allow any type of private key in PEM files by treating PEM guards ending with "PRIVATE KEY-----" as a private key instead of looking for a pre-defined set of PEM guards. This enables the possibility for custom GTlsBackend to add support for new key types. Test cases have been expanded to ensure PEM parsing works for private key when either header or footer is missing. Encrypted PKCS#8 is still rejected. Test case has been added for this to ensure behaviour is the same before and after this change.
2018-12-10 08:48:45 +01:00
static void
from_files_pkcs8enc (const Reference *ref)
{
GTlsCertificate *cert;
GError *error = NULL;
/* Mare sure an error is returned for encrypted key */
cert = g_tls_certificate_new_from_files (g_test_get_filename (G_TEST_DIST, "cert-tests", "cert1.pem", NULL),
g_test_get_filename (G_TEST_DIST, "cert-tests", "key8enc.pem", NULL),
&error);
g_assert_error (error, G_TLS_ERROR, G_TLS_ERROR_BAD_CERTIFICATE);
g_clear_error (&error);
g_assert_null (cert);
}
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
static void
list_from_file (const Reference *ref)
{
GList *list, *l;
GError *error = NULL;
int i;
Rename G_TEST_DISTED to G_TEST_DIST Since this feature is so utterly automake-centric, we may as well be using the same terminology as automake itself (ie: although it's BUILT_SOURCES, it's DIST_EXTRA, not DISTED). Also add some comments to the enum explaining that these terms are really corresponding directly to the automake terms. https://bugzilla.gnome.org/show_bug.cgi?id=549783
2013-05-29 14:49:16 +02:00
list = g_tls_certificate_list_new_from_file (g_test_get_filename (G_TEST_DIST, "cert-tests", "cert-list.pem", NULL),
tests: move tests to new _get_filename() API This API was introduced to save a few lines of code here and there, so let's start by removing a bunch from our own tests. https://bugzilla.gnome.org/show_bug.cgi?id=549783
2013-05-28 20:24:47 +02:00
&error);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
g_assert_no_error (error);
g_assert_cmpint (g_list_length (list), ==, 3);
l = list;
for (i = 0; i < 3; i++)
{
GTlsCertificate *cert = l->data;
gchar *parsed_cert_pem = NULL;
g_object_get (cert,
"certificate-pem", &parsed_cert_pem,
NULL);
g_assert_cmpstr (parsed_cert_pem, ==, ref->cert_pems[i]);
g_free (parsed_cert_pem);
l = g_list_next (l);
}
g_list_free_full (list, g_object_unref);
/* Empty list is not an error */
Rename G_TEST_DISTED to G_TEST_DIST Since this feature is so utterly automake-centric, we may as well be using the same terminology as automake itself (ie: although it's BUILT_SOURCES, it's DIST_EXTRA, not DISTED). Also add some comments to the enum explaining that these terms are really corresponding directly to the automake terms. https://bugzilla.gnome.org/show_bug.cgi?id=549783
2013-05-29 14:49:16 +02:00
list = g_tls_certificate_list_new_from_file (g_test_get_filename (G_TEST_DIST, "cert-tests", "nothing.pem", NULL),
tests: move tests to new _get_filename() API This API was introduced to save a few lines of code here and there, so let's start by removing a bunch from our own tests. https://bugzilla.gnome.org/show_bug.cgi?id=549783
2013-05-28 20:24:47 +02:00
&error);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
g_assert_no_error (error);
g_assert_cmpint (g_list_length (list), ==, 0);
}
gtlscertificate: Add support for PKCS #11 backed certificates This reverts commit d58e5de9e9c8d93e64d34aa8a7100bdfbc9b8dac.
2020-09-25 21:40:14 +02:00
static void
from_pkcs11_uri (void)
{
GError *error = NULL;
GTlsCertificate *cert;
gchar *pkcs11_uri = NULL;
cert = g_tls_certificate_new_from_pkcs11_uris ("pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=ca-bundle.crt", NULL, &error);
g_assert_no_error (error);
g_assert_nonnull (cert);
g_object_get (cert, "pkcs11-uri", &pkcs11_uri, NULL);
g_assert_cmpstr ("pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=ca-bundle.crt", ==, pkcs11_uri);
g_free (pkcs11_uri);
g_object_unref (cert);
}
static void
from_unsupported_pkcs11_uri (void)
{
GError *error = NULL;
GTlsCertificate *cert;
/* This is a magic value in gtesttlsbackend.c simulating an unsupported backend */
cert = g_tls_certificate_new_from_pkcs11_uris ("unsupported", NULL, &error);
g_assert_error (error, G_IO_ERROR, G_IO_ERROR_NOT_SUPPORTED);
g_assert_null (cert);
g_clear_error (&error);
}
tls: expose cert details on GTlsCertificate This changeset exposes * `not-valid-before` * `not-valid-after` * `subject-name` * `issuer-name` on GTlsCertificate provided by the underlying TLS Backend. In order to make use of these changes, see the related [glib-networking MR][glib-networking]. This change aims to help populate more of the [`Certificate`][wk-cert] info in the WebKit Inspector Protocol on Linux. This changeset stems from work in Microsoft Playwright to [add more info into its HAR capture][pw] generated from the Inspector Protocol events and will bring feature parity across WebKit platforms. [wk-cert]: https://github.com/WebKit/WebKit/blob/8afe31a018b11741abdf9b4d5bb973d7c1d9ff05/Source/JavaScriptCore/inspector/protocol/Security.json [pw]: https://github.com/microsoft/playwright/pull/6631 [glib-networking]: https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/156
2021-05-26 09:59:37 +02:00
static void
not_valid_before (void)
{
const gchar *EXPECTED_NOT_VALID_BEFORE = "2020-10-12T17:49:44Z";
GTlsCertificate *cert;
GError *error = NULL;
GDateTime *actual;
gchar *actual_str;
cert = g_tls_certificate_new_from_pkcs11_uris ("pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=ca-bundle.crt", NULL, &error);
g_assert_no_error (error);
g_assert_nonnull (cert);
actual = g_tls_certificate_get_not_valid_before (cert);
g_assert_nonnull (actual);
actual_str = g_date_time_format_iso8601 (actual);
g_assert_cmpstr (actual_str, ==, EXPECTED_NOT_VALID_BEFORE);
g_free (actual_str);
g_date_time_unref (actual);
g_object_unref (cert);
}
static void
not_valid_after (void)
{
const gchar *EXPECTED_NOT_VALID_AFTER = "2045-10-06T17:49:44Z";
GTlsCertificate *cert;
GError *error = NULL;
GDateTime *actual;
gchar *actual_str;
cert = g_tls_certificate_new_from_pkcs11_uris ("pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=ca-bundle.crt", NULL, &error);
g_assert_no_error (error);
g_assert_nonnull (cert);
actual = g_tls_certificate_get_not_valid_after (cert);
g_assert_nonnull (actual);
actual_str = g_date_time_format_iso8601 (actual);
g_assert_cmpstr (actual_str, ==, EXPECTED_NOT_VALID_AFTER);
g_free (actual_str);
g_date_time_unref (actual);
g_object_unref (cert);
}
static void
subject_name (void)
{
const gchar *EXPECTED_SUBJECT_NAME = "DC=COM,DC=EXAMPLE,CN=server.example.com";
GTlsCertificate *cert;
GError *error = NULL;
gchar *actual;
cert = g_tls_certificate_new_from_pkcs11_uris ("pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=ca-bundle.crt", NULL, &error);
g_assert_no_error (error);
g_assert_nonnull (cert);
actual = g_tls_certificate_get_subject_name (cert);
g_assert_nonnull (actual);
g_assert_cmpstr (actual, ==, EXPECTED_SUBJECT_NAME);
g_free (actual);
g_object_unref (cert);
}
static void
issuer_name (void)
{
const gchar *EXPECTED_ISSUER_NAME = "DC=COM,DC=EXAMPLE,OU=Certificate Authority,CN=ca.example.com,emailAddress=ca@example.com";
GTlsCertificate *cert;
GError *error = NULL;
gchar *actual;
cert = g_tls_certificate_new_from_pkcs11_uris ("pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=ca-bundle.crt", NULL, &error);
g_assert_no_error (error);
g_assert_nonnull (cert);
actual = g_tls_certificate_get_issuer_name (cert);
g_assert_nonnull (actual);
g_assert_cmpstr (actual, ==, EXPECTED_ISSUER_NAME);
g_free (actual);
g_object_unref (cert);
}
tls: expose SAN details on GTlsCertificate This changeset exposes * `dns-names` * `ip-addresses` on GTlsCertificate provided by the underlying TLS Backend. See https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/165 for the corresponding glib-networking changes. Relates: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2113 Relates: https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/156/diffs Relates: https://github.com/microsoft/playwright/issues/6759
2021-06-10 02:54:45 +02:00
static void
dns_names (void)
{
GTlsCertificate *cert;
GError *error = NULL;
GPtrArray *actual;
const gchar *dns_name = "a.example.com";
GBytes *expected = g_bytes_new_static (dns_name, strlen (dns_name));
cert = g_tls_certificate_new_from_pkcs11_uris ("pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=ca-bundle.crt", NULL, &error);
g_assert_no_error (error);
g_assert_nonnull (cert);
actual = g_tls_certificate_get_dns_names (cert);
g_assert_nonnull (actual);
g_assert_cmpuint (actual->len, ==, 1);
g_assert_true (g_ptr_array_find_with_equal_func (actual, expected, (GEqualFunc)g_bytes_equal, NULL));
tests: Fix a memory leak in the tls-certificate test Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-02-18 03:33:39 +01:00
g_ptr_array_unref (actual);
tls: expose SAN details on GTlsCertificate This changeset exposes * `dns-names` * `ip-addresses` on GTlsCertificate provided by the underlying TLS Backend. See https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/165 for the corresponding glib-networking changes. Relates: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2113 Relates: https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/156/diffs Relates: https://github.com/microsoft/playwright/issues/6759
2021-06-10 02:54:45 +02:00
g_bytes_unref (expected);
g_object_unref (cert);
}
static void
ip_addresses (void)
{
GTlsCertificate *cert;
GError *error = NULL;
GPtrArray *actual;
GInetAddress *expected = g_inet_address_new_from_string ("192.0.2.1");
cert = g_tls_certificate_new_from_pkcs11_uris ("pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=ca-bundle.crt", NULL, &error);
g_assert_no_error (error);
g_assert_nonnull (cert);
actual = g_tls_certificate_get_ip_addresses (cert);
g_assert_nonnull (actual);
g_assert_cmpuint (actual->len, ==, 1);
g_assert_true (g_ptr_array_find_with_equal_func (actual, expected, (GEqualFunc)g_inet_address_equal, NULL));
g_ptr_array_free (actual, TRUE);
g_object_unref (expected);
g_object_unref (cert);
}
gtlscertificate: Add ability to load PKCS #12 encrypted files This depends on the GTlsBackend implementing these properties
2021-09-04 02:13:21 +02:00
static void
from_pkcs12 (void)
{
GTlsCertificate *cert;
GError *error = NULL;
const guint8 data[1] = { 0 };
/* This simply fails because our test backend doesn't support this
* property. This reflects using a backend that doesn't support it.
* The real test lives in glib-networking. */
cert = g_tls_certificate_new_from_pkcs12 (data, 1, NULL, &error);
g_assert_null (cert);
g_assert_error (error, G_IO_ERROR, G_IO_ERROR_NOT_SUPPORTED);
g_error_free (error);
}
static void
from_pkcs12_file (void)
{
GTlsCertificate *cert;
GError *error = NULL;
char *path = g_test_build_filename (G_TEST_DIST, "cert-tests", "key-cert-password-123.p12", NULL);
/* Fails on our test backend, see from_pkcs12() above. */
cert = g_tls_certificate_new_from_file_with_password (path, "123", &error);
g_assert_null (cert);
g_assert_error (error, G_IO_ERROR, G_IO_ERROR_NOT_SUPPORTED);
g_clear_error (&error);
/* Just for coverage. */
cert = g_tls_certificate_new_from_file (path, &error);
g_assert_null (cert);
g_assert_error (error, G_IO_ERROR, G_IO_ERROR_NOT_SUPPORTED);
g_error_free (error);
g_free (path);
}
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
int
main (int argc,
char *argv[])
{
int rtv;
Reference ref;
GError *error = NULL;
Convert some gio tests to installed tests
2013-05-20 12:38:41 +02:00
gchar *path;
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
g_test_init (&argc, &argv, NULL);
_g_test_tls_backend_get_type ();
/* Load reference PEM */
Rename G_TEST_DISTED to G_TEST_DIST Since this feature is so utterly automake-centric, we may as well be using the same terminology as automake itself (ie: although it's BUILT_SOURCES, it's DIST_EXTRA, not DISTED). Also add some comments to the enum explaining that these terms are really corresponding directly to the automake terms. https://bugzilla.gnome.org/show_bug.cgi?id=549783
2013-05-29 14:49:16 +02:00
path = g_test_build_filename (G_TEST_DIST, "cert-tests", "cert1.pem", NULL);
Convert some gio tests to installed tests
2013-05-20 12:38:41 +02:00
g_file_get_contents (path, &ref.cert_pems[0], NULL, &error);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
g_assert_no_error (error);
tests/tls-certificate: Change to g_assert_null/nonnull Use g_assert_null/g_assert_nonnull instead of g_assert since g_assert can be compiled out with G_DISABLE_ASSERT.
2018-12-18 10:39:01 +01:00
g_assert_nonnull (ref.cert_pems[0]);
Convert some gio tests to installed tests
2013-05-20 12:38:41 +02:00
g_free (path);
Rename G_TEST_DISTED to G_TEST_DIST Since this feature is so utterly automake-centric, we may as well be using the same terminology as automake itself (ie: although it's BUILT_SOURCES, it's DIST_EXTRA, not DISTED). Also add some comments to the enum explaining that these terms are really corresponding directly to the automake terms. https://bugzilla.gnome.org/show_bug.cgi?id=549783
2013-05-29 14:49:16 +02:00
path = g_test_build_filename (G_TEST_DIST, "cert-tests", "cert2.pem", NULL);
Convert some gio tests to installed tests
2013-05-20 12:38:41 +02:00
g_file_get_contents (path, &ref.cert_pems[1], NULL, &error);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
g_assert_no_error (error);
tests/tls-certificate: Change to g_assert_null/nonnull Use g_assert_null/g_assert_nonnull instead of g_assert since g_assert can be compiled out with G_DISABLE_ASSERT.
2018-12-18 10:39:01 +01:00
g_assert_nonnull (ref.cert_pems[1]);
Convert some gio tests to installed tests
2013-05-20 12:38:41 +02:00
g_free (path);
Rename G_TEST_DISTED to G_TEST_DIST Since this feature is so utterly automake-centric, we may as well be using the same terminology as automake itself (ie: although it's BUILT_SOURCES, it's DIST_EXTRA, not DISTED). Also add some comments to the enum explaining that these terms are really corresponding directly to the automake terms. https://bugzilla.gnome.org/show_bug.cgi?id=549783
2013-05-29 14:49:16 +02:00
path = g_test_build_filename (G_TEST_DIST, "cert-tests", "cert3.pem", NULL);
Convert some gio tests to installed tests
2013-05-20 12:38:41 +02:00
g_file_get_contents (path, &ref.cert_pems[2], NULL, &error);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
g_assert_no_error (error);
tests/tls-certificate: Change to g_assert_null/nonnull Use g_assert_null/g_assert_nonnull instead of g_assert since g_assert can be compiled out with G_DISABLE_ASSERT.
2018-12-18 10:39:01 +01:00
g_assert_nonnull (ref.cert_pems[2]);
Convert some gio tests to installed tests
2013-05-20 12:38:41 +02:00
g_free (path);
tests/tls-certificate: Add PEM files containing CRLF Add test case to ensure correct parsing of PEM files containing CRLF (\r\n) line endings.
2018-12-18 11:21:19 +01:00
path = g_test_build_filename (G_TEST_DIST, "cert-tests", "cert-crlf.pem", NULL);
g_file_get_contents (path, &ref.cert_crlf_pem, NULL, &error);
g_assert_no_error (error);
g_assert_nonnull (ref.cert_crlf_pem);
g_free (path);
Rename G_TEST_DISTED to G_TEST_DIST Since this feature is so utterly automake-centric, we may as well be using the same terminology as automake itself (ie: although it's BUILT_SOURCES, it's DIST_EXTRA, not DISTED). Also add some comments to the enum explaining that these terms are really corresponding directly to the automake terms. https://bugzilla.gnome.org/show_bug.cgi?id=549783
2013-05-29 14:49:16 +02:00
path = g_test_build_filename (G_TEST_DIST, "cert-tests", "key.pem", NULL);
Convert some gio tests to installed tests
2013-05-20 12:38:41 +02:00
g_file_get_contents (path, &ref.key_pem, NULL, &error);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
g_assert_no_error (error);
tests/tls-certificate: Change to g_assert_null/nonnull Use g_assert_null/g_assert_nonnull instead of g_assert since g_assert can be compiled out with G_DISABLE_ASSERT.
2018-12-18 10:39:01 +01:00
g_assert_nonnull (ref.key_pem);
Convert some gio tests to installed tests
2013-05-20 12:38:41 +02:00
g_free (path);
tests/tls-certificate: Add PEM files containing CRLF Add test case to ensure correct parsing of PEM files containing CRLF (\r\n) line endings.
2018-12-18 11:21:19 +01:00
path = g_test_build_filename (G_TEST_DIST, "cert-tests", "key-crlf.pem", NULL);
g_file_get_contents (path, &ref.key_crlf_pem, NULL, &error);
g_assert_no_error (error);
g_assert_nonnull (ref.key_crlf_pem);
g_free (path);
Rename G_TEST_DISTED to G_TEST_DIST Since this feature is so utterly automake-centric, we may as well be using the same terminology as automake itself (ie: although it's BUILT_SOURCES, it's DIST_EXTRA, not DISTED). Also add some comments to the enum explaining that these terms are really corresponding directly to the automake terms. https://bugzilla.gnome.org/show_bug.cgi?id=549783
2013-05-29 14:49:16 +02:00
path = g_test_build_filename (G_TEST_DIST, "cert-tests", "key8.pem", NULL);
Convert some gio tests to installed tests
2013-05-20 12:38:41 +02:00
g_file_get_contents (path, &ref.key8_pem, NULL, &error);
GTlsCertificate: support unencrypted PKCS#8 private keys PKCS#8 is the "right" way to encode private keys. Although the APIs do not currently support encrypted keys, we should at least support unencrypted PKCS#8 keys. https://bugzilla.gnome.org/show_bug.cgi?id=664321
2011-11-18 21:05:34 +01:00
g_assert_no_error (error);
tests/tls-certificate: Change to g_assert_null/nonnull Use g_assert_null/g_assert_nonnull instead of g_assert since g_assert can be compiled out with G_DISABLE_ASSERT.
2018-12-18 10:39:01 +01:00
g_assert_nonnull (ref.key8_pem);
Convert some gio tests to installed tests
2013-05-20 12:38:41 +02:00
g_free (path);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
g_test_add_data_func ("/tls-certificate/pem-parser",
&ref, (GTestDataFunc)pem_parser);
Add certificate chain construction test Enhance GTestTlsBackend to allow setting the issuer property of GTlsCertificates, and add a test to ensure certificate chain construction with g_tls_certificate_new_from_pem() works as expected. https://bugzilla.gnome.org/show_bug.cgi?id=754264
2015-08-29 02:47:19 +02:00
g_test_add_data_func ("/tls-certificate/pem-parser-handles-chain",
&ref, (GTestDataFunc)pem_parser_handles_chain);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
g_test_add_data_func ("/tls-certificate/from_file",
&ref, (GTestDataFunc)from_file);
g_test_add_data_func ("/tls-certificate/from_files",
&ref, (GTestDataFunc)from_files);
tests/tls-certificate: Add PEM files containing CRLF Add test case to ensure correct parsing of PEM files containing CRLF (\r\n) line endings.
2018-12-18 11:21:19 +01:00
g_test_add_data_func ("/tls-certificate/from_files_crlf",
&ref, (GTestDataFunc)from_files_crlf);
GTlsCertificate: support unencrypted PKCS#8 private keys PKCS#8 is the "right" way to encode private keys. Although the APIs do not currently support encrypted keys, we should at least support unencrypted PKCS#8 keys. https://bugzilla.gnome.org/show_bug.cgi?id=664321
2011-11-18 21:05:34 +01:00
g_test_add_data_func ("/tls-certificate/from_files_pkcs8",
&ref, (GTestDataFunc)from_files_pkcs8);
gtlscertificate: Allow any type of private key in PEM files Allow any type of private key in PEM files by treating PEM guards ending with "PRIVATE KEY-----" as a private key instead of looking for a pre-defined set of PEM guards. This enables the possibility for custom GTlsBackend to add support for new key types. Test cases have been expanded to ensure PEM parsing works for private key when either header or footer is missing. Encrypted PKCS#8 is still rejected. Test case has been added for this to ensure behaviour is the same before and after this change.
2018-12-10 08:48:45 +01:00
g_test_add_data_func ("/tls-certificate/from_files_pkcs8enc",
&ref, (GTestDataFunc)from_files_pkcs8enc);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
g_test_add_data_func ("/tls-certificate/list_from_file",
&ref, (GTestDataFunc)list_from_file);
gtlscertificate: Add support for PKCS #11 backed certificates This reverts commit d58e5de9e9c8d93e64d34aa8a7100bdfbc9b8dac.
2020-09-25 21:40:14 +02:00
g_test_add_func ("/tls-certificate/pkcs11-uri",
from_pkcs11_uri);
g_test_add_func ("/tls-certificate/pkcs11-uri-unsupported",
from_unsupported_pkcs11_uri);
gtlscertificate: Add ability to load PKCS #12 encrypted files This depends on the GTlsBackend implementing these properties
2021-09-04 02:13:21 +02:00
g_test_add_func ("/tls-certificate/from_pkcs12",
from_pkcs12);
g_test_add_func ("/tls-certificate/from_pkcs12_file",
from_pkcs12_file);
tls: expose cert details on GTlsCertificate This changeset exposes * `not-valid-before` * `not-valid-after` * `subject-name` * `issuer-name` on GTlsCertificate provided by the underlying TLS Backend. In order to make use of these changes, see the related [glib-networking MR][glib-networking]. This change aims to help populate more of the [`Certificate`][wk-cert] info in the WebKit Inspector Protocol on Linux. This changeset stems from work in Microsoft Playwright to [add more info into its HAR capture][pw] generated from the Inspector Protocol events and will bring feature parity across WebKit platforms. [wk-cert]: https://github.com/WebKit/WebKit/blob/8afe31a018b11741abdf9b4d5bb973d7c1d9ff05/Source/JavaScriptCore/inspector/protocol/Security.json [pw]: https://github.com/microsoft/playwright/pull/6631 [glib-networking]: https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/156
2021-05-26 09:59:37 +02:00
g_test_add_func ("/tls-certificate/not-valid-before",
not_valid_before);
g_test_add_func ("/tls-certificate/not-valid-after",
not_valid_after);
g_test_add_func ("/tls-certificate/subject-name",
subject_name);
g_test_add_func ("/tls-certificate/issuer-name",
issuer_name);
tls: expose SAN details on GTlsCertificate This changeset exposes * `dns-names` * `ip-addresses` on GTlsCertificate provided by the underlying TLS Backend. See https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/165 for the corresponding glib-networking changes. Relates: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2113 Relates: https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/156/diffs Relates: https://github.com/microsoft/playwright/issues/6759
2021-06-10 02:54:45 +02:00
g_test_add_func ("/tls-certificate/dns-names",
dns_names);
g_test_add_func ("/tls-certificate/ip-addresses",
ip_addresses);
tests/tls-certificate: Add a unit test Test whether g_tls_certificate_new_from_pem() can handle a non-nul-terminated PEM. Helps https://gitlab.gnome.org/GNOME/glib/-/issues/2416
2021-06-03 22:24:47 +02:00
g_test_add_func ("/tls-certificate/pem-parser-no-sentinel",
pem_parser_no_sentinel);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
rtv = g_test_run();
g_free (ref.cert_pems[0]);
g_free (ref.cert_pems[1]);
g_free (ref.cert_pems[2]);
tests/tls-certificate: Add PEM files containing CRLF Add test case to ensure correct parsing of PEM files containing CRLF (\r\n) line endings.
2018-12-18 11:21:19 +01:00
g_free (ref.cert_crlf_pem);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
g_free (ref.key_pem);
tests/tls-certificate: Add PEM files containing CRLF Add test case to ensure correct parsing of PEM files containing CRLF (\r\n) line endings.
2018-12-18 11:21:19 +01:00
g_free (ref.key_crlf_pem);
Plug some leaks in the GIO tests Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk> Bug: https://bugzilla.gnome.org/show_bug.cgi?id=666115 Reviewed-by: Matthias Clasen <mclasen@redhat.com>
2011-12-13 19:18:07 +01:00
g_free (ref.key8_pem);
Added TLS PEM parser unit test
2011-07-25 21:59:58 +02:00
return rtv;
}
Reference in New Issue Copy Permalink