[Asterisk-Users] Re: Advice on OS Choice

[Andrew Kohlsmith]

On Friday 15 October 2004 17:22, Joe Greco wrote:
> > If they're sharp cookies then they're also smart enough to know that they
> > are liable if they fuck something like that up.  Having access to the
> > source is a red herring in this case.  They could just as easily tinker
> > with hex dumps and try to make it work.
>
> Giving them the source is like a road map to the system.

Nothing wrong with that, IMO.  You are placing the maintenance of hte machine 
in their hands.  Even without source there are some real trust issues at 
stake.

> With hex dumps, it's a lot more difficult for them to bypass your redundant
> system integrity checks.  Not impossible, but a lot more difficult.  It
> means you need to put some serious effort into the reverse engineering.

You use hardware checks and as I put in another reply, the hardware keys to do 
the upgrade are in the hands of someone who *is* responsible.  Hell have the 
firmware upgrade code on a cryptokey that someone with authority needs to 
insert.  Can't hack around that.

Oh but wait, they could already write their own firmware loader and use that.

Reductio ad absurdam.  I'm not playing that game with you.  

> If you give them source, it's more a matter of "grab the appropriate
> compiler off the 'net and have at it".

Again where's the upgrade/install policy that wasn't being followed?  This 
isn't a software or even a licensing issue.

> Now what happens next is even worse, because the electronics shop guy who
> did this, in a very human gesture of "CYA", replaces the modified image
> with the factory image, because the first thing they did was to send the
> unit down to the shop as defective.

> Are they liable?  Well, of course they are, if you can prove it.  This
> requires that someone be clued in to the possibility that this happened.

Your scenario can be played out any number of ways, with or without source.  
You routinely send your life critical hardware down to Bob and Doug's repair 
shop?  You have bigger issues in place.

> Under a closed source model, this kind of thing is generally considered
> highly unlikely to virtually impossible, because the equipment in question
> runs a variety of integrity checks to make sure that the program image has
> not been altered (most frequently due to the storage medium going bad).

True enough but the system integrity checks would also include autoshutoff due 
to alarm condition, and likely in hardware as well if at all possible. 

There's a million ways to play this, and I'm sorry, but having access to the 
source (or rather the build environment, which is *not* covered by GPL 
licensing) is *not* part of the problem.  Institutional policy exists for a 
reason, and having the source handy doesn't mean you can disregard policy, no 
matter how trivial the change.

> Of course, but that doesn't always translate as you'd hope.

> You can have all the nifty policies you want, but there's always the person
> who thinks they're smarter than the policy.  Frequently they might even be
> right, because many policies are moronically stupid.  Unfortunately, these
> people tend to learn to ignore policies and do as they please anyways.

Then you change the policy.  People die because policy isn't followed all the 
time.  Hell they dropped a quarter billion dollar satellite because policy 
wasn't followed.  You fix the problem, not point to ways to make it harder to 
abuse the policy.

> (Incidentally, this is part of why the LGPL was introduced, so even
> the so-called FSF has tipped its hat to these legitimate concerns.)

And again, having access to the source is what's at stake here, not the build 
environment, which would have made any of these scenarios work.

-A.