Commit Graph

24 Commits

Author SHA1 Message Date
Michael Catanzaro
c50e543e9d 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-06-15 16:06:52 -05:00
Ross Wollman
4d3618cbd1 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 00:54:45 +00:00
Peter Bloomfield
f0a1671161 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 10:14:24 -04:00
Peter Bloomfield
b9d07813d8 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-04 20:40:16 -04:00
Ross A. Wollman
a17c28790a 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]: 8afe31a018/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-06-01 16:24:33 +00:00
Patrick Griffis
f9fc29f0b7 gtlscertificate: Add support for PKCS #11 backed certificates
This reverts commit d58e5de9e9.
2020-10-01 17:09:04 +01:00
Philip Withnall
00bfb3ab44 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:01:08 +01:00
Michael Catanzaro
d58e5de9e9 Revert "gtlscertificate: Add support for PKCS #11 backed certificates"
This reverts commit b6d8efbebc.

This GLib API is good, but the implentation is not ready, so there's no
reason to commit to the API in GLib 2.64. We can reland again when the
implementation is ready.

There are three problems: (a) The glib-networking implementation normally
works, but the test has been broken for a long time. I'm not comfortable
with adding a major new feature without a working test. This is
glib-networking#104. (b) The WebKit implementation never landed. There
is a working patch, but it hasn't been accepted upstream yet. This API
isn't needed in GLib until WebKit is ready to start using it.
https://bugs.webkit.org/show_bug.cgi?id=200805. (c) Similarly, even if
the WebKit API was ready, that itself isn't useful until an application
is ready to start using it, and the Epiphany level work never happened.

Let's try again for GLib 2.66. Reverting this commit now just means we
gain another six months before committing to the API forever. No reason
to keep this in GLib 2.64 when nothing is using it yet.
2020-01-30 04:19:22 -06:00
Patrick Griffis
b6d8efbebc gtlscertificate: Add support for PKCS #11 backed certificates
This adds properties to allow backends to expose PKCS #11 support.
2019-10-02 10:12:40 -07:00
Fredrik Ternerot
a437a50694 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-18 11:43:08 +01:00
Fredrik Ternerot
73ca761a8d 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:41:45 +01:00
Fredrik Ternerot
c7ee522172 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 11:40:26 +01:00
Fredrik Ternerot
feff178c3f 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 20:18:55 +01:00
Sébastien Wilmet
d9a44b66af 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-29 19:53:34 +02:00
Michael Catanzaro
516adb99c0 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 08:43:29 -05:00
Daniel Mustieles
078dbda148 Updated FSF's address 2014-01-31 14:31:55 +01:00
Ryan Lortie
8df1bb3486 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 09:03:32 -04:00
Ryan Lortie
17ded322c5 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-29 09:03:32 -04:00
Ryan Lortie
58c6ca32aa tests: use new g_test_build_filename() API
Port most of the tests to the new g_test_build_filename() API.

https://bugzilla.gnome.org/show_bug.cgi?id=549783
2013-05-29 09:03:31 -04:00
Matthias Clasen
5e1f9173c3 Convert some gio tests to installed tests 2013-05-20 06:38:41 -04:00
Ryan Lortie
1dc774a653 Remove g_type_init() calls
Very many testcases, some GLib tools (resource compiler, etc) and
GApplication were calling g_type_init().

Remove those uses, as they are no longer required.

https://bugzilla.gnome.org/show_bug.cgi?id=686161
2012-10-16 09:39:24 -04:00
Simon McVittie
995a2eb50b 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-14 12:41:15 +00:00
Dan Winship
1dc8d1f932 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 20:26:58 -05:00
Nicolas Dufresne
dbb78fe57d Added TLS PEM parser unit test 2011-07-27 16:23:33 -04:00