Use the managed signer to remove the code signature from singlefile bundles

[jtschuster]

When working on using the managed Mac signer in the SDK on non-mac hosts, I found that since the bundler uses codesign to remove the signature, we end up with an invalid signature for single file osx executables. This PR updates the bundler to use the managed signer to remove the signature.

Signing bundles requires a little more thought and effort since the headers/load commands need to be updated to include the bundle data in the file. This will be done in a separate PR.

Part of #110055.

[dotnet-policy-service]

Tagging subscribers to this area: @vitek-karas, @agocke
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @vitek-karas, @VSadov
See info in area-owners.md if you want to be subscribed.

[am11]

since the bundler uses codesign to remove the signature, we end up with an invalid signature for single file osx executables

Was it due to some unintentional refactoring? SingleFile was a no-diff in #108992 because it required follow-up work. I understand that ultimately we want to use managed codesign everywhere, just trying to understand do we know what went wrong?

[jtschuster]

since the bundler uses codesign to remove the signature, we end up with an invalid signature for single file osx executables

Was it due to some unintentional refactoring? SingleFile was a no-diff in #108992 because it required follow-up work. I understand that ultimately we want to use managed codesign everywhere, just trying to understand do we know what went wrong?

Nothing went wrong, we would only end up with an invalid signature if we merge the SDK PR (dotnet/sdk#45019) before this. HostWriter.CreateAppHost would create a signed SingleFile host on Windows or Linux, but then Bundler wouldn't remove it before creating the bundle, since it only does signing tasks with codesign.

[am11]

nit: this can be:

    public static void RemoveCodesign(FileStream bundle)
    {
        // Windows doesn't allow a FileStream to be resized while the file is memory mapped, so we must dispose of the memory mapped file first.
        using MemoryMappedFile mmap = MemoryMappedFile.CreateFromFile(bundle, null, 0, MemoryMappedFileAccess.ReadWrite, HandleInheritability.None, true);
        using MemoryMappedViewAccessor accessor = mmap.CreateViewAccessor(0, 0, MemoryMappedFileAccess.ReadWrite);
        if (TryRemoveCodesign(accessor, out long? newLength))
        {
            bundle.SetLength(newLength.Value);
        }
    }

[am11]

Maybe in else case, we should throw InvalidOperationException("Unable to remove Codesign from bundle.").

[jtschuster]

I was getting failures on Windows when trying to resize the file length while the memory mapped file was still open, so the SetLength has to come after the using block.

The TryRemoveCodesign will only return false if the file isn't a Mach-O binary or there already isn't a signature present. We could throw if it's not a Mach-O, but I don't think it's a failure if the signature isn't present. Maybe we could rename both to RemoveSignatureIfExists instead?

[am11]

Ah, alright. I think RemoveSignatureIfExists makes sense. If algorithmically we can tell that there is going to be a signature before calling this method, then we can simply throw the exception when TryRemoveCodesign fails (i.e. failure mode is something other than signature wasn't present).