Import OVF fails with Digest mismatch (VERR_NOT_EQUAL): Attribute 'SHA1'

[MarcT]

It seems the SHA1 digest check is case sensitive when it should not be. Importing an OVF created by VMware ovftool 3.5.0.

Actual error:

Digest mismatch (VERR_NOT_EQUAL): Attribute 'SHA1' on 'XXXXXXX.ovf' does not match ('3E6C3CD5F4813E5058F2CB9AC50F9636B9D92D2F' vs. '3e6c3cd5f4813e5058f2cb9ac50f9636b9d92d2f').

Result Code: VBOX_E_FILE_ERROR (0x80BB0004) Component: ApplianceWrap Interface: IAppliance {8398f026-4add-4474-5bc3-2f9f2140b23e}

[socratis]

Related discussion in the forums:  https://forums.virtualbox.org/viewtopic.php?f=1&t=79593

[MarcT]

So, I did some digging and came up with a rough patch which might solve this issue. The problem is that I can't easily test it here, as I don't have Qt5 libs (my system is using Qt4.8.7). I normally just use the pre-built VirtualBox binaries.

The patch changes all attribute matches to be case insensitive. That may not be ideal (I don't know), so some refinement may be required to check whether it's a SHA1 attribute (or other hash).

Interestingly the same issue seems to occur in VMWare ESXi 6.5 (but not 6.0).

Anyway, here's the "potential patch":

--- ./src/VBox/Runtime/common/checksum/manifest2.cpp.orig       2018-01-15 14:56:05.000000000 +0000
+++ ./src/VBox/Runtime/common/checksum/manifest2.cpp    2018-02-08 19:15:50.258686659 +0000
@@ -469,7 +469,7 @@
     /*
      * Compare them.
      */
-    if (strcmp(pAttr1->pszValue, pAttr2->pszValue))
+    if (strcasecmp(pAttr1->pszValue, pAttr2->pszValue))
     {
         if (*pEquals->pszCurEntry)
             RTStrPrintf(pEquals->pszError, pEquals->cbError,

[socratis]

MarcT, I have replied to you in the forums, not sure if you've subscribed to the topic or not...

[Dani_3xton]

Hello,

Is there any updates on this? I have an OVF file that I cannot import because of this error.

Digest mismatch (VERR_NOT_EQUAL): Attribute 'SHA1' on 'eFramework-2.8.8.ovf' does not match ('F33C5B7E74C552360722CF9B22943D30F4E122D1' vs. 'f33c5b7e74c552360722cf9b22943d30f4e122d1').

Thank you,

Dani

[socratis]

I'm not directly impacted by this, but I can apply the patch and test it. So, I downloaded the "eFramework-2.8.8.ova" (thanks @"xDani_3xton") and I got the same results. I wrapped the string on purpose to make it more than obvious what the problem is:

Digest mismatch (VERR_NOT_EQUAL): Attribute 'SHA1'
on 'eFramework-2.8.8.ovf' does not match ('
F33C5B7E74C552360722CF9B22943D30F4E122D1' vs. '
f33c5b7e74c552360722cf9b22943d30f4e122d1').

I tried it with test build 5.2.11 rev. 122553 and with the latest build from the trunk (rev. 72142), built locally. Same results. I then applied the patch by 'MarcT' from comment:2 and rebuilt VirtualBox.

The OVA imported just fine.

I do not know if the OVF specification mentions "CAPITAL" or "lower" case, or "If It DoEsN't MaTtEr", but I highly doubt that a checksum should be case-dependent. So, I really hope that this patch from 'MarcT' will soon find its way in the trunk and eventually the next release.

With all the Spectre/Meltdown issues, the security patches, the new releases from the major distributions, it has been a crazy time (if you're a developer), so some seemingly easy things to fix, may have fallen through the cracks.

I'm making a collection of these small patches, "The patches that won't kill you"... ;)

[andyp1973]

In a strict sense, the output from SHA-1 is a 160-bit hash value which for convenience and readability is represented as a 40 digit hexadecimal number.

Hexadecimal is not case sensitive and so 0xf == 0xF and the proposed patch is correct.

-Andy.

[socratis]

After a friendly ping to the devs (thanks!), I've been told that the "strcasecmp" function is not part of the C standard, only the POSIX/BSD standard (see " "strcasecmp() : A Non-Standard Function?"). That's why my testing of the patch worked; I'm on OSX, the function is available. But it will fail on a Windows compiler. :o

Test Builds >= 5.2.15 r123596 should contain the fix. I tested the  OVA (mentioned in the  forums thread by Dan), and it worked. If you can test the fix, that'd be great!

[jkim]

FYI, the standard is here:

 https://www.dmtf.org/sites/default/files/standards/documents/DSP0243_2.1.1.pdf

Please see line 418 and 419 on page 13. Although ABNF string is case-insensitive, it seems "hex-digit" can never be upper-case per Annex A (line 1362 and 1363 on page 42).

"Any characters must be processed case sensitively, instead of case-insensitively as defined in ABNF."