 Hello, me again. So, it used to be not so long ago, this is from 2013, this article that people asked, can you trust open source software? If you run it on your computer, will it do something nasty? These people call themselves hackers, so how can you trust these people? You don't know what they've put in their code, it might be something malicious. They might be spying on me, they might be wanting to blackmail me like this character from Black Mirror and I might have to end up being blackmailed and then in a fist fight in the forest to the finish for my very life just because I want to run KD Plasma. And this feels like quite a nasty thing to say to people, but that was a genuine worry not so long ago. Fortunately these days, people seem to understand that actually the genuine worry is if you run commercial software, which has commercial interests and companies keep trying to put in stuff which will spy on you and will try and get some sort of edge to make them an extra little bit of money or get them some data that they can then sell on and that a lot of commercials often will be actively spying on you and you can't stop it. And with a lot of software, you will end up with your files encrypted and blackmailed back to you and you will end up dead, which is not a good story either. So people trust open source, people trust KDE, but there's a long chain between us writing software and then getting on to people's computers and somewhere along that long chain it can be hacked. So people trust that we're not going to put malicious stuff in our code because it's all peer reviewed and it would be noticed. And we don't really want to spend hours of our volunteer time only to write something that then breaks into people's computers, but hackers will come along and do mess around with our stuff on somewhere on that long chain and well, people might end up in the fist fight to the death in the forest just because they want to run plasma. So there's a long chain of trusts that goes between us and it getting on to people's computers and we have to make sure that you can verify at every one of those steps that it's not been hacked and you're not going to be blackmailed, you're not going to end up in that forest in a fist fight to the death. So how do we do at dealing with this long chain of trust? One place that people got our software is by installing it from packages, out to get and yum and zipper and the rest and for quite a long time now most of these have all been digitally signed. So you can authenticate the package you're downloading and installing on your computer really is the same package that has been uploaded by some developer to their archive and it's automated. So it's fairly easy. So for a long time that's been a mostly successful story, apart from a little bit guilty as the judge in Gotham City would say because I screwed up last year when the KDE or Neon server wasn't set up properly and anybody could upload stuff to that server if they knew where to find it. We don't think anybody did know where to find it. We've no reason to think there was a problem but that's an example of the kind of area where issues can come along in this long chain of trust is if you have an incompetent sysadmin like me. So people will download an ISO to get our software and these isos contain large amounts of code and they have to make sure that code really does come from us or come from the open source communities that they trust. And typically when you download an ISO they will come with a GPG signature and typically they will come with a checksum so you can make sure that it hasn't been hacked somewhere along the way and that's fine but there's some people who don't quite do best practice according to Judge Dredd and Mega City One. Just picking a random example, NetRunner which is fine, it's not actually that guilty. I don't think they're going to get Judge Dredd come along and slam them up but they have a checksum here. It's a 256 chart checksum so it's a decent algorithm but there's no GPG signature so you can't be quite sure from release that there's nothing terribly wrong with it but actually that's okay. It's just not quite 100% best practice. This is Kubuntu and they have a whole load of files and they've got a whole load of checksums and I don't quite know why they have three different checksums so that seems overly complex and if you know anything about security, complexity is the enemy of security. Why you have three checksums when you just could have the best one rather than the obviously older ones and they have a GPG signature for each of those checksums so why do they GPG sign the checksum which contains a checksum for the ISO rather than just GPG signing the ISO directly? It's not a bad thing to do, it's just a little bit more complex, a little bit more faffy than it needs to be complexity as the enemy of security. So I've written a tool or I'm in the process of writing a tool, ISO image writer which is a fork of Rosa or hopefully not a fork because I'm working with the Rosa developer and that will automatically check the checksum and the GPG signature for your ISOs that people download because nobody will actually do that manually. I don't think anybody actually checks the checksum and I don't think anybody actually checks the GPG signature so it needs to be done automatically by a program and that means that if you trust that program then you know you can trust your ISO and of course that isn't a solution to a problem, it just moves it further upstream but that's fine because we can deal with that single issue case where you make sure those packages are valid and that means you can make sure the ISOs you want to install are valid. So we released TARS and that's the main output from KDE is TARS for our applications and a lot of those are made with the ReleaseMe tool which now forces GPG signatures for people who make releases using ReleaseMe so if you're not using ReleaseMe then you're not being forced to do the right thing but it's okay because there's frameworks in KDE applications and Krita and KDevelop which don't use ReleaseMe, nevertheless we've managed to convince them all to use GPG signatures as well so we follow a good practice there and on the packaging side because the chain of trust there goes from KDE releasing it to distros picking it up the packaging in Debian and Kubuntu and KDE Neon at least will automatically verify those GPG signatures. I don't know if that's the case for other distros for other packaging formats but I hope it is. Is there a person do you know? Not sure, hopefully it is. But guilty according to the Court of Session in Scotland highest court in the land we've released in this year we've released these tarbles which don't have GPG signatures so people could be downloading this stuff and they will end up in the Court of Session or the Release Manager as well because all these tarbles get released which don't have GPG signatures. Why is that? I've no idea. This admin doesn't require it and I think this admin should require it. They probably use obscure scripts, they use their own scripts which don't GPG sign it. GPG is often quite faffy and there's some incredibly amazing intelligent people such as the Critter Release Manager who nevertheless gets very frustrated because GPG is obscure and faffy to use and enemy is the complexity as the enemy of security so a lot of people just don't want to use GPG because it's too faffy like Frederick had trouble setting up yesterday but nevertheless it's what we should all get into using. For example, well I'm sorry to become Kirigami again because they had it yesterday but the release page for Kirigami has checksums which is good and uses a good algorithm so that's nice and it's got a link to Marco's signature so that's good. It's all GPG signed bits of wiki so if a hacker hacks the tarble hacker it's trivial to change the wiki and so there's no security there. Oh this is another guilty party according to this beautiful court with foreign elected judges in the European Court of Human Rights. Git tags so can you verify that the code you have on your computer actually goes all the way back to the git commits from the people that we trust and it turns out that you can't with this is kauth which is frameworks so for some reason the framework script they push the tags they don't push the signatures of the tags and the same thing with applications I think so the chain of trust should go all the way from git to your install on your computer and for some reason we don't push a lot of git tags and why is this important? Well that's our vision for our software. You can't have freedom without privacy and you can't have privacy without control and you can't have control without knowing who you trust. People trust us we should make sure that we successfully take that trust all the way through to the point of installation of people's computers. That's all. Thank you. Thanks Jonathan. Is it time for questions? Maybe one. I have two questions. One is how is the state of builder reproducibility for KDA projects so I mean theories are really huge issue that some distros are trying to make build reproducible but some software have built in dates or built in stuff that every time you build the software changes so how is the state for our project and the second thing is should we move to sign also commits on git? Build reproducibility I don't know I happen not to care about it maybe I should care about it but I'm not sure yes yes I do care about it yes good. Scarlett has a comment give your microphone to Scarlett she says she's building she's working on reproducible builds. We're not as terrible as as some projects but we do have some issues. Should we sign all git commits? I don't think we should. Why? Harold says thumbs up is that we should okay yes we should yes absolutely we should of course we should. Why wouldn't we? Yes another question. Mike's coming down. So why would you want really a tar balls to be signed by a GPG signature if you're downloading them from an HTTPS server where you can verify the HTTPS certificate it's a lot easier to verify an HTTPS certificate. Right so our tar balls get put on a master server which gets pushed out to a dozen or more different mirrors and any one of those mirrors could be hacked so even though your HTTPS connection authenticates that yes you're really talking to the server you think you're talking to it doesn't mean that server has not been hacked that server could easily be hacked and there's dozens of those servers so chances are one of them will get hacked before too long. I would say that you have the exact same chance of having an HTTPS server just a download server being hacked as you have of creating a GPG key where the short key collides with another. It doesn't matter if the short key collides with the long key because this job gets the right key. And the verification people are packages they're not random punters on the street there people should know what they're doing so packages should know how to get the correct key and that's why in your release announcement you should say exactly where you to get the correct key for so that the packages will get the correct key and not get the wrong key. I'll continue this. And they should not say it on the way. Take this discussion offline. Thank you all for the pass session track. So we have a 20 minutes break and we'll start at 16 or 30. Thank you.