mirrors/qemu
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
7794b34e63
qemu/tests/test-crypto-secret.c

457 lines
11 KiB
C
Raw Normal View History

crypto: add QCryptoSecret object class for password/key handling Introduce a new QCryptoSecret object class which will be used for providing passwords and keys to other objects which need sensitive credentials. The new object can provide secret values directly as properties, or indirectly via a file. The latter includes support for file descriptor passing syntax on UNIX platforms. Ordinarily passing secret values directly as properties is insecure, since they are visible in process listings, or in log files showing the CLI args / QMP commands. It is possible to use AES-256-CBC to encrypt the secret values though, in which case all that is visible is the ciphertext. For ad hoc developer testing though, it is fine to provide the secrets directly without encryption so this is not explicitly forbidden. The anticipated scenario is that libvirtd will create a random master key per QEMU instance (eg /var/run/libvirt/qemu/$VMNAME.key) and will use that key to encrypt all passwords it provides to QEMU via '-object secret,....'. This avoids the need for libvirt (or other mgmt apps) to worry about file descriptor passing. It also makes life easier for people who are scripting the management of QEMU, for whom FD passing is significantly more complex. Providing data inline (insecure, only for ad hoc dev testing) $QEMU -object secret,id=sec0,data=letmein Providing data indirectly in raw format printf "letmein" > mypasswd.txt $QEMU -object secret,id=sec0,file=mypasswd.txt Providing data indirectly in base64 format $QEMU -object secret,id=sec0,file=mykey.b64,format=base64 Providing data with encryption $QEMU -object secret,id=master0,file=mykey.b64,format=base64 \ -object secret,id=sec0,data=[base64 ciphertext],\ keyid=master0,iv=[base64 IV],format=base64 Note that 'format' here refers to the format of the ciphertext data. The decrypted data must always be in raw byte format. More examples are shown in the updated docs. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-10-14 11:58:38 +03:00
/*
* QEMU Crypto secret handling
*
* Copyright (c) 2015 Red Hat, Inc.
*
* 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
* version 2 of the License, or (at your option) any later version.
*
* 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 Public
* License along with this library; if not, see <http://www.gnu.org/licenses/>.
*
*/
tests: Clean up includes 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> Reviewed-by: Eric Blake <eblake@redhat.com> Tested-by: Eric Blake <eblake@redhat.com>
2016-02-08 21:08:51 +03:00
#include "qemu/osdep.h"
crypto: add QCryptoSecret object class for password/key handling Introduce a new QCryptoSecret object class which will be used for providing passwords and keys to other objects which need sensitive credentials. The new object can provide secret values directly as properties, or indirectly via a file. The latter includes support for file descriptor passing syntax on UNIX platforms. Ordinarily passing secret values directly as properties is insecure, since they are visible in process listings, or in log files showing the CLI args / QMP commands. It is possible to use AES-256-CBC to encrypt the secret values though, in which case all that is visible is the ciphertext. For ad hoc developer testing though, it is fine to provide the secrets directly without encryption so this is not explicitly forbidden. The anticipated scenario is that libvirtd will create a random master key per QEMU instance (eg /var/run/libvirt/qemu/$VMNAME.key) and will use that key to encrypt all passwords it provides to QEMU via '-object secret,....'. This avoids the need for libvirt (or other mgmt apps) to worry about file descriptor passing. It also makes life easier for people who are scripting the management of QEMU, for whom FD passing is significantly more complex. Providing data inline (insecure, only for ad hoc dev testing) $QEMU -object secret,id=sec0,data=letmein Providing data indirectly in raw format printf "letmein" > mypasswd.txt $QEMU -object secret,id=sec0,file=mypasswd.txt Providing data indirectly in base64 format $QEMU -object secret,id=sec0,file=mykey.b64,format=base64 Providing data with encryption $QEMU -object secret,id=master0,file=mykey.b64,format=base64 \ -object secret,id=sec0,data=[base64 ciphertext],\ keyid=master0,iv=[base64 IV],format=base64 Note that 'format' here refers to the format of the ciphertext data. The decrypted data must always be in raw byte format. More examples are shown in the updated docs. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-10-14 11:58:38 +03:00
#include "crypto/init.h"
#include "crypto/secret.h"
include/qemu/osdep.h: Don't include qapi/error.h 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-03-14 11:01:28 +03:00
#include "qapi/error.h"
include/crypto: Include qapi-types.h or qemu/bswap.h instead of qemu-common.h qemu-common.h should only be included by .c files. Its file comment explains why: "No header file should depend on qemu-common.h, as this would easily lead to circular header dependencies." Several include/crypto/ headers include qemu-common.h, but either need just qapi-types.h from it, or qemu/bswap.h, or nothing at all. Replace or drop the include accordingly. tests/test-crypto-secret.c now misses qemu/module.h, so include it there. Signed-off-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-03-11 11:20:17 +03:00
#include "qemu/module.h"
crypto: add QCryptoSecret object class for password/key handling Introduce a new QCryptoSecret object class which will be used for providing passwords and keys to other objects which need sensitive credentials. The new object can provide secret values directly as properties, or indirectly via a file. The latter includes support for file descriptor passing syntax on UNIX platforms. Ordinarily passing secret values directly as properties is insecure, since they are visible in process listings, or in log files showing the CLI args / QMP commands. It is possible to use AES-256-CBC to encrypt the secret values though, in which case all that is visible is the ciphertext. For ad hoc developer testing though, it is fine to provide the secrets directly without encryption so this is not explicitly forbidden. The anticipated scenario is that libvirtd will create a random master key per QEMU instance (eg /var/run/libvirt/qemu/$VMNAME.key) and will use that key to encrypt all passwords it provides to QEMU via '-object secret,....'. This avoids the need for libvirt (or other mgmt apps) to worry about file descriptor passing. It also makes life easier for people who are scripting the management of QEMU, for whom FD passing is significantly more complex. Providing data inline (insecure, only for ad hoc dev testing) $QEMU -object secret,id=sec0,data=letmein Providing data indirectly in raw format printf "letmein" > mypasswd.txt $QEMU -object secret,id=sec0,file=mypasswd.txt Providing data indirectly in base64 format $QEMU -object secret,id=sec0,file=mykey.b64,format=base64 Providing data with encryption $QEMU -object secret,id=master0,file=mykey.b64,format=base64 \ -object secret,id=sec0,data=[base64 ciphertext],\ keyid=master0,iv=[base64 IV],format=base64 Note that 'format' here refers to the format of the ciphertext data. The decrypted data must always be in raw byte format. More examples are shown in the updated docs. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-10-14 11:58:38 +03:00
static void test_secret_direct(void)
{
Object *sec = object_new_with_props(
TYPE_QCRYPTO_SECRET,
object_get_objects_root(),
"sec0",
&error_abort,
"data", "123456",
NULL);
char *pw = qcrypto_secret_lookup_as_utf8("sec0",
&error_abort);
g_assert_cmpstr(pw, ==, "123456");
object_unparent(sec);
g_free(pw);
}
static void test_secret_indirect_good(void)
{
Object *sec;
char *fname = NULL;
crypto: remove temp files on completion of secrets test The secret object tests left some temporary files on disk when completing. Ensure they are unlink, and rename them to make it more obvious where they come from. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2016-04-26 12:59:09 +03:00
int fd = g_file_open_tmp("qemu-test-crypto-secret-XXXXXX",
crypto: add QCryptoSecret object class for password/key handling Introduce a new QCryptoSecret object class which will be used for providing passwords and keys to other objects which need sensitive credentials. The new object can provide secret values directly as properties, or indirectly via a file. The latter includes support for file descriptor passing syntax on UNIX platforms. Ordinarily passing secret values directly as properties is insecure, since they are visible in process listings, or in log files showing the CLI args / QMP commands. It is possible to use AES-256-CBC to encrypt the secret values though, in which case all that is visible is the ciphertext. For ad hoc developer testing though, it is fine to provide the secrets directly without encryption so this is not explicitly forbidden. The anticipated scenario is that libvirtd will create a random master key per QEMU instance (eg /var/run/libvirt/qemu/$VMNAME.key) and will use that key to encrypt all passwords it provides to QEMU via '-object secret,....'. This avoids the need for libvirt (or other mgmt apps) to worry about file descriptor passing. It also makes life easier for people who are scripting the management of QEMU, for whom FD passing is significantly more complex. Providing data inline (insecure, only for ad hoc dev testing) $QEMU -object secret,id=sec0,data=letmein Providing data indirectly in raw format printf "letmein" > mypasswd.txt $QEMU -object secret,id=sec0,file=mypasswd.txt Providing data indirectly in base64 format $QEMU -object secret,id=sec0,file=mykey.b64,format=base64 Providing data with encryption $QEMU -object secret,id=master0,file=mykey.b64,format=base64 \ -object secret,id=sec0,data=[base64 ciphertext],\ keyid=master0,iv=[base64 IV],format=base64 Note that 'format' here refers to the format of the ciphertext data. The decrypted data must always be in raw byte format. More examples are shown in the updated docs. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-10-14 11:58:38 +03:00
&fname,
NULL);
g_assert(fd >= 0);
g_assert_nonnull(fname);
g_assert(write(fd, "123456", 6) == 6);
sec = object_new_with_props(
TYPE_QCRYPTO_SECRET,
object_get_objects_root(),
"sec0",
&error_abort,
"file", fname,
NULL);
char *pw = qcrypto_secret_lookup_as_utf8("sec0",
&error_abort);
g_assert_cmpstr(pw, ==, "123456");
object_unparent(sec);
g_free(pw);
close(fd);
crypto: remove temp files on completion of secrets test The secret object tests left some temporary files on disk when completing. Ensure they are unlink, and rename them to make it more obvious where they come from. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2016-04-26 12:59:09 +03:00
unlink(fname);
crypto: add QCryptoSecret object class for password/key handling Introduce a new QCryptoSecret object class which will be used for providing passwords and keys to other objects which need sensitive credentials. The new object can provide secret values directly as properties, or indirectly via a file. The latter includes support for file descriptor passing syntax on UNIX platforms. Ordinarily passing secret values directly as properties is insecure, since they are visible in process listings, or in log files showing the CLI args / QMP commands. It is possible to use AES-256-CBC to encrypt the secret values though, in which case all that is visible is the ciphertext. For ad hoc developer testing though, it is fine to provide the secrets directly without encryption so this is not explicitly forbidden. The anticipated scenario is that libvirtd will create a random master key per QEMU instance (eg /var/run/libvirt/qemu/$VMNAME.key) and will use that key to encrypt all passwords it provides to QEMU via '-object secret,....'. This avoids the need for libvirt (or other mgmt apps) to worry about file descriptor passing. It also makes life easier for people who are scripting the management of QEMU, for whom FD passing is significantly more complex. Providing data inline (insecure, only for ad hoc dev testing) $QEMU -object secret,id=sec0,data=letmein Providing data indirectly in raw format printf "letmein" > mypasswd.txt $QEMU -object secret,id=sec0,file=mypasswd.txt Providing data indirectly in base64 format $QEMU -object secret,id=sec0,file=mykey.b64,format=base64 Providing data with encryption $QEMU -object secret,id=master0,file=mykey.b64,format=base64 \ -object secret,id=sec0,data=[base64 ciphertext],\ keyid=master0,iv=[base64 IV],format=base64 Note that 'format' here refers to the format of the ciphertext data. The decrypted data must always be in raw byte format. More examples are shown in the updated docs. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-10-14 11:58:38 +03:00
g_free(fname);
}
static void test_secret_indirect_badfile(void)
{
Object *sec = object_new_with_props(
TYPE_QCRYPTO_SECRET,
object_get_objects_root(),
"sec0",
NULL,
"file", "does-not-exist",
NULL);
g_assert(sec == NULL);
}
static void test_secret_indirect_emptyfile(void)
{
Object *sec;
char *fname = NULL;
crypto: remove temp files on completion of secrets test The secret object tests left some temporary files on disk when completing. Ensure they are unlink, and rename them to make it more obvious where they come from. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2016-04-26 12:59:09 +03:00
int fd = g_file_open_tmp("qemu-test-crypto-secretXXXXXX",
crypto: add QCryptoSecret object class for password/key handling Introduce a new QCryptoSecret object class which will be used for providing passwords and keys to other objects which need sensitive credentials. The new object can provide secret values directly as properties, or indirectly via a file. The latter includes support for file descriptor passing syntax on UNIX platforms. Ordinarily passing secret values directly as properties is insecure, since they are visible in process listings, or in log files showing the CLI args / QMP commands. It is possible to use AES-256-CBC to encrypt the secret values though, in which case all that is visible is the ciphertext. For ad hoc developer testing though, it is fine to provide the secrets directly without encryption so this is not explicitly forbidden. The anticipated scenario is that libvirtd will create a random master key per QEMU instance (eg /var/run/libvirt/qemu/$VMNAME.key) and will use that key to encrypt all passwords it provides to QEMU via '-object secret,....'. This avoids the need for libvirt (or other mgmt apps) to worry about file descriptor passing. It also makes life easier for people who are scripting the management of QEMU, for whom FD passing is significantly more complex. Providing data inline (insecure, only for ad hoc dev testing) $QEMU -object secret,id=sec0,data=letmein Providing data indirectly in raw format printf "letmein" > mypasswd.txt $QEMU -object secret,id=sec0,file=mypasswd.txt Providing data indirectly in base64 format $QEMU -object secret,id=sec0,file=mykey.b64,format=base64 Providing data with encryption $QEMU -object secret,id=master0,file=mykey.b64,format=base64 \ -object secret,id=sec0,data=[base64 ciphertext],\ keyid=master0,iv=[base64 IV],format=base64 Note that 'format' here refers to the format of the ciphertext data. The decrypted data must always be in raw byte format. More examples are shown in the updated docs. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-10-14 11:58:38 +03:00
&fname,
NULL);
g_assert(fd >= 0);
g_assert_nonnull(fname);
sec = object_new_with_props(
TYPE_QCRYPTO_SECRET,
object_get_objects_root(),
"sec0",
&error_abort,
"file", fname,
NULL);
char *pw = qcrypto_secret_lookup_as_utf8("sec0",
&error_abort);
g_assert_cmpstr(pw, ==, "");
object_unparent(sec);
g_free(pw);
close(fd);
crypto: remove temp files on completion of secrets test The secret object tests left some temporary files on disk when completing. Ensure they are unlink, and rename them to make it more obvious where they come from. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2016-04-26 12:59:09 +03:00
unlink(fname);
crypto: add QCryptoSecret object class for password/key handling Introduce a new QCryptoSecret object class which will be used for providing passwords and keys to other objects which need sensitive credentials. The new object can provide secret values directly as properties, or indirectly via a file. The latter includes support for file descriptor passing syntax on UNIX platforms. Ordinarily passing secret values directly as properties is insecure, since they are visible in process listings, or in log files showing the CLI args / QMP commands. It is possible to use AES-256-CBC to encrypt the secret values though, in which case all that is visible is the ciphertext. For ad hoc developer testing though, it is fine to provide the secrets directly without encryption so this is not explicitly forbidden. The anticipated scenario is that libvirtd will create a random master key per QEMU instance (eg /var/run/libvirt/qemu/$VMNAME.key) and will use that key to encrypt all passwords it provides to QEMU via '-object secret,....'. This avoids the need for libvirt (or other mgmt apps) to worry about file descriptor passing. It also makes life easier for people who are scripting the management of QEMU, for whom FD passing is significantly more complex. Providing data inline (insecure, only for ad hoc dev testing) $QEMU -object secret,id=sec0,data=letmein Providing data indirectly in raw format printf "letmein" > mypasswd.txt $QEMU -object secret,id=sec0,file=mypasswd.txt Providing data indirectly in base64 format $QEMU -object secret,id=sec0,file=mykey.b64,format=base64 Providing data with encryption $QEMU -object secret,id=master0,file=mykey.b64,format=base64 \ -object secret,id=sec0,data=[base64 ciphertext],\ keyid=master0,iv=[base64 IV],format=base64 Note that 'format' here refers to the format of the ciphertext data. The decrypted data must always be in raw byte format. More examples are shown in the updated docs. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-10-14 11:58:38 +03:00
g_free(fname);
}
static void test_secret_noconv_base64_good(void)
{
Object *sec = object_new_with_props(
TYPE_QCRYPTO_SECRET,
object_get_objects_root(),
"sec0",
&error_abort,
"data", "MTIzNDU2",
"format", "base64",
NULL);
char *pw = qcrypto_secret_lookup_as_base64("sec0",
&error_abort);
g_assert_cmpstr(pw, ==, "MTIzNDU2");
object_unparent(sec);
g_free(pw);
}
static void test_secret_noconv_base64_bad(void)
{
Object *sec = object_new_with_props(
TYPE_QCRYPTO_SECRET,
object_get_objects_root(),
"sec0",
NULL,
"data", "MTI$NDU2",
"format", "base64",
NULL);
g_assert(sec == NULL);
}
static void test_secret_noconv_utf8(void)
{
Object *sec = object_new_with_props(
TYPE_QCRYPTO_SECRET,
object_get_objects_root(),
"sec0",
&error_abort,
"data", "123456",
"format", "raw",
NULL);
char *pw = qcrypto_secret_lookup_as_utf8("sec0",
&error_abort);
g_assert_cmpstr(pw, ==, "123456");
object_unparent(sec);
g_free(pw);
}
static void test_secret_conv_base64_utf8valid(void)
{
Object *sec = object_new_with_props(
TYPE_QCRYPTO_SECRET,
object_get_objects_root(),
"sec0",
&error_abort,
"data", "MTIzNDU2",
"format", "base64",
NULL);
char *pw = qcrypto_secret_lookup_as_utf8("sec0",
&error_abort);
g_assert_cmpstr(pw, ==, "123456");
object_unparent(sec);
g_free(pw);
}
static void test_secret_conv_base64_utf8invalid(void)
{
Object *sec = object_new_with_props(
TYPE_QCRYPTO_SECRET,
object_get_objects_root(),
"sec0",
&error_abort,
"data", "f0VMRgIBAQAAAA==",
"format", "base64",
NULL);
char *pw = qcrypto_secret_lookup_as_utf8("sec0",
NULL);
g_assert(pw == NULL);
object_unparent(sec);
}
static void test_secret_conv_utf8_base64(void)
{
Object *sec = object_new_with_props(
TYPE_QCRYPTO_SECRET,
object_get_objects_root(),
"sec0",
&error_abort,
"data", "123456",
NULL);
char *pw = qcrypto_secret_lookup_as_base64("sec0",
&error_abort);
g_assert_cmpstr(pw, ==, "MTIzNDU2");
object_unparent(sec);
g_free(pw);
}
static void test_secret_crypt_raw(void)
{
Object *master = object_new_with_props(
TYPE_QCRYPTO_SECRET,
object_get_objects_root(),
"master",
&error_abort,
"data", "9miloPQCzGy+TL6aonfzVcptibCmCIhKzrnlfwiWivk=",
"format", "base64",
NULL);
Object *sec = object_new_with_props(
TYPE_QCRYPTO_SECRET,
object_get_objects_root(),
"sec0",
&error_abort,
"data",
"\xCC\xBF\xF7\x09\x46\x19\x0B\x52\x2A\x3A\xB4\x6B\xCD\x7A\xB0\xB0",
"format", "raw",
"keyid", "master",
"iv", "0I7Gw/TKuA+Old2W2apQ3g==",
NULL);
char *pw = qcrypto_secret_lookup_as_utf8("sec0",
&error_abort);
g_assert_cmpstr(pw, ==, "123456");
object_unparent(sec);
object_unparent(master);
g_free(pw);
}
static void test_secret_crypt_base64(void)
{
Object *master = object_new_with_props(
TYPE_QCRYPTO_SECRET,
object_get_objects_root(),
"master",
&error_abort,
"data", "9miloPQCzGy+TL6aonfzVcptibCmCIhKzrnlfwiWivk=",
"format", "base64",
NULL);
Object *sec = object_new_with_props(
TYPE_QCRYPTO_SECRET,
object_get_objects_root(),
"sec0",
&error_abort,
"data", "zL/3CUYZC1IqOrRrzXqwsA==",
"format", "base64",
"keyid", "master",
"iv", "0I7Gw/TKuA+Old2W2apQ3g==",
NULL);
char *pw = qcrypto_secret_lookup_as_utf8("sec0",
&error_abort);
g_assert_cmpstr(pw, ==, "123456");
object_unparent(sec);
object_unparent(master);
g_free(pw);
}
static void test_secret_crypt_short_key(void)
{
Object *master = object_new_with_props(
TYPE_QCRYPTO_SECRET,
object_get_objects_root(),
"master",
&error_abort,
"data", "9miloPQCzGy+TL6aonfzVc",
"format", "base64",
NULL);
Object *sec = object_new_with_props(
TYPE_QCRYPTO_SECRET,
object_get_objects_root(),
"sec0",
NULL,
"data", "zL/3CUYZC1IqOrRrzXqwsA==",
"format", "raw",
"keyid", "master",
"iv", "0I7Gw/TKuA+Old2W2apQ3g==",
NULL);
g_assert(sec == NULL);
object_unparent(master);
}
static void test_secret_crypt_short_iv(void)
{
Object *master = object_new_with_props(
TYPE_QCRYPTO_SECRET,
object_get_objects_root(),
"master",
&error_abort,
"data", "9miloPQCzGy+TL6aonfzVcptibCmCIhKzrnlfwiWivk=",
"format", "base64",
NULL);
Object *sec = object_new_with_props(
TYPE_QCRYPTO_SECRET,
object_get_objects_root(),
"sec0",
NULL,
"data", "zL/3CUYZC1IqOrRrzXqwsA==",
"format", "raw",
"keyid", "master",
"iv", "0I7Gw/TKuA+Old2W2a",
NULL);
g_assert(sec == NULL);
object_unparent(master);
}
static void test_secret_crypt_missing_iv(void)
{
Object *master = object_new_with_props(
TYPE_QCRYPTO_SECRET,
object_get_objects_root(),
"master",
&error_abort,
"data", "9miloPQCzGy+TL6aonfzVcptibCmCIhKzrnlfwiWivk=",
"format", "base64",
NULL);
Object *sec = object_new_with_props(
TYPE_QCRYPTO_SECRET,
object_get_objects_root(),
"sec0",
NULL,
"data", "zL/3CUYZC1IqOrRrzXqwsA==",
"format", "raw",
"keyid", "master",
NULL);
g_assert(sec == NULL);
object_unparent(master);
}
static void test_secret_crypt_bad_iv(void)
{
Object *master = object_new_with_props(
TYPE_QCRYPTO_SECRET,
object_get_objects_root(),
"master",
&error_abort,
"data", "9miloPQCzGy+TL6aonfzVcptibCmCIhKzrnlfwiWivk=",
"format", "base64",
NULL);
Object *sec = object_new_with_props(
TYPE_QCRYPTO_SECRET,
object_get_objects_root(),
"sec0",
NULL,
"data", "zL/3CUYZC1IqOrRrzXqwsA==",
"format", "raw",
"keyid", "master",
"iv", "0I7Gw/TK$$uA+Old2W2a",
NULL);
g_assert(sec == NULL);
object_unparent(master);
}
int main(int argc, char **argv)
{
module_call_init(MODULE_INIT_QOM);
g_test_init(&argc, &argv, NULL);
g_assert(qcrypto_init(NULL) == 0);
g_test_add_func("/crypto/secret/direct",
test_secret_direct);
g_test_add_func("/crypto/secret/indirect/good",
test_secret_indirect_good);
g_test_add_func("/crypto/secret/indirect/badfile",
test_secret_indirect_badfile);
g_test_add_func("/crypto/secret/indirect/emptyfile",
test_secret_indirect_emptyfile);
g_test_add_func("/crypto/secret/noconv/base64/good",
test_secret_noconv_base64_good);
g_test_add_func("/crypto/secret/noconv/base64/bad",
test_secret_noconv_base64_bad);
g_test_add_func("/crypto/secret/noconv/utf8",
test_secret_noconv_utf8);
g_test_add_func("/crypto/secret/conv/base64/utf8valid",
test_secret_conv_base64_utf8valid);
g_test_add_func("/crypto/secret/conv/base64/utf8invalid",
test_secret_conv_base64_utf8invalid);
g_test_add_func("/crypto/secret/conv/utf8/base64",
test_secret_conv_utf8_base64);
g_test_add_func("/crypto/secret/crypt/raw",
test_secret_crypt_raw);
g_test_add_func("/crypto/secret/crypt/base64",
test_secret_crypt_base64);
g_test_add_func("/crypto/secret/crypt/shortkey",
test_secret_crypt_short_key);
g_test_add_func("/crypto/secret/crypt/shortiv",
test_secret_crypt_short_iv);
g_test_add_func("/crypto/secret/crypt/missingiv",
test_secret_crypt_missing_iv);
g_test_add_func("/crypto/secret/crypt/badiv",
test_secret_crypt_bad_iv);
return g_test_run();
}
Reference in New Issue Copy Permalink