WEBVTT 00:00.000 --> 00:11.240 One before last speaker of the day, Michele will be talking about how to figure out if 00:11.240 --> 00:17.720 you're so far as updates by sorting this data in DLS and getting it from there. 00:17.720 --> 00:18.720 Yes. 00:18.720 --> 00:19.720 So great. 00:19.720 --> 00:20.720 So many people are here. 00:20.720 --> 00:24.960 It's mentioned my name is Michele Kin, and from the Netherlands, I mostly go developer 00:24.960 --> 00:29.960 and most of today's talk relates mostly to the Go Software ecosystem. 00:30.080 --> 00:32.520 I've an open source project called Mox. 00:32.520 --> 00:38.760 It's a modern, all-in-one email server that the aim is to make it really easy to install 00:38.760 --> 00:41.840 and maintain your mail server, including getting it updated. 00:41.840 --> 00:45.040 So that's how I got into this topic. 00:45.040 --> 00:47.280 So today's agenda, two parts. 00:47.280 --> 00:53.040 Part one is actually about this using DLS to find, to discover that updates are available. 00:53.040 --> 00:57.320 So first, doing it manually, and then I found a way to automate this for all the go software 00:57.320 --> 01:01.800 out there, and then part two is taking it to a next level, so that only finding the updates 01:01.800 --> 01:09.400 will also actually upgrading your services to run with the latest version of the application 01:09.400 --> 01:16.600 and also automatically compiling binaries, so you can actually get those latest software 01:16.600 --> 01:17.600 deployed. 01:17.600 --> 01:24.280 So let's start with the manual updates through DLS, so in Mox, there's an option, and 01:24.280 --> 01:30.480 I urge always admins to enable it, that will check every 24 hours to see if there is 01:30.480 --> 01:31.480 an update available. 01:31.480 --> 01:37.960 So that's this endpoint, underscore updates at XMox.nl, if you create it, you get essentially 01:37.960 --> 01:43.200 the latest version back, and if there's a new version available, and Mox compares it, if there's 01:43.200 --> 01:46.880 a new version available, Mox creates an enomestate, and delivers it to the postmaster 01:46.880 --> 01:51.160 mailbox, and then the postmaster, the admin, can update the installation. 01:51.160 --> 01:57.800 So that means when I do an release of Mox, I update the DNS record. 01:57.800 --> 01:58.800 So that'll work. 01:58.800 --> 02:03.680 Now I think the DNS is a pretty good fit to do these kinds of checks, because it's very 02:03.680 --> 02:08.680 low overhead, it's just a little bit packet, and that is a funds back, and of course DNS 02:08.680 --> 02:13.560 provides the caching redundancy with another service, and what I like especially is that 02:13.560 --> 02:18.360 it's not so easy to track, which installations are out there, because the Mox instances 02:18.360 --> 02:24.280 will likely go through a network recursive resolver, and that can be many machines behind 02:24.280 --> 02:26.280 one resolver. 02:26.280 --> 02:30.680 You can do other stuff, it's the PS request, but then it's more overhead, and it's more 02:30.680 --> 02:32.920 centralized, you get more options for tracking. 02:32.920 --> 02:37.880 I don't like being tracked, I don't like making software, and that makes it easy to track. 02:37.880 --> 02:43.960 Now then I figured out, there's a way to automate this for all the goes software ecosystems. 02:43.960 --> 02:47.440 So there's a lot of text on this slide, I want to have this with point nine point, but 02:47.520 --> 02:53.360 I just tried to explain this, so all of those software is in a transparency log. 02:53.360 --> 02:59.640 So we know that transparency log is a few people, we've heard about certificates transparency, 02:59.640 --> 03:04.520 much more people, so certificates transparency is essentially a transparency log with all 03:04.520 --> 03:06.480 the T-less certificates that have been issued. 03:06.480 --> 03:12.080 So you can monitor that and see if your domain is in there and you didn't expect it. 03:12.160 --> 03:17.600 The transparency logs are append-only logs, and you can cryptographically verify the 03:17.600 --> 03:21.040 entries that are in there, and you can verify that it's actually append-only, that it's 03:21.040 --> 03:22.040 working correctly. 03:22.040 --> 03:27.800 So for go, the go ecosystem has a transparency log called a go-sum database, and all the 03:27.800 --> 03:34.120 go software, both applications and libraries are in the transparency log. 03:34.120 --> 03:41.880 Okay, something I want to mention, go software is identified by a go module path, so 03:41.880 --> 03:46.760 they're packaged in so-called modules and they have a path, and you can have multiple versions 03:46.760 --> 03:53.040 and there's semantic versions, and the transparency log also contains the hash of the source code. 03:53.040 --> 03:57.240 So it's used for supply change security. 03:57.240 --> 04:02.240 If you want to release your new go module version, you make a get tag and you push it or another 04:02.240 --> 04:06.520 version console system, but it's the most popular one, and you push it and then it gets 04:06.520 --> 04:09.480 discovered and added to the transparency log. 04:09.480 --> 04:13.360 Now the thing was, I already had the surface code go for watch.org, it was already monitoring 04:13.360 --> 04:19.200 the transparency log, so it's a pent-only ledger, and you can just follow it, and I was already 04:19.200 --> 04:22.040 putting all those entries in a database for easy lookup. 04:22.040 --> 04:28.000 So to automate the DNS records for all these go applications, I just needed to add the 04:28.000 --> 04:31.200 DNS server to go for watch. 04:31.200 --> 04:37.240 Now here's an example of creating the same application of mine, through DNS, now you 04:37.240 --> 04:43.160 have a bit of a longer name, DNS name to look up, so essentially it's go for watch 04:43.160 --> 04:48.600 log at the website, then L is the delegation to go for watch application instance, V0 is 04:48.600 --> 04:55.120 the versioning ID, so if I want to change the responses and the format of the left part, 04:55.120 --> 05:01.040 I can just make a V1, so that thing, that's a go module path, we call it, but it's 05:01.040 --> 05:08.240 actually more like a URL with a host name and a path, so I just put the original host of 05:08.240 --> 05:12.760 the URL in there, then a bare underscore to the limit, the host part from the path, and 05:12.760 --> 05:19.000 then there's the split path elements with the special dash there at the end, which is 05:19.000 --> 05:25.640 kind of a special encoded with an underscore in the access, that's more value of the 05:25.640 --> 05:31.480 S key value, and that is more, so this whole thing, if you look that up, you get the same 05:31.480 --> 05:37.120 information back, the latest version is 0.015, and there's also timestamp, access, the time 05:37.120 --> 05:41.160 it was discovered in the transparency log, so when it was published, you can use that to 05:41.160 --> 05:45.280 delay your updates a bit, we'll get to that later. 05:45.280 --> 05:49.160 There's also the go tool change, so new compilers and standard libraries are also in this 05:49.160 --> 05:54.000 transparency log, so you can also query that, you've got multiple semi-colon separated 05:54.000 --> 05:58.080 values, there's the current latest release, then there's the previous release, the go 05:58.080 --> 06:02.880 has released every six months, and two releases are essentially kept up to date with 06:02.880 --> 06:06.480 patch versions, and there's also a third one that's the release kind of that will be the 06:06.480 --> 06:11.040 next version, so you can also query that. 06:11.040 --> 06:17.000 Then, this go for what's DNS server, it's built with this great library, mini g slash 06:17.000 --> 06:24.040 DNS, it makes it easy, just keeps me DNS superpowers and go, adding the DNS server 06:24.040 --> 06:28.000 to go for what was less than 1000 lines of code, and one third of that was parsing configuration 06:28.000 --> 06:31.720 file in cryptographic keys, because it also includes DNS sec with online signing and 06:31.720 --> 06:39.720 compact the null of existence, so there's like 600 code handling, a UDP request, TCP connections, 06:39.720 --> 06:46.920 and handling the right messaging, ED and SDR, all that stuff, so this is, I think it 06:46.920 --> 06:50.880 really nice about these libraries and programming nowadays, with the go ecosystem, it's 06:50.880 --> 06:58.120 not easy to pull in these libraries, and so be safe, feel safe, and doing that, and just adding 06:58.120 --> 07:03.000 all this functionality to an existing application, now you may wonder how, how actually 07:03.000 --> 07:07.400 does this transparency log, because some database get filled with all these modules, with 07:07.480 --> 07:11.960 all these applications, well the go tool change, so the go compiler, that all the developers 07:11.960 --> 07:17.920 use, they essentially go through, they ensure that these entries get added, when you use 07:17.920 --> 07:22.080 them in your application, so when you install a go application, you'll usually install 07:22.080 --> 07:28.360 the latest version, and you'll go, if a compiler will go for the go module proxy, that's 07:28.360 --> 07:33.280 something the go team runs, and that will resolve the latest once in a while, by going 07:33.280 --> 07:37.840 to get, seeing if there's new get tags, and if it finds new ones, it downloads the code, 07:37.840 --> 07:42.640 and it adds this hash to the transparency log, and the same happens where you use an external 07:42.640 --> 07:47.440 library for the first time, by the way, you get the latest, that's resolved, and the new 07:47.440 --> 07:52.960 entries automatically get added to transparency log, so it's pretty much like always up to date. 07:52.960 --> 07:58.000 Then, go for what, so the DNS there's not that, not yet done, so actually I only have 07:58.000 --> 08:02.680 one instance, so I want to get this redundancy, need to run another go for what instance, 08:02.680 --> 08:07.240 it's very easy, just a static go binary, and it'll run, but haven't gone around to it yet, 08:07.240 --> 08:11.720 I also want to test or first somehow this DNS message handling that I've implemented, so 08:11.720 --> 08:16.120 I'm sure that I didn't get everything 100% right, so if anyone knows, test suite, that 08:16.120 --> 08:22.920 I can run against this, let me know, and then I may also want to change these responses, 08:22.920 --> 08:27.960 so currently they're just very small text responses that you get from the DNS server, but 08:28.040 --> 08:33.000 I could actually include this transparency log proofs in there, so that you can, you can 08:33.000 --> 08:39.960 apply into doing these requests for itself, verify that these entries are actually in the transparency 08:39.960 --> 08:44.760 log instead of having to trust the go for what's a service, but there's, it gets a bit complicated, 08:44.760 --> 08:50.040 there's also new stuff coming out within the transparency log scene called something called 08:50.040 --> 08:54.120 verifiable indexes, and that allows you to actually check that this is indeed the latest entry, 08:54.120 --> 08:59.560 not just I'm entry that's in the transparency log, but actually the latest one, but that gets 08:59.560 --> 09:07.160 complicated quickly. All right, that was the DNS screening part, now we're taking it one step further 09:07.160 --> 09:11.720 with automating upgrades of the software, so I've got this separate tool called iSCO, 09:12.600 --> 09:16.680 that allows you that will upgrade to your software for you, you'll go services, 09:17.720 --> 09:22.600 and it uses this other service that the builds go builds.org, that will create binaries on 09:22.600 --> 09:30.520 demands from the source code. So, automating upgrades with iSCO, so instead of running your 09:30.520 --> 09:35.240 those service directly yourself in your system D file or your RST script or whatnot, 09:35.240 --> 09:41.720 you make iSCO start that, so it's like a supervisor demon kind of thing, so it just starts the 09:41.720 --> 09:46.680 application, but it also at the same time starts monitoring the go for what's DNS endpoint for updates, 09:47.560 --> 09:51.240 and when it finds an update, so that's the querying every 24 hours, it also queries 09:51.240 --> 09:57.080 for new go tool chains, so in go binders are statically linked, so if there's a security fixed 09:57.080 --> 10:01.880 to the go compiler and instead of library, you want to update your application to include that fix, 10:01.880 --> 10:07.000 and the go standard library is large, it has its piece server, et cetera, so many applications 10:07.000 --> 10:13.000 use that, so you do want to get updates into your application. So once it's found an update, 10:13.000 --> 10:19.480 it can upgrade by downloading a new binary, terminating the existing process, and restarting 10:19.560 --> 10:25.400 the application with a new binary, it's just simple as that. Now, iSCO can do that just with one click, 10:25.400 --> 10:31.000 so as the admin is the one click to do the update, iSCO is a small web interface, we'll look at 10:31.000 --> 10:40.680 the screenshot in a moment, so you can there's also Prometheus metrics in iSCO, so you can 10:40.680 --> 10:45.720 get an alerts when there's an update available, but you can also just have iSCO completely automatically 10:46.280 --> 10:52.040 do the upgrade. Usually, i delayed a little bit, so if there's a release, i'll wait two days 10:52.040 --> 10:57.080 to do the automatic upgrade, because you have to maybe a quick release after to fix some last 10:57.080 --> 11:03.000 minute bugs that were found, they can set a policy of what to update, so maybe only one to update 11:03.000 --> 11:08.680 patch versions automatically, and do the other ones, the minor version updates manually, 11:10.680 --> 11:14.840 there's some more policies, but it gets complicated, or i don't have time to explain it, 11:15.320 --> 11:19.960 and you can also set a schedule that you only want updates, automatic upgrades during working 11:19.960 --> 11:25.960 hours or outside working hours, so just to make sure you don't get broken stuff where you're not 11:25.960 --> 11:30.280 available, so the great thing about this approach is that no modifications to go applications 11:30.280 --> 11:35.000 necessary, this works for all the most go applications, there's a little caveat about 11:35.000 --> 11:39.000 which go applications it wouldn't work for, but again, bit too much detail. 11:45.800 --> 11:52.120 This is screenshot of the web interface, at the top you can check for updates now, 11:52.120 --> 11:55.800 so after i do a git push of a new version of my own code, and i want to upgrade my 11:55.800 --> 12:02.040 other services, i click that, and i got a sometimes update scheduled, you can select a different 12:02.040 --> 12:05.480 version and different go tool chain to build with and just hit the button, and it will 12:06.120 --> 12:10.520 get a new binary in update at all, that long version is like a pre release version, 12:10.600 --> 12:17.240 essentially just for a specific git commit tag, so when i do commit due development, 12:17.240 --> 12:21.720 i can also easily update my development environment for a specific git tag. 12:21.720 --> 12:26.200 At the bottom, you can see that ice code itself is also managed this way, it has a version, 12:26.200 --> 12:30.120 and it goes tools in that it's compiled with, and it can also update itself, get a new binary, 12:30.120 --> 12:35.560 re-execate itself, so it doesn't have any downtime. So everything stays up to date, 12:35.640 --> 12:44.360 automatically with this, then the go build to talk service, it compiles source code on demand, 12:48.040 --> 12:53.480 so when there's a new git tag pushed in the ecosystem and discovered, you want to binary with 12:53.480 --> 12:59.400 that for that source code, what you get to binary from, some projects that publish binaries, but 12:59.400 --> 13:04.360 usually don't really release them when there's no new go tool chain, so you've got binaries, 13:04.360 --> 13:09.160 maybe provided by a project, but only with old tool chains build, so now you can always get 13:09.160 --> 13:13.960 a fresh binary, so the source code that's download is fairified with this, and it goes some database, 13:13.960 --> 13:19.720 the transparency log, so let's how you know that go build is using the correct source code that 13:19.720 --> 13:26.200 everyone else is seeing, the service also automatically downloads and fairifies go new go tool chains 13:26.200 --> 13:32.360 when they release, the cool thing about go is that it allows you to cross compile for any operating system 13:32.360 --> 13:39.080 architecture, so that makes it much easier to provide this service for the entire go ecosystem. 13:40.120 --> 13:45.960 In Go, your builds are reproducible, so you get byte for byte, the same output, the same binary, 13:45.960 --> 13:50.920 so you can verify that this is working as intended and you're not getting some different binary, 13:50.920 --> 13:55.160 and effects go builds has two machines, different architectures are different set up, 13:55.960 --> 14:00.840 the build same thing, and go build checks if the output is indeed the same, and when that's the case, 14:01.400 --> 14:06.680 it adds the hash of the binary to its transparency log of its own, so for transparency, 14:06.680 --> 14:11.480 so we can verify that the binary you're getting is sort of publicly vouched for, 14:11.480 --> 14:15.560 and you could monitor this transparency log and also verify that these builds are indeed 14:16.920 --> 14:23.080 correct, that you get the correct binary, so this adds trust, and this, just otherwise, 14:23.080 --> 14:29.320 I would be hesitant to download binaries from the internet and start running them on my service, 14:29.400 --> 14:34.120 but this way you can verify that it's the correct binary as expected. 14:34.840 --> 14:40.120 So another cool part that next to me at ease in doing this is that the Go tool chain, 14:40.120 --> 14:46.520 when you compile code, it only runs its own compiler code, it doesn't run any code of the project 14:46.520 --> 14:53.880 that it's compiling, so there's quite a bit less danger in compiling random codes that you find 14:53.880 --> 15:00.920 on the internet. Now, how are we doing in time? I was just about to put up the tenant. 15:00.920 --> 15:07.160 Okay, oh, well, then you've time, probably if we got half of the stuff I wanted to say, 15:07.960 --> 15:12.280 do we have a browser? Yeah, we do. Now we can look at this Go build service for a moment, 15:14.040 --> 15:18.520 so it's just a website. Can I make it a bit smaller, you need a bigger? Yeah, I can. 15:19.240 --> 15:23.000 Yeah, there you go. No, no, that's not it. 15:23.000 --> 15:31.400 Which green thing? Green thing, then I'm going. Yeah. All right, so here you can see some recent builds. 15:32.440 --> 15:38.120 So one of the problems I'm having at the moment, AI scrapers, they scrape the website, they follow 15:38.120 --> 15:44.760 all the links, and they build all kinds of stuff. They're hard to block. I don't like them. 15:44.840 --> 15:51.960 My phone is lighting up too much now, but let's see, I'll just click one of these, 15:51.960 --> 15:56.840 which is all all stuff. Anyway, you can you can see from the URL also, 15:59.400 --> 16:03.400 can see from the URL what what this is, right? This is a specific application. This is the 16:03.400 --> 16:10.600 Go build service itself, specific version created for highlighters, created for a freebiesd, 16:10.600 --> 16:16.280 AMD 64 with a certain tool chain, and this thing here at the end is the hash of the binary, 16:16.280 --> 16:23.560 so you can send links to people. They can download the binary from here, then you don't get 16:23.560 --> 16:29.400 the advantage of having yourself verifying that this binary is in the transparency log, 16:29.400 --> 16:33.400 but it's still useful service. So for my Go project, I don't provide binaries at all, 16:33.400 --> 16:38.200 anymore, it just points to this service, and people can just automatically download the latest Go 16:38.280 --> 16:44.200 binaries at the time. So that's there. You can, you can, in fact, download it with this 16:44.200 --> 16:48.600 Go build command line tool and verify that's the correct sum. You can also reproduce this 16:48.600 --> 16:54.360 build locally, so this is what Go build is running. If you do that yourself, and you verify, 16:55.560 --> 16:59.080 you can verify that it's the correct. See, there's a snippet here that it's 17:00.520 --> 17:05.240 this Unreal will. It has a Python snippet, so you can verify that the hash is correct. 17:06.040 --> 17:09.800 And here at the bottom, so these are the links that these AI scrapes are following, 17:09.800 --> 17:15.560 because you can get any module version for any supported operating system architecture, for any 17:15.560 --> 17:23.400 Go compiler, and the default build or strips build with the debugging signals. Let me see if this works 17:23.400 --> 17:33.400 if I know. No, no space left on device. Yeah. This is, this is something I have to fix soon. 17:35.240 --> 17:41.560 Let me get back to slides. Yeah, so this is already getting to the end. The summary is, 17:43.480 --> 17:47.960 I can get for any Go application, one click, or fully automated upgrades. 17:49.320 --> 17:53.480 Without changes to the application, and DNS is helping me discover these at a very low overhead 17:53.480 --> 18:01.640 cost. Isco is the supervisor service that does that, and Go build is giving me the binaries. 18:02.600 --> 18:07.640 Then, one more slide with all the source code. Of course, this is open source. You can run it yourself. 18:07.640 --> 18:14.360 It's pretty easy. And here is a blockbout with some more details about ice going, what it means. 18:15.000 --> 18:19.240 You know, if it's a good idea to do this at all, it raises some questions. 18:19.960 --> 18:24.680 So if you're interested in this, please read that and contact me by email. 18:26.040 --> 18:30.920 So that's it for now. Yeah, well, this is was quick. Thanks. 18:31.800 --> 18:33.800 Thank you. 18:37.800 --> 18:39.800 Any questions from us here? 18:39.800 --> 18:41.800 There's a question. 18:43.640 --> 18:47.640 So questions, how do I handle low names? You mean DNS, like a packet names? 18:49.480 --> 18:55.880 Yeah, so how do I handle low module names? I don't. So if you have, if you think, it's a wise 18:55.880 --> 19:01.080 idea to have a really long project name, then you cannot query it's over DNS, and it's 19:01.160 --> 19:08.440 just, to be honest, yeah, the query will just never come in, right? Because if the query 19:08.440 --> 19:13.160 would come in, I would answer it, but DNS will not allow it. So yeah, that's, so do you have, by any 19:13.160 --> 19:22.760 chance, long, if we just say, like, more, not a question. 19:23.720 --> 19:31.800 All right, let me add, actually. So I've recently built something like this, and on top of that, 19:31.800 --> 19:37.960 you're just not leaking what's installed on the machine. So I do have a solution for that, 19:37.960 --> 19:43.720 you're using lip-soluble and encoding it with several public key. So I'll, all right, yeah. 19:43.720 --> 19:45.160 Oh, interesting. 19:45.160 --> 19:50.840 Do you do the origin one? Because it's very lightweight. Yeah. I also need to add, like, 19:50.920 --> 19:57.400 replay production, and stuff like this. So if I understand correctly, you say, I'm leaking that, 19:57.400 --> 20:01.960 by doing this DNS requests, I'm leaking what I'm, I had installed, because I'm asking for a certain 20:01.960 --> 20:07.480 version. Yeah, so the thing is, the solution, and I have the solutions, though. Yeah, yeah, yeah, 20:07.480 --> 20:18.920 yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, 20:18.920 --> 20:23.000 it's so much to do list for having a, for, for the redundancy. And it's very, it's very simple. 20:23.000 --> 20:27.560 This go, this go for what's thing, it's just a static binary can run it. It doesn't, 20:27.560 --> 20:31.320 it doesn't need much, it just needs incoming GDP requests. But yeah, I need to set up a machine, 20:31.320 --> 20:36.840 and run it, and time is limited. Yeah. One more question? 20:36.840 --> 20:41.240 Is it possible to distinguish between the security and the structure of things? 20:42.280 --> 20:45.080 Is it possible, all the questions? Is it possible to distinguish between security, 20:45.160 --> 20:51.000 feature updates and security updates? And no, I don't think, not really, 20:51.000 --> 20:59.880 but you can assume that patch updates of go applications are security updates, maybe. 21:01.880 --> 21:08.600 I can have, there's no meta information about a release of whether it is a security 21:08.680 --> 21:14.520 release or a feature release. Except that go applications are supposed to, I mean, 21:15.800 --> 21:20.840 so, be semantic recursion, but do developers actually do that and practice not always, 21:21.640 --> 21:28.440 so there's no way to really know for sure. So if, if I'm, I'm using high school to deploy a specific 21:28.440 --> 21:33.000 application that I'm using, I can check, I kind of know what the developers are doing. So maybe 21:33.080 --> 21:38.840 I know that some applications are safe to do patch updates and assume that they will do a patch 21:38.840 --> 21:43.400 update of their security release, but there's no guarantee that that's the case. 21:44.840 --> 21:51.320 So yeah, the answer to the question? Yes, so I understand now, because the meta data is not there, 21:51.320 --> 21:58.120 you cannot provide that. Indeed, so there's in the go binary, there's the go module path, 21:58.120 --> 22:02.280 so this identified as a version, and they go to the version that it's built with, 22:02.360 --> 22:07.160 but there's no information, and also I kind of, I don't think there's a public place, 22:07.160 --> 22:12.040 and maybe there's a maybe, maybe I could go to some place and see if there's an automated 22:12.040 --> 22:20.200 way to get security vulnerability. Probably there is, maybe, maybe I should look into that. Good question. 22:23.000 --> 22:27.240 Yeah, so is anyone, would anyone, like, happily run this, or do you think it's a bit scary? 22:27.240 --> 22:32.040 Yeah, as a bit scary. Yeah, a bit scary, yeah, why is it scary? 22:48.040 --> 22:52.040 But you're, so you're afraid, so you're afraid, essentially, that I'm leaking with applications, 22:52.040 --> 22:55.320 I'm running on a network, even though it's behind the recursive resolver. 22:57.240 --> 23:07.560 Yeah, and what are your fate of then? What would, what would it attack me? 23:07.560 --> 23:13.640 Yeah, but you're running on an untrusted network. 23:13.640 --> 23:19.640 Yeah, so the fake answer you could send is, well, this data's exciting, right? 23:19.640 --> 23:26.680 So you could, no, no, so I'm sure, no indeed, so you have to trust the resolver, 23:26.680 --> 23:32.120 but I don't, many people would trust, I think, the resolver, but maybe not. 23:33.160 --> 23:37.960 But then with this, that's why I had this idea of adding this transparency of proofs to the responses, 23:38.600 --> 23:42.440 but then still the attack could be just to drop all those DNS requests and then you never update. 23:42.440 --> 23:45.880 So if there's a security update that you would get, one to get, you're not getting it. 23:45.880 --> 23:50.440 Of course, if you're so security conscious, maybe you also want to monitor and manually deploy your 23:50.440 --> 23:55.080 applications anyway. For me, I'm using this more as a convenience way, because I noticed that I'm running 23:55.160 --> 24:01.000 all by myself, I currently running 35 internal services, not very important, although also my 24:01.000 --> 24:04.760 mill service updated this way and go watch and go build their all updated this way. 24:06.360 --> 24:10.280 It's just very convenient to stay on the latest go build, because otherwise I have to 24:10.280 --> 24:14.680 set up, I guess this is what you do for your serious applications. You do set up a CICD pipeline, 24:15.720 --> 24:21.160 lots of YAML, build everything, deploy everything, blah, blah, blah, and so I noticed I'm not doing 24:21.160 --> 24:26.840 that. Of course, I'm using my own software, but this is for me a way to stay at least up to date with 24:26.840 --> 24:32.360 the latest security fixes also in the standard library of go. So when I would be afraid of more, 24:32.360 --> 24:36.760 I would suggest, I would expect someone to say that you're running, I'm running application, 24:36.760 --> 24:41.880 that I've not been running the test suite, because I just built the code as published. 24:41.880 --> 24:48.760 I'm not, but that's why I wait two days, so, before I deploy it, it's like, if something is wrong, 24:48.840 --> 24:52.840 I would probably hear it by, see it somewhere by then, and then maybe there's any release by then. 24:52.840 --> 24:55.960 There's not a question behind the back. Come in. 24:55.960 --> 25:01.160 You're the ask queries, but then to create the fingerprint. It makes me, makes it possible to be 25:02.440 --> 25:08.760 to track the behavior of that system. So, yeah. And this is for all the software applications, 25:08.760 --> 25:14.760 if they're timely, you typically have a number of applications that ask CICD to leave, 25:14.760 --> 25:19.400 or update information, and that will provide a fingerprint from which I can track you. 25:20.600 --> 25:26.600 Yeah, track, you can use this, these Dnesia requests to track what is installed and what's happening. 25:26.600 --> 25:31.000 I call the other genus, so I can correlate your fingerprint. 25:31.000 --> 25:33.400 Yeah, all the other genus queries are in the lab system. 25:33.400 --> 25:35.960 Yeah, yeah, that's correct, yeah. 25:35.960 --> 25:40.840 No, I would have not expected that to be sort of a concern for people that's tracking. 25:40.840 --> 25:42.840 Yeah, yeah, okay, interesting. Thanks. 25:42.840 --> 25:45.800 All right, thank you, Miguel.