Shim 15.7 for Hedgehog ONIE and SONiC

[mheese]

Confirm the following are included in your repo, checking each box:

• completed README.md file with the necessary information
• shim.efi to be signed
• public portion of your certificate(s) embedded in shim (the file passed to VENDOR_CERT_FILE)
• binaries, for which hashes are added to vendor_db ( if you use vendor_db and have hashes allow-listed )
• any extra patches to shim via your own git tree or as files
• any extra patches to grub via your own git tree or as files
• build logs
• a Dockerfile to reproduce the build of the provided shim EFI binaries

---

What is the link to your tag in a repo cloned from rhboot/shim-review?

---

https://github.com/githedgehog/shim-review/tree/hedgehog-shim-15.7-amd64-arm64-20230925

---

What is the SHA256 hash of your final SHIM binary?

---

f43357e978b690aaef58b53de9e898105230d45cc825a4fb8ef996e577e8c541  artifacts/shimx64.efi
c9cb5349cb38fb3e6305a8beab75b2bab498057f1b8a1f0589f473f7859d760c  artifacts/shimaa64.efi

---

What is the link to your previous shim review request (if any, otherwise N/A)?

---

N/A

[aronowski]

I'm positively impressed with several things here. Like performing additional static analysis of the binaries with pedump when building a Docker image.

Still, I can see a few curiosities regarding your SBAT entries.

With the line shim.hedgehog,3,Hedgehog SONiC Foundation,shim,15.7,https://github.com/githedgehog/shim-review you set your product specific generation number to 3 but since it's the first time you're releasing your shim, it should be 1 instead.

With GRUB2 I'm unsure. With grub.hedgehog,2,Hedgehog SONiC Foundation,grub,2.06,https://github.com/githedgehog/grub-build you have number 2 and while it should be 1 instead, I would understand that it was 1 back in the day but you addressed a security issue and increased it to 2 (in the meantime when preparing this shim-review).

[mheese]

@aronowski essentially, I kept the number to the same of the next upstream version which we are relying on (so 3 for shim, and 2 for fedora grub) - mainly because it made it easier for me to reason about it.

Do you guys want me to start with 1 for both of our shim.hedgehog and grub.hedgehog SBATs? I thought as it is just a counter that it does not really matter, but happy to change that if this matters.

[aronowski]

SBAT was formalized in a way so the numbers do matter. It should be changed unless there was some specific reason for an exception.

Maybe there is one that I just don't know about. I'll let the official committee decide.

[mheese]

@aronowski no worries, thanks for the input. I'll change the numbers and update the tag 👍

[mheese]

@aronowski I updated the builds for the SBAT to start at 1, and created a new tag at: https://github.com/githedgehog/shim-review/tree/hedgehog-shim-15.7-amd64-arm64-20230513

I also updated the issue text above to correctly reflect the new tag, as well as the SHA256 hashes.

Is there anything else I need to do right now? Or do I just need to wait for somebody to review this?

[mheese]

as my builds did not reproduce any longer I had to update them. I guess the compiler or something in Ubuntu 22.04 changed which is why the resulting hashes did not match any longer. I updated the main comment with the new tag, but I'm also putting it here again: https://github.com/githedgehog/shim-review/tree/hedgehog-shim-15.7-amd64-arm64-20230925

@aronowski if you would be so kind and verify it again? 🙏 ... nothing really has changed from what you have already reviewed before.

@THS-on thanks so much for pointing this out to me on slack! It's ready for review now if you would like to give it a go as well! 🙏 I apologize that this took a bit longer, I was a bit swamped lately.

[aronowski]

@aronowski if you would be so kind and verify it again? 🙏 ... nothing really has changed from what you have already reviewed before.

You know it! ;)

I managed to reproduce the shim binaries with Docker from the official Fedora 38 repository and installing the docker-buildx plugin v0.11.2 manually. The builds succeed and the checksums match.

---

The usage of additional patches to the kernel as well as its Secure Boot inclusions and exclusions have been explained and are publicly located in the patch folder in the repository https://github.com/sonic-net/sonic-linux-kernel.

The usage of a non-ephemeral key has been thoroughly explained. The aforementioned kernel modules signing enforcement is located in the kconfig-secure-boot-inclusions file in that directory.

---

The kernels used in SONiC and ONIE have been described precisely in regard to the versions used. Furthermore, in regard to the Microsoft requirements, a strictly enforced NX implementation in the kernel might be soon out there. Therefore, the assets have been well prepared for that, I believe.
Now, I'm not the expert here, but was just scratching the surface and base my reasoning on this listing I created some time ago:

$ objdump -x vmlinuz-6.0.0-0.rc6.41.fc38.x86_64 | grep DllCharacteristics
DllCharacteristics      00000100

Maybe @vathpela can confirm the NX implementation in the 6.0 kernels here.

[THS-on]

Review for hedgehog-shim-15.7-amd64-arm64-20230925

• This is the first submission for the Hedgehog SONiC Foundation
• A shim is required to enable Secure Boot for SONiC capable switches out-of-the-box and those require custom kernel versions for hardware support
• Security contacts (not yet verified)
  • Marcus Heese [email protected] (65F20EF3617803DCC5E0C3180A9749F383D6B2A9)
  • Mike Dvorkin [email protected] (C2661FA61B891C30E837281976C23BC6495DA313)
• Shim is reproducible using Dockerfile

Hashes

f43357e978b690aaef58b53de9e898105230d45cc825a4fb8ef996e577e8c541  shimx64.efi
c9cb5349cb38fb3e6305a8beab75b2bab498057f1b8a1f0589f473f7859d760c  shimaa64.efi

SBAT

sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
shim,3,UEFI shim,shim,1,https://github.com/rhboot/shim
shim.hedgehog,1,Hedgehog SONiC Foundation,shim,15.7,https://github.com/githedgehog/shim-review

• SBAT component suffix .hedgehog works
• Shim is upstream 15.7 with NX enabled
  • 0001-NX-compatibility-default.patch matches rhboot/shim@7c76425
  • 0002-fix-sbat-var-parse-for-buggy-toolchain.patch matches rhboot/shim@657b248
    • 0003-fix-buffer-overflow-in-realloc-wrapper.patch matches rhboot/shim@89972ae
  • 0004-align-section-size.patch matches rhboot/shim@c7b3051
  • 0005-dont-loop-forever-in-load-certs-with-buggy-firmware.patch matches rhboot/shim@f23883c
• Certificate matches organization
  • Serial: 24:26:12:ae:04:f6:db:d9:2c:0c:10:19:d7:f0:2a:46:4e:c0:c8:77
  • Subject: C = US, ST = Delaware, O = Hedgehog SONiC Foundation, CN = Hedgehog Secure Boot CA
  • Valid till: Apr 30 19:51:39 2033 GMT (10 years)
  • Certificate is a CA certificate, KeyUsage/DigitalSignature and ExtKeyUsage/CodeSigning are not set
• Keys are stored in an HSM. There also exists and encrypted offline backup of those keys.
• Shim launches only GRUB2
  • Based on Fedora with two custom modules is_sb_enabled and version
    • Fedoras Secure Boot implementation is used
    • https://github.com/githedgehog/grub-build does not exist or is not public, so I couldn't see the implementation of those modules
  • List of modules for SONiC and ONIE look fine
• Kernels
  • Have lockdown patches applied
  • ONIE mainly based on vanilla 6.1
    • No kernel modules are build
    • Older kernel versions might be used for hardware compatibility
  • SONiC kernel is based on 5.10.179 from Debian 11
    • No ephemeral key is used, because there might be the need to build modules for that platform later. Instead keys are rotated when there was an issue

Notes and Questions

• https://github.com/githedgehog/shim-review is the URL for the shim build repo, which is unusual, but fine
• For crossbuilding the ARM version I used https://docs.docker.com/build/building/multi-platform/ and docker build . --progress plain --no-cache --platform=linux/arm64 --build-arg EFIARCH=aa64
• The CA certificate does not set KeyUsage/DigitalSignature and ExtKeyUsage/CodeSigning, do you want to include at least the first one?
• How where the keys generated? Inside or outside the HSM? Who has access to the backup and can decrypt it?
• https://github.com/githedgehog/grub-build does not exist or is not public
• Regarding module signing
  • If you have enough space on your HSM, you can just create a new certificate and key for each kernel version
  • Bumping the ABI name on every version should prohibit old kernel modules being loaded. This is probably the way to go, if ephemeral keys or using a new key every time are not an option.

I also sent out contact verification emails, please post decrypted message here.

[mheese]

@THS-on received your PGP encrypted email for the verification, I believe this is what you are looking for:

lifeguard wrestle highways hyperboloid volkswagen mills accessibility 
flowcharting influential boeing

[thedvorkin]

arithmetize subrange tourists custom carbons contrasts potentialities
cozier march specification

[THS-on]

Phrases are correct, therefore the contact verification was successful.

[mheese]

@THS-on please see answers to your questions below

Notes and Questions

* https://github.com/githedgehog/shim-review is the URL for the shim build repo, which is unusual, but fine

I saw no reason not to use the forked shim-review repo for the build. To be honest, it would be great if the main repo could be enhanced with similar Dockerfile, Makefile, GitHub CI workflow files, etc. as a standardized template for folks to use for their shim builds. That would also make reviewing the builds easier.

* For crossbuilding the ARM version I used https://docs.docker.com/build/building/multi-platform/ and `docker build . --progress plain --no-cache --platform=linux/arm64 --build-arg EFIARCH=aa64`

Yes, you can find the same instructions in the Makefile as the docker-arm64 target.

* The CA certificate does not set KeyUsage/DigitalSignature and ExtKeyUsage/CodeSigning, do you want to include at least the first one?

As far as I understand it, key usage and extended key usage are optional, right? If that is the case, then I would rather not include this.

* How where the keys generated? Inside or outside the HSM? Who has access to the backup and can decrypt it?

The keys were generated inside of the HSM. However, there are no export restrictions to the key. This is to facilitate two things: (1) so that we are able to transfer the key to the backup HSM, (2) so that we can keep an encrypted backup of the key. There are attestation certificates for the keys that prove that the keys were generated within the HSM in our public certificates repo here: https://github.com/githedgehog/certificates/tree/main/attestation

The keys that can decrypt the backup also reside on the HSMs. There is no way to unwrap them without the HSM, and also only for the purpose of importing them into the HSM. There is only one (offline) backup of the wrapping key which exists in printed form in our company's bank vault.

The people that have access to the backup and are able to decrypt them are the same as our listed security contacts, which are myself and @thedvorkin .

* https://github.com/githedgehog/grub-build does not exist or is not public

I will send you a read-only invite to the repository shortly. It is our intention that this repository is public, and as it builds/contains GPL software it actually must be public. However, as it uses GitHub runners which are hosted in our lab in the datacenter, we did not make it public yet because of the security and access implications. That said, it looks like there are now ways to better expose and control that, so we will look into that again. This is not the only repository which is affected by this unfortunately.

* Regarding module signing
  
  * If you have enough space on your HSM, you can just create a new certificate and key for each kernel version

Yes, this is definitely a feasible option for us. Even if we run out of space, we can always keep an encrypted backup of older keys. The only thing which we do not want to do is to throw away the key after a build/release for the already mentioned reasons.

  * Bumping the ABI name on every version should prohibit old kernel modules being loaded. This is probably the way to go, if ephemeral keys or using a new key every time are not an option.

Just to be clear, you are essentially saying that as long as we compile the SONiC kernel with CONFIG_MODVERSIONS=n, then we are also in the clear? This is most likely also a feasible option for us.

[THS-on]

The keys were generated inside of the HSM. However, there are no export restrictions to the key. This is to facilitate two things: (1) so that we are able to transfer the key to the backup HSM, (2) so that we can keep an encrypted backup of the key. There are attestation certificates for the keys that prove that the keys were generated within the HSM in our public certificates repo here: https://github.com/githedgehog/certificates/tree/main/attestation

The keys that can decrypt the backup also reside on the HSMs. There is no way to unwrap them without the HSM, and also only for the purpose of importing them into the HSM. There is only one (offline) backup of the wrapping key which exists in printed form in our company's bank vault.

The people that have access to the backup and are able to decrypt them are the same as our listed security contacts, which are myself and @thedvorkin.

Thank you for the explanation. According to the Microsoft signing requirements the operating environment must achieve a level of security at least equal to FIPS 140-2 Level 2 and the key must be protected by a hardware security module (https://techcommunity.microsoft.com/t5/hardware-dev-center/updated-uefi-signing-requirements/ba-p/1062916).
I think those requirements are met, but I would like to get a second pinion on that.

I will send you a read-only invite to the repository shortly. It is our intention that this repository is public, and as it builds/contains GPL software it actually must be public. However, as it uses GitHub runners which are hosted in our lab in the datacenter, we did not make it public yet because of the security and access implications. That said, it looks like there are now ways to better expose and control that, so we will look into that again. This is not the only repository which is affected by this unfortunately.

I've got the invite. If it takes longer to make it publicly available, can you upload an archive for example to the shim-review repository, so that other reviewers can have a look?

• The is is_sb_enabled module patch looks fine
• no-devicetree-if-secure-boot.patch seems to be based on an upstream one. Can you elaborate from where this patch comes from
• Version command comes from Fedora (https://src.fedoraproject.org/rpms/grub2/blob/rawhide/f/0095-Add-a-version-command.patch)
• Otherwise it is fully based on the Fedora 37 version

As far as I understand it, key usage and extended key usage are optional, right? If that is the case, then I would rather not include this.

For the CA certificate from a technical perspective yes. The leaf certificates can definitely be more restricting.

Just to be clear, you are essentially saying that as long as we compile the SONiC kernel with CONFIG_MODVERSIONS=n, then we are also in the clear? This is most likely also a feasible option for us.

If you increase the version number accordingly probably. I've described the potential solutions in #345 (comment), but there is currently no consensus on what solutions are accepted.

[mheese]

Thank you for the explanation. According to the Microsoft signing requirements the operating environment must achieve a level of security at least equal to FIPS 140-2 Level 2 and the key must be protected by a hardware security module (https://techcommunity.microsoft.com/t5/hardware-dev-center/updated-uefi-signing-requirements/ba-p/1062916).
I think those requirements are met, but I would like to get a second pinion on that.

Great 👍 Yes, and the shim-review should probably get updated that an HSM is required for those keys. We just did it this way because we thought it's the right thing to do.

I will send you a read-only invite to the repository shortly. It is our intention that this repository is public, and as it builds/contains GPL software it actually must be public. However, as it uses GitHub runners which are hosted in our lab in the datacenter, we did not make it public yet because of the security and access implications. That said, it looks like there are now ways to better expose and control that, so we will look into that again. This is not the only repository which is affected by this unfortunately.

I've got the invite. If it takes longer to make it publicly available, can you upload an archive for example to the shim-review repository, so that other reviewers can have a look?

I have just made the repository public, so it's now available to view for everybody here: https://github.com/githedgehog/grub-build

* The is `is_sb_enabled` module patch looks fine

* `no-devicetree-if-secure-boot.patch` seems to be based on an upstream one. Can you elaborate from where this patch comes from

This is a patch which originally comes from Debian 2.04 grub: https://sources.debian.org/patches/grub2/2.04-12/no-devicetree-if-secure-boot.patch/

However, I adopted it from the ONIE grub patchset here: https://github.com/opencomputeproject/onie/blob/master/patches/grub/2.04/no-devicetree-if-secure-boot.patch

That said, that patch might not be required anymore, as I can see (right now) that the later Debian grub versions are not including that patch any longer. @steve-mcintyre might know, as he signed off on that patch :)

Also, this patch would be specific/required for the aarch64 grub build only, which we currently don't target beyond a virtual machine image with ArmVirt firmware as no ARM hardware platform has been selected yet (which will come sooner though than I want for sure).

As far as I understand it, key usage and extended key usage are optional, right? If that is the case, then I would rather not include this.

For the CA certificate from a technical perspective yes. The leaf certificates can definitely be more restricting.

Makes sense. I got burned in the past with certificates that had too many extensions, so by now I'm mindful using them when not needed - and particularly with hardware/firmware the probability that something can and will go wrong is just higher.

Just to be clear, you are essentially saying that as long as we compile the SONiC kernel with CONFIG_MODVERSIONS=n, then we are also in the clear? This is most likely also a feasible option for us.

If you increase the version number accordingly probably. I've described the potential solutions in #345 (comment), but there is currently no consensus on what solutions are accepted.

Yeah, I read that comment. Both solutions in there essentially match what we discussed here, and both would work for us.

[THS-on]

I will send you a read-only invite to the repository shortly. It is our intention that this repository is public, and as it builds/contains GPL software it actually must be public. However, as it uses GitHub runners which are hosted in our lab in the datacenter, we did not make it public yet because of the security and access implications. That said, it looks like there are now ways to better expose and control that, so we will look into that again. This is not the only repository which is affected by this unfortunately.

I've got the invite. If it takes longer to make it publicly available, can you upload an archive for example to the shim-review repository, so that other reviewers can have a look?

I have just made the repository public, so it's now available to view for everybody here: https://github.com/githedgehog/grub-build

👍

* The is `is_sb_enabled` module patch looks fine

* `no-devicetree-if-secure-boot.patch` seems to be based on an upstream one. Can you elaborate from where this patch comes from

This is a patch which originally comes from Debian 2.04 grub: https://sources.debian.org/patches/grub2/2.04-12/no-devicetree-if-secure-boot.patch/

However, I adopted it from the ONIE grub patchset here: https://github.com/opencomputeproject/onie/blob/master/patches/grub/2.04/no-devicetree-if-secure-boot.patch

That said, that patch might not be required anymore, as I can see (right now) that the later Debian grub versions are not including that patch any longer. @steve-mcintyre might know, as he signed off on that patch :)

Also, this patch would be specific/required for the aarch64 grub build only, which we currently don't target beyond a virtual machine image with ArmVirt firmware as no ARM hardware platform has been selected yet (which will come sooner though than I want for sure).

Upstream there exists now the Lockdown framework since 2.06 and that implements similar functionality: https://git.savannah.gnu.org/cgit/grub.git/commit/?id=468a5699b249fe6816b4e7e86c5dc9d325c9b09e

If I see that correctly, Fedora uses that feature when Secure Boot is enabled, so that patch is likely not needed anymore.

As far as I understand it, key usage and extended key usage are optional, right? If that is the case, then I would rather not include this.

For the CA certificate from a technical perspective yes. The leaf certificates can definitely be more restricting.

Makes sense. I got burned in the past with certificates that had too many extensions, so by now I'm mindful using them when not needed - and particularly with hardware/firmware the probability that something can and will go wrong is just higher.

Just to be clear, you are essentially saying that as long as we compile the SONiC kernel with CONFIG_MODVERSIONS=n, then we are also in the clear? This is most likely also a feasible option for us.

If you increase the version number accordingly probably. I've described the potential solutions in #345 (comment), but there is currently no consensus on what solutions are accepted.

Yeah, I read that comment. Both solutions in there essentially match what we discussed here, and both would work for us.

I think for now choose the option that best fits and we see after the meeting what options are accepted.
Besides that, for me the questions are sufficiently answered and this submission is ready.

[mheese]

@THS-on as discussed earlier re managing keys for kernel modules, we are going to choose the following path:

• CONFIG_MODVERSIONS=n --> more or less just as a precaution, as we don't need to cross-load anyways
• ABI will be bumped either through patch version change, or through LOCALVERSION when required
• most importantly though: we will use a dedicated set of keys for every kernel version that we compile

[THS-on]

As discussed today the kernel module signing is not a blocker.

If we can another (also non official) review, then is is ready to go. Maybe someone of the new (nearly) accepted shims can have a look (@akodanev, @Fabian-Gruenbichler, @keithdlopresto)?

[ClaudioGranatiero-10zig]

I’m not an authorized reviewer, I’m just trying to help and learn.

I was only able to build the x86_64 version, so I'm reviewing only that.

---

sha256:

f43357e978b690aaef58b53de9e898105230d45cc825a4fb8ef996e577e8c541  shimx64.efi

Build is reproducible, sha256 is confirmed.

---

Obj Alignment:

shimx64.efi

SectionAlignment	00001000
DllCharacteristics	00000100

Alignement is ok.

---

DllCharacteristics:

shimx64.efi

            DllCharacteristics:        256         0x100  NX_COMPAT

NX_COMPAT is enabled.

---

Sections:

shimx64.efi

=== SECTIONS ===

  NAME          RVA      VSZ   RAW_SZ  RAW_PTR  nREL  REL_PTR nLINE LINE_PTR     FLAGS
  "/4"         5000    1db8c    1dc00      400     0        0     0        0  40000040  R-- IDATA
  .text       23000    6135a    61400    1e000     0        0     0        0  60000020  R-X CODE
  .reloc      85000        a      200    7f400     0        0     0        0  42000040  R-- IDATA DISCARDABLE
  "/14"       87000       86      200    7f600     0        0     0        0  c0000040  RW- IDATA
  "/26"       88000       47      200    7f800     0        0     0        0  40000040  R-- IDATA
  .data       89000    2ced4    2d000    7fa00     0        0     0        0  c0000040  RW- IDATA
  "/37"       b6000      3be      400    aca00     0        0     0        0  40000040  R-- IDATA
  .dynamic    b7000      100      200    ace00     0        0     0        0  c0000040  RW- IDATA
  .rela       b8000    1b468    1b600    ad000     0        0     0        0  40000040  R-- IDATA
  .sbat       d4000       e2      200    c8600     0        0     0        0  40000040  R-- IDATA

Code section is not writable: OK

---

SBAT:

shimx64.efi

shimx64.efi:     file format pei-x86-64

Contents of section .sbat:
 d4000 73626174 2c312c53 42415420 56657273  sbat,1,SBAT Vers
 d4010 696f6e2c 73626174 2c312c68 74747073  ion,sbat,1,https
 d4020 3a2f2f67 69746875 622e636f 6d2f7268  ://github.com/rh
 d4030 626f6f74 2f736869 6d2f626c 6f622f6d  boot/shim/blob/m
 d4040 61696e2f 53424154 2e6d640a 7368696d  ain/SBAT.md.shim
 d4050 2c332c55 45464920 7368696d 2c736869  ,3,UEFI shim,shi
 d4060 6d2c312c 68747470 733a2f2f 67697468  m,1,https://gith
 d4070 75622e63 6f6d2f72 68626f6f 742f7368  ub.com/rhboot/sh
 d4080 696d0a73 68696d2e 68656467 65686f67  im.shim.hedgehog
 d4090 2c312c48 65646765 686f6720 534f4e69  ,1,Hedgehog SONi
 d40a0 4320466f 756e6461 74696f6e 2c736869  C Foundation,shi
 d40b0 6d2c3135 2e372c68 74747073 3a2f2f67  m,15.7,https://g
 d40c0 69746875 622e636f 6d2f6769 74686564  ithub.com/githed
 d40d0 6765686f 672f7368 696d2d72 65766965  gehog/shim-revie
 d40e0 770a                                 w.              

shimx64.efi:     file format pei-x86-64

Contents of section .sbatlevel:
 88000 00000000 08000000 22000000 73626174  ........"...sbat
 88010 2c312c32 30323230 35323430 300a6772  ,1,2022052400.gr
 88020 75622c32 0a007362 61742c31 2c323032  ub,2..sbat,1,202
 88030 32313131 3530300a 7368696d 2c320a67  2111500.shim,2.g
 88040 7275622c 330a00                      rub,3..         

sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
shim,3,UEFI shim,shim,1,https://github.com/rhboot/shim
shim.hedgehog,1,Hedgehog SONiC Foundation,shim,15.7,https://github.com/githedgehog/shim-review

SBAT seems ok to me.

---

Certificate:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            24:26:12:ae:04:f6:db:d9:2c:0c:10:19:d7:f0:2a:46:4e:c0:c8:77
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, ST = Delaware, O = Hedgehog SONiC Foundation, CN = Hedgehog Secure Boot CA
        Validity
            Not Before: May  3 19:51:39 2023 GMT
            Not After : Apr 30 19:51:39 2033 GMT
        Subject: C = US, ST = Delaware, O = Hedgehog SONiC Foundation, CN = Hedgehog Secure Boot CA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:da:9e:ec:69:c4:de:db:30:e5:e4:94:2d:69:c9:
                    e4:47:73:73:74:a3:a7:3a:ec:7e:89:01:16:e5:e6:
                    03:ad:63:bd:14:3a:92:8f:60:df:9e:16:fb:40:aa:
                    fa:60:30:67:67:4c:10:9d:e4:5c:a7:cd:fc:8a:c1:
                    4b:df:2c:94:6b:39:32:d1:48:4b:49:a0:70:c0:0c:
                    62:a4:79:f8:5f:90:3b:0f:7f:ce:f6:76:c4:99:a4:
                    5e:de:bb:51:5f:ef:8d:91:8c:5c:d1:d2:96:83:c2:
                    99:8b:9b:a1:b8:3a:b7:fe:81:f6:d3:0d:37:6b:75:
                    f3:e0:73:2a:77:85:a4:fd:d6:70:4a:c1:47:f2:37:
 
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:TRUE
            X509v3 Subject Key Identifier: 
                10:F5:A7:5C:21:47:2E:C0:F1:90:0A:AC:23:9D:03:57:87:AB:38:45

It's a CA, good
Certificate is ok.

============================================

[THS-on]

@ClaudioGranatiero-10zig thanks for having also a look at it. Got three reviews now, marking as accepted.

[THS-on]

What is the status of this? Did you get a signed shim back or are you creating a new submission for 15.8?

[mheese]

@THS-on after the news about the upcoming 15.8 release I did not bother anymore to submit the shim to Microsoft in December. As I'm no longer working for Hedgehog I cannot speak to the actual state of this though.

[THS-on]

@mheese ok I'll close this one then.