WineHQ database compromised

> They kept screaming, for example, that our version of
> SSH had known vulnerabilities - even though the distributor had long since patched those
> vulnerabilities out. All that mattered was The Checklist, which had little to do with how
> secure we actually were.

Yep, that sounds about our experience, too. I ended up writing a script to scrape info of patched CVE issues from our distribution's website and emailing the PCI people a list of links to "prove" that said patches have been applied.

It's all, I think, so that the card processor can push the liability for any losses away from them.

FWIW: As someone who's gone through many, many rounds of proving PCI compliance, I can say that, yes, it's a hassle proving, each time, that your installed version of a security-sensitive package includes backported fixes not reflected in its publicly scan-able version number. I've worked out a routine where I keep handy a canned response that I can quote to answer that objection, which I haul out each testing cycle, with only minimal use of everyone's time.

Rick Moen
rick@linuxmafia.com

I work for a vendor who sells software that is sometimes used as part of the PCI compliance picture.

It's all too familiar to hear from customers (from auditors) that their scan-thing found a red item. Usually these red items represent bugs in the scanners, but they don't care (neither the auditor, nor the customers).

Fortunately our software doesn't have to actually pass the test software (it doesn't touch the card stream). So I point out some of the clauses of PCI compliance that say they don't have to care, and suddenly they're happy.

Sigh.