 All right, so thank you, thank you everyone for coming. So this is a talk from the GnuPG, the package GnuPG main team, the Debian GnuPG packaging team. I'm DKG. I'm Eric Dorland. And there are many other folks who have been working on GnuPG over the years and are currently working also on GnuPG. So we're just gonna give a little report back about where we are with GnuPG and Debian and what we have planned. And maybe my mouse will work. Yeah, so there's been lots of people who've been working on it. We want to just say, just to be clear there, this has always been a big team effort and continues to be a team effort, so thank you to everybody who has contributed. There's lots more people, that's what that dot dot dot is. It probably includes you if you've reported bugs or complained about the way things work or made new suggestions. But I mean, Daniel's actually done an incredible job this year, has really shepherded the project. I think he deserves a huge round of applause right now. Oh. Thanks. Thanks. So since last year, we've gotten everything moved over to Git for packaging. If folks just saw my previous discussion, that was one of the things that makes life easier for me as a packager. So that was a selfish move on my part to push it. I hope it's useful and I hope other people feel more inclined to jump in if they have things they can contribute. The team itself has adopted GnuPG 2, Libassioon, PinEntry, GPGME. So a bunch of the packages that are sort of related to GPG and in the GPG ecosystem are all under the package GnuPG main umbrella now. Also since last year, GnuPG is now reproducibly built under the reproducible builds thing. So that is awesome. Many, many thanks to the folks who've done a lot of work to make reproducible Debbie in something that we are heading towards at a much faster rate than I expected. GnuPG, we're happy to be part of that. Version 2.1 of GnuPG has been an experimental for many months and it's actually been in Debbie and Unstable for many hours. If you have, so we are. So we uploaded it before we started drinking last night. Yeah, we uploaded it before drinking. So sorry to make your slides wrong this afternoon, Verner, because you said it was in experimental. It's now also in Unstable. It is Unstable. Well Unstable is all kinds of Unstable right now. And so we're making it part of that. Here is our chance to break stuff. This is the beauty of Unstable. We're at that time in the release cycle. We wanna get more eyeballs on it. We wanna find out what problems people have so that we can make it work for everybody who is relying on Debbie and Stable to be stable. So 2.1 is in Unstable. We also did a cleanup of the base install on a minimal server where there were some complaints, I think justifiable complaints that things were pulling in by default too much, too many packages on a minimal server install. We want those minimal Debbie and the installs to be as small as possible, both for resource consumption and for potential bugs. We don't wanna pull in all the graphical stack just cause you wanna have GPG available. And so we've cleaned up the default dependency arrangements to make server installs minimal. We missed that for Jesse and apologies are due for that. Some folks are pushing that that could be something we could do in a Jesse proposed updates. The release team has been reluctant to take that on mainly because there are no strong bugs open about it. All of the bugs are like, oh man, I did this install and it pulled in these extra packages. Is that a release critical bug? And so the release team is justifiably concerned about trying to make a big change in the dependency ordering. To be clear, there's a workaround. If you have a minimal install and you're like, oh, I really wanted to have the GPG2 packages in there but the trouble is they pull in all this extra stuff, the workaround is very easy. You just install pin entry dash curses instead of installing pin entry because the default pin entry will be a graphical one. That's what pulls in the graphical libraries. So if you do have a minimal install and you're worried that it's too bloated because of your GPG2 dependency, please go ahead and install pin entry curses and then clean out the graphical stuff. If you really think that it needs to be done in Jesse, open up a bug and elevate its severity and explain why the severity is elevated and that'll give us the recourse to go to the release team and start talking through what we need to do to make that happen in a Jesse proposed update. I'm not convinced that that's the best use of our time right now but if it really bugs you, let's figure out how to make it work. So this is the big news right? We really want GNU PG 2.1. We want it for a lot of reasons and we want it for Debian in particular. Debian relies heavily on GNU PG for things like verifying our software. We want it because we have updated key storage mechanisms which should give us some faster access to keys. We want it because it'll provide us with elliptic curve crypto which provides us with stronger cryptography for less compute power. We want it for the demonized processes and isolation which have potential to help people keep their secret key materials safer and we want it because we want to stop shipping stuff that people will have the old broken things available to them by default. So this is a little bit controversial because if anybody needs the old broken stuff to work it's probably a Debian developer who's hooked it to some kind of email system that has their old MD5 signed key that simply cannot change and they really need some kind of old broken thing to work. However, that doesn't mean that that's what we should be supporting by default for everybody who's using Debian. It's a mistake for us to offer tools that say hey and by the way this comes with this really cool knife that has blades on both sides for regular use. If you want the knife with blades on both sides you really need to do something special to get access to it. So one of the reasons I personally want to see 2.1 in Debian and move the old stuff, we can move the old stuff out of the way. The older crypto really is not strong anymore and we need to make sure we can move away from it. So a brief slide about elliptic curve crypto and what that means. So without going into the math this is about sort of the social and deployment questions around elliptic curve crypto. So it's a new set of algorithms in the same way that RSA is different from DSA. It's a completely different set of math that's used. And there are different parameter choices you can make for elliptic curve keys. Ooh, spooky. So there are different parameter choices you can make for elliptic curve keys. There are different kinds. And as Werner mentioned in his talk earlier today there are curves from NIST that are well defined, everyone understands but they come from NIST and there's a little bit of dubiousness about their origin. I haven't heard any strong cryptographic explanation that they're backdoored in the way that some standards that came from NIST were. But nonetheless there are some open questions about the way they were generated and we would like to not rely on them. They're also harder to implement and slightly slower and more prone to mistakes than some of the newer kinds of elliptic curves that are being published. And so thanks to Nibesan who's back there we actually have this ed25519 and curve25519 which is a different set of elliptic curve parameters that will be available to us in GNU PG 2.1. And we may even get another curve that's coming from the same process that's sort of settling on the 25519 process. So how do we deploy a new algorithm in a way that's useful? So the first thing is that we really need to get a widely deployed base that can do the public key operations with a new algorithm before we start using them. If I say hey you can encrypt a message to me and here's my key and it's an algorithm that you just don't have access to, then you can't use it. And similarly if I assign something with my key that's an algorithm that you've never heard of before you can't verify my signature. So those things are effectively useless. So we care more about getting the public key side of the algorithms deployed first and then later we'll make sure that people can start to deploy the secret key side of things. And there will be some, you know, people who like to play on the bleeding edge who will deploy the secret key side of things earlier. But the secret key side in generating these keys is gonna be hidden for the moment behind an expert flag in the GPG interface. So that means that if we can get 2.1 deployed and we can verify these signatures and we get a wide base of people who can handle the crypto, then we can start encouraging people to consider switching to it. But I don't think we're under any expectation that people will all switch over to ECC as soon as they have a copy of 2.1 available. We just want you to be able to use it when you're communicating with other people who happen to use those keys. So by the way, if folks have questions or concerns about any of the topics here, give a holler. No. Should be mics around. Yep. So the 2.1 transition, how's that gonna work? 2.0 is gonna go away. 2.1 has already replaced 2.0 in unstable. And if we can get 2.1 to the point of stable-ishness enough in unstable, then 2.0 will also go away in testing. It's not co-installable with 2.1. And 1.4, we're gonna move to becoming GNU-PG-1 and the binary will be user bin GPG-1 and the binary for GPG-2 will be user bin GPG. So most people won't have GPG-1 installed. As I said, there are some folks who are gonna need it and they're gonna need to figure out how to get that working. We will support the software, but they're gonna need to explicitly install on their systems, we're not gonna have it available for people to cut themselves with by default. So why the hard cut over? Some people might wanna do Etsy alternatives instead. We as a team don't really wanna deal with that many moving parts. We have enough bug reports to deal with and we have enough things to get settled. We would like to focus our efforts on the 2.1 stream, make sure that we can support upstream, which is also doing an excellent job of focusing on the 2.1 development path. And it creates an additional layer, possibly additional round trips for bug reports. Oh well, what do you have for Etsy alternatives for GPG? We wanna make sure we've got modern crypto available to everyone by default. We wanna discourage older crypto and we wanna just make sure that we're streamlined and focused. So that's why a hard cut over and we're not gonna be going with the Etsy alternatives approach, unless someone comes up with a really good argument for why we should. I also don't think it's very, it's a bit disingenuous at this point where 2.1 and 1.4 are different enough that an alternative is kind of lying. Yep. They don't really provide the same, they're starting to not provide the same interface. They don't support the same algorithms and there's lots of new features in 2.1 that just don't work with 1.4. Yeah. So we're gonna do the cut over in experimental first. We'll continue packaging GNU PG2 as, you know, 2.1 as GNU PG2 in unstable, but we will experiment with a transition with uploads of GNU PG and GNU PG2 into experimental that shift which one is responsible for the GNU PG package. We'll mail WNDevelop announce when that's available so that you, yes, you can try out with experimental on your systems and let us know how we broke everything and deleted all of your personal files so that we don't do that to our users. And we're thinking through how to do this with mailing to all of the reverse dependencies just as a heads up. I'm not sure whether that's the best thing. If folks have suggestions about how to do that, I'd be happy to hear them. You could bring them to the GNU PG mate mailing list. And I mean, I think we should mention too, we're gonna try to be working on this during DEB Conf this week so we may actually have something to look at by the end of DEB Conf, no promises. Yep. So one of the issues about the transition is the Udebs, the Debian installer uses these Udebs, microdebs I guess is the way you could pronounce it. And at the very least it needs GPGV to verify the packages that it downloads. So GPGV is also gonna transit, the Udebs is gonna transition over to the GNU PGV. We've already had some discussions with the Debian installer folks and some discussions with upstream. Thank you, Werner, to try to streamline that process. And similarly, there's a special, weirdly architecture independent Win32 Udeb to help the Windows based installer verify things. And that's also gonna probably move to the GNU PG2 packages. We currently have a GNU PG-Udeb package which used to be depended on by Partman Crypto for people who are setting up encrypted disks. Partman Crypto no longer depends on it. So we're probably gonna make it go away. If you know that you're using GNU PG-Udeb for your Debian installer work, let us know. I did a search of the Debian archive via codesearch.debian.net. Many, many thanks to the folks who are maintaining codesearch.debian.net. And the only place this showed up was that we were at all concerned about was Partman Crypto and it's no longer used there. So if you know of anybody that wants to use GNU PG-Udeb during the installer, give a holler, because it's probably gonna go away. In the GNU PG ecosystem, there's the pin entry tools, which is how the GPG actually interacts with the user. So Upstream has made a number of choices recently to make that streamlined and more sort of graphically in line with existing user interface toolkits. I think those changes are really awesome. There's GNOME 3 work, there's QT work that's moving, I think, from four to five. One of the potentially scary changes Upstream is that this means, one of the things about pin entry is that it used to do very, it was very careful about locking memory so that the memory wouldn't be swapped, which means so that the password you typed into the pin entry wouldn't be written to disk by accident. Upstream is kind of moving away from that. And one of the reasons they're moving away from that, I think, is because it meant basically maintaining all your own user interface tools, which meant that whatever user interface there was didn't integrate with whatever people's user experience was. And part of the move towards making this stuff usable is making it fit in your environment. So the move away from let's maintain our own sort of variant stack of QT and our variant stack of GTK so that we can build this stuff and make sure that the memory never gets locked is kind of, that justification is going out. So yes, your password might get swapped to disk as a result of this change. On the other hand, if you're using a modern system and it's a laptop, you probably hibernate your laptop and even locked memory gets hibernated to disk. So the protections against locked memory are not as good as they used to be either. So I think this is a move in the right direction. It's a move towards usability. There's a particular case where maybe it's a slight move away from security, but I actually think getting more people using it will be a broader help to security overall compared to less people using it. I'll repeat the question if the mic doesn't come. The question was, does it also count for pin entry curses? I'm looking to Werner to see, he's struggling. Yeah, pin entry curses may also be making the same set of tests. Yeah, so anyway, it may also be pin entry curses. If you can think of ways that we can fix that with pin entry curses or improve that, that would be great. Here's a microphone, Werner, if you can. There would be an easy solution and just have an encrypted swap space. Have an encrypted swap space, right? That's much, much easier and we could throw away all these things and it's just easier. And of course something which triggers clearing the memory and hibernation, but that's the packaging or the administration thing, so I really would vote for that encrypted swap space would be the default of the systems because I don't think that it's any performance issue than anyway. Yeah, but is encrypted swap space a default in Debian? I don't know, sure. It's not, but it probably should be. Did they open this yet, so. Can someone file that bug right now? Seriously, these are the kinds of things that we can do as an operating system that no individual upstream can do and it would be better for all of our users. So we should make encrypted swap the default and it would remove some of this concern. Thank you. Well, my understanding is that encrypted swap by default would require a lux or some type of encryption and then you'd have to have a password you'd enter. I think it's, is that not the case? No, there are techniques to do it without that, where you randomize the encryption key for your swap at each boot. Oh, right, okay. Yeah, so there are trade-offs, and we need to, but as an operating system, we can figure out how to do those trade-offs to protect the largest number of people. Right now we're probably not doing our best job at that and maybe that's a separate session we can have about how do we deal with this kind of question, you know, encrypted swap, but this is not GNU PG. But this is the sort of thing that I really want Debian to do because we are the only folks in a position to do this. Right, this is not something that anyone upstream can do for us. So we may also diverge in GNU PG, sorry, back to GNU PG from the encrypted swap questions. We may diverge from upstream somewhat in the Debian packaging. We're not interested in doing wild divergence. We want to minimize the deltas where possible, but there are a lot of guides out there that are sort of fiddly guides that say you got to do this thing and change this config and remember, make sure this config is there and some of those guides are more sensible than others and what we would like to do is to reduce the size of those guides to the point where if possible the guide says just use an up-to-date GNU PG. And so the way we may diverge from those is to potentially change some defaults to try to make them more secure so that the guides have less to say. And we're going to do that probably in unstable and therefore maybe testing. And if we get reports of interoperability failures from folks in unstable and testing we may revert those changes before they hit stable. But we have an opportunity to try to encourage people to use stronger defaults without asking them to go fiddle with their text files because that's something that people don't do unless they're mega nerds. We want this to work for everybody. So we're going to adjust it some, we're going to look for interoperability problems and we're going to try to get some of these changes back upstream if we can. Another example is some Linux specific hardening. One change that we made recently is to go ahead and avoid the ability to dump the memory of the GNU PG process. The agent process. Yeah, sorry, the agent process. Thank you, via Petrace. And that's something that upstream is unwilling to do because there are other ways that those processes can be attacked which is definitely the case. But here's a particular attack. We can mitigate it. So we're experimenting with mitigating it right now in Debian unstable. If it turns out to cause too many problems we can also revert that as well. But so these are a couple of places where we might diverge from upstream. Hopefully our experiences in Debian can inform upstream and help them decide whether they want to take those changes or not. If we can get them back upstream, I would love it. If it turns out that we diverge a little bit I also have no problem with that. We want to minimize our divergence. So desktop integration is one of the ongoing pieces of work Werner mentioned to push towards usability as a security feature for the future of GPG. And desktop integration is a big part of that. The work on pin entry has been a big part of that. And we had this conflict for a long time between GNOME and GNU PG about who gets to provide the GNU PG agent interface and what is a proper GNU PG agent interface and how can we evolve the GNU PG agent interface if different implementations are supporting different feature sets. There's a sense that it was being hijacked. And that fight is over. I'm really pleased to announce that the fight is over. Things are better for everyone now. A bunch of folks, the folks who are up here is a mix of people from different teams from GNOME and GNU PG who managed to resolve this in a way that I think is gonna be better for everyone going forward. It's gonna be more usable and more secure. So in light of that kind of improvement I'd like to ask if people have ideas about how we can do better desktop integration better still to suggest those changes. And if there's ways that we can do that within Debian where we can act as the social glue between projects and we can say, look, here's how the negotiations work. We should be able to solve this stuff within Debian. Integration is what we're doing as a distro. So let's do that and let's improve it and make it better. If you have ideas for how to do better integration let us know. Possible future ideas, better testing, auto package test is pretty cool. There's a proposal for doing a little bit of that. We'd like to do a lot more of that. If folks don't know about auto package test, check it out. There's a way that once your package has been built it's like a test suite for the built package as opposed to a test suite while you're building it. So you can actually declare I want an environment that has the following other packages installed and I want to execute this stuff and the output and the return codes should look like this. So you can actually test your system in an integrated way with other pieces of the software ecosystem and then you can get reports that say, hey, this thing broke. So we'd like to do some of that. We'd like to find ways to streamline the user experience for what we know to be some best practices like the use of smart cards and like the use of offline master keys. Currently it's a little bit fancy to get that done and if we can find a way to streamline that that doesn't cause additional support headaches down the line, we'd like to do that. If anybody here is working on one of the language teams like Ruby or Python or Perl or there's lots of others and forgive me if I've forgotten your favorite one but we had GPG has programmatic interfaces like Astuon and GPGME and we'd like to make sure that those are well maintained and well supported. So if we can work with the language binding teams we'd like to do that. Also user interface and user experience review. We know the usability is security argument is pretty strong. Let's make sure that this thing is usable. Let's figure out how to do that without breaking existing tools that rely on it. And if there are other graphical user interfaces that relate to key ring management or to encryption or decryption support if we can help with that as the GPG packaging team we'd like to do that. So just a call for contributions. If you've got ideas from this talk, if you've got ideas before this talk that you've been scared to voice, we're friendly, we don't bite, we would love your help. We would love your suggestions even if it's a bug report that says this is broken for me and you can tell us here's why it's broken we wanna know that, that'll make it better for everybody. So any contributions you have for improvements are totally welcome. Do folks have questions? This is how you can get in touch with us. We've got a mailing list, we've got an IRC channel, there's a wiki page with some details. Zoe Meaghan, I remember there was an issue with APT and GPG 2.1 when being installed together not being able to verify things anymore. Yep, so I can talk a little bit about that. David Kay, I'll say. We worked on, thanks. So we worked on that together, we talked through what was needed to be done and I think it's, and it is resolved. So that kind of interaction was awesome, by the way. Thank you for bringing it to our attention and I'm glad that we could have the conversation that we did. So, oh, question from Enrico. I have a bunch. Okay. One is auditing. We currently, I currently have no way to get an audit log of every time my key is used in WN. It will be, I would like to have it because that would allow me to spot replay attacks or whether my key has been compromised. My bank does send me an email every time I log into the home banking. And it would be, I sometimes go toyed with a thingy that generated an RSS feed of every time my key was, something that was signed with my key was like taken into the archive, for example. It was, or it could be, so it could be like package uploads, requests to DB Debianorg for changing my credential, that sort of things. That'd be nice to have. It wasn't easy, but I'd like to discuss it. And that's one. And another one is we currently require two signatures on a key for some, or one and another trust path to the core of the web of trust to accept the developer. And we're talking about Tofu. I'd like to have a conversation about possibly with you, other than I'm hearing mine, without you, about how do things change in Debian with regards to that. It could be, we want a key that has enough of a reputation attached to it that it wouldn't have been easy to create, for example. Okay. So these are both great ideas. And I'm not sure that they relate specifically to the GNU-PG packaging team. You might be mistaking my hat here. I'm wearing my GNU-PG packaging team and not my key ring maintenance team hat. So, but I don't want that hat. That's your hat. I definitely don't want to be responsible for AdNam. You're right. I was thinking about GNU-PG used by Debian rather than GNU-PG packaging. So, sorry about that. No, but those are both good ideas. And if there's ways that we can support that, I would like to. We should definitely talk about this tofu, the relationship between tofu and the web of trust. I think that the tofu proposals in GNU-PG are not at all intended to make the web of trust impossible to use. The goal is to make it, so let me actually explain a little bit about my relationship with tofu and GNU-PG. I actually have a workflow with a set of really hacky scripts that implements tofu for me. And I've been using it for two years, or three years now, where when I email with somebody and I think that's their key, I convince GNU-PG locally that their key is valid in a way that GNU-PG won't tell other people that I think that that's their key. Because I don't wanna announce it to everybody else, but I want it to be true for myself, that this is the key that they're using. So I don't think that the move to tofu in upstream is gonna make it harder for us to do the kind of web of trust connections that we're currently doing within Debian. And I don't think they're gonna get in the way or conflict at all. If anything, it may make it easier to have those connections made without making it less secure. Too many negatives. So this renaming of GPG2 to just GPG, is this something that's also being done upstream or being coordinated with other distros? We've been shipping a patch for years that renames user-bin-GNU-PG, user-bin-GPG to user-bin-GPG2. Oh really, so this is actually bringing it in line with upstream? That's right, right. And there are other distros that have shipped user-bin-GPG as a GNU-PG2 2.0 something for quite a long time now, okay. Yeah, I think Fedora's been on 2.0 for at least a little while. Yeah, okay, that's awesome, yeah. Can we please have backpots instead of being required to run unstable? Can you have backpots? Instead of being required to run unstable? Backpots of what? 2.1? 2.1? The backpots policy is we may not put things in backpots unless they're in testing. I do not plan to ask for an exception to backpots policy. Which is a good way. So if your concern is that you want it in a backport, help us fix the bugs that keep it out of testing, okay. And then we can talk about backpots. I think Noodle's had a... This is sort of a bigger point, but I think backpots are very important because 2.1 adds a bunch of things that 1.4 and 2.0 are currently mangling in Debian. And that's causing us with our key ring may have had some problems. So if there was a commitment by the team to maintain a backport, I think that would be very helpful. And if you need ma'am part of do that, then I'm happy to be curled into helping that happen. I'm writing that down right now, you know how to find me. I don't think anyone's against a backport. But we do want to make sure that it's good enough to meet the quality of the backport. There's an obvious need to do security commitment to backpots and I understand that that's a lot of work that has to be signed up to otherwise there's absolutely no point putting it in. But I think that will be very useful in terms of getting access to things like ECC out into the wider world, at least for people to play with. Right, and there may be parts of the Debian infrastructure that want to run stable plus backports that we would like to be able to accept ECC signatures on, for example. So yes, I agree. Thank you for offering that. One more question about the hardware support. I make use of tokens for GBG keys. And the support right now, it's a bit, let's say, messy in the sense that you'd have, who should be providing you the rules? Right now it's Gnope G1, I think. So if I have only Gnope G2, I don't have the rules for that. And now that you are transitioning, have you already transitioned? Why is not upstream keeping the list of that stuff? So I have to go and ask every supporter, every provider of a token, like please go and tell them to also add your rule, your ID. That's the first one. And the second one is like SCDemon, the agent for the hardware stuff. And the PCSCDemon, which is the system-wide daemon, they always fight between them. They are a bit racy. Right now, it's better. I mean, I'm not having a problem daily, but in the past it was a bit messy. Now, I don't know where the support is going. If they are merging, they plan to reuse the same kind of code or whatever. So that would be my question. So you might want to hand me a pad? Would you have to talk about that? Right behind you. You can answer this question even better. I maintain SCDemon in upstream. So perhaps if you have encountered some problem, that's because of my badness, perhaps. But these days, SCDemon in upstream has the capability to handle more leaders. I mean, it supports more leaders. So we don't need PCSCDemon anymore for most of cases. Yes. My point was also a bit as a distribution user because I have not only a GPG key, I also have keys for PCSCS 11 or whatever other secret key that I own tokens. So I start having demons for handling multiple stuff and then I have to configure SCDemon to just take care of the GPG token and not the other cards. It's like, my setup is a bit messy right now. So you're basically saying you've got you're competing with each other. So my question is like what do you plan to do as a distribution like? Do we want to set up a policy like SCDemon? Because I know that SCDemon could use PCSCD but it doesn't by default, something like that. So it's like, do we want to unify the handling of all the tokens, cryptographic tokens that exist in PCSCD and then use the other helpers on top of PCSCD or do we want to keep them split or whatever that was like, my question. So I don't have a good instinct on that and my workflow doesn't include those tokens but I'm very interested in the question. I think Nikos had a talk last session about the idea of a unified crypto policy. I was there where it was something completely different. It was more about handling which kind of algorithm and rules every library should support default. So it sounds like you might have instincts about ways that might work or that work for you or work better for you. If there are things that we can be doing better in terms of as a distro accumulating Udev rules, figuring out ownership of certain kinds of devices that would actually work across multiple systems. I agree with you. That's something that Debian is in a position to do. I'd be, I'm willing to work with you on trying to figure out how to fix that and that probably will mean bug reports against multiple packages. I also took a note of your question about the Udev rules within GPG itself and yes, those will be moving to the package that provides user bin GPG. We can talk about that in private later but my question was more like, am I the only one that is having these issues? I mean, I have multiple keys because I work in an hostile environment sometimes and I'm the only one that is having these issues that was strange for me. When I was eating these boxes was like when you're the first doing something and nobody's having the same issues. Yeah, strange. Thanks. I'm the first person in this room with those issues. Five years ago, I encountered similar issues and my answer is my own project that is GNUQ token. So I recommend GNUQ token for your project, for your use. So do we have more questions? There's about seven minutes left but if we wanted five minutes left but if we get five extra minutes out of the day there's one in the back there. This one is not strictly related to Debian but to upstream GNU-PG. It could be easier to implement the best practices. I mean, it's highly troublesome to generate a master key without the encrypted part. You have to do so many steps. If it would just write key missing the primary portion to a file and the complete key to another file and generate a secret key, it would be much easier than you just store away the complete key and you already have one that's missing the circuit part so you can use that as your protected but still daily use keys that it cannot sign other keys but yes, it could be easier. I agree that could be easier and I don't know whether that's actually something specifically for upstream. If we can find specific things that we could fix with an upstream, that would be great but I put this up here as possible futures, streamlining known best practices, offline primary keys. I mean, I fully agree with you that this is an important thing to work on to make it easier for people to do than the current dance. Yes, and about ECC, we should have a guide for Debian people trying to use ECC keys because you actually have to read that safecurves.crypto to actually know what's the problem. I mean, sometimes they are too hard to implement so you should select a cube because it's easier to not make deadly mistakes in code than the nice, the NIS-T ones and they are actually, I think, they are more vulnerable to some attacks than cube. So with my key ringmate hat on, I think we don't want to encourage anyone to switch to ECC right now. I think we want to make sure that this software is deployed so we can deal with ECC keys. Yes, but before, it's not just to have the software that can handle that, but before we tell people that, well, you can try now. We should have a simple guide if the defaults are not already geared towards that. That teaches people a bit about what are the differences between the several curves available in simple terms. Just to reiterate the key ring main point, we're a long way off being able to accept ECC keys in the Debian key ring and them to work reliably. Every single piece of the Debian infrastructure that talks to a GPG key that you expect to work on will have to have 2.1 installed. It's not even in testing, let alone stable at the moment. So I would imagine we're at least two and possibly four years off those being widely supported in Debian. That doesn't mean that we shouldn't look at how we can get them in the hands of developers and I'm glad to see that 2.1 has hit on stable which it hadn't last time I looked. I checked, so we're heckling you. So yeah, absolutely play with it, but don't expect it to work on the Debian infrastructure as being a thing you can use for at least two years and I would say potentially up to four years because of the number of systems that it will be required to understand them. Right, which is why we're switching now so that we can have it in two years or four years instead of in six years or eight years. In two years we should probably have a lot more knowledge about which curves are better. Right, and at that point hopefully the defaults, when we do get that, when it's time to turn those things on then the defaults should be simple and we shouldn't need too much. I mean, documentation is great for those people who read it. But hopefully the simple key generation steps will just do the right thing and make a strong key for people to use once we're ready for people to start using them. Okay, thank you. Sorry, thanks. Rene, do you wanna say something? Well, actually with the offline primary key are with two dot one. It's really, really simple to do that. Are you use dash dash key grip of the listing to see the key grip of the key and then you go and delete the private, the private, find the private and the private deers. We won things directory. There's a file with this key grip dot key. You just delete this one and it is an offline key. Of course you should have on your secure laptop, you should have a copy of it so you can still use it. But it's really, really easy. Just if it's not there, it's an offline key. That's how it works. Cool. All right, so thank you everyone for coming. And I hope to see you on the mailing list, IRC, get in touch with us, let us know what we can do. And of course in the BTS, we'll see you there. Thanks.