This month I had the pleasure to visit Manchester and Wales for a couple of weeks. I caught the last of the summer before the crazy climate-crisis storms of October began and everywhere started flooding.
I also just came back from A Coruña where I attended the excellently organised X.org Developers Conference. Thankfully there were no talks about X.Org, but we did talk a lot about managing hardware test rigs. This is a problem that Mesa 3D developers are particularly interested in, given the nature of that project, and it’s increasingly relevant for GNOME as well. It was also great to catch up with some folk I hadn’t seen since before the Great Plague or who I’d never even met in real life before.
Outreachy
I decided that the GNOME openQA tests were a good candidate for running an Outreachy internship. Initially I thought I would run a project to test GNOME with mobile form factor. After chatting to Sonny we came up with a much more interesting plan which helped me to re-evaluate my whole approach to these kinds of internships.
I have been involved in Google Summer of Code in the past, once as an intern and once or twice as a mentor. I think in all cases it’s been useful for the intern, and we have had some great interns, but it’s not always super useful for the project.
The difficulty is: allocating a task that is exactly 3 months long is quite difficult, and the task ends up being something that an experienced developer might do in a week, which you arbitrarily draw out to 3 months and turn into a teaching opportunity. I am yet to mentor someone who has later become a long-term contributor to the same project. Parcelling out appropriate tasks in active project is a headache – for example, once an applicant submitted a merge requst during the application period that already implemented a big part of one project.
Sonny ran an internship for Workbench this year where the goal was to add as many platform demos as possible. So instead of one big task, it involves many smaller tasks. This avoids all of the issues I mentioned above. Each contribution during the application period can be actually useful, and you can have multiple interns collaborating, or just one.
This is especially nice for this year since GNOME has funding for 3 interns, and the openQA tests project is our only proposal.
So I have spent a lot of time in the #GNOME OS room on Matrix the last few weeks helping applicants to run the openQA tests and contribute small modifications. We have a bunch of ideas for tests to add – please add more here if you have them. Some may become essential and others perhaps won’t work at all – trying different ideas in parallel we’ll definitely have some useful outcomes for GNOME.
Github Security Lab
Carlos already posted about the exploit in Tracker Extract found by Github Security Lab. I don’t have much to add, except to echo that the reporter, Kevin Backhouse, dealt with this report in a really helpful way, and Carlos himself did some heroic work to rework the entire main loop of tracker-extract works in the space of a weekend. You can take a look at the branch here.
That’s not the whole story, SECCOMP sandboxing is an ongoing pain in the butt to maintain; it’s one of those things that has to be funded in order to happen, as very few people will do this kind of work voluntarily – the main issue, I think, is that success here is invisible. It’s an absense of security holes. An absence of test failures. And it’s hard to celebrate and take credit for doing stuff that nobody will notice until it goes wrong.
So while its great to see Microsoft (and Google) funding research into potential vulnerabilities in GNOME, let’s remain realistic that the best way to ensure high quality GNOME releases is to commit funding for the maintainers who deal with these issue reports.
Sam Thursfield 