3 ms·

And the signing software looks like it's like 20+ years old. Maybe more. AND, the USB keyfob they give you DOES NOT WORK via RDP. You have to use VNC to log

by e40 4y ago

And the signing software looks like it's like 20+ years old. Maybe more. AND, the USB keyfob they give you DOES NOT WORK via RDP. You have to use VNC to login to the console, otherwise the USB device is not seen. We have the key plugged into a machine in a data center. Originally, I tried the USB forwarding from RDP, where I had it plugged in locally at my workstation (a Mac). The feature of forwarding devices exists in macOS MS RDP, but it doesn't work for the device I had. It took me about a month of effort to get the EV code signing certificate to work. I'm pretty bitter about it.

mike_hearn 4y ago
Conveyor can solve that. It's a packaging tool that amongst other things can sign Windows binaries and packages from macOS and Linux, including with the USB key fobs you use with EV certificates. The UX is also better than standard signing tools - you configure it with a simple config file, it can show progress bars on the console etc. There's a video on the website. https://hydraulic.software/ https://hydraulic.software/ EV certificates tend to be quite trusted by AV vendors, even if you're new and never had any downloads before, because you have to go through more validation. OV certificates are cheaper and less work to get but start out with neutral trust, so your early downloads will get warnings that the binaries aren't downloaded very often. The sort of AV problem is unfortunately quite common on Windows, partly because a lot of devs and especially the sort of UNIX-oriented devs that write Nim and Go programs simply won't sign their software. It's the nature of modern platforms: you either sign your software and build up reputation, like with sending email, or you don't and end up being hit by the full brunt of heuristic guessing (or on macOS, refusal to run at all without workarounds). Not signing on Windows is a bit like sending email without SPF or DKIM, it's going to land you in the spam folder a lot.
- e40 4y ago
  Thanks. When our current solution expires, I will look at this solution.
dfox 4y ago
The USB issue is intentional and documented Windows feature (although so badly documented that it apparently surprises even MS insiders). IIRC it only behaves this way on Windows Server SKUs. (the idea is that when it is used as terminal server, each user may have their own similar device)

by e40 4y ago

mike_hearn 4y ago

Conveyor can solve that. It's a packaging tool that amongst other things can sign Windows binaries and packages from macOS and Linux, including with the USB key fobs you use with EV certificates. The UX is also better than standard signing tools - you configure it with a simple config file, it can show progress bars on the console etc. There's a video on the website. https://hydraulic.software/ https://hydraulic.software/ EV certificates tend to be quite trusted by AV vendors, even if you're new and never had any downloads before, because you have to go through more validation. OV certificates are cheaper and less work to get but start out with neutral trust, so your early downloads will get warnings that the binaries aren't downloaded very often. The sort of AV problem is unfortunately quite common on Windows, partly because a lot of devs and especially the sort of UNIX-oriented devs that write Nim and Go programs simply won't sign their software. It's the nature of modern platforms: you either sign your software and build up reputation, like with sending email, or you don't and end up being hit by the full brunt of heuristic guessing (or on macOS, refusal to run at all without workarounds). Not signing on Windows is a bit like sending email without SPF or DKIM, it's going to land you in the spam folder a lot.

e40 4y ago
Thanks. When our current solution expires, I will look at this solution.

dfox 4y ago

The USB issue is intentional and documented Windows feature (although so badly documented that it apparently surprises even MS insiders). IIRC it only behaves this way on Windows Server SKUs. (the idea is that when it is used as terminal server, each user may have their own similar device)