 Okay, next up is Gunard who is going to talk about our PGP key ring and what we can learn from it. Thank you very much. Well, first of all, I've been working on this information, well, more or less started doing it for fun, because well, as part of what we did in key ring maintainers, led me to start wondering how does our snapshot of reality look like. So this is not, don't take it as something seen to be improving the avian, or even you can even see this as something that was made by an outsider. Not that I am an outsider, but the view I'm taking here is, well, objectively looking at whatever information I can gather from the key ring and trying to explain some bits about it. The thing is, the work that started me going on this is what we did in DevCon 14, that's when we kicked off what became the migration to strictly greater than 24-bit, 2024-bit keys, because, well, there were security liability by then. And, well, I'll start showing this first with the graphs we used then. This is a graph that we showed two years ago, showing how it was taking so long for us to migrate away from short keys. You can see several, one of the most responsive people did the switch here at first, but then the trend was very slowing going down. We were very happy that we were almost at the point of crossing. In fact, I think we crossed during that month, but the trend showed we would take at least three, four, five more years to do the final changes, and, of course, that would become flatter and flatter over time. So, well, that's what prompted us to do an aggressive change. It was quite a lot of work for us. I mean, not that we didn't know it, but through less than half a year, we replaced over 250 keys. And we were happy with the result, I think, although we did have problems in the end, because, for example, close to one-quarter of the project lost access to, well, both uploading and voting rights, because they are expressed, well, through having a valid key, right? And, well, 18 months, no, yeah, 18 months later, 200 dds still have not transitions to a valid key, so they are effectively locked out of most of their project rights, right? This is how the key ring looks like. The devian developer uploading key ring. So, well, yeah, this slope was, well, very abrupt. And, of course, we have managed to gain back these bits that we had lost by then. But, well, this prompted me into looking at this same information in different ways. This is fun to get, but I wanted to understand a bit more what social interactions can I get from looking at the file we have. So, currently, I saw, well, not today, but while I was in the plane, we had 816 valid keys for devian developer uploading. And, well, I'm focusing on those, of course. I mean, because they're, like, representative, devian maintainers are a very different case, but I'm not going into them. I'm sorry because of time constraints. I have not digged into that one. And we don't hold maintainers as, like, a source of trust. So, it's a difference. And non-uploading, there are so few that I am sure that, I mean, I'm looking at them separately because we keep them in separate directories, but it would not strongly influence anything. I'm almost sure. Okay. So, I decided not to stop there. And they started trying to draw the dataset we have. So, well, what is the as strong set defined related to a key ring is the largest set of keys that from each of them, you can reach all the others. Yeah. There's, like, a looser definition that I'm not using. That's the reachable set. You have somebody who cannot reach back via a trust relationship, but can be reached is in a reachable set, but not in the strong set. The strong set is all connected. Like, you can trace the trust paths between all of them. And this is the, well, the first thing I measured some months ago is how much the proportion of the strong set vary regarding to the total number of keys. I was supposing that we would lose a lot of connectivity by doing the roll over to larger keys. And, of course, we had some interesting jitter here. We started here with the migration. But the lowest point we have, I mean, this starts at 70. The lowest we have was 82% reachability. The highest is 89. And we were, like, at 88 and reached 89 here. Of course, here was the lowest point ever. I'm going to explain why very shortly, but it was, in some way, expectable, right? I'm sorry for relaying IRC over here, but it was... Okay. So how did I graph the rest? Well, I used GraphVis. Why did I use GraphVis? Today, I realize it may not have been the greatest choice. GraphVis is a great tool for simpler diagrams, but it's not meant to track a set of keys that change over time. So what's here like this, it will be like that in the next one because each graph is unique. And I don't control, or at least I haven't dug enough to control the algorithm that positions things. And also, when dealing with large amounts of nodes and edges, it becomes just too slow. Yeah? In this computer, for example, this is a very low-end laptop. It takes about 10 seconds to generate each snapshot. And I'm generating about 300 snapshots when I'm doing it fully, okay? Of course, the first thing I need is to graph the key ring. It's beautiful. It's boring. It's useless. I mean, it's just a blob. Yeah, it has some spikes, but I asked a friend who works in psychology, sociology fields. What do you want me to do with it? It's useless because analyzing social graphs deals with small bits of it, small pieces. Yeah, here I have some, say, here you see some isolated, some islands, some people that are not connected, which are not in the strong set or things like that, but this doesn't tell me anything. But this is a recent photo for us, right? But the thing is, as I generated a graph for each tag, that means for each upload with each key ring push, I found some that were like this, right? Something very strange for me. This is from before, just before we started the transition. So the transition didn't yet affect, but you can see here it's something that's splitting in half. And well, it got me scratching my head. Yeah, what does this split mean? Why does it appear? Where does it come from? Why is it there? So I took several snapshots. Well, this is generally, I mean, the top row is more or less each year, 2010, late 2010, 12, 13, sorry, the months are in Spanish. And here you see how it was, well, it's hard to see maybe in this resolution. It was a blob, then by early 2012, you start seeing groups separating. And by 2014, it was very obvious. And this is when we started actually the immigration. So this group starts getting smaller and smaller. And by the end, when this is December, this is the last time we had the short kiss. What we effectively cut away was just a small portion. And by here, well, that group disappeared. So I started, well, trying to understand what that was. So I came up with a hypothesis that's something related to curing aging. The thing is we are a long running project and the GPG has been, well, PGP, which GPG is an implementation of open PGP. PGP has been a constant trait of the project for a very long time. Not for all the project history, but say since the late 90s at least. We don't have the history for the first years, but the social interactions that happened over 10 years ago may be getting lost or maybe falling away because those people, well, it's logical that are having new interests and may not remain connected, say for some few cases. So I tried to get the graphs colored. It took me a long time to get this straight because my scripts were so, so, so badly written that it took six minutes to generate each one of them. When or something like that, when I rewrote the script in a much simpler way, which are ugly and I don't want to show them, I will show them at the, I'm sure, but it took me like 100 times less. So I was very happy. So I made these next graphs with blue for less than one year, green one to two, yellow up to three, orange up to four and red over four year old and I'm graphing the edges only, the signatures. I'm ignoring self signatures and I'm ignoring the keys because here they are not of much value by themselves, right? Well, it doesn't look very nicely, it looks very different than my screen, but you can see that this was occurring before the immigration. So yes, this whole blob was a red thing. All were very old signatures over five year old and here we have a lively community. Today, this is a, well, in June, we have several old key, old signatures in our living key ring, but it's all full of different colors. It's all mixed. That means, I understand that, that means that maybe, well, my 4K key, I started using it in 2009 and many other people started by that year as well. So we got it connected and our signatures will remain in because, well, they are between two valid keys. So I did the same thing we had before and yes, the red blob, of course, the colors are relative to the moment I took the snapshot. So if this was, well, I don't have, I can see the dates here, but this was early 2010, the red signatures are before 2006, right? And it does follow this same pattern. We had a large body of very old signatures that were slowly being pushed away by people retiring or by people slowly migrating to newer keys. So this is more or less, this more or less coincides with this here and here. And this is, well, much more often during the 2014 where we see this split. So, well, yes, in the end what happens here is that there is a body of old signatures that weren't socially integrated with the rest of the group and as the rest of the group migrated away from their old keys, started becoming a separate group until, well, they were cut away. It seems to confirm what I initially thought. I haven't really, really checked each case of them, but well, it seems to be so. I know that, and we will talk about this, I mean, in the next session that some of us are going to be in that's like explaining bits of what the key signing is and how to do it. Signing a key doesn't mean I trust you as a person. It just means I trust that at a given point in time, the person I'm talking with and I have somehow identified holds control of a given key. It's an important measure of trust for us because we don't get to meet every day. Not everybody gets to meet at DevConf. Not everybody goes to every DevConf. So we do need this as a bit of accountability to real world threats. This is the only bit that links our electronic activity to a physical identity and well, I hope we don't need it. But in case we needed to find who did something, that's the only way we have. So how long should this trust last? I am starting to advocate here for expiring our signatures. When I sign your keys, I should do it in a way that the signature lasts for as long as I recognize your face. Of course, I don't know how long I will remember you, but I can sign, for example, I'm trying to start signing for three years and probably after some time I will start checking, well, of the people I already, I have on this list who I still remember who they are, who are not, and I can renew my trust on them without having to meet again. It's just as if I were following a transition statement but signed by myself, right? If you see it this way. So how would this look if we were to expire by default? We are not going to do this, but well, we have a curatorial process. Creation means, say, in a museum exhibit, an artist brings a whole lot of works, right? And the museum curator says, well, I want this one here, this one here, because I don't want. So we do more or less the same. That's what keyring maintainers do. From the whole available keys in the universe, we form what keyrings are meaningful to the bien. So what if we started expiring old signatures and didn't treat them as valid? We are not going to do this. I mean, we talk this and it's not like our policy and will not be, but it's an exercise I'm playing, right? How many people would fall off the strong or the reachable sets if we were to discard the old signatures? Or how much would the keyring change its shape? If we were talking six years ago and expired keys that were older than five-year-old, then I mean, this is the snapshot I showed you before and this is how it would look if we were discarding. And I'm sorry, well, we don't have a better resolution here. You can see there's noise around here because those are dots, those are dots that are no longer connected. To be honest, I didn't get the exact numbers. Here you have more dots because there are more disconnected people, but they are just smaller so we don't see them. One of the details of graph is that I didn't really control. But the thing is I did write down how many signatures are being expired. So here we have over 6,000 signatures that were no longer taken into account, right? And well, what I get from here is that the resulting sets are very similar to those sets, to what happens after we have to remove these keys that were smaller thus older, right? Again, I know I have to do a lot more numbers on this, but this is as far as I've got. So, well, I can later show whoever's interested a better resolution form of this. I intend to make this all available. Well, my talks are already in the annex, but the graphs are higher resolution than what I used for the PDF. So whoever's interested, please contact me and I intend to publish this all. Now, how can we ask GPG to sign with an expiry date? That's something that's not very common. I haven't seen this advocated. Microphone, yeah. Maybe you'll talk about it in a second so maybe never mind, but when I looked into these features I found there was no way for GPG to ignore the expired certifications and I wonder if you have found a way. To ignore them. And I haven't searched for it. You can filter from your... Yeah, I want to write some scripts to help you, like filter your stats and get what needs to be refreshed. But no, I haven't found a way to discard this information, right? So GPG has an option that's ask cert expire, right? And we can set it by hand when we call the GPG binary itself, or we can set it in our GPG.com. Just if we do remember that tools such as CAF usually have a second GPG configuration, we will go in the other session into a brief explanation of what CAF is and how does it work. Remember to do it from the tools you use to generate the signatures. Okay, this I went on a different path just to understand again how this goes on and there's a lot of work I have not yet finished and I intend to keep working on this direction, right? What's this about asymmetric signatures? Well, we were talking what other things should I look for. So asymmetric key signing, we usually meet in pairs and I check your identity, you check mine, we exchange fingerprints and we sign each other's key. But it has happened to me a couple of times in the past that I get a mail like this, right? Okay, my key was in the DEF CONF key signing party key ring, but in the end I didn't go to DEF CONF, so you didn't meet me, but you still signed my key. Well, it happened to me, I don't know, I hope nobody else ever got such a mail. Okay, so I looked for how many signatures do we have that are only in one direction. Of course, this does not mean that all of them are result of sloppy practices. Sometimes, well, I don't have a passport on me and I meet with somebody and well, I will sign their signature but their fingerprint, they don't have to sign mine because they didn't check my identity or whatever. We don't have to have a really matched group as long as we have a strong set that's enough, but I still did this, oh, it doesn't even show. There's a blob of red on top of this. So here I graphed again over time how many red lines mean signatures that are in one direction only and well, I don't have much more data than this single number. I can tell you it was around 26% and over time it has kept basically constant. I didn't even graph it like a single line, but I can tell you that well, it was 25.8% in 2010, 27.2% in 2012, 27.17% in 2014, now it's at 24.36% and well, it doesn't vary that much. It's in average 26.6% and well, that may just mean that it doesn't mean anything but that's one of the checks I'm doing. I want to play as well. I think I have here the further ideas. There are many other things I want to start doing with this. Again, this has nothing to do either with cryptography or with security or with Debian itself. I'm just taking a set of data that maps us all and I try to understand what else does it map. What can I understand from it? Which algorithms were used for signatures? Because well, that also can say, well, I want to discard all signatures done with Shawan or if we still have any with RC5, I doubt we do. How many islands do we or would we have where we have some change? This is an island. This is the definite proof that Debian is satanic. For a long time, we had this five-point island floating around. It was there for most of 2014 and well, it's gone. Now we absorbed it. How many islands are there? What's their shape? Or for example, do some further guesswork, right? What's the minimum degree of connectedness? For example, to migrate a key, to replace a key for any developer, we require the new key to be signed by two people so we can avoid impersonation, impersonation attacks. Two people should certify this key belongs to the person who previously held the other key. So what would be the minimum degree of connectedness to consider a key or a group as belonging to a strong set? Maybe we do have some inner boundaries. I don't know. I don't think so, but I'd like to check a bit first, right? Identifying main hubs. Say, I know that I am quite well connected. What happens if we extract my key? Say, I retire, so my key is no longer in the key ring. How much does the connectedness of the key ring suffer? How many people, how many hubs would we have to remove to create a divide or things like that? And well, whatever ideas we can come up with starting with this set, right? Again, I don't know how this, besides this idea, trying to push to expire our signatures, I'm not sure this is really contributing to Debian, but rather using Debian as a source of information. But well, I'm very happy you were here interested in what I have to say. As for this conference, well, this is a graph of the key signing party key ring we have. It doesn't say much. And again, well, projected on screen, the resolution doesn't give us many features. But say we have here some floating keys. Those are most important to get signed, most important to get connected with the rest of us. Who is, say, here away? This person is clearly in the reachable, but well, it's most probably in the reachable, in the strong set, right? Because I think you can reach here, but not back or the other way around. I'm not sure. I mean, many of you saw that from this map, I generated also a personalized one where each person, I'll open it, well, each of us. I think I don't have it here. Well, anyway, it's on my People Debian org thingy. And I mailed it so you can check how does the key ring look from your perspective, who is connected to you. You can check for the post in the DevConf discuss list. I sent it recently. And well, this is a point that Anibal requested me to do. I think it's important. Although here, we cannot really check this. I just show here how I got to this number. We're going to do, and I'm not going into details on this key signing party that we're doing right now, because it's the subject of the next session we will have. But from this URL, I got the list of participants to the key signing party. And if any of you have their lucky number, first, if you don't have the lucky number, that's very bad for you, because it's not a, I mean, we will not start at the same time. It's very important that before doing any key signing, you check this is the SHA255 sum of the... And check for your key. Of course, of course. Check that your key matches what's on the thingy, on the file, and check that this SHA sum matches the one on the document itself. And well, basically, that's it for what I have prepared. So yeah, please, we have some questions and we have some microphones. I fear the questions because I don't have answers. Will it make sense to re-sign signatures? I mean, every three years I will sign your signature. I think so, yeah. I think that if I sign your key now, but I don't see your face for the next three years, I will let that signature expire because I will not remember you probably. But if I keep seeing you, I will sign by myself at home looking who is expiring. I will see you and I will remember who you are. If I... Or we can meet again for the express purpose of key signing. So yeah, I think... I mean, re-signing people who you have already signed should be done. Very much like your proposal to set an expiry date on signatures so they lax if they don't get renewed. So I wonder if I should revoke all the signatures I have made and then issue new ones for people who are in that time and from now on issue time-limited ones. If lots of us follow that policy, that's going to cause quite a change in the graph. Do you think that's a sensible thing to do or are we going to get ourselves into trouble by breaking lots of those links very quickly? Well, the reality is it's very hard to know. I picked three years because I know my attention span is low. But that was the reason I did the... Let me see if I have this here. No. I know I wrote... No, but yeah, I reset this... No, I deleted it from here and it's only in my main work machine. I think from the runs I did, expiring over five-year-old keys, that it doesn't make that much of a difference. But of course, all of the red blob fell away. But those were... In the end, those were Mia candidates. So it's hard to know. I have to play more with the information and probably start using better tools to do it because I'm really, really doing it by hand and that doesn't scale. So you said at the beginning that about 200 people that lost their key haven't sent a new one. Do you think that means those people are missing in action and do you think they should have their accounts removed? Well, we started talking with some of the people in Mia team and they said, well, okay, last time we talked, they said, well, give us a list of people to start contacting. The thing is there are too many people to contact. I think many of them will be missing. Many of them will be willing to retire. Many of them are not. We know of some people who have been trying to get reconnected I would be willing to possibly make some concessions but it's hard to say. I say concessions and Jonathan starts looking at me different. For clarity in the meantime, just in case there's any doubt, those people who have been removed do not stop being Debian developers. Of course not doing removals at this stage will follow the normal MIA process first. Of course, now that you mentioned this quickly. You have a session five minutes. Five minutes ago. Yes, I don't know. Why wasn't I interrupted earlier? I don't know, so I'm interrupting you now, sorry. Okay, sorry. Let's go tomorrow. Thank you very much.