 Okay, welcome to the last session of the day, I guess, yes. Yes, so Chris Lam will be presenting on the reproducible builds status update. Thank you very much, welcome him please. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. So yeah, the other thing I wanna say straight up is not just me, this is a woefully incomplete list of people who are on the team who've contributed and been lurking around. Who is on this and is here? Can they raise their hands? Can they now stand up? And can we all give them a big round of applause? Woo! Up, up, up, up, up. You're right over there. Are you not on? No. No. No, just there. Oh. That's great. Yeah, yeah. Okay, so people don't know anything about me. I'm a freelance engineer, DD since 2008, first bit of code in etch, I think. Joining me for reproducible builds in January 2015 after I found it sort of a little offensive that a package that I was building just didn't have the same MD5 when I rebuilt it. This is awful. FTP assistant for the second time. I do QA, I run a few services. Travis, blah, blah, blah, do the regular packaging. Previously, Devin Livework, DI work, that IRC bot, it's a bit annoying. Package is all timeline, et cetera, et cetera. So just a bit of blah about me if you hear that. So a bit of a history lesson. I guess everyone knows who this chap is. Or at least he's beard. So he had the four freedoms. Let's immediately ignore what would you say? Numbers two and three, zero index. So, for you to study how the program works, okay, it's pretty useful. And for you to run the program, but what is the program? Like to run the program is a little bit odd. And particularly when you, I can't see that, but basically that's an app to get installed of I think Apache or something. But what is the program? So free software allows you to analyze the source code for malicious flaws. But as most distributions provide binaries for you, like where do those binaries come from? I mean, you install something that has a million dependencies and things like that. So can you really trust that they're producing binaries that you really wanna run in your system? Do they really even match that source code that you've checked every single line of, cough, cough, et cetera, et cetera? So reproducible builds is a way of solving that problem. And we do that by ensuring that compilation, repeated compilation, et cetera, will always produce the same result whether you do it today, tomorrow, and whatever, architecture, et cetera. And then multiple people will compare the results. And the idea is that any attacker would have to infect blackmail, et cetera, every one simultaneously to get the new checks on the central. Because if someone infected just my computer, my uploads, et cetera, and my builds would have a different char one or whatever you wanna do. And so basically everything is bit-for-bit identical between builds. That's what reproducible builds is, in that shell. For more information, there's a really good talk here, which is available on the CCC website. It looks a little old, but it's still extremely relevant. It has a lot of really interesting examples. Really concrete ones as well, especially a really cute Linux kernel-based hack, which is definitely worth checking out. There are some technical reasons for, yes, so there's some technical advantages of reproducible builds as well. So you can look at your corrupted build environment, maybe you've accidentally installed something into your char, et cetera. Things that access the internet are not very good anyway, because they leak privacy. General non-determinism in your thing isn't very good. The whole Martin Crowler idea of unit tests should be reproducible, sorry, deterministic. The embedded folks really like to be able to go back in time, as they call it, so they can just check out an old version from Git and rebuild it, and it shows them that their build system is just kind of working and things like that. And it's actually just easier to test changes. So if you, I make it up, you're writing a Python package and you want to hack on DH Python, you can just see whether your change actually makes any difference whatsoever to the package. Currently, if you rebuild, the char will be different. So you're like, oh, did my change break anything? Did it just change the things I wanted? You don't know. So yeah, a lot of advantages there. So this is getting onto Debian. What have we got to in Debian? Testing is now over 90% reproducible, and only 64, which I think is not bad, not bad. Yeah, thank you. Excuse me? Yeah, it's only a few thousand. And people keep uploading more. Well, hopefully not, because they're sitting in. And unstable is 88%. Yeah, just pretty good. So we have three more blocks. Unfortunately, this is just showing the sort of prospects because if you do this in regular old SIDs that you're writing on your laptops, it's not percent because you need a few patches from our archive, the reproducible builds, sort of custom archive. And these are the three. They're all in d-package, assigned to at least, but they have different dependencies and blockings. So for the actual status of these, I recommend looking at the bug numbers themselves because it's moving pretty fast. And they obviously would love some help if you can help on any of these bugs. That'd be great. Once these land, you will be able to have a normal SID, distribution in your laptop, and your packages will build reproducibly if they are reproducible. And that is the real goal. And I think that's really important because then this turns from some sort of signed project where you need like our custom devs. I mean, who's gonna, are you really gonna use our d-package on your regular system? I certainly don't, and I'm in the project. So yeah, so once these lands, I think those 90% will go up pretty high and quite quickly after that. So, yeah. So what else have we done? We agreed on a fixed build path. This is a problem where binaries, et cetera, encode that they've been built in, for example, temp buildy. And, but as the Debian builds, buildies don't specify that. We basically said that to be reproducible, we'll need a fixed build path. We also defined how our dot build info, which is a way of recording the environment used to build a package is being saved alongside a build. And so it can be reproduced later because to build a package reproducibly, you don't only need the same source, you need to know which dependencies were used to actually build that library and things like that. We've also been sending a whole bunch of patches. One in particular, to upstream GCC, to make sure that the underscore date and underscore time macros are reproducible, in a way that I'll go into in a second. We could spend the next 10 years patching them out of software, but we thought, no, we'll just fix them in one place. We've also been working on tools. Differscope are in-depth differ, so what it will do is unpack it, instead of just doing a very simple diff between two files, it'll say, oh, this file is actually a zip file, we'll unpack that, and if that zip file contains an ISO, we'll also unpack that, and then it'll get all the way down and do very detailed diffs. So it's extremely useful to, not generally, but especially for reproducible builds. So it'll unpack a dev and get all the way to the bottom as in one. DisorderFS was worked on last year as well, and this year it's a fused file system for returning random directory orderings, which makes things quite interesting when doing linking, et cetera. Reprotest was defined and work is being started. This is our tool that will enable developers to test whether their builds are reproducible on their own system without installing multiple P-builders, random scripts. You should just be able to do reprotest name of a package or point it towards a directory on your local machine, and it'll build it twice in various ways, and then it'll say, yeah, we think a package is reproducible. Stripped non-determinism is our library helper utility that will strip out very common causes of non-determinism in things like JPEG files, zip metadata, and things like that, and that supports a whole bunch of file formats, and we're adding a lot more, and that's another source of work that we've been doing over the past year. We also have an online version of the Difascope tool, which I reference, so you can upload two files, for example, two depths, and it will give you a pretty diff between the two files. I'm packing them recursively and things like that. We've also defined source date epoch, which is our environment variable for specifying the build date and time for a particular build. This is because a build date is not particularly useful and also makes packages unreproducible if they add that, for example, to documentation pages. As the date changes, the shell would clearly be different between two different builds if you built them on different days. And it's also useful, random seeds. For example, the Polygen man pages were random because, you know, it's a cute piece of software. They are still random, but it at least uses the number of seconds since the Unix epoch from the DeviantChange log entry to seed that random, so at least that the package now builds reproducibly, even though if you upload a new version of the package, it will have a different man page context. These are very important, very important things to work on. Anyway, that spec's available there. We also have been working a lot on our testing infrastructure. We are testing three suites, three architectures, a number of distributions, not just Deviant. And we also have an Outreachy student working on improving the output web pages. So that's Valerie over there. It's great. And the I36 and AD64 hardware is sponsored by Profit Bricks and the ARM hardware is sponsored by Deviant and Vagrant. And yeah, very cool. Just an example of the sort of variations that we run on our tests. So that first column over there is what we run on our first build or A build and the second build column there. So we set different user and things like that. Useful and interesting ones are changing the locale, which has some very, very weird effects. And things like that. Time zone's obviously interesting, particularly when it causes time zone libraries to break. But you had one draw, things like that. We're always thinking of more things to add to here. These are a bit more work in progress. For example, CPU type variations. That kind of depends on the hardware and things like that. And the file system, things like that. We'd like to vary a few more things in that direction. What is Disorder FS? Disorder FS is our few-use file system that we overlay on top. And if you run it, if you do a reader, it will provide you with hopefully random results instead of the file system order. As I understand it, X and the variance will genuinely give you back the files in the same order that you added them to a directory. Whilst BDR FS, because it has a different internal structure, will give you sort of non-deterministic results. And this just is like, well, yeah, you're round. You're gonna get them in any order. So force you to add explicit sorts and things like that. Beyond Debian, we're certainly trying to expand this beyond Debian because this is a problem that A, all distributions have. Everyone's interested in things like that. So this is just a short list of projects and distributions that are working on this. We also have huge projects like Tails and Tor are obviously, you know, clearly and things like this. And to speak to the cross-distribution, we had a World Summit, it's been like a pretentiously called in Athens last year. Late last year, and we hope to have another one soon, where we have sort of cross-distribution, collaboration and sharing of tools, sharing of ideas and things like that. And that was great to see other people's sort of angles and things like that and why other projects care about reproducibility. Because we, Debian has some sort of, we wanted for these kind of reasons, but other people want them for other, more technical reasons and things like that. Great to know. There are also projects that you wouldn't necessarily think cared about at all. Homebrew, the Apple, we call it package around, I suppose. The, yeah, I hear some laughs. And the, they're also interested in reproducible worlds as well. So it's not just hardcore technical people or whatever you want to call it. To speak to that in further, we removed, we used to use reproducible.debian.net. And now we switch to this more distribution agnostic L and we try and run everything under that. So our tests are now being run on test.reproduciblebuild.org instead of under Debian name. So whilst the role of Debian folks in its distribution agnostic, I think it's like that. So getting involved yourself, so obviously check your own packages and fix your own packages if you have unreproducible ones. On that, I have a spare DebConf t-shirt. So the first person to apply a patch and upload it and close a reproducible bug or fix their package. If you mail me, the first person gets it. So yeah, just throwing that out there. I hear they're in demand. Stop using dates if you're an upstream. So if you're using, you know, just getting the current date, stop using, stop doing that. Use our source date epoch. See the spec for more details or examples. Visit our website, things like that. Or and certainly stop by the IRC channel because that'd be the best way to work out how you can sort of get involved and sort of see what interests you and things like that. There's all sorts of technical things you could be working on and loads of documentation. We have an idea to, we certainly need some documentation for that build info file that I mentioned earlier. So that's one thing. So don't feel that this is a too technical for you or in that kind of angle. So yeah, I didn't really left a lot of time for questions. So fire away. Firstly, thank you. Thank you to everyone who's involved in reproducible builds. I think this is an amazing piece of work. I think it's very important to someone who has built commercial products on top of Linux, on top of Debian in the past, the ability to know I can reproduce everything just from get fantastic in both personally from a security point of view and from a commercial point of view. Great. How can we make this happen for stretch? You say it's all patches that are yours. There's three in the package. If we get those three packages in the deep package or are we good for stretch? Is that happening? Is it something we in the room can do to help? I mean, it'd be lovely to have a release where we actually have reproducible builds in mainline Debian. How do we make that happen sooner or later? So whether, I suppose there's, we can split that into two immediately. Do we have those packages landed and you can build reproducible packages in stretch? That'd be great. Shall we try and make stretch reproducible in itself? It's obviously harder. For example, will require us to rebuild the archive a day before the release, which is fun on architectures that don't build in 24 hours. What's the best way? I'm not really sure. I mean, landing those packages is probably, those patches is probably the best way forward. And then we'll sort of have to see where we are in terms of the release. It's not something I can really speak to because I haven't really been thinking about that. I mean, I'm presumed you would like stretch to be reproducible. I think stretch fully reproducible would be absolutely fantastic. But even if we got it to the point that you could do reproducible builds of your own packages. So some packages are reproducible and the infrastructure was in stretch so that the subsequent release would be fully reproducible as the release go. I think it'd be ideal. If you could achieve stretch reproducible with our help, fantastic, but really it's the tools. Can we get all of the tool pieces in so that if I have my own package in stretch, I can be sure I can make it reproducible and worry about my piece of the puzzle? Yes, well, I would love that to happen. And it's just a case of time, stroke manpower. And is that just the deep package package? Is there anything on those three bugs you listed on that screen that we need to worry about getting into stretch to have the infrastructure and the distro proper? I don't, yes, there's another thing for DAC, but I think that's covered under one of those bugs to support the build-in, for example. And then, yes, sorry? Build these. I guess it would also mean throwing away uploaded binary packages. Is that a requirement? I would assume so, yes. For what reason? Because to some degree, I don't think the build environment of all the, these are set up reproducible, even when the tools are there, because there are different approaches how to build a package, like CalBuilder, SBuilds, PDBuilds. And, sorry, what was that? I mean, if you upload a binary of something where the build is reproducible, then I mean, it's either reproducible or it's not. And if it's reproducible, I don't really care where the binary that's in the archive came from. Exactly, yes, but is that a blocker? That's a really good question. I don't think that we would necessarily have to do wholesale removal of binaries during upload for that reason. There's other good reasons that we've thought about in the past to want to have the autobilder network build all the binaries that are in the distro, but it's occurred to me a couple of times that if, in fact, we get to the point where all the binary packages are reproducible, whether it was built on my laptop or your laptop or an autobilder, it doesn't really matter if it's reproducible. Completely agree. And these are my kind of cherry on the top things. For example, you could have not only throw away binaries, but if you upload something, it doesn't matter, it's not reproducible, then it just gets automatically discarded, things like that. Yes, I would love all those things. I'm keeping my focus on the shorter term. Yeah. Yeah, something like that. So I've been paying close, not close enough attention, but some attention to reproducible builds from the use case that I have, which is actually very different from the use case. I just was reviewing a website of all the participants on the reproduciblebuilds.org. They all have a very different use case than I have. Most people in the room know I do a good amount of GPL enforcement as part of my living. I often worry about a problem that I would call reproducible builds, but I have a wily opponent, meaning that they don't want me to reproduce their binary. They don't care if I can, and I'm fighting with them to try to prove to them that the source code they gave me doesn't actually reproduce their binary when they claim that it does. Maybe you run into that, I don't know, but I think mostly you have people cooperating with you. You've already done, first of all, I wanna thank you. You've already done some tools that will immediately help GPL enforcement. I didn't know about Difascope until just now. That tool itself is gonna be a huge help to GPL enforcement, so thank you for writing it. It will be a big help to us. But I also wanted to ask you if you had any thoughts about how to take reproducible builds in that wily opponent area, where they're trying to basically trick you and you need to test the source to see if it's all really there. Have you done any work in thinking about that area and do you think that's appropriate to be part of the reproducible builds community? We haven't done much thinking about the area. I mean, some of it is sort of, by the wily opponent, just to clarify, do you mean that they're changing the source code? For GPL, they claim they're not. I'm saying there is source that's supposed to be here that's not, I can prove it to you because I can't reproduce the build and we have a fight about it. So I need the technical facts to back that up and using a reproducible build process and showing that it doesn't work is one technical fact that I can use to back that up and we actually do that, we do it all by hand. We have a human that tries to build the source code release they give it and we send them a giant report saying the source code doesn't match the binaries you distributed, here's the hundred reasons why. I would love to do more and more of that in an automated process. It would probably always need human intelligence but the less human intelligence, the better because humans are much more expensive than computers. Nice, well I literally had never thought of that use case and it sounds really valuable. So no, I personally haven't heard of that. But yes, I feel like it's certainly be part of that community, yeah. And if the description of the defascope impressed you, you should really look at the tool. I think it can be enhanced with very, very little bits of extra with the insight you gave with this use case. For example, on finding bits of a binary that are clearly copied or carried from other places. Like having as part of the defascope output, the Shah of whatever blobs it contains, it can really enhance its work. To speak to your first comment actually about upstreams, were you talking about whether upstreams are amenable to changes or was that a difference? Who's talking about GVM-I? They're my upstreams. They are upstreams, yes. Thank you. Hi, one more question. Hi. Thank you very much for your talk and for your work. My question is actually, is Linux itself reproducible like the kernel? And secondly, apart from potentially Linux, are there any packages which are not yet reproducible and look like they're really tricky and no one knows why or could you tell us a little bit about that? Thank you. OK, so on Linux itself, and by that, I mean the source package called Linux inside Debian, Ben Hutchings did a lot of work making that reproducible and working with upstream. So special thanks to him. It certainly was at one point and I think it remains reproducible. Someone should probably check that quite quickly. But if not, it's going to be very small things. But yeah, Linux itself is reproducible, et cetera. I think it's great. And your second point was on? Oh, particular packages, yeah. Well, the big one was making the GCC underscore macro supported and that was not necessarily a technical thing, but more of just getting it in the GCC release cycle. We maintain a large, what happens to be a large YAML file of, and we categorize all the particular issues. And so it's straightforward to see which packages we haven't worked out a reason for. For example, there are 200 packages affected by a Sphinx, the documentation generator. And so we tag them together so we're like, OK, we know these are only reproducible, but it's for reason X. And so we can concentrate on the ones that we don't know the reason of. We have added notes to particularly weird ones, but we don't have a priority or a list of these packages are particularly weird and we don't understand. Things like that. OK, so it's not going to be a case of the last 10% requiring another 100% of the time sort of? Well, it might be. Yeah, there's a really nasty, not 80-20 principle there, but 95 bar, yeah. Thank you. And of course, as we keep adding more variations to the previous list, we make our jobs harder in a sense. So I will just relay Gillem's comments on IRC. He said, hey, the SID is already reproducible from the DPKJ point of view. The hash in the status patch is a non-blocker. The control tower permission patch is only required if you build with a different UMask. And the build info is required to be able to build the same package over a period of time on a different setup. If you build right now twice in a row, it should give you the same result as of the DPKJ188. Smiley. Brilliant. Well, thanks again. Oh. I still have a question. Currently, you build the same package twice with different environments, but do you compare any of these two builds with what we have in the archive or not at all? We currently don't. We probably could. We just don't have that. We just haven't done that kind of thing. We're also not comparing between the two architectures at the moment, or sorry, three architectures. We care. We currently, it's only really visible if, for example, the I386 ones are reproducible within themselves. The, for example, architecture-independent packages, which should really be the same across, depending on which can make any difference what architectures you build them on. I believe Vagrant was thinking of working on that. Yeah, oh, he's got further. Well, actually what caused me to set up the Armature Build Network was one of my packages, UBoot, built reproducibly on AMD64. But I knew that it was impossible for it to be reproducibly on Arm because it built different targets. So there are some packages in the archive that actually build different packages on different architectures. So one idea I was having was to build arch all packages on different architectures and compare them. But that's a longer term goal. Thank you. What I meant before with respect to the uploaded binary files should get thrown away. Somehow the archive needs to check. I mean, we can put trust into the developers that they're building an environment that produces reproducible binaries. But we should sort of check that. At that point, if we build it reproducible for checking if it's the same, then we can throw away the uploaded binary directly and take the one from the check. Yes. This is all amazing and my question, so I have a package that used to be reproducible, but then I allowed it to become irreproducible. Very embarrassing. And so I have a question, which is, Landi, when will you be providing me a depot target where I can depot my upload, my dot upload to, along with a registered TGD and everything else, XZ, so that it only gets actually uploaded FTP master if it is reproducible. And then your depot target can just reject my garbage. Great question. So our attack for that was actually the re-protest tool, so you test it locally first. But I'm not going to. I'm too lazy. I know. I just want to think of depot too. It's just a question of manpower. We'd love to add that to DAPT, et cetera, and things like that. Well, but can I add it, and would you accept a contribution to add that sort of thing to your existing Jenkins setup? So it'll, so. Oh, absolutely, yeah. I could depot to your Jenkins, and then it'll run it through your blender, and then it'll upload it. Well, certainly I accept that, yeah. Because that's perfect, because that'll save you an upload, and having a dev revision of dash 17 to try and get, oh, try again to get reproducible, oh, try again to get reproducible. Yeah, absolutely, certainly accept that. Oh, and you can also subscribe to notifications, so you can get an email to say when your package was previously reproducible and now isn't. So you can get that sort of state through your chain. Have discussions been started with the release team to have that into Britney somehow, so that reproducibility regressions actually block migration, or is that for the next release cycle? That would probably be for the next release cycle, I would guess. Perhaps the microphone? Yeah. I would opt into this kind of aggressive thing for my packages. Okay, okay, yeah. We're speaking to a release team mostly in the context of stretch, but can be reproducible, and we'd have to probably speak to them for stretch plus one on the question of whether that becomes a Britney blocker. A transition blocker. But I do like the idea. Further questions? We have one here. Have you noticed any packages that have been trojan or backdoor? Have we noticed any, no. Unfortunately not in a weird sense, because that would be a quite good publicity coup. We have found a whole bunch of broken packages that are just horrendous. We have no idea of why they even worked up to now. Like it's just been through. Some of them are quite fantastic. But no, we haven't found any malicious attempts. What's the weirdest thing that you've seen while doing this stuff? Well, the weirdest fix I think was required for DH Python was where if a package built too quickly, it would result in the shebang lines in packages in user bin non-deterministically being set to use to Python 2 or Python 3.5. Just whacked. And it was because, well, I've already sort of perhaps given the game away with it built too quickly because it meant that the end time was under a second and it was using second resolution and it didn't think that something had updated, et cetera, et cetera. But yeah, all sorts of wind. We could all go fast on really fast machines and really slow machines. Testing on fast and slow machines, yeah. Or ARM, yes. Oh, there are some goodies. I'll have to think of them and get back to you on that one. Okay, great. Oh, we have another question. There was some concerns that I heard about that building reproducible might open new kind of attack patterns because all distributions now probably after reproducible deployed everywhere have exactly the same packages, the same binaries. And through that attack patterns might work more universal than they are now which might be specific to a certain distribution. So I'm not sure I follow. There was some security concerns with respect to that there might be new attack patterns with respect to reproducible builds because the same binary is used on all the distributions and not just within Debian, within Reddit, but already have their own binaries, so to say. And how is that? Which different patterns? The monoculture concern, hmm, use GR security. Is that there? Is that there? It's not something I've really thought much about. Sorry, go ahead, Steven. Actually, the GR security package in Debian has the exact same problem under described. If you randomly build GR security yourself, it puts some entropy into a header which changes the order of kernel data structures. So you're actually safer from building a non-deterministic binary than to use a distribution provided one. Right. But this is really a sort of edge case and generally reproducible builds fixes so many other security flaws that are more important to fix right now. Yes. And you're right that there are other sort of uses for non-determinism, for example, profile guide to optimization. It's pretty random and things like that, so because it's based on test timing. Yeah, I hadn't thought of that one, that's quite interesting. So I just wanted to observe that it's obvious to me that the work on reproducibility is following on the footsteps of a lot of other similar-ish initiatives we've tackled over the years, whether it was cross-architecture portability or dealing with 64-bit isms or whatever. It seems like every time we find something to focus on in the distribution, we end up generally improving the quality of the software because we end up finding and chasing down all of these sort of weird behavioral corner cases where someone was either too clever or too lazy in the development of the software or it's build harnessing. And I just, I can't tell you how excited I am every time I hear about progress here because it's another example of a place where I think Debian generally sort of leading and helping to drive, you know, making the free software world a better, more robust, safer place. It's just really cool. So thanks again for me and all the folks around. Thank you. So I wanted to rely a message on ISC that different distros still use different version combinations. So they will be different. And my own comment to the GRSEC randomization is the fact that you could put a deterministic pattern in there doesn't mean you have to. It just means you can verify that if you use the same pattern, you get the same binary. If you were to place a bet on a date to have net inst be fully reproducible, when would that be? So that becomes problematic because that requires maintainer scripts to be deterministic which is also same problem for making reproducible debut strap, for example, et cetera. And that's a different problem. I mean, it's technically not reproducible build if you squint, but yeah, it's the same issue. In terms of a date, I mean, five years, because it, I've looked at a few post-ins, thank you. I've looked at a few post-ins and a lot of them are just not reproducible and things like that. So yeah, it's a really hard one. Well, the networking starter is basically kernel plus some static scripts plus a bunch of packages. Did you just use the word just there? Yes. I do have a branch with a reproducible debut strap, but it's really ugly and it seems just that will be harder itself. And so as soon as you start doing other stuff, it becomes. Well, maybe we didn't understand each other. What I meant was not having the first run of net-ins to be reproducible. What I meant was having net-ins, actually, the image that is most downloaded to get Debian. Well, there's not that many packages in net-ins itself. It's more like it's an ISO or something that you put on a USB-K, but that is the first thing everyone downloads as being Debian and that might be the first goal to have reproducible so that anyone in the world can say, when I take this entry point for Debian, well, I can know that it's really what they mean. What do you mean? Yeah, sorry for misunderstanding. I don't know. I haven't done any poking in that direction. It's not something that's been worked on so it may be sort of a big can of worms. Yeah, it intrigues me, however. It seems like if you had the UDEVs being reproducible, then what you would need on top of that is just the DI scripts being reproducible. I say just as someone who has recently hacked on DI, but it's simpler than having a root file system being reproducible all the time. So it's a halfway house. That's probably the best first step, I think, yeah. Immediately thinking that's to be difficult to test because, but yeah. I'll take that. Just give me one year. One year? One year. Okay. Zero. I volunteered. You'll get more than a T-shirt. Oh, working on a T-shirt. I think we're in time to close the session. There's time for many more questions outside of this room. So thank you very much. Thank you. Thanks, team.