WEBVTT 00:00.000 --> 00:11.000 So, welcome to the last session of the Secure to the Room. 00:11.000 --> 00:18.000 Let me introduce Fredrik Skogman with his talk on enhancing up-to-flexicular activities 00:18.000 --> 00:21.000 to get up at the stations. 00:21.000 --> 00:22.000 Thank you. 00:22.000 --> 00:24.000 So, yeah, my name is Fredrik Skogman. 00:24.000 --> 00:29.000 I work at GitHub, and my team is primarily focusing on supply chain security, 00:29.000 --> 00:33.000 active maintainer in a lot of open-source security related things like 00:33.000 --> 00:35.000 six-door and update framework. 00:35.000 --> 00:37.000 And also, thank you very much for coming. 00:37.000 --> 00:38.000 I know it's super late. 00:38.000 --> 00:39.000 You are probably tired. 00:39.000 --> 00:40.000 I'm tired. 00:40.000 --> 00:44.000 So, I will run, try to run this as fast as I can. 00:44.000 --> 00:45.000 Speak up. 00:45.000 --> 00:47.000 I will. 00:47.000 --> 00:49.000 Oh, sorry. 00:49.000 --> 00:50.000 Oh, just sorry. 00:50.000 --> 00:54.000 This is on me. 00:54.000 --> 00:57.000 There we go. 00:57.000 --> 01:01.000 So, yeah, I would like to talk about artifact adaptations. 01:01.000 --> 01:05.000 So, this is a feature that fairly recently out. 01:05.000 --> 01:10.000 So, it allows you to provide a way to guarantee integrity from the build step 01:10.000 --> 01:14.000 to the library for everything that's built on GitHub actions. 01:14.000 --> 01:19.000 This way, we like to offer a very simple way to sign all this open-source stuff 01:19.000 --> 01:20.000 that you're building. 01:20.000 --> 01:25.000 So, it's been around since summer of 2024, 01:25.000 --> 01:30.000 and the work started in 2022 when we were doing a similar way for open-source 01:30.000 --> 01:35.000 NPM packages to provide signed build provenance for everything that's built on a 01:35.000 --> 01:37.000 width for NPM. 01:37.000 --> 01:40.000 And, of course, it's free for open-source to use. 01:40.000 --> 01:42.000 So, I encourage everyone to use it. 01:42.000 --> 01:44.000 And, early doctors include home brew. 01:44.000 --> 01:47.000 So, huge thanks to William, previous presenters. 01:47.000 --> 01:51.000 So, they've been working very hard with us to try it out and make it working. 01:51.000 --> 01:57.000 And, I'm super excited that all bottles on from brew are now signed and built with provenance. 01:57.000 --> 02:03.000 Although the home brew is still in beta, so we're working on them to kind of clear out 02:03.000 --> 02:09.000 a few issues that they're experienced to go full GA. 02:09.000 --> 02:14.000 So, to kind of describe the problem, we like to start a little bit with sort of 02:14.000 --> 02:16.000 typical signing how it happens. 02:16.000 --> 02:18.000 Like, you have a typical build pipeline. 02:18.000 --> 02:21.000 You build something from source code repository. 02:21.000 --> 02:26.000 You put it into the registry, the registry sign set, and then the user can download it from the 02:26.000 --> 02:30.000 registry, and they can verify it hasn't been tempered away from the registry. 02:30.000 --> 02:34.000 The problem is, what went into the registry in the first place? 02:34.000 --> 02:35.000 It's very hard to tell. 02:35.000 --> 02:38.000 You just know that it was signed by the registry, but was it a release? 02:38.000 --> 02:39.000 Was it a dev build? 02:39.000 --> 02:40.000 We don't really know. 02:40.000 --> 02:44.000 Maybe it was a malicious artifact being put in the first place. 02:44.000 --> 02:49.000 And basically, we're lacking some context of the artifacts when it comes from the registry. 02:49.000 --> 02:54.000 You can try to solve it by pushing signer, signing sort of further to the left. 02:54.000 --> 03:00.000 But given a lot of the solutions out there, like, it creates a problem around managing the PKI. 03:00.000 --> 03:05.000 Like, it's kind of complicated and not all open source projects have the resources to 03:05.000 --> 03:07.000 run like a fully complete PKI system. 03:07.000 --> 03:11.000 So, that's kind of what we are trying to simplify with this. 03:12.000 --> 03:16.000 So, with artifact that is stations, when you're building something in the action, 03:16.000 --> 03:19.000 it's signed automatically by the system. 03:19.000 --> 03:21.000 And it's not just signed. 03:21.000 --> 03:26.000 It also extracts a lot of metadata around the build, like, which repository was it coming from, 03:26.000 --> 03:29.000 what are the commit ID, and so on. 03:29.000 --> 03:34.000 So, basically, we're capturing the context around the build, and we add that. 03:34.000 --> 03:37.000 We are also including, like, exact build run. 03:37.000 --> 03:45.000 We're creating, like, a paper trail tracing, this specific artifact back to a specific workflow run. 03:45.000 --> 03:50.000 So, with part of this, we are hosting an entire PKI platform. 03:50.000 --> 03:55.000 And we're also doing it by relying on workload identities instead of, like, human identities. 03:55.000 --> 04:02.000 So, that gives us a way to kind of simplify the policy processing around it. 04:02.000 --> 04:06.000 And the great thing about it is that, from a developer perspective, you don't need to manage. 04:06.000 --> 04:11.000 You don't need to manage any key material at all, like, everything happens automatically by the system, 04:11.000 --> 04:14.000 which I will of course describe. 04:14.000 --> 04:16.000 So, rough. 04:16.000 --> 04:18.000 Yep. 04:18.000 --> 04:21.000 Please wait, if possible. 04:21.000 --> 04:22.000 Yep. 04:22.000 --> 04:24.000 I will get side track otherwise. 04:24.000 --> 04:25.000 We'll get what to say. 04:25.000 --> 04:26.000 Yeah. 04:26.000 --> 04:31.000 Some of the components, like, we have the actions, of course, that you can use in your workflow. 04:31.000 --> 04:33.000 We have a CA and a PKI. 04:33.000 --> 04:37.000 And now the station store to capture the metadata that's generated during the build. 04:37.000 --> 04:42.000 Then we have the GitHub CLI that can be used to run policies around the artifact. 04:42.000 --> 04:47.000 And then there's an integration with the policy controller from six store, which is a Kubernetes, 04:47.000 --> 04:48.000 a mission controller. 04:48.000 --> 04:55.000 So, you can use the same thing to secure your workloads in, in, like, Kubernetes way. 04:55.000 --> 05:02.000 So, everything, almost everything is done fully open source, like, we want to meet the community where it is. 05:02.000 --> 05:06.000 So, we avoid to, you know, build and custom things that only work with what we're doing. 05:06.000 --> 05:13.000 So, we're, teaming up, we're much with six store, salsa, internal, and tough. 05:13.000 --> 05:21.000 So, a quick introduction is that six store is an open source project that aims to simplify signing and verification for everything. 05:21.000 --> 05:28.000 And, according to the six or project, they're trying to be, like, the lesson script for digital signatures. 05:28.000 --> 05:36.000 And it, we're interesting with six store is that it's not just, uh, a lot of source code repositories that you can use. 05:36.000 --> 05:43.000 Six store is also a public good instance that anyone can use, and my team are part of that operation as well. 05:43.000 --> 05:51.000 Like, we are wearing the picture for the public good six or instance to make sure it's operating as smooth as this can. 05:51.000 --> 05:59.000 And for describing the metadata around the builds, we are relying on something called salsa build provenance. 05:59.000 --> 06:03.000 And it's a standardized format for distributing metadata for builds. 06:03.000 --> 06:17.000 And to kind of ship them around and tie them to the specific artifact, we're using internal adaptations, which sort of create that link between a subject and some metadata were predicate as it's called in internal. 06:17.000 --> 06:24.000 And then we have the update framework, which is a framework for securing upgrades over untrusted channels. 06:24.000 --> 06:31.000 So, we are relying on that to manage the trust route, like the route certificates and public keys, etc. 06:31.000 --> 06:38.000 So, we're using it to manage it and to distribute it to the clients. 06:38.000 --> 06:49.000 So, a simple overview of the system is that when you're running a build during, if you're using adaptations or artifact adaptations. 06:49.000 --> 06:59.000 The system first collects the metadata required, like, as I mentioned, repository git commit, workflow run, the actual workflow file being used. 06:59.000 --> 07:06.000 It then extracts the identification token from the actions that uniquely identifies the build. 07:06.000 --> 07:12.000 And then we use that to request assigning certificate from focio. 07:12.000 --> 07:19.000 And then when you have the signing certificate, we can sign the provenance and we can put it in our adaptation store. 07:19.000 --> 07:24.000 And then clients can be adopted framework, get the latest version of the trust route. 07:25.000 --> 07:31.000 Fetch whatever adaptation they would like, because they might have a file and they can compute the digest and query our store. 07:31.000 --> 07:35.000 And then they will get all the matching adaptations for that. 07:35.000 --> 07:39.000 And then run whatever verification they would like to use. 07:39.000 --> 07:48.000 And it doesn't have to be in this case to get a client like it could be co-sign or basically any six-store client we work here. 07:48.000 --> 07:55.000 So, to avoid burden of relying developers, managing private keys. 07:55.000 --> 08:03.000 Six-store is heavily relying on something called the femoral keys or ambient tokens, or you might also have heard keyless signing, 08:03.000 --> 08:07.000 which is of course just a gimmick like keys or definitely used. 08:07.000 --> 08:17.000 So the way it works is that you create an in memory key per, and then you send a public key of that together with identity token describing who you are. 08:17.000 --> 08:26.000 To the CA, who then verifies identity token via Federation to the identity provider to make sure you're not lying. 08:26.000 --> 08:33.000 And then it creates a short-lived certificate that's only valid for 10 minutes, binds it to the public key and then sends it back. 08:33.000 --> 08:38.000 Then you can sign via that certificate. 08:38.000 --> 08:44.000 And because the certificate is only valid for 10 minutes, you need to think about something to simplify the verification, 08:44.000 --> 08:51.000 because you can rely on the typical certificate verification where the certificate has to be valid during the time you're very fine. 08:51.000 --> 08:57.000 So what we're doing here is that we either reach out to that time stamping a 40 or in the six-store public key of the instance, 08:57.000 --> 09:03.000 we are using a public append-only transparency log that also gives us a timestamp. 09:03.000 --> 09:09.000 So we can get a counter signature and then store that together with the original signature. 09:10.000 --> 09:17.000 And then when you're trying to verify this, you can verify the timestamp of the signature when it was made. 09:17.000 --> 09:23.000 And that way you can see like, okay, this signature was made during the time the certificate was valid. 09:23.000 --> 09:32.000 And this greatly improves the risk of a key compromise, because let's say someone manages to extract the key from the memory. 09:32.000 --> 09:37.000 It's very unlikely that they will do it like uncompromise the full attack within the 10 minute window. 09:39.000 --> 09:48.000 So yeah, the benefits of using the store here is like you get identity federation out of the box. 09:48.000 --> 09:53.000 So you have a system that kind of vouchers for your identity. 09:53.000 --> 09:56.000 You don't need to manage the keys. 09:56.000 --> 10:03.000 And especially for all the fact that the stations we rely on workload identities instead of human identities. 10:03.000 --> 10:08.000 So the identity is basically the organization repository and the workflow. 10:08.000 --> 10:14.000 So you don't need to understand like who is the maintainer of this package and something like that. 10:14.000 --> 10:18.000 You can look at where should this thing come from. 10:18.000 --> 10:21.000 We expected to come from this repository. 10:21.000 --> 10:28.000 So as I mentioned, six store operates one instance. 10:28.000 --> 10:31.000 At GitHub we operate a private instance. 10:31.000 --> 10:40.000 The public instance from six stores free for use for anyone, but you need to think that everything that's being signed is also put on a public transparency logs. 10:40.000 --> 10:44.000 If you have privacy concerns, it may not be the right place. 10:44.000 --> 10:50.000 The instance we are running at GitHub is completely compatible with the public goods. 10:50.000 --> 10:56.000 So every tooling that you have will work with both of these instances. 10:56.000 --> 10:59.000 So this also build provenance. 10:59.000 --> 11:04.000 So it's a JSON specification for the format capturing a lot of the metadata. 11:04.000 --> 11:13.000 As I mentioned, we have the basic stuff like repository owner and the exact workflow file that was being used. 11:13.000 --> 11:18.000 It also contains a reference to like the logo of the system like the build rug for action. 11:18.000 --> 11:25.000 And importantly, we also encode the numerical identifiers for the repository and the owner. 11:25.000 --> 11:35.000 So that's to make sure you can have a policy to protect against like rename attacks or resurrection attacks. 11:35.000 --> 11:42.000 You can of course browse that is stations in the web UI. 11:42.000 --> 11:50.000 And if you don't like looking at JSON data, you can have like a view that kind of summarized what's in the build provenance stock. 11:50.000 --> 11:55.000 And these are of course UX like it's continually hopefully being improved. 11:55.000 --> 11:58.000 It's definitely continually being changed. 11:58.000 --> 12:07.000 Right, so if six stories altered out there, there is a public instance that anyone can use why did we spend like a couple of years doing something on top of this. 12:07.000 --> 12:12.000 And it's to get a better experience for the developers. 12:12.000 --> 12:17.000 A six store is mostly concerned around signing and verification. 12:17.000 --> 12:20.000 Six store doesn't really know what the sales have been provenances. 12:20.000 --> 12:26.000 Six store does not provide a solution for storing or discovery of other stations. 12:26.000 --> 12:33.000 So those are the things that we have added on top of the existing six store components. 12:33.000 --> 12:36.000 Yes. 12:37.000 --> 12:41.000 So how to use it, it's pretty simple. 12:41.000 --> 12:50.000 If you're on get abactions, you need to add one more step that reference one of the various attest actions we are providing. 12:50.000 --> 12:58.000 In this case, it's a test build provenance and in this example, I'm a testing container image. 12:58.000 --> 13:03.000 And you can see here that also a parameter called push to registry true. 13:03.000 --> 13:12.000 And that means that when the build.grimmage is being pushed, we're also pushing the build attestation to the container registry. 13:12.000 --> 13:21.000 And the useful thing here is that if you're running let's say Kubernetes, you may not want to allow the cluster to communicate with like around or maybe I such as GitHub. 13:21.000 --> 13:25.000 So we're putting that station next to the image that you already have access to from the clusters. 13:25.000 --> 13:28.000 You can have tighter egress rules. 13:28.000 --> 13:33.000 And this action allows you to attest whatever file that's being produced. 13:33.000 --> 13:42.000 It doesn't have to be a container or a package or it can be basically an individual file like an espon, if you like. 13:42.000 --> 13:49.000 So for the verification side, which is the most important, like you should not sign if you're not verify, then you're not getting anything. 13:49.000 --> 13:57.000 So everything is compatible with cosine, which is sort of the go to CLI for six store. 13:57.000 --> 14:07.000 You can also use the GitHub CLI to verify, or as I said, like if you're running in Kubernetes, you can use the six store policy controller. 14:07.000 --> 14:13.000 So when thinking about signatures, I think it's very important to understand just because it sign doesn't mean that it's secure. 14:13.000 --> 14:20.000 What the only guarantee we're giving you is that we're giving you a paper trail that this artifact was created here. 14:20.000 --> 14:25.000 Safe to run, we can tell, we can only tell where it's coming from. 14:25.000 --> 14:36.000 And of course, you need to follow all the best practices on tightening up your build system, like William's presentation supergulence is more like very relevant technology to use. 14:36.000 --> 14:49.000 On GitHub, we have some solutions like you can rely on for instance code owners to separate who can modify the build instructions, or if you want to go for a real secure model, you can have our useful workflow. 14:49.000 --> 15:02.000 The salsa community provides a builder for most of the ecosystems out there, like go Java, that builds the binary for you, creates the build provenance and signs it for you. 15:02.000 --> 15:14.000 And the benefit here is that you get that complete separation of concerns, because the salsa builder is in the salsa org, like typical developer doesn't have right access and can modify the building instructions. 15:14.000 --> 15:22.000 So that's very useful for a lot of people to kind of make sure that developers can write the code that they can't modify how it's built. 15:22.000 --> 15:30.000 And we'd reusable workflows, you also get other benefits such as build isolation, the workflow is guaranteed to run a separate VM. 15:30.000 --> 15:40.000 So if you have, for instance, a place where you're running unit test, the test, my friends has modified the file system that can change the outcome of the build. 15:40.000 --> 15:43.000 So it's a real strong thing to use. 15:44.000 --> 15:56.000 Just when I just want to mention free recent attacks, like it's no grudge against this projects at all for me, it's just that they are very recent and they are very relevant. 15:57.000 --> 16:08.000 So in December last year, Solona Web3JS had an attack where someone got a hand on the published token to NPM. 16:08.000 --> 16:15.000 So they uploaded a malicious version that contained, I think it was like, cryptocurrency dealer, but it's not super relevant. 16:15.000 --> 16:22.000 But here, like, if they were using build provenance, you could just take that by modifying, so not modifying. 16:22.000 --> 16:31.000 But by modifying the artifact and see that, wait a minute, it doesn't have a build provenance or the build provenance has changed. 16:31.000 --> 16:37.000 It's coming from a different repository than it used to be and that is a strong signal that something may have happened. 16:38.000 --> 16:57.000 As William mentioned on the talk before this, ultroletics had an attack and in this case, the existence of build provenance proved to be very useful during the forensics because they can see what was the offending workflow that built this malicious artifact and approved like really strong during the forensics. 16:57.000 --> 17:08.000 And also, once the first malicious version were removed from the register, another one was published, and that one did not have build provenance. 17:08.000 --> 17:15.000 So if they were verifying the provenance, they will see that the second one didn't have one, which, as I said, like, it's suspicious signal. 17:16.000 --> 17:34.000 The third one is the same scenario as the first one, I just added it there to kind of show that this is a frequent pattern we're seeing like compromised tokens to register is a common way for people to upload bad packages and with build provenance, you can easily detect if that is happening. 17:34.000 --> 17:41.000 So it's getting late, so just going to run through some quick examples of how this can be used. 17:41.000 --> 17:57.000 In this case, it's readable, like, I'm just running the GH or the GitHub CLI to kind of verify that this container image is originating from in this case of specific repository. 17:57.000 --> 18:07.000 And when you run this, it kind of takes the digest of image, interacts with a station store, gets the matching administrations and verifies them. 18:07.000 --> 18:21.000 In and here we can see that we're getting information like yep, it's originating from the expected repository, and we can see a reference to the exact workflow file that was being used to create the sign it. 18:22.000 --> 18:24.000 Is this readable? 18:24.000 --> 18:32.000 The idea here is I just want to show how it can look like when you're using reusable workflows, so this build creates free artifacts. 18:32.000 --> 18:45.000 One does being built directly within the workflow, one creating the bug build via reusable workflow and the third one is a release build via another reusable workflow. 18:45.000 --> 18:54.000 Because the way you're thinking about signer identity changes a little bit with this. 18:54.000 --> 19:05.000 So the first one is the simplest one is just verifying that this file is originating from a specific repository and everything looks good. 19:05.000 --> 19:11.000 Second one, I'm looking at the bug artifact that was created by the debug reusable workflow. 19:11.000 --> 19:18.000 And if I try to verify this, we can see that it's failing, that is because the identity of the signer doesn't match the expected one. 19:18.000 --> 19:27.000 And this is because when you're using our reusable workflow, the signer's identity reference reusable workflow, not the originating repository. 19:27.000 --> 19:39.000 So to fix this, we need to be very explicit that the artifact has to resonate from one repository, but it should be signed by another repository. 19:39.000 --> 19:45.000 In this case, I'm just saying like it anywhere flow in this repository is good. 19:45.000 --> 19:56.000 If you try the same or if you try to verify with the release workflow for the debug, it's of course failing because that's not the workflow used. 19:56.000 --> 20:06.000 You're using the release artifact, of course passes. So this is just kind of showing that you need to think about the signer identity. 20:06.000 --> 20:13.000 And that is the last slide. Thank you very much. 20:14.000 --> 20:19.000 Thank you very much. 20:20.000 --> 20:22.000 What are you looking at? 20:22.000 --> 20:26.000 I have been a fan of Huffland also. 20:26.000 --> 20:29.000 By the way, it's a beautiful question. 20:29.000 --> 20:34.000 If you want pretty pictures, question list. 20:34.000 --> 20:35.000 Okay. 20:35.000 --> 20:37.000 Now I'm going to make some design for you. 20:37.000 --> 20:40.000 I can give you that mostly about what you're signing. 20:41.000 --> 20:46.000 For example, if I'm going to ask you a few questions, 20:46.000 --> 20:51.000 say that the action was something where I can never send to another account. 20:51.000 --> 20:57.000 So what did the any kind of checks into a not sign and probably another project? 20:57.000 --> 21:01.000 No, we currently, we don't care really what you're signing. 21:01.000 --> 21:03.000 We sign whatever you provide. 21:03.000 --> 21:07.000 So the question was around if we have checks from all of our things like that, and we don't. 21:07.000 --> 21:09.000 It's currently out of the scope. 21:09.000 --> 21:13.000 We're basically providing a link back to the workflow. 21:13.000 --> 21:15.000 So we don't introspect the binary at all. 21:15.000 --> 21:18.000 Like we sign what you provide to us. 21:29.000 --> 21:31.000 It's out of scope. 21:31.000 --> 21:36.000 I think it's different mitigation attack. 21:36.000 --> 21:38.000 To kind of introspect and look for binaries. 21:38.000 --> 21:44.000 And it goes way beyond signing and working with build provenance. 21:44.000 --> 21:46.000 Yep. 21:46.000 --> 22:00.000 So the question was around how do we try to mitigate and attack on the runner to extract the key? 22:00.000 --> 22:04.000 And currently, it's not really a problem. 22:04.000 --> 22:12.000 So the question was around how do we try to mitigate and attack on the runner to extract the key? 22:12.000 --> 22:19.000 And currently, it's not really something that's done beyond the capabilities already in action. 22:19.000 --> 22:26.000 And that is one way, for instance, to use our reusable workflow because you move to a new VM when you do the signing from the building. 22:26.000 --> 22:30.000 So that's the preferred way to kind of separate out the concerns. 22:30.000 --> 22:35.000 But otherwise, it has to be a full blown attack on the runner. 22:35.000 --> 22:41.000 And as I mentioned, like the certificate is valid for 10 minutes, you need to work really fast. 22:42.000 --> 22:45.000 Yeah, I think you're, sorry, you're next. 22:45.000 --> 22:46.000 Yeah. 22:46.000 --> 22:47.000 Yeah. 22:47.000 --> 23:09.000 So the question was around basically what data is included in the build provenance. 23:09.000 --> 23:18.000 And I think the short answer is that you get the source code that is being built from. 23:18.000 --> 23:20.000 I think that's the primary indicator. 23:20.000 --> 23:24.000 And everything is defined by the salsa team. 23:24.000 --> 23:28.000 So that's not something we can sort of, or we don't want to mess around with that. 23:28.000 --> 23:33.000 Like we want to use what's already decided by the salsa framework to include in the build provenance. 23:33.000 --> 23:38.000 But it's, it's currently the source code and then sort of the transitive closure. 23:38.000 --> 23:43.000 You can see what's being pulled from that source code. 23:43.000 --> 23:47.000 No, it's only the git commit object. 23:47.000 --> 23:48.000 Yeah. 23:48.000 --> 23:53.000 Assuming that the build step to the source are deterministic. 23:53.000 --> 23:56.000 Just the method that you use is information. 23:56.000 --> 24:02.000 So the question is, if the build steps are deterministic, 24:02.000 --> 24:08.000 does the build provenance give you sufficient information to recreate it? 24:08.000 --> 24:17.000 And I would say yes, because the build provenance contains an exact reference to the version of the repository. 24:17.000 --> 24:21.000 So you can, for instance, see, okay, this is the, let's say it's a make file in there. 24:21.000 --> 24:25.000 Then you can look at the make file and see what steps we're being made to build it. 24:25.000 --> 24:29.000 And then you can try to reproduce it based on that if that's a question. 24:29.000 --> 24:32.000 So if that's a clear, you can have that more access in there. 24:32.000 --> 24:35.000 This other external image that they can use, get that build process. 24:35.000 --> 24:38.000 Like this is not a reproducible bit. 24:38.000 --> 24:41.000 Like the, it's not actually running. 24:41.000 --> 24:43.000 I could still do another thing. 24:43.000 --> 24:44.000 Oh, yeah. 24:44.000 --> 24:49.000 So this, like I'll just make sure that you cannot be guaranteed to reproduce the same word as that. 24:49.000 --> 24:50.000 I just did another thing. 24:50.000 --> 24:52.000 Okay, yeah. 24:53.000 --> 24:57.000 Oh, yeah, yeah, yeah, yeah. 24:57.000 --> 25:02.000 We are not making any guarantees at all that it's being reproducible because I mean, 25:02.000 --> 25:07.000 for instance, if it's a C project, the order of the object files may be, you know, based on the, 25:07.000 --> 25:08.000 I know it's in the file system. 25:08.000 --> 25:14.000 So we are not making any guarantees, but if the project is built to be reproducible, 25:14.000 --> 25:18.000 that could give you the link to the make file that was used to build this. 25:18.000 --> 25:25.000 But, yeah, otherwise we don't make any guarantees at all about reproducible builds. 25:25.000 --> 25:26.000 Just a little more. 25:26.000 --> 25:29.000 It's a very, I heard that you mentioned them to get them to get up now. 25:29.000 --> 25:34.000 Why it's a way to collect and expose the signatures at a, 25:34.000 --> 25:36.000 upon places, that's correct. 25:36.000 --> 25:40.000 So yeah, they are available via the public API for the repository. 25:40.000 --> 25:43.000 So that's how you can clear for them. 25:44.000 --> 25:47.000 I mean, you mentioned about the private things of C store. 25:47.000 --> 25:52.000 I mean, like, others that work out there is a private key store then in the HSM one. 25:52.000 --> 25:53.000 No, it's the same model. 25:53.000 --> 25:55.000 Like, it's still using a formal keys. 25:55.000 --> 25:57.000 It's just that we are hosting the infrastructure, 25:57.000 --> 25:59.000 instead of the public good version. 25:59.000 --> 26:01.000 Otherwise, they are equally the same. 26:01.000 --> 26:03.000 All the actions are exactly the same. 26:03.000 --> 26:07.000 So when we are building or when we are creating the provenance, 26:07.000 --> 26:10.000 we basically look on the repository visibility. 26:10.000 --> 26:13.000 If it's a public repository, we use public six store otherwise, 26:13.000 --> 26:14.000 we're using hours. 26:14.000 --> 26:19.000 But otherwise, they are technically more or less the same. 26:19.000 --> 26:20.000 Yep. 26:20.000 --> 26:21.000 Let's go. 26:21.000 --> 26:22.000 Yeah. 26:22.000 --> 26:23.000 Let's go. 26:28.000 --> 26:29.000 Yeah. 26:29.000 --> 26:32.000 For Docker images in specifics. 26:32.000 --> 26:33.000 Yeah. 26:33.000 --> 26:37.000 So the question was if other repositories for Docker are supported 26:37.000 --> 26:41.000 and the question is, yes, I don't have the full list in my head, 26:41.000 --> 26:45.000 but I think virtually every container register out there. 26:45.000 --> 26:46.000 We are supporting. 26:46.000 --> 26:49.000 And when we are uploading the build-out station, 26:49.000 --> 26:53.000 we are probing for compatibility with the reverse APIs. 26:53.000 --> 26:56.000 If you support the reverse API, we rely on that. 26:56.000 --> 27:02.000 Otherwise, we use, it's called like a tag hack that seeks to invent it to upload. 27:02.000 --> 27:06.000 A signature next container that is in a registry. 27:06.000 --> 27:09.000 So yeah, I would say probably everything out there, 27:09.000 --> 27:12.000 at least that I'm aware of should support this. 27:12.000 --> 27:14.000 Yep. 27:14.000 --> 27:17.000 Packages. 27:17.000 --> 27:18.000 Packages. 27:18.000 --> 27:19.000 Yeah. 27:19.000 --> 27:23.000 So we did the work for NPM. 27:23.000 --> 27:29.000 Pipi is using sort of their own version of build provenance. 27:29.000 --> 27:32.000 Homebrew uses it. 27:32.000 --> 27:37.000 And I think, I mean, may even are doing something similar with 27:37.000 --> 27:38.000 sixth door. 27:38.000 --> 27:40.000 They're not using build provenance, but they are relying on 27:40.000 --> 27:42.000 sixth door signatures. 27:42.000 --> 27:44.000 Ruby is working at it. 27:44.000 --> 27:45.000 So those are. 27:45.000 --> 27:49.000 But yeah, I think it's also important to understand the difference 27:49.000 --> 27:51.000 between a sixth door signature and a build provenance. 27:51.000 --> 27:54.000 Because a build provenance is, you know, met that data around it. 27:54.000 --> 27:59.000 Whereas sixth door is just signing your package without the extra context. 27:59.000 --> 28:04.000 So there, yeah, a lot of ecosystems are looking at 28:04.000 --> 28:05.000 sixth door. 28:05.000 --> 28:07.000 And we're, of course, hoping that they will start to use 28:07.000 --> 28:09.000 salsa provenance as well. 28:09.000 --> 28:11.000 Because I think that gives you more information when you're doing 28:11.000 --> 28:13.000 a policy evaluation. 28:13.000 --> 28:16.000 I'm actually working on a programming and the links are right now. 28:16.000 --> 28:17.000 Oh, nice. 28:17.000 --> 28:19.000 Super happy to hear. 28:19.000 --> 28:20.000 Thanks. 28:24.000 --> 28:25.000 Thank you. 28:25.000 --> 28:26.000 Thank you. 28:26.000 --> 28:33.000 We made it on time. 28:33.000 --> 28:34.000 We made it on time. 28:34.000 --> 28:41.000 We get to do a big thing for it. 28:41.000 --> 28:44.000 Yeah, but if we had a driver's system, do you use the same thing 28:44.000 --> 28:45.000 with them? 28:45.000 --> 28:46.000 Yeah. 28:46.000 --> 28:47.000 Yeah. 28:47.000 --> 28:50.000 We're using the same technology for a driver. 28:50.000 --> 28:51.000 Yeah. 28:51.000 --> 28:54.000 But of course, we have different people running it. 28:54.000 --> 28:55.000 Yeah. 28:55.000 --> 28:56.000 Yeah. 28:56.000 --> 28:58.000 But the technology is exactly the same. 28:58.000 --> 28:59.000 I know. 28:59.000 --> 29:00.000 Yeah. 29:00.000 --> 29:01.000 Thank you. 29:01.000 --> 29:02.000 Yeah. 29:02.000 --> 29:03.000 I just have a small question. 29:03.000 --> 29:08.000 And is the timestamp utility of data publicly available? 29:08.000 --> 29:09.000 Sorry. 29:09.000 --> 29:10.000 It's the timestamp authority. 29:10.000 --> 29:12.000 So I'm working in William's team. 29:12.000 --> 29:13.000 Yeah. 29:13.000 --> 29:15.000 And we developed as a signed timestamp. 29:15.000 --> 29:16.000 Yeah. 29:16.000 --> 29:20.000 For sixth door, we don't test it against data. 29:20.000 --> 29:21.000 Yeah. 29:21.000 --> 29:23.000 The fourth is public available. 29:23.000 --> 29:24.000 Yeah. 29:24.000 --> 29:27.000 But it's not officially announced as public available. 29:27.000 --> 29:28.000 Yeah. 29:28.000 --> 29:29.000 So you can do it today. 29:29.000 --> 29:31.000 I thought from us, it's going to be available. 29:31.000 --> 29:32.000 Yeah. 29:32.000 --> 29:34.000 But just at least for all tests. 29:34.000 --> 29:35.000 Yeah. 29:35.000 --> 29:36.000 Yeah. 29:36.000 --> 29:37.000 Wait a minute. 29:37.000 --> 29:40.000 What about stability of all the wrong system? 29:40.000 --> 29:44.000 We promise that this is like a blockchain. 29:44.000 --> 29:45.000 Yeah. 29:45.000 --> 29:46.000 We change it tomorrow. 29:46.000 --> 29:47.000 Yeah. 29:47.000 --> 29:49.000 It will be difficult to verify. 29:49.000 --> 29:50.000 Yes. 29:50.000 --> 29:54.000 So we are, I mean, it's a large topic in a short month of time. 29:54.000 --> 29:56.000 But we are public. 29:56.000 --> 29:57.000 Yeah. 29:57.000 --> 29:58.000 We are public.