 I will start, and I will update the bits to this, to other gentleman. Okay, so we are the key ring main team. And, well, what do we do? We manage the key rings. All of my files are here now. Yeah. Oh, okay. So, well, we are, hello. We are the key ring maintain team. What we do is we maintain the key rings that define who is part of, what part of Debian, or who is in which, I don't like saying category, but, well, it's the right word. And, well, the key ring is formed from these six files or directories depending how you look at them. The naming is suboptimal because it's mostly historic. So, when I joined Jonathan, who has been a longer-time maintainer, a key ring maintainer, we only had the Debian key ring and the not used ones. Nowadays, Debian key ring means Debian developer. Debian maintainers means who is a maintainer. Debian are non-uploading developers. And the other three are kept, well, Debian roll keys is something that I guess is not used for basically anything. Most of the roll keys have moved to more specific packages. So, previously that would have had things like the archive key which has moved to its own package. There are a few other ones like that which are actually maintained by their own teams. So, we don't actually look after those anymore, but they're just running for historic reasons. And we have, well, those keys that are explicitly kept for history, those the emeritus and removed keys, but are no longer used. We don't see here, well, we do have, and I made a little mistake, we have emeritus curing PGP and GPG. Well, because of some of the migration history we will explain now. So, well, this is like an overview of how the number of Debian keys we are currently handling. We have again passed the 990 or just about 1000 developers with developer keys. We are at, well, I'll show the numbers just next to somewhere around here, but we are close to 270 maintainers and about 10 non-uploaders. I mean, this is just over time. Our history just goes back to 2008 because before that it was not maintained in a version control system. So, we have the history, but it's up to you to mind the data. So, one of the concerns recently that I'm sure people have heard about and not so recently is that we're trying to make sure that the Debian key ring does not contain cryptographically weak or weak for protocols keys that could actually affect the contents of the archive. So, in particular, there have been a couple of successful moves and some that have not yet been successful but will be soon. So, one of them was that, so PGP keys are a certificate that wraps up a public key material, but there are different formats of PGP certificates. There's PGPv3 and PGPv4 and everyone should be using PGPv4 and in fact everyone in Debian is now using PGPv4 because we wanted to get rid of PGPv3. I can talk a bit about why PGPv3 is a terrible format, but the simplest answer is it's trivial to forge a fingerprint for a PGPv3 certificate. Trivial. So, those are going away. Those went away and the final, I think, little bump down there is a nice triage that just finally said, okay, it's too late. Whereas it has GPG there, that should say PGPv4. That's okay. So, people got the message, they started moving away, some of them never made it and then there was this nice bump of actually just kicking out 17 keys that people just couldn't be bothered to swap out for V4. One more. So, the other thing that we're interested in is the strength of the key. So, cryptographic keys have a key length, different algorithms, the key lengths mean different things. And I just wanted to give a brief background for why we are trying to get rid of shorter keys. And so, this is a table from eCrypt, which is a European cryptography report from 2012. So, two years old now. And it's a description, I don't know if you can read this on the slides here, but basically it describes different types of key, these are different key types here. RSA, D-Log is like DSA and EC is Elliptic Curve. And for keys of these lengths, so this is the DSA size, the RSA size, you'll see that those are paired up, you measure the strength of a key in sort of equivalent bits of symmetric security. And there's a little number there. So, what this means is that an attacker would need to do say two to the 80th operations to crack a 1,248-bit DSA key. So, this is rough, right? All of these estimations are very rough. There's a bunch of different details about how an attack like that would go. And here they've got common key sizes that show that a 1024-bit DSA key or RSA key is about 73 bits of security. So, what is 73 bits of security? Can you go back one? So, this is the same report. You can go and find this. I can point you to the eCrypt slides. So, this is a table that just shows bits of symmetric security and then there's a description and there's a comment. And so, 73, well, 72 is the closest here. It says short-term protection against medium organizations, medium-term protection against small organizations. And there's no comment. 96, legacy standard level, roughly 10 years protection. So, 1024-bit keys are way too short for something as important as the ability to upload into the Debian archive. We've been trying to get people off of 1024-bit keys for a long time and we haven't done it yet, but we plan to. So, two forward, please. If you weren't convinced that you should boob away from it, the Certificate Authority Cartel, via the CA browser forum, they have baseline requirements, which they publish an update. This is the update from earlier this year, v118. You cannot issue, if you're a member of the Certificate Authority Cartel, you cannot issue an End Entity Certificate with 1024-bit, with anything less than 24-bit RSA, as of the end of last year. So, we are behind what the Certificate Authority Cartel is requiring for End Entity Certificates for my crappy website dot com. So, okay, so this is a breakdown of the different keys, different key sizes. These are non-uploaders. You can see that the non-uploaders are quite good at having strong keys. No 1024-bit RSA keys or DSA keys. Next? Yeah. And the Debian maintainers are also quite good. We still have a few 1024-bits in there that's 50 or so, but on balance they're much stronger. Here, I want to point out something here. Both the maintainers and non-uploaders have reacted quicker because, well, they're newer figures. So, we were able to require this earlier on, but you see there's this flattening trend. So, I think it can be harder to get to those last 50 if we don't act quickly on it. The other thing that's one. Sorry, yellow is 1024-bit, purple is 4096. Green is 2048. Yeah, so just to actually back up a bit, our current recommendation is that people use 4K keys. We have allowed 2048 keys into the key ring. So, in general, people are going with the recommendation. There have been some reasonable reasons to use a shorter key length. In particular, the OpenPGP smart cards were originally limited into the key length they could support. Anyone who doesn't have a restriction like that, we really are saying 4K keys, which is why you'll see them being the predominant key length. The other thing to point out about the maintainers is some of the down trend in the 1K keys here is because maintainers become developers and that's a straightforward transition of key and we haven't necessarily been enforcing a key change at that point, Phil. I can repeat the question. Sorry, shouldn't that be a... Phil's point is that we're only looking at the key length of the primary key on the key. It could be that the sub-keys are either a longer or a shorter length. Longer doesn't really help because you're still limited by the primary key, but if the sub-keys are shorter length, then that could mean that they are weaker than they seem. I think in general, what I've seen is that sub-keys are usually longer, if anything, but usually the same size. Well, and this is the graph that worries us most. Although we have a converging trend here, this is for the developers. And here it looks we're heading in the right-to-the-direction. You can very well see the places where we've sent mail, sent posts and things to the people to really update. You probably can't see the scale of the backboard for the next five years. Is there a second mic? Do we have a second mic? Maybe we'll come to you. So the point has been made that we could cross-reference the line with a number of people here at DebConf. I have a list of all 517 short keys, and I need to talk to the organizer to try and get a dump of the people here. There's no easy way to do that at the moment. Steve, you were next. Wait, until I saw that number, my question was going to be, why haven't we just dropped these people already? They've been told a dozen times already. So we have already started looking at that. Of the 517 keys that are short, 253 of these people are already known to MIA. So yeah, there is an issue there about what's going on, and we have already started having discussions with both DSA and MIA about what we do with these people. And we will eventually get to the point that we dropped them. Please, name and shame. If you know someone on this list, go and slap them. Yeah, part of the thing is, we didn't want to push this too much earlier, because, well, you can see we started like really caring about this around 2010. And that would have meant either a tremendous amount of work for us that's coming, we know it's coming, but also that we would end up locking three-fourths of Debian out of the project. Nowadays, we're only going to lock one-half of the project away. Half of them are MIA. Yeah, our estimation is that most of them are not active currently. I should clarify the MIA figures. It doesn't mean they're actually MIA. It just means that they are known to the MIA database. They are in discussions with them. So it could be people who are just not completely active or haven't been seen rather than people who are truly missing. So it doesn't necessarily mean that they really are people we should drop from the project. And one of the things we've been very careful about as K-Ring means is, we don't want to kick people out who actually still have an interest in being involved in Debian. We don't want to force people out of the project. And that's the line we've taken so far, and it's come to the point that we are actually going to have to drop people. There's a sense of time, because we really did want people to have an opportunity to get it sorted, enough time to come to a DEBCOM for another local event and get a key cross-sign. And we felt that we've bent over backwards and made quite a few meals about get this done. And now comes the time that we really do need to sort of say, take a harder line on it. Well, we will now show, until now we have stated facts. I will also continue. Oh, please, Enrico. Once the obvious ones like MIA and so on have been taken away, then I think we enter the domain of people who are not necessarily paying a lot of attention to Debian Dev Announce. And I'll be glad to send around the emails to those people with Damhat saying, hi. Yeah. Okay, so what we're going to present now is how we want to go forward with this, and also some bits of the problems we've had, right? So, yeah. Oh, I didn't update this, sorry. Well, anyway. It's more or less the same. Oh, yeah, right. I did update it. So, we finally were talking about setting up a cut update. Yeah, after the end of the year, after the last day of the end of this year, we will just disable all 1K keys, because, well, I think there's an agreement that we can and we should do this. Well, it's... So, that's a good response because what we're considering doing in terms of this is, we'll send a meal to DDA, which everyone will ignore, because I think anyone who's paying attention has hopefully already made the switch. But I know for a fact that there are at least three people here at this conference which, so even people who are paying attention to DDA and turning them to events have not done this. Stand up. Find them out. I will name them once I have got a definitive list and have emailed them once. No. You can take the Debian keyring and do exactly what I did, which is dump it, look for the 1 or 2 4 keys. It's not hard to do. We will mail all of them individually as well and send them a meal going by the way, this is going to happen. So, we're going to send those meals out but we did want to run it by people first as going, this is what we're going to do. So, let me also say that the bottom point here is kind of critical. There are three different kinds of developers that we can imagine in this situation which are people who are who are... I'm sorry, this is... There's three types. There's people who are ignoring people out of Debian who are interested in maintaining the infrastructure that they need to keep Debian secure. Just one thing about this is, well, there are many special cases we are reaching the point where we will find a way to somehow kick those cases. Something that was quite a strange to understand how is that... when Anibal sent the call for keys for the key signing at DebianConf, we got like 12 1K keys that, well, they were kicked out of the key signing party. They will not take part of this. Well, one of the... Maybe it's... Yeah, one of the things that maybe difficult sometimes is that there are many people who are not socially involved in Debian so those are the faces we don't know and those people they have a hard time maybe they don't... they care about their particular each but they do not care about being a member of socially a member of the project meeting people and all that. So getting their keys signed is also difficult for many reasons. Not only because they are far away but maybe because they don't feel like at home socially with the rest of us. I don't know. Thing is up to now a very good thing is that I feel that we have as a project honoured to meet a person before signing their keys. A lot of people are on the word and being nice to people that have been part those far-off Debian projects. So on one hand I like to de-emphasise the fact that we are not kicking out people of the project. So technically where you are acting on the key ring will make them unable to do specific kind of participation in Debian but I pretty sure that them when those people get a new key in the key ring will not have them go through NM again. So it's not like we are kicking people out of the project. We are putting in place technical means that sacrifice their current ability to participate favouring the security of a lot of people around the world. So this is one first comment I wanted to make and the second one is that we are very much likely in a 80-20 situation in which I think 80% are people that are not paying attention and maybe 20% or maybe 5% are the people with specific condition you have mentioned. So I think you should put in place a process that takes care of the 80% of the people like mailing them now they've had four years to migrate and saying okay if you have a special case that need our attention let us know in one month otherwise in two months we will just disable your key and for the special case it's well I think that's very important so we can consider asking funds to fly people to them and sign their key in person instead of creating precedents for you know signing keys without being tested. I did at one point make a joking suggestion to a DPL I can't remember exactly who it was that Gunnar and I should get to fly around the world and personally verify every single DD's key but for some reason that didn't get accepted. The other thing we have considered is that there are various other webs of trust that we can tie into. I know that kernel.org have got fairly strict about getting their keys cross signed so we can potentially piggyback on some of those for developers who are geographically remote from other DD's but are actually close to other free software developers and we can get trust pass to them so some of that we will consider and I think that ultimately it comes down to case by case basis for that 20% and I hope this doesn't apply to anyone in the room. It's for people who are watching on the streams or people reporting this afterwards. Anyone at debconf has no excuse for not having a larger key signed by two DD's. At least the other thing also remember is sign keys with your new key. It's a web of trust that needs to link both ways so don't just get signatures on your new key but make sure you have signed people because I think we are actually strengthening the network. Can we bring those people to debconf instead of flying the DPL or you guys to wherever they are? We have this debconf newbies initiative that part of the air for return refund we do are usually meant for people who have not yet come to debconf. That's one way to reach out to them but yes I have talked with some people who say well no it's not my interest to go debconf. The reason I say this is then they can get more signatures on their keys by a larger variety of people. The other potential has been for local groups to cross sign each other and then get a couple of those members to then come and visit somewhere else and get it signed so you can actually do that much more efficiently as long as you have a concentration of developers somewhere that makes sense. To jump on what Zach said do you know if FTP master is intending to actually block uploads from these keys because the security is the concern and they would be concerned of getting uploads from untrusted keys so maybe one way to enforce that would be to disallow uploads but not dropping the keys from the key ring. So the problem would be that the reason we run several different key rings and maintain them separately ourselves is because the various users of those key rings determine what to do with the key by which key ring they're in. One potential option if we want to keep people uploading without having them be able to upload anything which is the major issue is that we downgrade their key to a debbie maintainer key which would mean that they're tied very much to only uploading their own package so they're not disenfranchised in that way but we lose the security thing but really at this point no, I don't think that's worthwhile. A very special case we will potentially consider that but it would have to be incredibly special to say that that's the thing because then you've still got a weakness there it's just you've limited it to one package. If we get down to a point where we have a smallish number of people left who for whatever reasons can't travel, haven't traveled whatever, definitely please, don't necessarily name and shame and I would suggest of that earlier tongue in cheek if we can find out geographical areas and post a list somewhere there are a lot of us who travel anyway as part of our work in the last year alone I've met up with probably a dozen people outside of the UK and I've signed including people in the Bay Area who managed to not meet all the Debian people that scared me you know it's not easy necessarily there are going to be some people who might live a thousand miles down a beaten track and we will never get to see them but we must be able to solve this one of the I don't know, eternal huge places that comes to mind that many people there have had problems is Canada there's a very large amount of Canadians who are far away from anything and they so when you were talking about possible trust paths with other organizations I just wanted to mention that for the Guinea project we're also evaluating our current signing policies key ring policies for FTP upload where a lot of the Guinea upstream packages live so we've been looking at the Debian policies and trying to see if maybe this could help with some of the if we could link those communities together possibly more signatures could happen that way too it would surely help I think so yeah when it's about people who have issues meeting other people to get signatures it goes back to the known problem of verifying them in the first place which is something we at front desk already struggle with and have several ways including sometimes mailing private so I don't think that is an issue that's just something we already do and I'd be happy if people get in touch happy to help the issue is probably what do we do with people that don't get in touch and which I would think Mia is kind of the point I think the problem here has been that there are still lots and lots of keys that need dealt with well whenever we did the v3 migration or getting rid of them quite a few of them had two keys in the key ring they had one v3 and one v4 it was easy enough to remove quite a lot of them were people who been in the project for a very long time were actually quite well connected and can get a new key or already a new key so it wasn't the short tail at the end of people who needed chased was quite small and at this point we're aware that if we just sort of dumped 500 people on dam or mia or whatever it is that's quite a lot so we are going to do an initial round of meals and try and get the easy ones done and kick people into actually reacting and then certainly we will engage with any team who wants to come and chase those people and I'm all for the actually producing a list of people who need to move their keys it's not a naming and shaming but it's about people who know them maybe being able to kick them into action if they somehow missed a meal or realizing that they know someone who needs a key signed and they can go and offer and say I'll sign your key get off your arson do it this hasn't been said clearly and so I feel the need to say it these key ring things is because one compromise key will have a huge impact on the whole world I'd like to sleep better at night just please move that forward we are living in a post-Snowden world I mean if people part of the project can't understand that they have at hand the responsibility of thousands of hundreds of thousands of people then I mean sorry read again the social contract priorities, users and and so that's one thing the other thing is that there is the security of the individual keys and how developers manage that key and this is a complicated topic and one thing I would very much love to see I love you yep I mean I was I would love to see the key ring maintainer put up a best practices document and maybe I would love to see the project funds smart cards for any developer who want one yeah well thank you for this I completely agree with what you say and I was telling them well maybe we should right now interrupt for a little discussion we have just one more point here in the key of things to say one point that will probably bug more of you because we don't do it I must say well my own keys I don't think they're properly handled and I should be among the first to change this so we've been talking for example how can we improve the key handling practices well for example separating the main key from the signing keys requiring keys to expire and technically we can easily as the checks to see if all of the keys we have are I mean we got an expire expirable or can I just justify that for a second so some people are probably horrified by seeing a recommendation or even a possible requirement of key expiration and so I wanted to just explain why this is potentially a reasonable thing I know that many people don't have an expiration date set on their keys and they have a revocation certificate that they have offline some place so that if they lose their key or their key gets compromised they can just publish the revocation certificate and be done with it in that case those people probably there is no good reason to argue that they need an expiration date but we can't know from the outside whether you actually are maintaining your revocation certificate properly and we would like to know that you are trying to maintain your key and if you have an expiration date set on your key it turns out that you can update the expiration date so if you update it every couple of years and move the expiration date out you will have an expiration date on your key and by updating the expiration date you are proving that you still have your key at the very least you can also even update it after it expires so just it's worth being aware that you can do this and that you should maintain your keys and that you can actually add new self-siggs on your keys as your key handling practices change you can add new sub-keys and so forth and so setting a key expiration publicly is a way of ensuring that people get a copy of your new updates from the key servers and say oh this key is expired let me refresh it and then they will get whatever updates you have updated so expirations have other advantages beyond like your keys suddenly disappearing if the use case you have in mind is just see that the person still controls the key that could just as well be done by seeing that they have used the key like signed something recently or be okay also to just have expiration dates on sub-keys because I would still you're missing the last use case that I mentioned which is that people probably will update their keys if they're maintaining them and they may update by signaling that they prefer different cypher suites they may update in other ways the only way to get people to notice that is to make sure that they refresh their keys from the key servers so expiration dates on sub-keys still fit their requirement so after two years my sub-keys have expired somebody needs to re-download my key to see that there's sub-key material that's usable that's true might having expiration dates on the master keys help mitigate the 1024 problem probably not because your master key would still have been 124 the keys would have just faded out so the keys wouldn't have faded out what you could potentially use it for is a way of saying this key is obviously not an active use and then potentially flagging that to the MIA team as this key has been expired for a period of time and therefore might need to be looked at if it's been expired the point is that actually if it's been expired then the FTP won't accept signatures from it and that's actually probably a good thing if the key is actually idle and it's a weak key and so there may be other changes that we want in the future we've talked about v3 to v4 we've talked about 1024 bit to larger than 2048 bit there may be other changes that we want to push in the future and requiring an expiry gives us at least a window that we can say okay when the next change comes down the line potentially elliptic curve crypto I'm not requiring this now I'm just like putting it out there that there are other possible changes that we will be pushing for having expiration dates and all the keys in the key ring will make sure that we have a window in which we can actually do that kind of transition that everyone knows about and has seen from the beginning just wanted to point out there is a utility that you can install it's in Debian written by someone who's here at DefConf that will keep your key ring updated over time by slowly refreshing all the keys over tour so you are not exposing your social graph called parsimony and it will run in the background just keep everything updated for you I recommend checking that out although I believe there's like someone rewrote parsimony and it's better somehow I forget exactly how but like it's on github so there may be two versions yeah there's a it's written in bash I'd just like to point out that education and documentation could help here when I was doing signatures recently it wasn't clear to me what a signature meant what it meant for a subkey what it meant to change a parameter on a key in terms of signatures and all that kind of gets in the way of going forward on this if it was a clearer what exactly it means when you do a signature and what you can and can't do after you've signed a key validating either all or part of that signature and what does it mean to have a subkey and what does it mean to have a signature on master versus a subkey all that stuff is really not covering the documentation as well as it could be and if it was it would be easier for a person to sit down read the documents and understand what to do next well I agree the documentation is very important but on the other hand I mean there's so much documentation about crypto handling I don't think we we have to rewrite or even mirror all the available documentation I mean you are right maybe we should try at least to link to explanations we have tried for example to show the process one that comes to mind is when Anna wrote her instructions on how to generate a proper key well we just copied over because it was very well done and it was meant for our use but there's so many things that we can do about what it means to split a key between the subkeys and how to do that it gets too much in the details and all there I challenge you to look at to see what it means to sign a key and what you can do to change it without invalidating the key it seems very straightforward and I couldn't find a way to do it without getting into the source code so I would be happy to try to work with people who want to do that kind of documentation I worry that I've internalized too much of RFC 4880 to be able to write in English anymore but if someone wants to I'll just talk about what the scope is for the signature just when you sign something this is what it means sure and what I'm saying is anyone who wants to work on something like that who wants to run it by someone who knows the gruesome technical details to make sure that the documentation is both accessible to someone who is trying to get something concrete done and is not technically incorrect I would be happy to collaborate with that I'm not sure that I will be the one to be able to write the specific accessible stuff but anyone who wants to come find me, I'm DKG I would be happy to work with you on it Yeah, I think if anyone does want to work on such documentation then they can quite happily run it by keyring.debian.org and I think if we got something that was how to we would happily put it up on keyring.debian.org for people to be able to go and view but we're not the right people to write the accessible documentation because we've been doing this for years and some of it is second nature and we won't think of the right questions but to help someone who sort of wants to bridge that gap absolutely Let me also say that one of the problems is that Debian developers in their crypto handling process and in their packaging process and everything are a remarkably diverse group I suspect and so if we say here is a way to do it we're going to get pushback from people who say well that's not how I do it I do it better because it's better like this and it may well be better for them so this kind of documentation would be great to have to say here are three styles and we can pick them out and work on something like that and have something nice and concise that explains the advantages and the comparisons between the different styles I think that would be useful but it's still not one thing I would just say that on that point one of the things that we've done in the python team is we've said we have a strong opinion about how things are even though there's lots of options and we have the main path down the documentation is here's how to do it and then we can have links that say well there are alternatives go look over here if you're really interested in that but I think having a strong opinionated way which is largely maybe your consensus best practices is really helpful to people because a lot of people don't want choice they want to know what is the right way to do it and yes there's a lot of options but so I want to highlight that there's a tool that's called I think it's in Hopin PGP-Tools package that's called it's a Haskell implementation thank you Clint Adams but it's hokey lint and you can run it on your key and it will give you a list of suggestions about what you can do to improve the situation of your key itself so I recommend checking that out no valve games for users of one or two four bit keys problem solved that's not an incentive for some of us are we done with the slides did you get to everything could you say briefly something about the future of Hopin PGP itself well you were trying to get it to update so there's two questions here one is the future of Hopin PGP and one is the future of GPG in Debian and so I'll talk about Hopin PGP Hopin PGP is moving at a glacial pace towards elliptic curve cryptography which is not widely implemented but I don't know if folks have seen Google has produced a not yet distributed alpha version webmail plugin for Chrome called end to end encryption that generates new keys that are elliptic curve keys new PG's 2.1 beta has elliptic curve crypto in it so there's a push towards they're much smaller keys that per strength so for something comparably strong the keys and the signatures are much shorter it's a different kind of crypto and it will be hopefully available in experimental possibly by the end of debconf so this ties into the evolution of GPG so if folks are interested in experimenting with newer versions and newer crypto they can either come to the GPG mate session or come find some of us afterwards and watch experimental it's worth pointing out that this ties somewhat into Wiki's talk from the other day even if we get elliptic curve crypto in not Jesse but whatever comes next until that release becomes stable and is deployed throughout the Debian infrastructure we will have no way to accept those keys as part of Debian because nothing will be able to verify them so it will be some time before we can accept elliptic curve as part of the Debian key ring which is kind of unfortunate I have a moderately related question about strength which is that apparently the case that fingerprints are always SHA-1 and I was wondering if there are standard practices to get away from using SHA-1 here so there is some open PGP v5 format which will standardize on a separate hash and I think it's SHA-256 or SHA-512 there's no decision yet one of the things where the changes from v3 to v4 was v3 was using mv5 some over a different set of the key material which is part of the problem and v4 moved to SHA-1 but that's going to require an incompatible change in the actual PGP format so yeah you don't have to use SHA-1, you could use mv5 by using the v3 keys yeah, you don't do that that is not a serious suggestion this is actually the way that you forge a fingerprint in open PGP v3 the fingerprint is actually done by an mv5 of the modulus so RSA is a modulus in an exponent and it's a mv5 over the concatenation of the modulus in the exponent so the way that you forge the fingerprint is you just cut up the bit string in a different place with a modulus m and a new exponent e and you just look for that until you find a factorable m' and now you've got a key that has the exact same fingerprint so that's been fixed in v4 keys as of 20 years ago 12 years ago, I don't know, a long time ago but I wanted to talk about why so we can move away from that and that's a cryptographic problem but the SHA-1 for fingerprints is not I don't believe that that is directly attackable right now so SHA-1 is attackable for collisions no one has published an SHA-1 collision but actually open PGP v4 fingerprints are not a situation where we're worried about the collision resistance of the hash we're worried about pre-image resistance and pre-image resistance is significantly stronger than collision resistance so yes, we are moving away from SHA-1 but for the fingerprints themselves so another kind of related question is I guess inline PGP is not cool anymore and we use it all over a lot of our infrastructure in fact, even curing.debian.org when I looked at the process for updating keys it says don't use PGP MIME because it breaks it please fix request tracker please fix request tracker not to mangle PGP MIME and not to decide to re-encode meals and not to do all manner of things absolutely PGP MIME meals is the right way to do things as far as we're concerned but we're limited by the infrastructure we have RT will actually do signature verification for you but for hopefully fairly obvious reasons we want to do the verification ourselves rather than trust some random piece of infrastructure even sometimes it's quite bothering we have encoding issues when we have some keys correctly sent to RT inline signed but somebody used, I don't know, the wrong charset or whatever and we can spend hours looking for what's wrong I actually know what goes on here what actually goes on is that the likes of MUT will choose the best character set it can find to try and represent your meal as 7 or 8 bits so rather than coding as unicode it'll for example use Latin 1 and RT in its wisdom decides that it's going to re-encode everything into UTF-8 which is fine but then it sends out the meal in UTF-8 so your meal has been re-encoded from Latin 1 to UTF-8 and therefore doesn't validate when we receive it anymore line wrapping also happens there's a whole bunch of things that mangle meal that then mean that you can't validate the signature and I've got quite adept at trying to figure out what they are and fixing it up so they validate without having to go and bother the developers again but yeah but fix RT the archive is generating signed meals which are pretty much the changes file rather than I mean you'd have to basically take the changes file that has been uploaded what you've done is you've uploaded a clear signed file you'd have to take that apart turn it into PGP MIME thing and I think that's a bit more understandable I think that we should all be able to send PGP MIME meals and have them just work and I will accept that the Keringlient team are the worst example of people who can't just accept PGP MIME meals but we don't have the time to go and fix RT and we're very grateful for DSA for running the RT instance for us and we don't expect them to go and fix it so yeah please send patches I just wanted to add something to respond to the question about the future of new PG I know that the project itself is moving pretty slow at times and part of the reason for that is the developers are having difficult times sustaining the development and so they're looking for help not just actual help but funding to keep it going so if you happen to be a large company with lots of money to throw around I know they're looking for some it might help move things a little faster I don't know but I think the new PG needs a lot of labor help to move things quicker also on that subject there's a GPG1 and a GPG2 and I don't actually know anything about what the difference is or which one I should use and then there's also like a GPGV and a GPGME and it's got something else for someone who doesn't actually care and just wants to sign things and just wants to verify things what should I be using is there a canonical just use this answer on your Debian system no matter what so you can just use that but this is the wrong talk for that this is keyring mate not GPG mate and GPG mate will actually have a talk I believe it's tomorrow and please come we'll talk about the details there's been a lot of discussion about what we can do to improve that situation but that would be the place to talk about it you've already got it it's there it works any other questions yes there's a key signing event 230 to 315 and I believe it will be in this room correct yes it will be in this room so come to that get your keys signed alright you're out one minute early