Distributed and secure frontend deployment pipelines - Pavel Losev

Transcript

[music] >> Okay. Uh so, hello, I'm Pavel from Unos. Uh I'm going to talk about the deployment pipelines and how to distribute and secure them. So, the traditional deployment pipeline that most websites use is that there is a GitHub repo, you push some code, uh your web app gets built and compiled to a bundle, then it's uploaded to some kind of a cloud service like Vercel, and then once the deployment finishes, uh it points to a new version.

This is a pretty standard setup, but also quite fragile. Uh even before you deploy your website, um there is a risk of a supply chain attack happening when your dependencies are being poisoned and you don't even notice that. Your machine could get compromised. The The cloud service that you're using might have an outage for many hours, for example. There is and there is without any fallback. And even once you get your website deployed already, you're still at risk with the DNS. Uh there all kinds of attacks with it, uh hijacks, social engineering, take downs, and so on.

Only last year there's been a couple of uh long-running outages with the major cloud providers that all those front-end services depend on. Uh from Cloudflare to AWS to Azure, all of them. And uh they have affected many websites that were unavail- unavailable to users for hours. And uh one of the recent flags of Web3 uh is UI hacks. Just last year, there was a huge, actually the largest crypto hack in history with a UI compromise where developer's machine was uh uh compromised and malware has been shipped to the front end and sat there for 2 days completely unnoticed.

As well as also DNS that uh resulted in loss of over a million dollars and repeatedly happen where malicious actor contacts the register pretends to be the owner of the domain and then takes over the domain. But it doesn't have to be this way. Front ends should be verifiable, meaning that all the content that you request is the actual one that you the content that you requested is the same one as you as served and uh hashes match the files. All the updates should be transparent and you should be able to roll back to any previous version at any time and you should see who made the update and uh to which version.

And it should be possible for both users and developers to roll back, not only to developers. And all the and access should be distributed. They should not depend on a single CDN or any other point of failure. And there should be multiple ways to access the same website. For example, through multiple gateways or through browsers that would fetch content from distributed storage and then locally verify the validity of the content. Actually, we already have the technology to achieve that today. Uh one of them is ENS, which serves as a universal web content pointer, uh meaning that uh ENS domains map to content hashes similar to how DNS maps to IP addresses.

And ENS also provides a on-chain history of all the updates where you can see who made the update at which point to what it has been changed to and you can see all the previous versions and open the previous versions at any time as long as they're accessible. Uh Swarm and IPFS provide distributed storage for those websites. So, it also it is also possible to easily replicate the content as many times as you would like to and as many copies of the content. So, in case one of the nodes or providers goes down, you still have a bunch of copies laying around. Uh all the content on both IPFS and Swarm is content addressable, meaning that all the hashes are the same for the same files, so that you can actually very easily verify the integrity of the content that uh the one that you

requested is the same one. And Safe also allows to enforce manual reviews before you update your ENS name, so that it's not just a direct update. So, in case like there is a compromise of a Ethereum signer owning the name, your ENS name is hijacked as well. So, Safe protects from that requiring a manual approval from parties. And uh it also yeah, enforces uh reviewing the transaction before you actually make the update. So, how could it all be put together um with Omnipin? I have built this tool a couple years ago and uh the way it works is uh So, you have this Git repo, you push some code, uh but instead of the bundle being uploaded to one cloud, it's

uploaded to multiple providers at the same time in one go. Uh and that way you have multiple replicas automatically. You don't have to do it manually. After the deployment finishes, the transaction is proposed to a Safe. Uh you sign the transaction, and then your website now points to a new version. And it's all done in one single command. So, it's not only just a deployment tool, it also protects from a number of attacks thanks to the infrastructure that it uses, mainly ENS, because ENS register updates are governed by the DAO instead of how like registrars, which are mostly private companies where they instead decide privately how to change their uh service. The names are permissionless, meaning that you can

manage them yourself at any time. You don't have to uh depend on a specific provider or a service. All the records updates are transparent. Uh you can see all the changes. And all the updates require manual review. Uh and you can always replicate anybody else's front end or your own as many copies as possible. And uh websites deployed on Omnipin are also accessible through multiple means. There is a plenty of ENS gateways, both that are universal for multiple types of uh storage, and also uh like IPFS specific or Swarm specific. And there's also a couple of browsers that support ENS resolution, which you can

also access uh websites deployed on Omnipin with, such as Brave and Freedom. Uh there are a couple projects using Omnipin, well, uh DNS itself, and the docs, uh a project called Walletbeat, which is like a index of all the wallets, and uh they use Omnipin to deploy their website on ENS. Uh I actually initially built this project for Lido, so they have uh a mirror IPFS mirror of their staking UI there as well. Yeah, and now I'm going to show a simple demo of just uh deploying a website on Omnipin. I'm going to be using Swarm.

That runs on my VPS, just a node, so that is very easy to showcase demo. So, I have an HTML file here. Yep, just pretty boring, but uh just going to uh sorry. Yeah, need to load the Okay, I just loaded the environment keys for the for the for the signer, so that they can propose an update. So, yeah, it already deployed it, so if we just click the link, yeah, it already deployed the page, but it's just uh this Swarm hash, like it's not a an ENS name. For ENS name update to propagate, I need to

go to the Safe app. I need to connect to my wallet. Yeah, so here is the update. So, I can see here what actually I'm signing the name hash of the name, and uh the encoded content hash, but this year possible to decode it, so you can see what actually you're signing. And uh now I'm going to sign an update. Okay. Yeah, so now ENS is updating. It's going to take some time.

Yeah, okay. It's It's basically live already. Now, let's just try to change the the page to another one. Yeah, now there's another page, so let's just run a redeployment. Okay. Cool. So, yeah, now it's already live on Swarm again. Yeah, so this is another page. Um Now, now let's see if we have a new update for ENS. Yes, it's already queued.

Let's confirm it. Let's see. Yeah, yeah, everything's good. Now, let's execute the the update. And the transaction's processing, so shortly after the update should be available. And uh It's being being indexed now. ENS gateway is cached responses, but it should be available in a couple moments with the new page.

So, yeah, it's going to take some time, but uh yeah, anyway. So, how how it works, the demo is uh I have a local node running uh for Swarm, but it could an IPFS node as well. Yeah, and uh it just pings the node and then uh I use a postage batch, which is which is like a storage quota, so that I upload to the network immediately, then propose a ENS update to the safe, then approve it and Yeah, it but it still take time. But either way, the content was already live on the swarm network. It's just the the the ENS gateway just cached the response.

So, yeah, that's pretty much it. Uh But uh one second. Yeah, so you can read the documentation for Omnipin um or try an agent skill, so to ask your code or any other AI agent to try to deploy it. Yeah, the website with the Omnipin uh and thank you for listening.

>> [applause] >> And >> Okay, thank you for the speech. Do we have any questions to the author and speaker? >> Uh sorry, I didn't hear. Uh no, they actually updated the content hash cost like maybe a couple cents on mainnet right now. Like it's and the gas is pretty stable, so it's unlikely there's going to be like cost spikes for updating ENS. It's ac- It's very cheap now. It was a problem like uh maybe 3 4 years ago when gas was unstable, but after EIP 1559 gas got very stable, and

there there have been uh consequent network upgrades, which made it basically very predictable of how much gas costs. So, yeah, it's actually not very ex- like for example, I have a safe with like 15 bucks on it and I've been using it for my website for like 2 years and I haven't even spent like 2 bucks. So, yeah, uh it's Yeah, I would say the the major costs are not from the updating the ENS are but from storage. Like you either pay an IPFS cloud service for some subscription or if it's on Swarm, you pay the with the BZZ tokens, so it around like a buck maybe two. So, yeah, that's where most of the costs come come from, not from ENS. ENS is actually the cheapest component of them all.

>> Thank you. Do we have any more questions? Okay, if not, thank you for a speech. Let's say thank you to the our author again and >> [music]