Commercial software is the same. They make it clear that no promises are made that the software is fit for any particular purpose in the EULA. My assumption is making such a promise would hold them accountable when it failed, and I doubt any company would find it profitable to invest in enough QA to make that statement. Especially when the closest alternative is for customers to pay for a support contract.
Coming from a company that does lots of global credit card transactions (but no OBSD there...yet. :-) ), I have never heard of this "validation of install media without reasonable doubt" requirement. I've never bothered to read all of the DSS docs, but have skimmed through them. Perhaps it exists in such strict form and I am insulated from others in the company performing these tasks but I get the impression that either this guy is being given an especially hard time or has not realized that "Install media is downloaded, or physical media purchased, directly from the vendor" is probably good enough to meet the requirement. "Install media downloaded from bittorrent" or "purchased on a street corner" is what might raise some red flags... Valentin, If you're actually having to account for MITM, postal, etc. attacks on install media then the company has larger issues to which undeniably-secure install media will provide no additional protection. Stating that you get the install media directly from the vendor should be good enough. On Fri, Sep 13, 2013 at 9:09 PM, Ted Unangst <t...@tedunangst.com> wrote: > I think you're in trouble. Some of the software on the openbsd CDs was > written by me, > and I never made any promises it's safe to use on an important > server. Not that you should trust me even if I did make such a promise. > > It's software you're getting from the Internet. Made by people from the > Internet. > > > On Fri, Sep 13, 2013 at 11:13, Valentin Zagura wrote: > > Security itself is not the primary issue here. The issue is to easily > prove > > an assessor "without reasonable doubt" that you are running the right > thing. > > They will not worry about governments trying to break in with MITM signed > > ssl or about armies breaking in with the tanks. But they would worry > about > > me not building the image the right way, someone tampering with the image > > or leaving the door unlocked at the server room. > > Also, they require people to take responsibility for the thing they do > (in > > this case, CD images). > > > > > > On Fri, Sep 13, 2013 at 1:56 AM, Kenneth R Westerback < > > kwesterb...@rogers.com> wrote: > > > >> On Thu, Sep 12, 2013 at 07:52:22PM +0300, Valentin Zagura wrote: > >> > > There is no entity > >> > > that owns or can be held responsible for the code, or is capable > >> > > of providing a solid evidentuary path from commit to your hands. > >> > > >> > I thought if we buy the CDs we WILL get "a solid evidentuary path from > >> > commit to" our hands. > >> > > >> > So this isn't the case? > >> > >> Physical email is as susceptible to MITM attacks as network > connections. I > >> know a story of laptops entering the mail system and car springs coming > >> out the other end in the same box. :-) > >> > >> CDs will give you the best evidentuary path available. Compiling > everything > >> yourself with a compiler and hardware you built from piles of dirt in a > >> clean room would be better. And then you still have to worry about nano > >> technology being slipped into the dirt. > >> > >> .... Ken > >> > >> > > >> > > >> > > >> > > >> > On Wed, Sep 11, 2013 at 1:58 PM, Peter N. M. Hansteen < > pe...@bsdly.net > >> >wrote: > >> > > >> > > On Wed, Sep 11, 2013 at 01:49:14PM +0300, Valentin Zagura wrote: > >> > > > >> > > > We are going to use a OpenBSD system in a PCI-DSS compliant > >> environment. > >> > > > Is there any way we can prove to our PCI-DSS assessor that the > >> OpenBSD > >> > > > image we use for our installation can be checked so that it is the > >> > > correct > >> > > > one (is not modified in a malicious way by a third party) ? > >> > > > >> > > Probably not what you want to hear, but starting with > >> > > http://www.openbsd.org/orders.html > >> > > is usually an excellent idea in this context. Verifiably delivered > >> from a > >> > > trusted source. > >> > > > >> > > > A https link to some kind of ISO checksum or something similar > (but > >> using > >> > > > strong cryptography) I think would do it, but I could not find any > >> > > (except > >> > > > a line in the FAQ stating "If the men in black suits are out to > get > >> you, > >> > > > they're going to get you." which is not the case :) ) > >> > > > >> > > It's possible some of the more prominent entries on > >> > > http://www.openbsd.org/support.html > >> > > could be persuaded to provide something like that (M:Tier comes to > >> mind, > >> > > but why are > >> > > they not on that page?) in exchange for a reasonable fee. > >> > > > >> > > But again, for -RELEASE, the CD sets are a good starting point. > >> > > > >> > > - Peter > >> > > > >> > > -- > >> > > Peter N. M. Hansteen, member of the first RFC 1149 implementation > team > >> > > http://bsdly.blogspot.com/ http://www.bsdly.net/ > http://www.nuug.no/ > >> > > "Remember to set the evil bit on all malicious network traffic" > >> > > delilah spamd[29949]: 85.152.224.147: disconnected after 42673 > >> seconds. > >> > > > >> > >
