[11:23] Hi all [13:10] Frameworks 5.62.0 is all migrated in Eoan [13:12] I didn't know this existed! https://launchpad.net/cubic [13:12] very handy [16:15] That is awesome. I will check it out when I return home. [20:31] RikMills: that's super! people have been asking for a service like cubic for years [21:43] RikMills: any thoughts on https://phabricator.kde.org/T11304#197265 ? [21:43] that's the end of a very long thread but gets the important bit for us I think [21:45] do we gpg verify the signatures on various KDE releases? [21:55] On some things we check tars with upstream signing keys. Not all or systematically though. [21:58] valorie: nope, but when building packages we download the tarballs with sftp, which is secure [21:58] We could add gpg verification to KA as an extra layer of protection though [22:00] @RikMills ⬆️ [22:03] If kde sort out their key distribution properly, then sounds a good idea [22:15] I imagine sitter is the most up-to-date with that, along with Ben of course [22:27] from earlier today or yesterday: [22:27] [23:12] tsdgeos[m]: dfaure[m]: i've been thinking about https://phabricator.kde.org/T11304 and how we might best deliver that [22:27] [23:12] if the outcome of that BoF was that a Git repository is perfectly okay, then what I think we should do is [22:27] [23:12] 1) Create said repository [22:27] [23:14] 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] [23:16] 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] [23:16] Thoughts on that process?