33708801
submission
wmbetts writes
"We want to provide you with an update on this morning’s reports of stolen passwords. We can confirm that some of the passwords that were compromised correspond to LinkedIn accounts. We are continuing to investigate this situation and here is what we are pursuing as far as next steps for the compromised accounts"Link to Original Source
29488717
submission
wmbetts writes
"Today, well just now the hacktivist group anonymous has released a statement and mirror and data from yet another government website, this time being a ftc.gov subdomain business.ftc.gov which when checked appears to be offline for now."Link to Original Source
27395976
submission
wmbetts writes
"Important notification concerning your Trion Worlds account
We recently discovered that unauthorized intruders gained access to a Trion Worlds account database.
The database in question contained information including user names, encrypted passwords, dates of birth, email addresses, billing addresses, and the first and last four digits and expiration dates of customer credit cards."Link to Original Source
21999452
submission
wmbetts writes
"Hi all,
We are using libcurl on the server-side for the TF2 replay system, and could use some help diagnosing some problems.
Without getting into too much detail, the gist of the system is that replay-enabled servers use libcurl (7.21.2) to offload small chunks of data over FTP, every 15 seconds or so. Clients can then get at the data over HTTP.
One of the biggest issues server operators are running into is that things will be going along smoothly with no issues — uploading these chunks of data successfully — and then suddenly libcurl will error out with a "Couldn't resolve host name" message. Anyone have any clue what could be causing this?
I've pasted a simplified version of the uploading code below in case that's useful.
Thanks a bunch.
-Jon"Link to Original Source
20606512
submission
wmbetts writes
"On 27 April, ARIN placed Delegation Signer (DS) records into in-addr.arpa
and ip6.arpa. Now DNSSEC validation will occur from the root down if you
properly set up your DNSSEC-aware recursive resolver.
For most DNSSEC-aware recursive resolver operators, nothing needs to be
done for this change to be in effect as long as you have configured your
DNSSEC-aware server to use ICANNâs trust anchor for the root zone. For
those who have used ARINâs trust anchors (in place since 2 July 2009) to
take advantage of DNSSEC before the root or in-addr.arpa was signed, you
MUST remove them within the next two months of this date. Otherwise,
DNSSEC validation may fail due to a KSK change to ARINâs zones.
Additionally, ARIN will also coordinate with Internet Systems Consortium,
Inc. (ISC) to remove ARIN's delegations from their DNSSEC Lookaside
Validation (DLV) registry after setting up these records in in-addr.arpa
and ip6.arpa.
The DS records will remain the same as the current trust anchor for the
next two months. After that time, ARIN will begin rolling a KSK for its
authoritative zones, which will cause any DNSSEC-enabled resolvers that
use ARINâs statically, configured trust anchors to fail.
For full details on DNSSEC at ARIN, refer to:
https://www.arin.net/resources/dnssec/"Link to Original Source
20294856
submission
wmbetts writes
"APNIC announced that as of Friday, 15 April 2011, its IPv4 address pool
reached the Final /8 IPv4 address block, bringing the Asia Pacific
region to the last Stage of IPv4 exhaustion. This is a very important
milestone on the IPv4 exhaustion process at a global level."Link to Original Source