summaryrefslogtreecommitdiffstats
path: root/crypto/tlscreds.c
Commit message (Collapse)AuthorAgeFilesLines
* qom: Drop parameter @errp of object_property_add() & friendsMarkus Armbruster2020-05-151-8/+4Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The only way object_property_add() can fail is when a property with the same name already exists. Since our property names are all hardcoded, failure is a programming error, and the appropriate way to handle it is passing &error_abort. Same for its variants, except for object_property_add_child(), which additionally fails when the child already has a parent. Parentage is also under program control, so this is a programming error, too. We have a bit over 500 callers. Almost half of them pass &error_abort, slightly fewer ignore errors, one test case handles errors, and the remaining few callers pass them to their own callers. The previous few commits demonstrated once again that ignoring programming errors is a bad idea. Of the few ones that pass on errors, several violate the Error API. The Error ** argument must be NULL, &error_abort, &error_fatal, or a pointer to a variable containing NULL. Passing an argument of the latter kind twice without clearing it in between is wrong: if the first call sets an error, it no longer points to NULL for the second call. ich9_pm_add_properties(), sparc32_ledma_realize(), sparc32_dma_realize(), xilinx_axidma_realize(), xilinx_enet_realize() are wrong that way. When the one appropriate choice of argument is &error_abort, letting users pick the argument is a bad idea. Drop parameter @errp and assert the preconditions instead. There's one exception to "duplicate property name is a programming error": the way object_property_add() implements the magic (and undocumented) "automatic arrayification". Don't drop @errp there. Instead, rename object_property_add() to object_property_try_add(), and add the obvious wrapper object_property_add(). Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200505152926.18877-15-armbru@redhat.com> [Two semantic rebase conflicts resolved]
* crypto: Fix LGPL information in the file headersThomas Huth2019-07-191-1/+1
| | | | | | | | | It's either "GNU *Library* General Public License version 2" or "GNU Lesser General Public License version *2.1*", but there was no "version 2.0" of the "Lesser" license. So assume that version 2.1 is meant here. Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
* Include qemu/module.h where needed, drop it from qemu-common.hMarkus Armbruster2019-06-121-0/+1
| | | | | | | | | Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190523143508.25387-4-armbru@redhat.com> [Rebased with conflicts resolved automatically, except for hw/usb/dev-hub.c hw/misc/exynos4210_rng.c hw/misc/bcm2835_rng.c hw/misc/aspeed_scu.c hw/display/virtio-vga.c hw/arm/stm32f205_soc.c; ui/cocoa.m fixed up]
* crypto: use local path for local headersMichael S. Tsirkin2018-06-011-1/+1
| | | | | | | | | | | When pulling in headers that are in the same directory as the C file (as opposed to one in include/), we should use its relative path, without a directory. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Acked-by: Daniel P. Berrangé <berrange@redhat.com>
* qapi: Change data type of the FOO_lookup generated for enum FOOMarc-André Lureau2017-09-041-1/+1
| | | | | | | | | | | | | | | | | | | | Currently, a FOO_lookup is an array of strings terminated by a NULL sentinel. A future patch will generate enums with "holes". NULL-termination will cease to work then. To prepare for that, store the length in the FOO_lookup by wrapping it in a struct and adding a member for the length. The sentinel will be dropped next. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20170822132255.23945-13-marcandre.lureau@redhat.com> [Basically redone] Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <1503564371-26090-16-git-send-email-armbru@redhat.com> [Rebased]
* crypto: add support for TLS priority string overrideDaniel P. Berrange2016-07-041-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The gnutls default priority is either "NORMAL" (most historical versions of gnutls) which is a built-in label in gnutls code, or "@SYSTEM" (latest gnutls on Fedora at least) which refers to an admin customizable entry in a gnutls config file. Regardless of which default is used by a distro, they are both global defaults applying to all applications using gnutls. If a single application on the system needs to use a weaker set of crypto priorities, this potentially forces the weakness onto all applications. Or conversely if a single application wants a strong default than all others, it can't do this via the global config file. This adds an extra parameter to the tls credential object which allows the mgmt app / user to explicitly provide a priority string to QEMU when configuring TLS. For example, to use the "NORMAL" priority, but disable SSL 3.0 one can now configure QEMU thus: $QEMU -object tls-creds-x509,id=tls0,dir=/home/berrange/qemutls,\ priority="NORMAL:-VERS-SSL3.0" \ ..other args... If creating tls-creds-anon, whatever priority the user specifies will always have "+ANON-DH" appended to it, since that's mandatory to make the anonymous credentials work. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
* include/qemu/osdep.h: Don't include qapi/error.hMarkus Armbruster2016-03-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 57cb38b included qapi/error.h into qemu/osdep.h to get the Error typedef. Since then, we've moved to include qemu/osdep.h everywhere. Its file comment explains: "To avoid getting into possible circular include dependencies, this file should not include any other QEMU headers, with the exceptions of config-host.h, compiler.h, os-posix.h and os-win32.h, all of which are doing a similar job to this file and are under similar constraints." qapi/error.h doesn't do a similar job, and it doesn't adhere to similar constraints: it includes qapi-types.h. That's in excess of 100KiB of crap most .c files don't actually need. Add the typedef to qemu/typedefs.h, and include that instead of qapi/error.h. Include qapi/error.h in .c files that need it and don't get it now. Include qapi-types.h in qom/object.h for uint16List. Update scripts/clean-includes accordingly. Update it further to match reality: replace config.h by config-target.h, add sysemu/os-posix.h, sysemu/os-win32.h. Update the list of includes in the qemu/osdep.h comment quoted above similarly. This reduces the number of objects depending on qapi/error.h from "all of them" to less than a third. Unfortunately, the number depending on qapi-types.h shrinks only a little. More work is needed for that one. Signed-off-by: Markus Armbruster <armbru@redhat.com> [Fix compilation without the spice devel packages. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* crypto: register properties against the class instead of objectDaniel P. Berrange2016-02-011-15/+21
| | | | | | | This converts the tlscredsx509, tlscredsanon and secret objects to register their properties against the class rather than object. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
* crypto: Clean up includesPeter Maydell2016-01-291-0/+1
| | | | | | | | | | Clean up includes so that osdep.h is included first and headers which it implies are not included manually. This commit was created with scripts/clean-includes. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 1453832250-766-3-git-send-email-peter.maydell@linaro.org
* crypto: avoid two coverity false positive error reportsDaniel P. Berrange2015-12-041-2/+2
| | | | | | | | | | | | | | | | | | | | | In qcrypto_tls_creds_get_path() coverity complains that we are checking '*creds' for NULL, despite having dereferenced it previously. This is harmless bug due to fact that the trace call was too early. Moving it after the cleanup gets the desired semantics. In qcrypto_tls_creds_check_cert_key_purpose() coverity complains that we're passing a pointer to a previously free'd buffer into gnutls_x509_crt_get_key_purpose_oid() This is harmless because we're passing a size == 0, so gnutls won't access the buffer, but rather just report what size it needs to be. We can avoid it though by explicitly setting the buffer to NULL after free'ing it. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
* crypto: introduce new base module for TLS credentialsDaniel P. Berrange2015-09-151-0/+251
Introduce a QCryptoTLSCreds class to act as the base class for storing TLS credentials. This will be later subclassed to provide handling of anonymous and x509 credential types. The subclasses will be user creatable objects, so instances can be created & deleted via 'object-add' and 'object-del' QMP commands respectively, or via the -object command line arg. If the credentials cannot be initialized an error will be reported as a QMP reply, or on stderr respectively. The idea is to make it possible to represent and manage TLS credentials independently of the network service that is using them. This will enable multiple services to use the same set of credentials and minimize code duplication. A later patch will convert the current VNC server TLS code over to use this object. The representation of credentials will be functionally equivalent to that currently implemented in the VNC server with one exception. The new code has the ability to (optionally) load a pre-generated set of diffie-hellman parameters, if the file dh-params.pem exists, whereas the current VNC server will always generate them on startup. This is beneficial for admins who wish to avoid the (small) time sink of generating DH parameters at startup and/or avoid depleting entropy. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>