ima-evm-utils: Add --keyid option

Allow user to set signature's keyid using `--keyid' option. Keyid should correspond to SKID in certificate, when keyid is calculated using SHA-1 in libimaevm it may mismatch keyid extracted by the kernel from SKID of certificate (the way public key is presented to the kernel), thus making signatures not verifiable. This may happen when certificate is using non SHA-1 SKID (see rfc7093) or just 'unique number' (see rfc5280 4.2.1.2). As a last resort user may specify arbitrary keyid using the new option.

This commit creates ABI change for libimaevm, because of adding additional parameter to imaevm_params - newer libimaevm cannot work with older clients.

Signed-off-by Vitaly Chikunov <[email protected]>

Reported-by Elvira Khabirova <[email protected]>

Reviewed-by Stefan Berger <[email protected]>

---
 README                 |  1 +
 src/evmctl.c           | 15 +++++++++++++++
 src/imaevm.h           |  1 +
 src/libimaevm.c        |  8 +++++---
 tests/sign_verify.test |  1 +
 5 files changed, 23 insertions(+), 3 deletions(-)

README +1 -0

index 321045d..8cd66e0 100644
@@ -48,6 +48,7 @@ OPTIONS
       --xattr-user   store xattrs in user namespace (for testing purposes)
       --rsa          use RSA key type and signing scheme v1
   -k, --key          path to signing key (default: /etc/keys/{privkey,pubkey}_evm.pem)
+      --keyid val    overwrite signature keyid with a value (for signing)
   -o, --portable     generate portable EVM signatures
   -p, --pass         password for encrypted signing key
   -r, --recursive    recurse into directories (sign)

src/evmctl.c +4 -0

index 7a6f202..d853d34 100644
@@ -2514,6 +2514,7 @@ static void usage(void)
 		"      --xattr-user   store xattrs in user namespace (for testing purposes)\n"
 		"      --rsa          use RSA key type and signing scheme v1\n"
 		"  -k, --key          path to signing key (default: /etc/keys/{privkey,pubkey}_evm.pem)\n"
+		"      --keyid val    overwrite signature keyid with a value (for signing)\n"
 		"  -o, --portable     generate portable EVM signatures\n"
 		"  -p, --pass         password for encrypted signing key\n"
 		"  -r, --recursive    recurse into directories (sign)\n"

@@ -2594,6 +2595,7 @@ static struct option opts[] = {
 	{"ignore-violations", 0, 0, 141},
 	{"pcrs", 1, 0, 142},
 	{"verify-bank", 2, 0, 143},
+	{"keyid", 1, 0, 144},
 	{}
 
 };

@@ -2638,6 +2640,8 @@ int main(int argc, char *argv[])
 {
 	int err = 0, c, lind;
 	ENGINE *eng = NULL;
+	unsigned long keyid;
+	char *eptr;
 
 #if !(OPENSSL_VERSION_NUMBER < 0x10100000)
 	OPENSSL_init_crypto(

src/evmctl.c +6 -0

+			    keyid == 0) {
+				log_err("Invalid keyid value.\n");
+				exit(1);
+			}
+			imaevm_params.keyid = keyid;
+			break;
 		case '?':
 			exit(1);
 			break;

src/imaevm.h +0 -0

index 4503919..9f38059 100644

src/imaevm.h +0 -0

 };
 
 struct RSA_ASN1_template {

src/libimaevm.c +1 -1

index fa6c278..481d29d 100644
@@ -45,6 +45,7 @@
 #include <sys/param.h>
 #include <sys/stat.h>
 #include <asm/byteorder.h>
+#include <arpa/inet.h>
 #include <unistd.h>
 #include <dirent.h>
 #include <string.h>

@@ -894,7 +895,6 @@ static int sign_hash_v2(const char *algo, const unsigned char *hash,
 	const EVP_MD *md;
 	size_t sigsize;
 	const char *st;
-	uint32_t keyid;
 
 	if (!hash) {
 		log_err("sign_hash_v2: hash is null\n");

src/libimaevm.c +0 -0

 	st = "EVP_PKEY_CTX_new";
 	if (!(ctx = EVP_PKEY_CTX_new(pkey, NULL)))

tests/sign_verify.test +1 -0

index 3d7aa51..eccf5fa 100755
@@ -365,6 +365,7 @@ sign_verify  rsa1024  sha256  0x0301 --rsa
 sign_verify  rsa1024  md5     0x030201:K:0080
 sign_verify  rsa1024  sha1    0x030202:K:0080
 sign_verify  rsa1024  sha224  0x030207:K:0080
+expect_pass check_sign TYPE=ima KEY=rsa1024 ALG=sha256 PREFIX=0x030204aabbccdd0080 OPTS=--keyid=aabbccdd
 sign_verify  rsa1024  sha256  0x030204:K:0080
   try_different_keys
   try_different_sigs

Quoted 11 lines · Vitaly Chikunov

Allow user to set signature's keyid using `--keyid' option. Keyid should correspond to SKID in certificate, when keyid is calculated using SHA-1 in libimaevm it may mismatch keyid extracted by the kernel from SKID of certificate (the way public key is presented to the kernel), thus making signatures not verifiable. This may happen when certificate is using non SHA-1 SKID (see rfc7093) or just 'unique number' (see rfc5280 4.2.1.2). As a last resort user may specify arbitrary keyid using the new option.

This commit creates ABI change for libimaevm, because of adding additional parameter to imaevm_params - newer libimaevm cannot work with older clients.

Thank you for highlighting the ABI change.

Quoted 51 lines

Signed-off-by Vitaly Chikunov <[email protected]>

Reported-by Elvira Khabirova <[email protected]>

Reviewed-by Stefan Berger <[email protected]>

---
 README                 |  1 +
 src/evmctl.c           | 15 +++++++++++++++
 src/imaevm.h           |  1 +
 src/libimaevm.c        |  8 +++++---
 tests/sign_verify.test |  1 +
 5 files changed, 23 insertions(+), 3 deletions(-)

README +1 -0

index 321045d..8cd66e0 100644
@@ -48,6 +48,7 @@ OPTIONS
       --xattr-user   store xattrs in user namespace (for testing purposes)
       --rsa          use RSA key type and signing scheme v1
   -k, --key          path to signing key (default: /etc/keys/{privkey,pubkey}_evm.pem)
+      --keyid val    overwrite signature keyid with a value (for signing)
   -o, --portable     generate portable EVM signatures
   -p, --pass         password for encrypted signing key
   -r, --recursive    recurse into directories (sign)

src/evmctl.c +4 -0

index 7a6f202..d853d34 100644
@@ -2514,6 +2514,7 @@ static void usage(void)
 		"      --xattr-user   store xattrs in user namespace (for testing purposes)\n"
 		"      --rsa          use RSA key type and signing scheme v1\n"
 		"  -k, --key          path to signing key (default: /etc/keys/{privkey,pubkey}_evm.pem)\n"
+		"      --keyid val    overwrite signature keyid with a value (for signing)\n"
 		"  -o, --portable     generate portable EVM signatures\n"
 		"  -p, --pass         password for encrypted signing key\n"
 		"  -r, --recursive    recurse into directories (sign)\n"

@@ -2594,6 +2595,7 @@ static struct option opts[] = {
 	{"ignore-violations", 0, 0, 141},
 	{"pcrs", 1, 0, 142},
 	{"verify-bank", 2, 0, 143},
+	{"keyid", 1, 0, 144},
 	{}
 
 };

@@ -2638,6 +2640,8 @@ int main(int argc, char *argv[])
 {
 	int err = 0, c, lind;
 	ENGINE *eng = NULL;
+	unsigned long keyid;
+	char *eptr;
 

src/evmctl.c int main(int argc, char *argv[]) · line 2795

Quoted 10 lines

src/evmctl.c +4 -0

 #if !(OPENSSL_VERSION_NUMBER < 0x10100000)
 	OPENSSL_init_crypto(

@@ -2785,6 +2789,17 @@ int main(int argc, char *argv[])
 		case 143:
 			verify_bank = optarg;
 			break;
+		case 144:
+			errno = 0;
+			keyid = strtoul(optarg, &eptr, 16);
+			if (errno || eptr - optarg != strlen(optarg) ||

Before using eptr, shouldn't there be a null test?

It's unclear what
verifying the resulting string length against the user provided length provides.

Requiring the optarg value to be prefixed with "0x" would simplify the strlen test. The length would be 2 * sizeof uint + 2. (The subsequent patch wouldn't need a contrived prefix.)

src/evmctl.c int main(int argc, char *argv[]) · line 2796

Quoted 2 lines

src/evmctl.c +1 -0

+			    keyid == ULONG_MAX || keyid > UINT_MAX ||

Why are both of these tests required? When ULONG_MAX and UINT_MAX aren't the same, wouldn't ULONG_MAX always be bigger than UINT_MAX?

Quoted 14 lines

src/evmctl.c +6 -0

+			    keyid == 0) {
+				log_err("Invalid keyid value.\n");
+				exit(1);
+			}
+			imaevm_params.keyid = keyid;
+			break;
 		case '?':
 			exit(1);
 			break;

src/imaevm.h +0 -0

index 4503919..9f38059 100644

src/imaevm.h struct libimaevm_params { · line 199

Quoted 5 lines

src/imaevm.h +1 -0

@@ -196,6 +196,7 @@ struct libimaevm_params {
 	const char *hash_algo;
 	const char *keyfile;
 	const char *keypass;
+	uint32_t keyid;		/* keyid overriding value, unless 0. */

If keyid is suppose to be big endiran format, please annotate it in the comment.

Quoted 28 lines

src/imaevm.h +0 -0

 };
 
 struct RSA_ASN1_template {

src/libimaevm.c +1 -1

index fa6c278..481d29d 100644
@@ -45,6 +45,7 @@
 #include <sys/param.h>
 #include <sys/stat.h>
 #include <asm/byteorder.h>
+#include <arpa/inet.h>
 #include <unistd.h>
 #include <dirent.h>
 #include <string.h>

@@ -894,7 +895,6 @@ static int sign_hash_v2(const char *algo, const unsigned char *hash,
 	const EVP_MD *md;
 	size_t sigsize;
 	const char *st;
-	uint32_t keyid;
 
 	if (!hash) {
 		log_err("sign_hash_v2: hash is null\n");

@@ -932,8 +932,10 @@ static int sign_hash_v2(const char *algo, const unsigned char *hash,
 		return -1;
 	}
 

src/libimaevm.c static int sign_hash_v2(const char *algo, const unsigned char *hash, · line 939

Quoted 7 lines

src/libimaevm.c +4 -2

-	calc_keyid_v2(&keyid, name, pkey);
-	hdr->keyid = keyid;
+	if (imaevm_params.keyid)
+		hdr->keyid = htonl(imaevm_params.keyid);
+	else
+		calc_keyid_v2(&hdr->keyid, name, pkey);
 

At what point should imaevm_params.keyid be converted to big endian - on usage or setting it?

Mimi

Quoted 14 lines

src/libimaevm.c +0 -0

 	st = "EVP_PKEY_CTX_new";
 	if (!(ctx = EVP_PKEY_CTX_new(pkey, NULL)))

tests/sign_verify.test +1 -0

index 3d7aa51..eccf5fa 100755
@@ -365,6 +365,7 @@ sign_verify  rsa1024  sha256  0x0301 --rsa
 sign_verify  rsa1024  md5     0x030201:K:0080
 sign_verify  rsa1024  sha1    0x030202:K:0080
 sign_verify  rsa1024  sha224  0x030207:K:0080
+expect_pass check_sign TYPE=ima KEY=rsa1024 ALG=sha256 PREFIX=0x030204aabbccdd0080 OPTS=--keyid=aabbccdd
 sign_verify  rsa1024  sha256  0x030204:K:0080
   try_different_keys
   try_different_sigs

Quoted 3 lines

Requiring the optarg value to be prefixed with "0x" would simplify the strlen test.
(The subsequent patch wouldn't need a contrived prefix.)

(I do not understand this remark at the moment.)

Base 16 will let user pass keyid just as a string, copy-pasting from somewhere else.

Thank you for the detailed explanation.

Quoted 6 lines · Vitaly Chikunov

Quoted 3 lines

Requiring the optarg value to be prefixed with "0x" would simplify the strlen test.
(The subsequent patch wouldn't need a contrived prefix.)

(I do not understand this remark at the moment.)

Quoted 2 lines

Base 16 will let user pass keyid just as a string, copy-pasting from somewhere else.

strtoul() supports prefixing the ascii-hex string with "0x". To differentiate between a keyid and pathname, why not require the keyid be prefixed with "0x", as opposed to requiring the pathname to be prefixed with '@', like "--keyid @/path/to/cert.pem".

The new test would be "OPTS=--keyid=0xaabbccdd"

thanks,

Mimi

Mimi,

Quoted 11 lines · Mimi Zohar

Thank you for the detailed explanation.

Quoted 6 lines · Vitaly Chikunov

Quoted 3 lines

Requiring the optarg value to be prefixed with "0x" would simplify the strlen test.
(The subsequent patch wouldn't need a contrived prefix.)

(I do not understand this remark at the moment.)

Quoted 7 lines

Quoted 2 lines

Base 16 will let user pass keyid just as a string, copy-pasting from somewhere else.

strtoul() supports prefixing the ascii-hex string with "0x". To differentiate between a keyid and pathname, why not require the keyid be prefixed with "0x", as opposed to requiring the pathname to be prefixed with '@', like "--keyid @/path/to/cert.pem".

I wanted to avoid (filename vs keyid) ambiguity of the argument to --keyid' - if user have file named "0x00112233" they would have hard time passing it to --keyid'. But, it's impossible to have keyid string starting with "@". So, "@" perfectly distinguish type of `--keyid' argument but "0x" isn't.

Also, in some software (zip, rar) "@" is common prefix meaning value should be taken from the specified file. But, yes, "@" is not common in Unix environments. Do you want me to create separate option like `--keyid-from-file'?

Quoted 26 lines · Vitaly Chikunov

Quoted 11 lines · Mimi Zohar

Thank you for the detailed explanation.

Quoted 6 lines · Vitaly Chikunov

Quoted 3 lines

Requiring the optarg value to be prefixed with "0x" would simplify the strlen test.
(The subsequent patch wouldn't need a contrived prefix.)

(I do not understand this remark at the moment.)

Quoted 7 lines

Quoted 2 lines

Base 16 will let user pass keyid just as a string, copy-pasting from somewhere else.

strtoul() supports prefixing the ascii-hex string with "0x". To differentiate between a keyid and pathname, why not require the keyid be prefixed with "0x", as opposed to requiring the pathname to be prefixed with '@', like "--keyid @/path/to/cert.pem".

I wanted to avoid (filename vs keyid) ambiguity of the argument to --keyid' - if user have file named "0x00112233" they would have hard time passing it to --keyid'. But, it's impossible to have keyid string starting with "@". So, "@" perfectly distinguish type of `--keyid' argument but "0x" isn't.

Quoted 4 lines

Also, in some software (zip, rar) "@" is common prefix meaning value should be taken from the specified file. But, yes, "@" is not common in Unix environments. Do you want me to create separate option like `--keyid-from-file'?

It's highly unlikely that both the filename and pathname would be prefixed with "0x". Defining a new option might be a good idea. Possibly naming it --extract-cert-keyid, ---cert-keyid, or --keyid- from-cert.

thanks,

Mimi

Quoted 32 lines · Mimi Zohar

Quoted 26 lines · Vitaly Chikunov

Quoted 11 lines · Mimi Zohar

Thank you for the detailed explanation.

Quoted 6 lines · Vitaly Chikunov

Quoted 3 lines

Requiring the optarg value to be prefixed with "0x" would simplify the strlen test.
(The subsequent patch wouldn't need a contrived prefix.)

(I do not understand this remark at the moment.)

Quoted 7 lines

Quoted 2 lines

Base 16 will let user pass keyid just as a string, copy-pasting from somewhere else.

strtoul() supports prefixing the ascii-hex string with "0x". To differentiate between a keyid and pathname, why not require the keyid be prefixed with "0x", as opposed to requiring the pathname to be prefixed with '@', like "--keyid @/path/to/cert.pem".

I wanted to avoid (filename vs keyid) ambiguity of the argument to --keyid' - if user have file named "0x00112233" they would have hard time passing it to --keyid'. But, it's impossible to have keyid string starting with "@". So, "@" perfectly distinguish type of `--keyid' argument but "0x" isn't.

Quoted 4 lines

Also, in some software (zip, rar) "@" is common prefix meaning value should be taken from the specified file. But, yes, "@" is not common in Unix environments. Do you want me to create separate option like `--keyid-from-file'?

Quoted 4 lines

It's highly unlikely that both the filename and pathname would be prefixed with "0x". Defining a new option might be a good idea. Possibly naming it --extract-cert-keyid, ---cert-keyid, or --keyid- from-cert.

It's not unlikely, because people may want to keep cert files named or symlinked by keyid. (For example, local cert database keep cert files symlinked like `f30dd6ad.0'.)

I will add an option, most understandable, perhaps, is `--keyid-from-cert'.

Also, I will remove base 16 from --keyid argument.

Quoted 42 lines · Vitaly Chikunov

Quoted 32 lines · Mimi Zohar

Quoted 26 lines · Vitaly Chikunov

Quoted 11 lines · Mimi Zohar

Thank you for the detailed explanation.

Quoted 6 lines · Vitaly Chikunov

Quoted 3 lines

Requiring the optarg value to be prefixed with "0x" would simplify the strlen test.
(The subsequent patch wouldn't need a contrived prefix.)

(I do not understand this remark at the moment.)

Quoted 7 lines

Quoted 2 lines

Base 16 will let user pass keyid just as a string, copy-pasting from somewhere else.

strtoul() supports prefixing the ascii-hex string with "0x". To differentiate between a keyid and pathname, why not require the keyid be prefixed with "0x", as opposed to requiring the pathname to be prefixed with '@', like "--keyid @/path/to/cert.pem".

I wanted to avoid (filename vs keyid) ambiguity of the argument to --keyid' - if user have file named "0x00112233" they would have hard time passing it to --keyid'. But, it's impossible to have keyid string starting with "@". So, "@" perfectly distinguish type of `--keyid' argument but "0x" isn't.

Quoted 4 lines

Also, in some software (zip, rar) "@" is common prefix meaning value should be taken from the specified file. But, yes, "@" is not common in Unix environments. Do you want me to create separate option like `--keyid-from-file'?

Quoted 4 lines

It's highly unlikely that both the filename and pathname would be prefixed with "0x". Defining a new option might be a good idea. Possibly naming it --extract-cert-keyid, ---cert-keyid, or --keyid- from-cert.

It's not unlikely, because people may want to keep cert files named or symlinked by keyid. (For example, local cert database keep cert files symlinked like `f30dd6ad.0'.)

Quoted 3 lines

I will add an option, most understandable, perhaps, is `--keyid-from-cert'.

Also, I will remove base 16 from --keyid argument.

I must be missing something. "openssl x509", "keyctl show %keyring:<keyring name>", and "getfattr -m security.ima -e hex --dump" all display the skid in hex. Why would anyone provide the skid as something other than in hex?

thanks,

Mimi

Mimi,

Quoted 47 lines · Mimi Zohar

Quoted 45 lines · Vitaly Chikunov

Quoted 32 lines · Mimi Zohar

Quoted 26 lines · Vitaly Chikunov

Quoted 11 lines · Mimi Zohar

Thank you for the detailed explanation.

Quoted 6 lines · Vitaly Chikunov

Quoted 3 lines

Requiring the optarg value to be prefixed with "0x" would simplify the strlen test.
(The subsequent patch wouldn't need a contrived prefix.)

(I do not understand this remark at the moment.)

Quoted 7 lines

Quoted 2 lines

Base 16 will let user pass keyid just as a string, copy-pasting from somewhere else.

strtoul() supports prefixing the ascii-hex string with "0x". To differentiate between a keyid and pathname, why not require the keyid be prefixed with "0x", as opposed to requiring the pathname to be prefixed with '@', like "--keyid @/path/to/cert.pem".

I wanted to avoid (filename vs keyid) ambiguity of the argument to --keyid' - if user have file named "0x00112233" they would have hard time passing it to --keyid'. But, it's impossible to have keyid string starting with "@". So, "@" perfectly distinguish type of `--keyid' argument but "0x" isn't.

Quoted 4 lines

Also, in some software (zip, rar) "@" is common prefix meaning value should be taken from the specified file. But, yes, "@" is not common in Unix environments. Do you want me to create separate option like `--keyid-from-file'?

Quoted 4 lines

It's highly unlikely that both the filename and pathname would be prefixed with "0x". Defining a new option might be a good idea. Possibly naming it --extract-cert-keyid, ---cert-keyid, or --keyid- from-cert.

It's not unlikely, because people may want to keep cert files named or symlinked by keyid. (For example, local cert database keep cert files symlinked like `f30dd6ad.0'.)

I will add an option, most understandable, perhaps, is `--keyid-from-cert'.

Also, I will remove base 16 from --keyid argument.

Quoted 4 lines

I must be missing something. "openssl x509", "keyctl show %keyring:<keyring name>", and "getfattr -m security.ima -e hex --dump" all display the skid in hex. Why would anyone provide the skid as something other than in hex?

Ah, I thought you want '0x' prefix mandatory. Will not remove base 16 then. Also, /proc/keys shows keyid without '0x' prefix.

src/libimaevm.c +6 -0

+/**
+ * imaevm_read_keyid() - Read 32-bit keyid from the cert file.
+ * @certfile:	File possibly containing certificate in DER/PEM format.
+ *
+ * Try to read keyid from Subject Key Identifier (SKID) of certificate.
+ * Autodetect if cert is in PEM or DER encoding.

Quoted 12 lines · Vitaly Chikunov

src/libimaevm.c +11 -0

+/**
+ * imaevm_read_keyid() - Read 32-bit keyid from the cert file.
+ * @certfile:	File possibly containing certificate in DER/PEM format.
+ *
+ * Try to read keyid from Subject Key Identifier (SKID) of certificate.
+ * Autodetect if cert is in PEM or DER encoding.
+ *
+ * Return: 0 on error;
+ *         32-bit keyid as unsigned integer in host order.
+ */
+uint32_t imaevm_read_keyid(const char *certfile)

src/libimaevm.c void calc_keyid_v2(uint32_t *keyid, char *str, EVP_PKEY *pkey) · line 837

Quoted 5 lines

src/libimaevm.c +5 -0

+{
+	uint32_t keyid_raw = 0;
+
+	__read_keyid(&keyid_raw, certfile, KEYID_FILE_UNK_CERT);
+	return ntohl(keyid_raw);

On error, __read_keyid() returns < 0, but the return value isn't checked before calling ntohl.

In either case, is imaevm_params.keyid
suppose to be big endian byte order?

If so, the call to htonl in
sign_hash_v2() would be unnecessary.

thanks,

Mimi

Quoted 2 lines

In either case, is imaevm_params.keyid
suppose to be big endian byte order?

No, it's in native order. This looked reasonable, since it could be presented to the user as a hex number.

Allow to have certificate appended to the private key of `--key' specified (PEM) file (for v2 signing) to facilitate reading of keyid from the associated cert. This will allow users to have private and public key as a single file. There is no check that public key form the cert matches associated private key.

Quoted 5 lines · Vitaly Chikunov

Allow to have certificate appended to the private key of `--key' specified (PEM) file (for v2 signing) to facilitate reading of keyid from the associated cert. This will allow users to have private and public key as a single file. There is no check that public key form the cert matches associated private key.

Is this a standard formats for storing the public and private key in the same file?

Mimi

src/libimaevm.c +0 -0

index 1c03768..bfce7ef 100644
@@ -1021,10 +1021,12 @@ static int sign_hash_v2(const char *algo, const unsigned char *hash,
 		return -1;
 	}

src/libimaevm.c +0 -0

 	st = "EVP_PKEY_CTX_new";
 	if (!(ctx = EVP_PKEY_CTX_new(pkey, NULL)))

Quoted 8 lines · Vitaly Chikunov

src/libimaevm.c +0 -0

index 1c03768..bfce7ef 100644
@@ -1021,10 +1021,12 @@ static int sign_hash_v2(const char *algo, const unsigned char *hash,
 		return -1;
 	}

src/libimaevm.c static int sign_hash_v2(const char *algo, const unsigned char *hash, · line 1029

Quoted 10 lines

src/libimaevm.c +5 -3

 
-	if (imaevm_params.keyid)
+	if (imaevm_params.keyid) {
 		hdr->keyid = htonl(imaevm_params.keyid);
-	else
-		calc_keyid_v2(&hdr->keyid, name, pkey);
+	} else {
+		if (__read_keyid(&hdr->keyid, keyfile, KEYID_FILE_PEM_KEY))
+			calc_keyid_v2(&hdr->keyid, name, pkey);
+	}

If the call to __read_keyid() was independent of the test and call to calc_keyid_v2(), it would make reading code the easier to understand.

result = __read_keyid(...);
if (result < 0)

    calc_keyid_v2(...);

thanks,

Mimi

Quoted 3 lines

src/libimaevm.c +0 -0

 	st = "EVP_PKEY_CTX_new";
 	if (!(ctx = EVP_PKEY_CTX_new(pkey, NULL)))

Quoted 23 lines · Mimi Zohar

Quoted 8 lines · Vitaly Chikunov

src/libimaevm.c +0 -0

index 1c03768..bfce7ef 100644
@@ -1021,10 +1021,12 @@ static int sign_hash_v2(const char *algo, const unsigned char *hash,
 		return -1;
 	}

src/libimaevm.c static int sign_hash_v2(const char *algo, const unsigned char *hash, · line 1029

Quoted 10 lines

src/libimaevm.c +5 -3

 
-	if (imaevm_params.keyid)
+	if (imaevm_params.keyid) {
 		hdr->keyid = htonl(imaevm_params.keyid);
-	else
-		calc_keyid_v2(&hdr->keyid, name, pkey);
+	} else {
+		if (__read_keyid(&hdr->keyid, keyfile, KEYID_FILE_PEM_KEY))
+			calc_keyid_v2(&hdr->keyid, name, pkey);
+	}

If the call to __read_keyid() was independent of the test and call to calc_keyid_v2(), it would make reading code the easier to understand.

Quoted 3 lines

result = __read_keyid(...);
if (result < 0)

    calc_keyid_v2(...);

No problem to add additional variable and check __read_keyid indirectly. But, how is this independent? Call to calc_keyid_v2 is dependent to __read_keyid result.

Thanks,

Quoted 9 lines

thanks,

Mimi

Quoted 3 lines

src/libimaevm.c +0 -0

 	st = "EVP_PKEY_CTX_new";
 	if (!(ctx = EVP_PKEY_CTX_new(pkey, NULL)))