New Code Signing Certificate and implementation

:tada: New Code Signing Certificate and implementation

The Certificate for code signing expired end of last year, AND, new rules from certification authorities, it was time for a new headache. As of today, all WIP installers are signed through Azure Trusted Signing. A lot of sweat to get there (many evening of reading, asking around, a looong evening of implementation going through Code signing on Windows with Azure Trusted Signing · Melatonin and finally a morning of debugging) but a fairly cheap and reliable solution is in place now.

The Certificate is under my name, Jean-Marc Couffin. I could not create an org / enterprise certificate because pyrevitlabs is not an org or a business, but just a small bunch of enthusiasts.

It seems to work great. Feel free to report any issue on the repo.

5 Likes

Hello,

We just downloaded the latest release (pyRevit_5.0.0.25034_admin_signed.exe) and installed it. We can see that the pyRevit_5.0.0.25034_admin_signed.exe is signed by you, but the pyRevitLoader.dll is not signed. As you can see in the screenshot, Revit is complaining that the publisher is Unknown.

image

Is it possible to get the dll signed?,
Greg

Surely
Oversight on my side.
Will do but later this week or the next, unless someone wants to edit the workflow file and make a pr

@gbudhijanto
Done, can you try the latest wip?
If you confirm this is good on your side with the wip, I will make a new release.

Yes, we can see that it is signed but the certificate seems to only be valid for 4 days, is that correct?

Is there any way to issue a certificate that lasts a year or more? Have you considered Signpath.org? They offer free code signing services to open source projects

We truly appreciate your efforts,
Greg

Not extendable, it is by design.

So far azure trusted signing has served us well.
The setup was close to a no brainer and done in a 2 days period. Compared to other certificate providers…

I don’t plan on switching but thanks for the suggestion with signpath. If azure trusted signing becomes an issue, we will consider.

So… Clarification
I had to go deep down the hole
Again

The certificate itself is valid three days, but as the signature is timestamped, the validity of the signature is valid as long as the time stamp authority is.

In our case, for the release, it is valid up to October. So we are good.

I also tried the installer, now, which is just after the certificate validity.

And all was well

Being a medium sized-company we deploy PyRevit to all production staff who use it regularly. In order to have a seamless experience for our staff, we deploy the certificate to whitelist the PyRevit add-in so users are not prompted to load the plugin in Revit. Every time PyRevit updates, there would be a need to redeploy the certificate each time.

We appreciate all the hard work you do for PyRevit. From a security standpoint and compliance best practice, it may be worth considering SignPath.org for future development, since it is free for open source and would remove the need for creating a certificate each time a software package is released.

Thanks again

yep, that would be the case

The fact that the certificate has a shelf life of a couple of days is safer. The signature validity makes it last long enough from our standpoint.

The integration in our CI was definitely seamless and less intricate than the previous supplier of certificate. So this will probably stay as is, at least for now, unless it becomes a pain for the majority of our users.
We plan on refactoring the whole dev pipeline: installer, loader and ui maker from python to C#, …
This will probably be overwhelming enough in terms of bandwidth / work load. Unless you want to do the research and implementation yourself.

Getting a certificate is a painful process, whatever the supplier. And Azure was a fairly decent and smooth one.