I’ve just changed the branch protection settings for GLib to disallow all pushes directly to git main (and old stable branches) from all git users. Unfortunately, this includes the translations user used by damned-lies to push translations updates.
The change has been made, experimentally, to harden the security of GLib. Allowing pushes directly to main means that any Foundation member can push to GLib without review. This has happened a few times recently, and while none of the changes have been malicious (some of them have been me, accidentally!) it demonstrates a pretty viable attack vector for getting untrusted code into a core part of the desktop. It means we have to trust everyone who has Foundation membership, and trust that their gitlab.gnome.org account doesn’t get compromised.
I’m not sure exactly how damned-lies will handle this; whether it’ll error or whether it’ll prompt people to open a merge request. The intention is that translation updates should be submitted as merge requests to GLib from now on. We will review and merge them promptly.
Hopefully this won’t be too much of an impact on the translation team — GLib doesn’t change its translatable strings often, so doesn’t see many translation updates.
There is a proposal for an improved damned-lies workflow which would work with this new branch protection setting. Maybe someone’s keen to implement it? Having filed the bug about it 6 years ago, I am no longer willing to let the translation workflow block supply chain security for GLib though, sorry.
Jumping to take such an action right after a discussion on Matrix, and without any prior announcement, seems a bit rushed, but oh well.
Not quite. Not every Foundation member is a member of the GNOME group on GitLab, and not every member of the GNOME group is a Foundation member. But yes, it means trusting members of the GNOME group.
That’s where an announcement, or at a minimum talking to i18n (hi!) prior to doing the switch, would have been appreciated. With a protected branch, trying to commit from Damned Lies results in an error. Damned Lies will display the git error output verbatim.
I have now added a description to the module, that appears at the top of workflows (see this example) and provides a link to glib merge requests. I don’t think I can tell Damned Lies, as it is currently, not to try to commit (or push, actually), so I expect some translators will miss the message, try anyway, and open issues against Damned Lies. It’s unfortunate but not the end of the world.
Please ensure they have been reviewed on Damned Lies as well. I mentioned in the top-of-page message that a link to the Damned Lies workflow is expected in the merge request.
Yes, I don’t think it will be a big issue. I hope we don’t start doing it on a larger scale though.
Well, I have to implement it, this is why an announcement would have been appreciated. But… anyway, good news, if we implement an ‘open a merge request’ feature on Damned Lies, we’ll be able to directly contribute to the FreeDesktop hosted projects by opening the merge request directly, so… no that bad
I am a Foundation member and have no right to push to @GNOMEs owned projects on GitLab.
Yes, this is also my concern. Doing such for more modules will kind of reduce the pace of the translation workflow.
In the future, if we implement a Merge Request feature to open MR instead of directly pushing commits to Git, we wish also have to trust those opened by @translations, it will follow probably the same rules that follows direct commits. That is to say the translations would have been reviewed by translation teams.
I’m sorry I missed this part of your message. It will probably included in a future cycle of modifications, to be release in the coming semester. But we’ll have to design a good and elegant solution with i18n teams, translators and developers.
