[00:00.000 --> 00:17.920]  Good afternoon. Can everyone hear me? It seems to be working. All right. So I'm going to
[00:17.920 --> 00:24.000]  talk about Git checkout authentication in the context of supply chain security. It's
[00:24.000 --> 00:28.000]  one of these birth words that we hear a lot today and I guess that's because there's a
[00:28.000 --> 00:34.000]  lot to be done in this area. I have to tell you this is going to be a talk about pre-crantom
[00:34.000 --> 00:41.000]  issues. So it's going to be different. All right. So I'm going to talk about work that
[00:41.000 --> 00:47.000]  has been done in the context of GNU Geeks like Simon was saying. Who has never heard about
[00:47.000 --> 00:54.000]  GNU Geeks in this room? A social offense. Very few people actually. This is real. I'm
[00:54.000 --> 01:01.000]  surprised. Anyway. So this started as part of Geeks. But as you will see, this is useful
[01:01.000 --> 01:08.000]  beyond Geeks, I think. So just, yeah, I have to introduce Geeks a little bit. This is an
[01:08.000 --> 01:13.000]  actual birthday cake that we ate a few months ago to celebrate 10 years of Geeks. So it's
[01:13.000 --> 01:25.000]  an actual, yeah. And it's a real cake. That's the thing. Yeah. So it's a distribution, a
[01:25.000 --> 01:29.000]  GNU Linux distribution that you can install standalone like you would install Debian or
[01:29.000 --> 01:34.000]  something. You can also install it on top of your system. If you're already running Debian,
[01:34.000 --> 01:38.000]  for example, this is great. And you can also have Geeks on top of Debian and that gives
[01:38.000 --> 01:42.000]  you an additional package manager. But anyway, I'm not going to go into the details of what
[01:42.000 --> 01:48.000]  it's like as a user. I want to talk about the, you know, what's behind the scenes, right?
[01:48.000 --> 01:56.000]  So what it looks like from a supply chain viewpoint. So this is a package definition for
[01:56.000 --> 02:03.000]  Geeks. Maybe some of you are wondering about the parents, right? That's okay. It could be
[02:03.000 --> 02:08.000]  JSON, it could be XML. You have similar things with other tools. It's just basically metadata
[02:08.000 --> 02:13.000]  that describes how to build the Hello package. It's telling you where to get the source code
[02:13.000 --> 02:18.000]  that tar.gz file. It's telling you how to build it with GNU build system. So configure,
[02:18.000 --> 02:24.000]  make, make, install, you know, that kind of thing. And there are now like more than 20,000
[02:24.000 --> 02:30.000]  packages in Geeks and they're all defined like this. So this is source code, right? And the
[02:30.000 --> 02:35.000]  thing is Geeks is able to build packages from source. So conceptually, you could think of
[02:35.000 --> 02:41.000]  Geeks as some sort of gen2, right? In the sense that it's building packages from source, except
[02:41.000 --> 02:45.000]  that you can actually get pre-built binaries and that's what people usually do because,
[02:45.000 --> 02:51.000]  you know, it's faster, especially if you want to use LibreRafis or, you know, whatnot. But
[02:51.000 --> 02:57.000]  Geeks is basically as a distro, it's all source code, right? Package definitions. And then
[02:57.000 --> 03:03.000]  when you go and build a package, that's also a salient feature. So if you've ever used or
[03:03.000 --> 03:08.000]  heard about Nix before, this is entirely inherited from Nix. So this is the functional
[03:08.000 --> 03:12.000]  model. Basically you say, all right, I want to build that hello package. And you run
[03:12.000 --> 03:16.000]  Geeks build hello and it's going to talk to a daemon that makes an isolated build of the
[03:16.000 --> 03:22.000]  hello package. So it's fully hermetic and that, you know, that removes a whole class of
[03:22.000 --> 03:27.000]  issues of nonreproducibility issues that you would have without that isolated environment.
[03:27.000 --> 03:34.000]  Yeah. And so that means that if you look at all the, all these things that we have in that
[03:35.000 --> 03:41.000]  GNU store directory, we have tons of packages and stuff in there. Well, they're all going to
[03:41.000 --> 03:47.000]  be bit identical for everyone. Or nearly. There can be issues, you know, but usually it's
[03:47.000 --> 03:52.000]  going to be bit identical. So typically if I look at that GNU store, blah, blah, blah, hello
[03:52.000 --> 03:58.000]  thing up there. Well, if I build it actually on my laptop, or if you build it on your laptop,
[03:58.000 --> 04:03.000]  you're going to get, we're going to get both the same hash. It's going to be identical. So
[04:03.000 --> 04:09.000]  it's all about reproducible builds, which we've probably heard of. So this is an effort where
[04:09.000 --> 04:14.000]  many distorts are involved. Daemon, of course, has been leading the effort, but there's also
[04:14.000 --> 04:20.000]  Nix OS, Arch Linux, blah, blah, blah, many distorts. And it's called reproducible builds,
[04:20.000 --> 04:26.000]  but we could very much call it verifiable builds. The whole point here is that you don't
[04:26.000 --> 04:31.000]  have to press binaries that you get from a server. You can always verify that the source
[04:31.000 --> 04:37.000]  that appears, you know, in the package definition that we saw before actually corresponds to
[04:37.000 --> 04:41.000]  the binary that you have. Because you can always rebuild locally. You can challenge the
[04:41.000 --> 04:47.000]  servers that provide pre-built binaries and see if it's the same. So from a supply chain
[04:47.000 --> 04:53.000]  viewpoint, that's pretty big deal, I think. And Geeks, we're trying to go a little bit
[04:53.000 --> 05:00.000]  further. So reproducible builds are nice, but it's not sufficient. Like if you're reproducing
[05:00.000 --> 05:07.000]  bit for bit malicious software, you still have a problem, right? So you've probably heard
[05:07.000 --> 05:14.000]  about that Trusting Trust attack, you know, illustrated by Ken Thompson in 1984. That's
[05:14.000 --> 05:20.000]  a long time ago. Well, this is that story. We want to be able to have fully auditable
[05:20.000 --> 05:24.000]  code that's entirely built from source. And actually someone over there in the back of
[05:24.000 --> 05:29.000]  the room with other people has been working on this, has been presenting this last year.
[05:29.000 --> 05:34.000]  We could talk about it for ages, but I have other things to tell you. But I encourage
[05:34.000 --> 05:40.000]  you to take a look at that talk by Yannick last two years ago, actually. The thing is
[05:40.000 --> 05:47.000]  how to be able to build the whole Geeks distribution starting from a binary that's just 357 bytes,
[05:47.000 --> 05:57.000]  I think, right? So pretty big deal. All right. Now to be more on topic. So we have these
[05:57.000 --> 06:02.000]  fancy things, you know, reproducible builds, strapable builds, building everything from
[06:02.000 --> 06:09.000]  source. That's nice from a supply chain security viewpoint. But, you know, for several years
[06:09.000 --> 06:15.000]  we've had that tiny issue specifically in Geeks. If you want to update your packages,
[06:15.000 --> 06:21.000]  well, your package collection, the available packages and the tool set, you would run Geeks
[06:21.000 --> 06:27.000]  pool. So it's similar to apt update in Debian, for example. That's roughly the same kind
[06:27.000 --> 06:36.000]  of tool. But it's implemented by fetching code directly from the Git repo of the project.
[06:36.000 --> 06:43.000]  And, you know, as you can imagine, you have to think about the implications of this, right?
[06:43.000 --> 06:48.000]  We're delivering code directly on users' computers, so we'd better be sure they're
[06:48.000 --> 06:54.000]  actually getting, you know, the real code coming from the Geeks project and not something
[06:54.000 --> 07:01.000]  different. For example, if the server that holds the Git repo is attacked, well, we'd
[07:01.000 --> 07:06.000]  rather have some mechanism to detect that, you know, to make sure that users are not
[07:06.000 --> 07:12.000]  going to download to clone a Git repo that contains malicious code, right? So we need
[07:12.000 --> 07:18.000]  something here. And, you know, we thought about this for quite a long time, actually.
[07:18.000 --> 07:24.000]  And the typical answer to this question is the update framework. Tough. I don't know
[07:24.000 --> 07:30.000]  if you've heard about it. It's sort of the reference for all things update in general.
[07:30.000 --> 07:34.000]  It's a specification with implementations in different languages and in different
[07:34.000 --> 07:41.000]  frameworks like for Python packaging, for Debian, I think, different things. But there's
[07:41.000 --> 07:47.000]  one thing. It's not quite a good fit for our case. Our case is we're just pulling from
[07:47.000 --> 07:53.000]  a Git repo in the end. The update framework is more about distributions that look like
[07:53.000 --> 07:58.000]  Debian or Fedora, where you have binaries on the server. And, you know, people are
[07:58.000 --> 08:03.000]  actually downloading those binaries. And those binaries are built by machines or developers,
[08:03.000 --> 08:11.000]  blah, blah. It's a different setup. So to illustrate that, let me show a bit what the
[08:11.000 --> 08:18.000]  workflow looks like in Git. So here we have what packages, Git packages do. So as a
[08:18.000 --> 08:24.000]  package, you define packages. So, for example, Python. And that's the kind of definition
[08:24.000 --> 08:29.000]  that I showed you before, right? And then you can test it with Git build Python, for
[08:29.000 --> 08:34.000]  example, like RISO. And eventually, the package is satisfied with the package while they
[08:34.000 --> 08:41.000]  eventually push it to the Git repo. And as a user, at some point, I'm going to run
[08:41.000 --> 08:47.000]  Git pool, which is very similar to Git pool, except it's also going to compile a few
[08:47.000 --> 08:54.000]  things. But roughly, that's like Git pool. And so at that point, I'm getting the new
[08:54.000 --> 08:59.000]  package definition, and I can run Git install Python, and I'm getting that package. That's
[08:59.000 --> 09:05.000]  the idea. And optionally, like I said, you can get pre-built binaries. I'm not going to
[09:05.000 --> 09:11.000]  go into details about this. This is optional, but this is something you usually want. But,
[09:11.000 --> 09:17.000]  you know, it's not baked in the model like you would say in Debian or Fedora. It's really
[09:17.000 --> 09:23.000]  something additional. And because we have reproducible builds, you know, pre-built binaries,
[09:23.000 --> 09:29.000]  it's substitutable, right? The key thing here is that people are going to pull from the
[09:29.000 --> 09:36.000]  Git repo, and we need to make sure that they are getting the right code, the real code. So
[09:36.000 --> 09:41.000]  we're really looking at these two things where the users are running Git pool or the build
[09:41.000 --> 09:47.000]  farm that builds packages is running Git pool, and how can we actually make sure they get
[09:47.000 --> 09:53.000]  the right code? And this is all about authenticating Git checkout. It's just Git after all. There's
[09:53.000 --> 10:00.000]  nothing special here. So with millions of people using Git, you would think that it's a
[10:00.000 --> 10:08.000]  solved problem, right? Oh, sorry, I thought. It is not, actually. So if you go, for example,
[10:08.000 --> 10:15.000]  to GitHub or GitLab, you can see these verified badges. This is a screenshot from GitHub. So
[10:15.000 --> 10:21.000]  you have verified badges. It's green. It's nice. You have partially verified, hmm, what does
[10:21.000 --> 10:28.000]  that mean? And you have also no badges. So what conclusion can you draw from that? Is it the
[10:28.000 --> 10:37.000]  real, the authentic repo or is it not? You know, you can't really do anything with that. So at
[10:37.000 --> 10:42.000]  that point of the talk, we need to talk about authentication. Authentication is about, you
[10:42.000 --> 10:48.000]  know, making sure we're getting the real thing, you know, the indisputed credibility. So we would
[10:48.000 --> 10:55.000]  say we want to make sure that people are getting the Git code as coming from the Git project.
[10:55.000 --> 11:01.000]  That's what it means to me. So specifically, we want to protect against a number of things. So
[11:01.000 --> 11:06.000]  we want to assume that potentially an attacker can gain access to the server that holds the
[11:06.000 --> 11:12.000]  Git repo. And from there, you know, the attacker can push more commits on that repo or could,
[11:12.000 --> 11:19.000]  you know, introduce malicious changes in many ways or even make a so-called downgrade attack
[11:19.000 --> 11:26.000]  where the attacker would revert or actually remove the latest commits, for example, so that
[11:26.000 --> 11:32.000]  users would be tricked into pulling an older version of Git with potentially like vulnerable
[11:32.000 --> 11:37.000]  packages and stuff like that. So this is what we want to protect against. What we want to
[11:37.000 --> 11:42.000]  protect against. There's a couple of additional goals. We want to make sure we can do offline
[11:42.000 --> 11:49.000]  authentication like we don't want to, you know, call out a number of services out there and, you
[11:49.000 --> 11:54.000]  know, key ring servers, whatever. And of course, we want to support changing authorizations in
[11:54.000 --> 11:59.000]  the sense that, you know, people contribute to Geeks and they come and go, right? So we need to
[11:59.000 --> 12:05.000]  add new people, new contributors, you know, official contributors, packages, and eventually
[12:05.000 --> 12:12.000]  we will remove them. You know, we need to be able to deal with that. So the solution, well,
[12:12.000 --> 12:18.000]  we're not yet at the solution, but the intuition, at least, that, well, this is Git. So this
[12:18.000 --> 12:25.000]  is a graph of commits, right? We're just dealing with a graph of commits. So we have
[12:25.000 --> 12:32.000]  commits here, actually, A, B, C, D, E, F. And each commit is made by someone. And the intuition
[12:32.000 --> 12:38.000]  is that we would like to be able to annotate each commit saying, well, at this point, you know,
[12:38.000 --> 12:43.000]  there's a certain number of people who are authorized to make commits in the project. And
[12:43.000 --> 12:48.000]  maybe it's going to change, you know, at each node of the commit graph. And yeah, this is what
[12:48.000 --> 12:57.000]  we would like to do. The solution we came up with is to have basically inside the repo a file
[12:57.000 --> 13:05.000]  that's called Git's authorization that lists the open PGP keys of authorized committers. You
[13:05.000 --> 13:12.000]  know, pretty simple. And the thing is, the file leaves inside the repo. And then we need to
[13:12.000 --> 13:18.000]  have a rule to determine whether a given commit is authentic. And so the rule is actually
[13:18.000 --> 13:25.000]  very simple as well. So a commit is authentic if and only if it is signed by one of the
[13:25.000 --> 13:32.000]  authorized committers of the parent commit. Got it? This is the main part of the talk. I'm
[13:32.000 --> 13:38.000]  almost done, actually. I could stop here. So we call this the authorization invariant. So
[13:38.000 --> 13:43.000]  let's see in practice what this looks like. So if I go back to my commit graph here, so let's
[13:43.000 --> 13:48.000]  assume for commit A, this is the first commit, let's assume Alice is authorized there, all
[13:48.000 --> 13:55.000]  right. And then in commit B, Alice is adding Bob as an authorized committer. So we have this
[13:55.000 --> 14:02.000]  label here. So at that point, Bob will be authorized to make commits. And if we look at
[14:02.000 --> 14:09.000]  commit C and E, well, they are made and signed by Bob this time. And it's perfectly fine
[14:09.000 --> 14:16.000]  because if we look at the parent commit of C, for example, so this is C, the parent commit
[14:16.000 --> 14:23.000]  is here, and we can see that Bob is authorized in the parent commit, right. And likewise
[14:23.000 --> 14:29.000]  with E, we can have so a second branch, the purple branch, and Bob is also committing
[14:29.000 --> 14:33.000]  in that branch, and this is fine because the parent commit is the same one, and Bob is
[14:33.000 --> 14:39.000]  authorized here, all right. And we can keep going that way, you know, remove people and
[14:39.000 --> 14:46.000]  so on and so forth. So a second example, if we take almost the same one, except that on
[14:46.000 --> 14:54.000]  the purple branch here, Bob removes Alice from the set of authorized committers, all
[14:54.000 --> 15:02.000]  right. And then what happens if Alice tries to make a merge commit that has D and E prime
[15:02.000 --> 15:11.000]  as parents? Well, if we apply the authorization invariant that we showed before, this commit
[15:11.000 --> 15:20.000]  is not authorized. It's not genuine. It's going to be rejected. That's the idea. Yeah, there
[15:20.000 --> 15:26.000]  is a small problem that perhaps you've noticed. We kind of didn't discuss the first commit,
[15:26.000 --> 15:32.000]  right. There's something to be said about that one too. Well, we need to introduce the
[15:32.000 --> 15:39.000]  repo in a way. So we need a way to say, well, this B commit is the first commit where we
[15:39.000 --> 15:44.000]  will start applying the authorization invariant. So we call this the introductory commit, and
[15:44.000 --> 15:49.000]  it's needed because, you know, perhaps you have some history already in your Git repo
[15:49.000 --> 15:54.000]  at the time you start using this mechanism. And so we need to be able to say this is the
[15:54.000 --> 16:02.000]  one where it starts. We call that the introductory commit. And so users are expected to know,
[16:02.000 --> 16:07.000]  you know, what the introductory commit is. So for example, this is a specification of
[16:07.000 --> 16:13.000]  a channel in Git, so a channel provides more packages. And as a user, you would provide
[16:13.000 --> 16:19.000]  not just the URL of the channel, of the repo, but also the introduction information that
[16:19.000 --> 16:25.000]  tells from which commit we're going to start authenticating. And that solves the bootstrap
[16:25.000 --> 16:32.000]  problem. So concretely, now that we have this, if we run GeeksPool, and it's been in production
[16:32.000 --> 16:37.000]  for a couple of years actually, if we run GeeksPool, well, we are going to have a message
[16:37.000 --> 16:43.000]  that says we're authenticating channel Geeks and a number of new commits, right, and it's
[16:43.000 --> 16:50.000]  sketched, so it's pretty fast. If I tell GeeksPool to use a different URL with a mirror, I'm
[16:50.000 --> 16:54.000]  going to get a warning saying, all right, it shows to use a mirror, that's fine, but
[16:54.000 --> 16:59.000]  be aware that this is not the canonical URL, so perhaps this mirror is tail. But at least
[16:59.000 --> 17:06.000]  we can tell it's authentic because we've verified the authorization invariance. But then if
[17:06.000 --> 17:12.000]  some evil attacker, you know, does something bad with the repo, then we're going to get
[17:12.000 --> 17:16.000]  a narrow message directly saying, no, this commit is not signed by an authorized key,
[17:16.000 --> 17:24.000]  you have a problem. And this is it. So this is all when using GeeksPool, but there is
[17:24.000 --> 17:28.000]  actually, you can use the same thing even if you're not using Geeks or even without
[17:28.000 --> 17:32.000]  using a channel, you can use the GeeksGit authenticate command that works the same
[17:32.000 --> 17:38.000]  except it's slower level, so you have to specify the introductory commit and the key that
[17:38.000 --> 17:43.000]  signed the introductory commit. And the thing is, I think we should all be using that kind
[17:43.000 --> 17:51.000]  of stuff with our Git repos because right now it's a wild west. But yeah, the key is
[17:51.000 --> 17:56.000]  a bit not super usable, so I understand we'll have to do some work on this if you have
[17:56.000 --> 18:03.000]  ideas, I'm open to them. Yeah, and you can specify where the key ring, the open PGP key
[18:03.000 --> 18:08.000]  ring is to be found because this is not going to talk to key servers which are very unreliable
[18:08.000 --> 18:14.000]  as you probably know. All right, I didn't mention downgrade attacks, I have to be fast
[18:14.000 --> 18:21.000]  right, I guess. Downgrade attacks. That's another kind of attack we want to protect
[18:21.000 --> 18:27.000]  against. And the good thing with Geeks is that Geeks keeps tracks of its own provenance.
[18:27.000 --> 18:33.000]  So for example, when you are running Geeks, you can run Geeks describe and it's going to
[18:33.000 --> 18:39.000]  tell you, I was built from this commit. So it knows where it comes from, so to speak.
[18:39.000 --> 18:45.000]  And because we have that provenance information, then if you run Geeks pool and it detects that
[18:45.000 --> 18:52.000]  it's not going to a commit that's a descendant of the one we're currently running, you're
[18:52.000 --> 18:59.000]  going to have a narrow message, right? Commit coffee is not a descendant of cabbage, of
[18:59.000 --> 19:07.000]  course. And this is pretty cool. And likewise, even at the system level when you deploy your
[19:07.000 --> 19:12.000]  system, the system itself, the distribution actually running on your machine records which
[19:12.000 --> 19:18.000]  commit it was built from. So we have the information here if we run Geeks system describe and so
[19:18.000 --> 19:25.000]  if I run Geeks system reconfigure to update my system, well, potentially I could get a
[19:25.000 --> 19:30.000]  message that says, no, you're trying to reconfigure to a commit that's older than the one you're
[19:30.000 --> 19:36.000]  currently running. That's a problem. I can overwrite that if I know what I'm doing, but
[19:36.000 --> 19:45.000]  usually you'd better not. All right, it's time to wrap up, I guess. Yeah. So to summarize,
[19:45.000 --> 19:51.000]  we have two things here. We have authenticating checkout which is good for Geeks because it
[19:51.000 --> 19:57.000]  gives us safe Geeks updates. And because we have safe Geeks updates, we can have unattended
[19:57.000 --> 20:02.000]  upgrades, for example, and this is super cool, you know, you know that the unattended upgrades
[20:02.000 --> 20:07.000]  are either going to work and run the right code or they're not going to run at all. And
[20:07.000 --> 20:13.000]  this is important, I think. This is in-band and offline which means all the data needed to
[20:13.000 --> 20:20.000]  perform this authorization while this authentication step is all inside the Git repo. There's no
[20:20.000 --> 20:26.000]  need to talk to key servers and stuff. And you can and should use that kind of tool on your
[20:26.000 --> 20:32.000]  Git repo, I think. We really need to think collectively about this issue. And we have
[20:32.000 --> 20:37.000]  again protection against downgrade attacks which is good for unattended upgrades and is
[20:37.000 --> 20:44.000]  deploying in Geeks for a while now. There's a paper if you want to see all the nitty-gritty
[20:44.000 --> 20:52.000]  details. There's the URL here. And yeah, to conclude, I'd like to think a little bit, to
[20:52.000 --> 20:57.000]  reflect a little bit about all these issues of supply chain security. I know I'm sharing
[20:57.000 --> 21:02.000]  this one with speakers about Seek Store, for example, and other projects. And we have a
[21:02.000 --> 21:08.000]  different approach to things. For example, with Geeks, we have a unified deployment toolbox.
[21:08.000 --> 21:14.000]  So we are very much talking about end-to-end integration of the tool set, verifiability
[21:14.000 --> 21:19.000]  with reproducible builds, for example, auditability. We have the commit graph. We have all the
[21:19.000 --> 21:26.000]  details available at our disposal when, you know, often popular approaches are more about
[21:26.000 --> 21:30.000]  assuming that you have a different set of tools. You can have a distro, you can have
[21:30.000 --> 21:35.000]  Docker, you can have Kubernetes, whatever. And you're just combining everything and thinking
[21:35.000 --> 21:43.000]  about artifact flow integrity, attestation, version strings and stuff like that. So I
[21:43.000 --> 21:48.000]  think the key is to really think about going from source code to deployed binaries. That's
[21:48.000 --> 21:53.000]  very much the free software ethos as well. And thinking about ensuring we have proper
[21:53.000 --> 22:00.000]  provenance tracking and the ability to verify things. This is it.
[22:00.000 --> 22:08.000]  Thank you.
[22:08.000 --> 22:15.000]  Thank you, Ludovic. We have three minutes for questions. Hello. Thank you for the talk.
[22:15.000 --> 22:20.000]  A really common workflow is to use GitHub to merge pull requests.
[22:20.000 --> 22:26.000]  Yes. And whenever you merge pull requests, there usually is a merge commit signed by
[22:26.000 --> 22:34.000]  GitHub. How would you go about allowing merges by GitHub without allowing GitHub
[22:34.000 --> 22:39.000]  skis to be used for arbitrary commits? That's a very good question. Actually, that's
[22:39.000 --> 22:44.000]  probably a limitation of this model. So we're not using GitHub or even GitLab for
[22:44.000 --> 22:52.000]  geeks. And actual developers are making merge commits, for example. But typically for
[22:52.000 --> 22:57.000]  automated merge commits, like you have on GitHub, it's not going to be practical. That's a
[22:57.000 --> 23:06.000]  limitation, yeah.
[23:06.000 --> 23:14.000]  Hi. Thank you. First of all, thank you for your brilliant presentation. I see that
[23:14.000 --> 23:23.000]  geeks or geeks, I haven't geeks, yeah. Thanks. He's a very promising package manager
[23:23.000 --> 23:31.000]  or even the Linux distribution. I probably have some off-topic question regarding
[23:31.000 --> 23:40.000]  to your talk, but I still believe that you can answer it. It would be enough, yes or
[23:40.000 --> 23:48.000]  no for me. Is it some kind of cross-compilation supported by geeks? Sorry.
[23:48.000 --> 23:54.000]  Yeah, there is cross-compilation support, yes. You can even cross-compile systems.
[23:54.000 --> 23:55.000]  Quick question.
[23:55.000 --> 24:01.000]  Thank you so much for your talk. I have a quick question. I saw you're using PGP keys to
[24:01.000 --> 24:06.000]  verify the commits, but these days you can also use SSH keys to sign your bit commits.
[24:06.000 --> 24:08.000]  Is this also supported in geeks?
[24:08.000 --> 24:17.000]  No, it's all open PGP. That's a good question. We started before Git supported anything
[24:17.000 --> 24:24.000]  other than open PGP, actually. Yeah, so it's a trade-off, I guess.
[24:24.000 --> 24:27.000]  Have you considered upstreaming this into Git?
[24:27.000 --> 24:28.000]  Oh, sorry.
[24:28.000 --> 24:32.000]  Have there been any ideas about upstreaming this into Git itself?
[24:32.000 --> 24:40.000]  I did consider it. It's a bit of work, I guess. Also, we have very tight integration
[24:40.000 --> 24:46.000]  with a small-scale open PGP implementation that can only do signature verification,
[24:46.000 --> 24:52.000]  so that would mean also having that into Git itself, which is quite a bit of work.
[24:52.000 --> 24:57.000]  But I think it should be in Git proper eventually, yes.
[24:57.000 --> 24:59.000]  Okay, final question here.
[24:59.000 --> 25:05.000]  Thank you. Have you considered a six-storey integration with Git?
[25:05.000 --> 25:07.000]  Oh, sorry. Can you repeat?
[25:07.000 --> 25:14.000]  Yeah, have you considered a six-storey integration? Is it possible? Is some work in that direction
[25:14.000 --> 25:15.000]  happening?
[25:15.000 --> 25:21.000]  No, there's no work in that direction happening as far as I know.
[25:21.000 --> 25:26.000]  I guess I'm not sufficiently familiar with six-storey to see how it could integrate with
[25:26.000 --> 25:29.000]  Git, but I don't know. Maybe there's something we could do.
[25:29.000 --> 25:31.000]  Thank you.
[25:31.000 --> 25:34.000]  Thank you, Ludovic. Five-minute break.
[25:34.000 --> 25:52.000]  Thank you.