Post-mortem and remediations for the Matrix.org security breach
One of the failures here is that they weren&#x27;t able to keep deployed software up to date for security fixes, even when those security fixes were publicly known.<p>They have acknowledged this in their section &quot;Keeping patched&quot;.<p>However, there is one thing I think they have omitted to consider. The more reliance on third party software not from the server distribution they are using, the more disparate and unreliable sources for security fixes become.<p>Careful choice of production software dependencies is therefore a factor. Usually it is unavoidable for some small number of dependencies that are central to the mission. But in general, I wonder if they have any kind of policy to favour distribution-supplied dependencies over any other type.<p>Another way of looking at this: we already have a community that comes together to provide integrated security updates that can be automatically installed, and you already have access to it. Not using this source compromises that ability. If some software isn&#x27;t available through Debian, it is usually because there is some practical difficulty in packaging it, and I argue that security maintenance difficulty arises from the same root cause.<p>On a similar note, I&#x27;m curious about their choice to switch from cgit to GitLab. Both are packaged in Debian, but I believe that even Debian doesn&#x27;t use the packaged GitLab for Debian&#x27;s own GitLab instance. Assuming that Debian GitLab package&#x27;s version is therefore not practical, wouldn&#x27;t cgit be better from a &quot;receives timely security updates through the distribution&quot; perspective?