On 2022-10-23 07:33, Ian Kelling wrote:
Siddhesh Poyarekar via Overseers <overse...@sourceware.org> writes:
I personally do not think the current sourceware infrastructure, even
with the roadmap it promises is a viable alternative to what LF IT can
provide. There is a significant resource gap (e.g.
....
established security and administration practices,
...
that we seem to disagree about.
Let's consider some "established security and administration practices"
curl -v http://vger.kernel.org | head
...
< Server: Apache/2.0.52 (Red Hat)
< X-Powered-By: PHP/4.3.9
This is RHEL 3, released in 2003, according to
https://people.redhat.com/crunge/RHEL3-package-lists.pdf,
The final end of support for this distro was on 2014-01-30.
There are CVE's for that version of Apache. I assume their apache is not
running in a configuration that makes them actually exploitable, but it
is still better security practice upgrade.
The kernel is likely from RHEL 3 too. I'm reminded of Greg KH beating the
drum that old kernels need upgrades for security, especially because the
kernel devs don't always check if a bug is a security issue and
especially not for really old kernels (
https://thenewstack.io/design-system-can-update-greg-kroah-hartman-linux-security/
)
Notice that link is http because https is not supported by the apache
from 2003. Linux kernel development works through patches on mailing
lists, and how do you find the patches if you aren't already subscribed
to a list? You'd naturally go to the lists main webpage,
http://vger.kernel.org, and click "LIST INFO",
http://vger.kernel.org/vger-lists.html, and then click one of the list
archive links, or maybe the subscribe link. So, those vger.kerne.org
pages are an essential part of retrieving upstream kernel patches and
security information for some people. And being http only, my isp or
anyone in my network path could alter them to be malicious urls that
that appear to give the correct result, but actually give malicious
kernel patches, or hides away a security relevant patch. Obviously,
https for security sensitive pages like these is a basic 101 security
practice in 2022.
+Konstantin from LF IT since he's better equipped to speak to this,
although ISTM that they started migrating off vger last year[1].
Sid
[1] https://www.kernel.org/lists-linux-dev.html
Sid
