[11:23] <BluesKaj> Hi all
[13:10] <RikMills> Frameworks 5.62.0 is all migrated in Eoan
[13:12] <RikMills> I didn't know this existed! https://launchpad.net/cubic
[13:12] <RikMills> very handy
 That is awesome. I will check it out when I return home.
[20:31] <valorie> RikMills: that's super! people have been asking for a service like cubic for years
[21:43] <valorie> RikMills: any thoughts on https://phabricator.kde.org/T11304#197265 ?
[21:43] <valorie> that's the end of a very long thread but gets the important bit for us I think
[21:45] <valorie> do we gpg verify the signatures on various KDE releases?
 On some things we check tars with upstream signing keys. Not all or systematically  though.
 valorie: nope, but when building packages we download the tarballs with sftp, which is secure
 We could add gpg verification to KA as an extra layer of protection though
 @RikMills ⬆️
 If kde sort out their key distribution properly, then sounds a good idea
[22:15] <valorie> I imagine sitter is the most up-to-date with that, along with Ben of course
[22:27] <valorie> from earlier today or yesterday: 
[22:27] <valorie> [23:12] <bcooksley> tsdgeos[m]: dfaure[m]: i've been thinking about https://phabricator.kde.org/T11304 and how we might best deliver that
[22:27] <valorie> [23:12] <bcooksley> if the outcome of that BoF was that a Git repository is perfectly okay, then what I think we should do is
[22:27] <valorie> [23:12] <bcooksley> 1) Create said repository
[22:27] <valorie> [23:14] <bcooksley> 2) Have people who release software send Sysadmin a MR for that repository, with the merge being made up of a single commit that adds their GPG key details in the appropriate format, with that commit being GPG signed itself (to prove they own the key)
[22:27] <valorie> [23:16] <bcooksley> 3) If people complete the details on their GPG keys in their Gitlab profile, then Gitlab can also validate the commits (which Github also does)
[22:27] <valorie> [23:16] <bcooksley> Thoughts on that process?