Building Desktop Apps Out of Web Apps: Scaling Electron With Code Signing & CI/CD

Hi, everyone. Thank you for joining my session today. I'll be talking about building depth of application out of web apps and also talking about scaling industrial applications with code signing and cross-platform CI CD. My name is Ayole Aonseola, I'm a solution architect and also the senior developer advocate. You have a web application and you want to convert that into a desktop-oriented application. So Electron helps you to wrap this existing web application into what you can serve for users on a desktop or as a desktop application.

But there's a challenge when you want to move from dev mode to ship mode. You need a wall for signing and CI CD. So these two walls can cause issues when you're trying to convert a web app into a desktop application. There are common stories that could happen when you're trying to build. One of the stories is when users are trying to install the app and they encounter a popup that says that the developer of this application is not verified, or you build on your Mac but you try to give that same application to another user who is using another Mac, but it doesn't work on their Mac.

Or let's say, for instance, you build it on a M-series app or a M-series Mac, so which means either you're using M1, M2, and you give a user who is using an Intel processor. Now, it might not work because these are two distinct processing chips. Or you build on Windows and you want that same file that you are building for Mac to be built on Windows. So these are some challenges that you might encounter. Another challenge is how do we sign the application for us to be able to avoid that unverified developer? So the problem is not just about building an application. So the problem is how can we scale this application with confidence?

Because all we need to do is get the URL of the deployed app and then wrap it with Electron to serve desktop users. There's an architecture that you need to follow when you are building for desktop users using Electron. And Electron gives you some core functionalities that allow you to also put security first, or let me say build a security layer around your desktop application. One of it is context isolation. If you turn this functionality on, which is set to true, it creates a secure barrier between your web page and your back end, forcing all communication through a safe, predefined bridge. So in this way, nothing goes without your catch.

Electron gives you some architecture that allows you to put security layer first when you are building your desktop application. And one of these layers is context isolation. So this functionality, if you turn it to true, creates a barrier between your web page code and your powerful back-end APIs, forcing all communication to go through a safe, predefined bridge. So if the communication is not going through this route, it will not go successfully. That is what context isolation does for you. Also, node integration helps you to disable Node.js functionality in your app front-end. So it is preventing web page scripts from directly accessing your computer file. So any dangerous file that is trying to execute, to have access to your computer files, once this node integration is turned to false, it ensures that no malfunction files or no scripts that is intended for AMP to your users who are using desktop applications does not come true. So that should be toggled to false. So that covers that part.

And the third functionality is validating IPC messages. So this is just a practice, ensuring that your back-end is checking all data. So more like sanitizing all data that has been sent from the front-end to the back-end, or every communication has been sanitized to ensure that there is no trick of performing unsafe actions. So in this process, your desktop users have been protected at all costs. After you are done with the background, we've been able to set a background of this content. Then when you are building, there's also something that you need to put into consideration, which is the engineering challenges. One of which is signing. So when your application is not signed, your users tend to see an untrusted application warnings, and this allows them to install your application, either for Mac or for Windows users. Also for distribution, you need to distribute for multiple OSs, because you don't want to just build for a specific OS. At least you want to build for Windows, you want to build for Linux, and you also want to build for Windows users. So which means distribution is also a key. Also, automation is also something you need to consider. Why? Because you don't want to allow human error to happen during your releases. So these are the engineering challenges that need to be considered.

So these are the engineering challenges that need to be considered. Signing, distribution, and automation. Now, what is scaling? What does it really mean? There's a place for trust, there's a place for automation, and there's also a place for security. If your application lacks the trust that it needs, your users won't install the application. And if some processes are not automated, there will be friction between your teams, and your time to market will be affected. Also, security is synonymous to trust. Just like the trust reduces app installation count, security also ensures that your app loses its credibility in the market. Which means you also have to build a strong trust, ensure that automation is consistent, and your security is up to the very standard. So that's why I define scaling as trust multiplied by automation multiplied by security. So this gives you a scaled application that can serve multiple users, or thousands of users, whereby your trust is protected, your security is also protected, and your automation is well inclined.

Now, code signing. I've been mentioning code signing since the beginning of this talk. What is code signing, and why do we need it? So, code signing verifies who built the app, and that it wasn't tampered with. Look for an example, we purchased a brand new phone, and when you are about to open this phone, you notice that the seal has been tampered with. So that is what signing ensures with your application. Either for Apple devices or for Windows devices, it will allow you to install an application that has been signed. So by default, if an application is unsigned, the app shows the users a dialogue that says that the developer of the application is not trusted. So, signing is not decoration. It is the passport that your app needs to access multiple operating systems.

Now, let's take Apple before we go to Windows. So, for the Apple chain of trust, you need developer ID, you need developer ID installer. So, these are the certificates you need to download from your developer account on Apple. So, the first thing you need to do is register yourself as an Apple developer, then sign in to your account, then under your settings, you will be able to download the developer ID application certification. So, this allows you to be able to distribute a .dmg, that is the Apple executable file, so it allows you to distribute the .dmg file. Then the second certificate is developer ID installer, both are there. So, you download the certificate, and then on your local machine, you can install it. And if you are using CI, you ensure that the certificate is uploaded on your CI pipeline. Then, app authorization is essential because when you are trying to bond your app into an executable app, the Apple OS scans and validates your build. So, in this way, authorization turns your on-site application into a trusted application of Mac operating system. So, for Apple, you need developer ID application certificates, you need developer ID installer certificates, and so you need the app authorization.

So, I prepared a sample code that shows the main ideas. In this sample code, I am converting my blog into a desktop app with multiple sections. The first section involves creating an instance by setting the window dimensions. When there's content to display, it ensures a smooth loading process without flashes on the screen. The app adjusts to the user's screen size after loading is complete. Additionally, functionalities like 'open at login' for Mac and 'window all closed' for platform-specific actions are implemented.

The main.js file contains the code for bundling the application. A notarized.js file is created for Mac, defining the app bundle ID, app name, and app ID. To proceed, an Apple-specific password is generated under the Apple account settings for security. This unique password, along with the team ID and Apple ID, is added to the environment file. It's crucial to differentiate this app-specific password from the developer account password.

You close the app, then it gives itself a space in the tree of your Mac environment, so that anytime you want to click, you can automatically open the environment. So, these are what all these actions are doing, and for Windows, we are trying to see that immediately the system turns on automatically open the application. So, that is what this will be doing.

This is the main.js file, and everything is ready to be bundled into a different application with this little code. Now, I created a notarized.js file. What this does is that, since I'm building for Mac, I've created the app bundle ID, where the app will be saved at and then the app name. Also, your app ID is needed. Then, you need to create an Apple specific password for your application. So, under your Apple account, you go to settings. Under security, you need to generate a app specific ID, not the password for your developer account. So, this is specific to an application. So, you generate this password. If I make it short-lived or long-time-lived, then you generate this password. That is the password you need for this process. Then, you add your team ID.

So, your team ID is always available in your developer account. Anytime you log in, you see your team ID is always shown. So, once you have this team ID, add it to your env file, put your Apple ID, which can be your email, then put the app-specific password. Remember, this is not the password for your developer account. So, this is specific to an application. So, you use that and also add your team ID. Then, you are good. Don't forget that we already added certificate downloaded, the ID application, and then the ID installer. Those two are very essential in this process. So, once all of that is available on your local machine, when you run npm run dist, it automatically builds and Apple scans the authorization file and ensures that everything works fine. Under two minutes, you are up to speed.

So, I added the packet.json file so you can actually see what is in my packet.json file. In that place, I added the author name, the email address that you can contact me on, and I also added that this beautiful Mac application should be universal. Either you are using Intel processor or you are using the M series, this installer works for everything because it is universal. And in this settings as well, I set for Windows as well because this code can also be used for both Mac and Windows. So, run one, use that to build multiple operating systems. So, with this file, we can be able to build for both Mac and Windows. So, that is why I added the packet.json file so you could see how it is looking like.

Now, for the Windows, I have explained how we need to build our environment to build for Mac. So, how do we build for Windows? So, building for Windows, Windows does not have a developer account like Apple does. So, it is a different ballgame, which means you need a certificate to sign your application. So, the last time I built, I purchased an installer certificate from Digisat and it's an EV certificate. So, I was given a USB token because that was what I requested for. Now, you can decide to go for a physical USB token or you go for an HSM token, which can be installed on your cloud infrastructure. So, if you go for a physical token, the first time you want to build your app, you plug your USB token into the PC and then you build, and your system or your app automatically scans or looks for the certificate and signs your app with it. And if it is HSM, immediately you are trying to build for your CI pipeline. Immediately you trigger a build. Try to locate the installer. Try to also locate the certificate and then ensure that everything is signed and you are good to go.

So, the reason why Windows is different is because Mac operates on a different level. Windows also operates on a different level. So, you need to consider that if you are building for these two operating systems, you need to consider what works for these two operating systems. So, immediately you get your certificates, there might be an app that you might need to install either on the cloud infrastructure or on your local machine. When you install this, that app allows your application to be able to access the certificate from your PC. Because if you plug in the token into your PC, you may not be able to see anything. So, this token allows that certificate on your PC to be seen and can be accessed by the application to sign the application. So, I've explained that you can do it locally and you can also do it on the cloud. So, for cloud applications or for the cloud processes, it can be done in two ways. This is because your cloud cannot access physical USB token, which means there's a need for you to look for a way to access your USB token. So, that was why I mentioned HSM. So, you can either go for Self-Posted Runner, whereby you have an on-prem infrastructure, whereby you can physically plug the USB token into, or if you don't have any on-prem infrastructure, everything is cloud, then you can either use a digital infrastructure where you get the HSM equivalent of the USB token, and then the certificate is being installed and stored securely.

Now, in this way, we're trying to automate the signing process, taking the power from human efforts to CI process efforts. So, that is what we are doing and handling the EV token efficiently. So, this is a sample workflow for we're trying to use the HSM module that is our certificate is being stored on a cloud infrastructure. So, I am assuming that I'm using GitHub and Azure. So, this is just a one-time setup, and after the setup, anytime you want to build, you don't need to do the setup again, because your YAML file is there, and anytime you push a tag, it automatically builds something for your processes. So, you send certificates after your purchase has been made, and then you securely upload the certificates, including the private key and the public key to your Azure key vaults, then this cloud service is designed for managing secrets and certificates.

So, if there's an Azure key vault, it does that. I know AWS also has something similar to that that you can also use to secure your key. So, on your Azure, you create a service principle which acts as human on behalf of your CI pipeline. So, you only grant that principle an access for specific certificates and perform signing on your behalf. So, that principle cannot delete or export the key. The only thing it could do is only to sign your application. So, on GitHub, you can also create a secret whereby you copy the service principle ID, you copy the tenant ID and the secret, and use that to log in into the Azure platform during your CI process.

So, that is why I put comments on some parts of the workflow file. So, there's a trigger that is being triggered for the view to happen, then there's a login to the Azure environments, then the signing is taking place, and after the signing is taking place, automatically the app is being uploaded to your desired storage and artifacts that you can distribute. So, now, every time you push a new code, your GitHub Actions workflows run automatically and can sign your application on the cloud using your CI. So, these are the two ways you can sign your application. Either you do it physically by plugging in the physical hardware token into your PC by the time you're running your build process, or you do it in your CI pipeline because your certificate is on the cloud. So, your workflow file automatically identifies the login credentials and can sign on behalf of your user.

The essence of this is that, with CICD, you need one push and all builds can be done. So, no manual signing, every build, make a build for both your Windows users and your Mac users, and then the respective artifacts are being auto-uploaded into the path that you expect. So, instead of you doing this manually, we are expecting that this is being done automatically.

Now, what is the good catch? I expected that you send your certificates into your repository or your client infrastructure in Base64. So, why are we choosing Base64? We all know that this is an encoding scheme that converts binary data into text-only string and allows you to copy the entire certificate and paste it into your repository secrets, probably maybe like your GitHub secret. So, in that way, it can be read by your CI workflow.

Another thing I also expect you to do is that you don't trigger your CI process for this build on every push. So, you can trigger this build process on a tag push. So, probably your developer pushes a tag, let's say, version v1.0, and automatically that runs the build and the signing process. So, in this way, you know when you are building for test, dev mode, and when you are building for release candidates. So, when you are building for release, all you need to push is a tag and that will automatically run your workflow file.