Update on progress after the compromise, for 27th November

Approved by:	bcr (mentor, implicit)
This commit is contained in:
Gavin Atkinson 2012-11-28 01:58:07 +00:00
parent b402808ad0
commit fc27e64612
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/head/; revision=40174

View file

@ -62,6 +62,7 @@
<ul>
<li><a href="#announce">Announcement</a></li>
<li><a href="#update20121127">Update: 27th November 2012</a></li>
<li><a href="#update20121122">Update: 22nd November 2012</a></li>
<li><a href="#update20121118">Update: 18th November 2012</a></li>
<li><a href="#details">Initial Details: 17th November 2012</a></li>
@ -72,6 +73,46 @@
<p>More details will be added here as they become available.</p>
<h1><a name="update20121127">Update: November 27th, 2012</a></h1>
<p>Due to the legacy third-party package build controller head
nodes being offlined pending reinstall, we have been unable to
build new package sets over the last two weeks. As a result,
FreeBSD 9.1-RELEASE has been delayed as it was felt that we
should not ship the release without at least a minimal package
set available. We are now in a position where we are once
again able to build third-party packages for both of our
<a href="/doc/en_US.ISO8859-1/articles/committers-guide/archs.html">
Tier-1 architectures</a> (i386 and amd64), and are planning on
releasing it within the next few days with only a slightly
limited set of packages. Please note that historically we have
also provided packages on a best-effort basis for some of our
Tier-2 architectures such as sparc64, ia64 and powerpc. We are
not currently expecting to be in a postition to build any Tier-2
packages before FreeBSD 9.1 ships, so initially for these
platforms no such precompiled packages will be available. We
may be in a position to provide some packages for these
architectures shortly after the release.</p>
<p>A few reports covering this incident on external tech news
websites have confused details relating to how this incident
was discovered. Over the last few weeks, many of our primary
cluster servers have been either physically relocated and/or
replaced with new hardware as part of work planned several
months in advance. The discovery of this incident was
unrelated to this ongoing cluster maintenance. Several
service outages in the days surrounding the incident were
correctly attributed to ongoing cluster work, and were not
related in any way to the compromise. In parallel with the
physical upgrades and relocation of servers, we are also
reworking the network layout in order to provide better
functionality, security, resilience, and to reduce any impact
from incidents such as this. Due in a large part to the
progress already made here, we were able to have full
confidence in many systems and services so quickly after the
compromised hosts on the legacy network segment were
discovered.</p>
<h1><a name="update20121122">Update: November 22nd, 2012</a></h1>
<p>Although not mentioned in the original report,