feat(pedm): add version check API and signature check API

[Richard Markiewicz (thenextman)]

Add a new policy option target_must_be_signed; this forces the target executable to have a valid auhenticode signature as per the policy.

Realistically, this should be a "rule" so I'm probably introducing some slight technical debt here but I believe it's a worthwhile feature and a low-hanging fruit we can squeeze in for the release.

Add the application (Agent) version to the "About" API endpoint. This is for future proofing: RDM needs a way to know what version of PEDM he's talking to, in case we add/remove/change APIs.

The implementation is in Win32 and I believe it to be correct, but it could use some close scrutiny.

I generated the OpenAPI in a. separate commit for easier reviewing.

[github-actions]

Let maintainers know that an action is required on their side

• Add the label release-required Please cut a new release (Devolutions Gateway, Devolutions Agent, Jetsocat, PowerShell module) when you request a maintainer to cut a new release (Devolutions Gateway, Devolutions Agent, Jetsocat, PowerShell module)

• Add the label release-blocker Follow-up is required before cutting a new release if a follow-up is required before cutting a new release

• Add the label publish-required Please publish libraries (`Devolutions.Gateway.Utils`, OpenAPI clients, etc) when you request a maintainer to publish libraries (Devolutions.Gateway.Utils, OpenAPI clients, etc.)

• Add the label publish-blocker Follow-up is required before publishing libraries if a follow-up is required before publishing libraries

[Benoît Cortier (CBenoit)]

By the way, in the Gateway we use the CARGO_PKG_VERSION env variable that is available at compile time:

devolutions-gateway/devolutions-gateway/src/api/health.rs

Line 64 in bee8578

version: Some(env!("CARGO_PKG_VERSION")),

This is replaced by, e.g., "2025.1.5", at compile time. I think I prefer that, unless there is a reason to stick to the runtime extraction from the executable?

Approving now to smooth the process for you.

[Richard Markiewicz (thenextman)]

By the way, in the Gateway we use the CARGO_PKG_VERSION env variable that is available at compile time:

devolutions-gateway/devolutions-gateway/src/api/health.rs

Line 64 in bee8578

version: Some(env!("CARGO_PKG_VERSION")),

This is replaced by, e.g., "2025.1.5", at compile time. I think I prefer that, unless there is a reason to stick to the runtime extraction from the executable?

Approving now to smooth the process for you.

Yes, as I wrote on Slack because we are in a crate that gives use the crate version

I do understand the alternative approach of using the build.rs to properly embed the version number in the crate, as also proposed by Allan Zhang (@allan2). Honestly I'm not sure which way I prefer.

Part of this is my own background: coming from a C/C++/C# perspective, the proper way to do this is to query the main module version. i.e. In C# you'd do GetEntryAssembly or GetExecutingAssembly and obtain the version that way. I like the idea that if I want to get the Agent version from another crate, I can call an existing function without having to modify the build system. It does (of course) rely on the developer knowing of the existence of said function.

But I do understand it's probably more idiomatic in rust to use a CARGO variable.

For now, I leave this like it is; but I'm not opposed to someone changing that to the alternative approach.

[Benoît Cortier (CBenoit)]

Part of this is my own background: coming from a C/C++/C# perspective, the proper way to do this is to query the main module version. i.e. In C# you'd do GetEntryAssembly or GetExecutingAssembly and obtain the version that way. I like the idea that if I want to get the Agent version from another crate, I can call an existing function without having to modify the build system. It does (of course) rely on the developer knowing of the existence of said function.

That’s a fair point. Anyway, now we have the function, we can use it 😉