aboutsummaryrefslogtreecommitdiff
path: root/crypto/tlscredsx509.c
AgeCommit message (Collapse)Author
2018-10-19crypto: require gnutls >= 3.1.18 for building QEMUDaniel P. Berrangé
gnutls 3.0.0 was released in 2011 and all the distros that are build target platforms for QEMU [1] include it: RHEL-7: 3.1.18 Debian (Stretch): 3.5.8 Debian (Jessie): 3.3.8 OpenBSD (ports): 3.5.18 FreeBSD (ports): 3.5.18 OpenSUSE Leap 15: 3.6.2 Ubuntu (Xenial): 3.4.10 macOS (Homebrew): 3.5.19 Based on this, it is reasonable to require gnutls >= 3.1.18 in QEMU which allows for all conditional version checks in the code to be removed. [1] https://qemu.weilnetz.de/doc/qemu-doc.html#Supported-build-platforms Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-06-01crypto: use local path for local headersMichael S. Tsirkin
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>
2016-09-12crypto: fix building complaintGonglei
gnutls commit 846753877d renamed LIBGNUTLS_VERSION_NUMBER to GNUTLS_VERSION_NUMBER. If using gnutls before that verion, we'll get the below warning: crypto/tlscredsx509.c:618:5: warning: "GNUTLS_VERSION_NUMBER" is not defined Because gnutls 3.x still defines LIBGNUTLS_VERSION_NUMBER for back compat, Let's use LIBGNUTLS_VERSION_NUMBER instead of GNUTLS_VERSION_NUMBER to fix building complaint. Signed-off-by: Gonglei <arei.gonglei@huawei.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2016-06-13TLS: provide slightly more information when TLS certificate loading failsAlex Bligh
Give slightly more information when certification loading fails. Rather than have no information, you now get gnutls's only slightly less unhelpful error messages. Signed-off-by: Alex Bligh <alex@alex.org.uk> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2016-03-22include/qemu/osdep.h: Don't include qapi/error.hMarkus Armbruster
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>
2016-02-01crypto: register properties against the class instead of objectDaniel P. Berrange
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>
2016-01-29crypto: Clean up includesPeter Maydell
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
2015-12-18crypto: add support for loading encrypted x509 keysDaniel P. Berrange
Make use of the QCryptoSecret object to support loading of encrypted x509 keys. The optional 'passwordid' parameter to the tls-creds-x509 object type, provides the ID of a secret object instance that holds the decryption password for the PEM file. # printf "123456" > mypasswd.txt # $QEMU \ -object secret,id=sec0,filename=mypasswd.txt \ -object tls-creds-x509,passwordid=sec0,id=creds0,\ dir=/home/berrange/.pki/qemu,endpoint=server \ -vnc :1,tls-creds=creds0 This requires QEMU to be linked to GNUTLS >= 3.1.11. If GNUTLS is too old an error will be reported if an attempt is made to pass a decryption password. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-12-04crypto: avoid two coverity false positive error reportsDaniel P. Berrange
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>
2015-11-18crypto: avoid passing NULL to access() syscallDaniel P. Berrange
The qcrypto_tls_creds_x509_sanity_check() checks whether certs exist by calling access(). It is valid for this method to be invoked with certfile==NULL though, since for client credentials the cert is optional. This caused it to call access(NULL), which happens to be harmless on current Linux, but should none the less be avoided. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-11-18crypto: fix leak of gnutls_dh_params_t data on credential unloadDaniel P. Berrange
The QCryptoTLSCredsX509 object was not free'ing the allocated gnutls_dh_params_t data when unloading the credentials Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-09-15crypto: add sanity checking of TLS x509 credentialsDaniel P. Berrange
If the administrator incorrectly sets up their x509 certificates, the errors seen at runtime during connection attempts are very obscure and difficult to diagnose. This has been a particular problem for people using openssl to generate their certificates instead of the gnutls certtool, because the openssl tools don't turn on the various x509 extensions that gnutls expects to be present by default. This change thus adds support in the TLS credentials object to sanity check the certificates when QEMU first loads them. This gives the administrator immediate feedback for the majority of common configuration mistakes, reducing the pain involved in setting up TLS. The code is derived from equivalent code that has been part of libvirt's TLS support and has been seen to be valuable in assisting admins. It is possible to disable the sanity checking, however, via the new 'sanity-check' property on the tls-creds object type, with a value of 'no'. Unit tests are included in this change to verify the correctness of the sanity checking code in all the key scenarios it is intended to cope with. As part of the test suite, the pkix_asn1_tab.c from gnutls is imported. This file is intentionally copied from the (long since obsolete) gnutls 1.6.3 source tree, since that version was still under GPLv2+, rather than the GPLv3+ of gnutls >= 2.0. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-09-15crypto: introduce new module for TLS x509 credentialsDaniel P. Berrange
Introduce a QCryptoTLSCredsX509 class which is used to manage x509 certificate TLS credentials. This will be the preferred credential type offering strong security characteristics Example CLI configuration: $QEMU -object tls-creds-x509,id=tls0,endpoint=server,\ dir=/path/to/creds/dir,verify-peer=yes The 'id' value in the -object args will be used to associate the credentials with the network services. For example, when the VNC server is later converted it would use $QEMU -object tls-creds-x509,id=tls0,.... \ -vnc 127.0.0.1:1,tls-creds=tls0 Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>