This is how you tell people about a security breach. Inform them soon as you know with what you know and assume the worst with your appraoch to restoring things.<p>Much respect and defineing the word professional for many.
I have a couple of FreeBSD machines which pulled binary packages between those dates. I'm not overly worried. The packages have been removed and installed again from ports after a fresh portsnap dump and the systems have been verified with "freebsd-update IDS" against known good signatures. Any modified files were manually checked. I use MAC on each machine and pf up front on firewalls so I know what is going in and out as well.<p>The fact that these mechanisms are available is the reason I use such a system.<p>Also, if you consider any problems like this happening to a closed source vendor, you may never know it's happened. And don't tell me they don't do it as I've worked for a couple of companies that felt that burying security fuck ups was acceptable practice. It's why I don't work for them any more.
Take note:<p>"We unfortunately cannot guarantee the integrity of any packages available for installation between 19th September 2012 and 11th November 2012, or of any ports compiled from trees obtained via any means other than through svn.freebsd.org or one of its mirrors. Although we have no evidence to suggest any tampering took place and believe such interference is unlikely, we have to recommend you consider reinstalling any machine from scratch, using trusted sources."
How does one know the offsite repository's are clean if svnsync runs at set intervals? What if part of the attack was to make it look like happened at much late date/time after the malicious code was mirrored and backed up to the offsite repositories?
Scary stuff.<p>Please use passwords for your keys and allow key access only to a small set of known IP addresses.<p>Also do share other security techniques you're using besides the ones above.