Experience has shown that:
1. The current logging methods are not very reliable or practical.
A logging bitmask makes little sense as the user-facing interface (who
would want debug but not crtical messages for example?); it's
computer-friendly and user-unfriendly. More importantly the console
log level preference is initialized too late in the startup process
to be used for the logging subsystem and that fact raises a number
of annoying and hard-to-fix usability issues.
2. Coding around G_MESSAGES_DEBUG to comply with our log level mask
and not clobber the user's settings or not create unexpected log misses
is unworkable and generally follows the principle of most surprise.
The fact that G_MESSAGES_DEBUG="all" can leak to other programs using
GLib is also annoying.
3. The non-structured GLib logging API is very opinionated and lacks
configurability beyond replacing the log handler.
4. Windows GUI has some special code to attach to a console,
but it would be nice to abstract away the rest under a single
interface.
5. Using this logger seems to be noticeably faster.
Deprecate the console log level preference and extend our API to
implement a log handler in wsutil/wslog.h to provide easy-to-use,
flexible and dependable logging during all execution phases.
Log levels have a hierarchy, from most verbose to least verbose
(debug to error). When a given level is set everything above that
is also enabled.
The log level can be set with an environment variable or a command
line option (parsed as soon as possible but still later than the
environment). The default log level is "message".
Dissector logging is not included because it is not clear what log
domain they should use. An explosion to thousands of domains is
not desirable and putting everything in a single domain is probably
too coarse and noisy. For now I think it makes sense to let them do
their own thing using g_log_default_handler() and continue using the
G_MESSAGES_DEBUG mechanism with specific domains for each individual
dissector.
In the future a mechanism may be added to selectively enable these
domains at runtime while trying to avoid the problems introduced
by G_MESSAGES_DEBUG.
Every supported distribution has at least the 3.3 branch of GnuTLS
(stable branch starting in April 2014). That branch was maintained
for bug-fixes until July 2018, so some distributions (e.g. RHEL7,
SUSE Enterprise 12) are still on it, keeping us from requiring 3.4 yet.
Also clarify a comment about when the Mac OS build of gnutls started
being compiled with pkcs11 support.
The version of p11-kit that we ship with Windows will crash if we feed
gnutls_pkcs11_add_provider an invalid path. Work around this by checking
for the file's existence ourselves.
Bug: 15957
Change-Id: I81484b8bd8f837a49bc17a6c9cb0b10fd33c3f6e
Reviewed-on: https://code.wireshark.org/review/34144
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Provide a way to retrieve key URIs ("pkcs11:" and in the future maybe
"system:") and validate the PIN/password for such keys. Additionally
permit validation of a RSA key file.
This will be used for the RSA Keys GUI dialog.
Change-Id: I4177a11cb9f4758d7564daae509e20a4a42623fa
Reviewed-on: https://code.wireshark.org/review/31794
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Add support for loading RSA private key files from PKCS #11 tokens,
identified by PKCS #11 URIs. Add a new 'pkcs11_libs' UAT which can
dynamically load PKCS #11 provider libraries that are not found by
p11-kit.
The configuration GUI will need additional code to discover available
PKCS #11 tokens and will be added later.
This feature requires GnuTLS 3.4 with PKCS #11 support, so Windows,
macOS via Homebrew, Ubuntu 16.04, Debian Stretch. Not supported: RHEL7.
Currently macOS via official packages disables PKCS #11 support, so that
will also not work.
Change-Id: I20646bfd69c6bd13c8c2d27cb65c164a4b0b7a66
Reviewed-on: https://code.wireshark.org/review/30855
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Change-Id: Ie6bd309134ebbd27e90b2bf92a2df1abfdfe45a5
Fixes: v2.9.1rc0-3-g4803390686 ("Add new "rsa_keys" UAT for storage of RSA private keys")
Reviewed-on: https://code.wireshark.org/review/31031
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
This should eventually replace the "ssl_keys" UAT which additionally
contains a useless address, port and protocol field. This prepares for
HSM support through PKCS #11.
Change-Id: I59409c98aeedf260d19266d18e14ef7d9b40b582
Reviewed-on: https://code.wireshark.org/review/30977
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Even if the certificate has a RSA public key, be sure to lookup the key
only if it is an actual RSA key exchange. Move the hashtable to the
secrets module to enable reuse.
Change-Id: I39010831079d3b65d5d4368ec97d02491c1615a5
Reviewed-on: https://code.wireshark.org/review/30854
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Add a new secrets API to the core, one that can outlive the lifetime of
a single capture file. Expose decryption secrets from wiretap through a
callback and let the secrets API route it to a dissector.
Bug: 15252
Change-Id: Ie2f1867bdfd265bad11fc58f1e8d8e7295c0d1e7
Reviewed-on: https://code.wireshark.org/review/30705
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
João Valverde