-
From: Charles Mills charl...@mcn.org
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Tuesday, June 18, 2013 7:45:09 PM
Subject: Re: Auditing vendor source code
Sam is correct.
Without giving away a whole lot of details, the code is in a position such
that it could for example (were it malicious) suppress
-
From: Phil Smith p...@voltage.com
To: IBM-MAIN@LISTSERV.UA.EDU
Cc:
Sent: Wednesday, June 19, 2013 4:10 PM
Subject: Re: Auditing vendor source code
Ed Jaffe wrote:
We once had a situation in which a foreign distributor had numerous
off-book customers using our software illegally. It's
@LISTSERV.UA.EDU
Subject: Re: Auditing vendor source code
Actually, US companies have also stolen software. I will not go into details,
but it has happened at a company that I worked for. One of their customers
stole the software for at least a couple of years until we changed how our
license
There is some considerable evidence that Soviet-bloc software was
pirated by Western intelligence agencies too. I should have been both
surprised and disappointed if it had not been.
This thread has veered close to disagreeable chauvinism: the notion
that any country or bloc of them has a corner
John Gilmore wrote:
There is some considerable evidence that Soviet-bloc software was
pirated by Western intelligence agencies too. I should have been both
surprised and disappointed if it had not been.
This thread has veered close to disagreeable chauvinism: the notion
that any country or bloc
] On
Behalf Of Lloyd Fuller
Sent: Friday, June 21, 2013 9:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Auditing vendor source code
Actually, US companies have also stolen software. I will not go into
details, but it has happened at a company that I worked for. One of their
customers stole
In 1371825433.55766.yahoomail...@web181402.mail.ne1.yahoo.com, on
06/21/2013
at 07:37 AM, Lloyd Fuller leful...@sbcglobal.net said:
Actually, US companies have also stolen software.
E.g., microsoft
http://en.wikipedia.org/wiki/Stac_Electronics#Microsoft_lawsuit.
--
Shmuel (Seymour J.)
On Tue, 18 Jun 2013 16:45:09 -0700, Charles Mills wrote:
... So it would not necessarily be in great a position to steal customer data
itself, but if we were malicious, and conspired with a rogue employee, we
could perhaps jointly steal valuable data.
..., nor how to defeat our keys. ...
Perhaps there is a place for a trusted third party who can audit the
source and issue some sort of assurance that the vendor could then attach.
Of course, this suffers from a number of problems. Such as cost. The need
to get a new certification after every change (or perhaps level set or
release).
I think in terms of auditing the source code for nefarious operations, there is
a kind of “mutual assured destruction” principle at work here. If a vendor was
so careless with their source code as to allow some kind of scam to be done
with their code, the ensuing scandal would simply ruin that
In my experience customers are often less concerned with looking at
source code themselves than they are with its availability after an
ISV, particularly a small one, has ceased to be.
I know of a number of arrangements in which current versions of some
product systematically replace deposited
On 13Jun19:0608-0700, Phil Smith wrote:
This is an interesting dilemma. FWIW, in almost 30
years as a vendor, I've never had anyone ask to see
source code for security reasons. That doesn't mean
it won't happen tomorrow, of course.
I suspect that the general attitude is a synthesis
of the
Right, but a very different issue.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of John Gilmore
Sent: Wednesday, June 19, 2013 6:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Auditing vendor source code
In my experience
Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Tuesday, June 18, 2013 11:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Auditing vendor source code
On Tue, 18 Jun 2013 16:45:09 -0700, Charles Mills wrote:
... So it would not necessarily be in great a position
On Wed, 19 Jun 2013 08:42:10 -0700, Charles Mills wrote:
- ... (assuming he had write access to the load library, or to protected
memory).
Il va sans dire.
- Our key (licensing, whatever you want to call it) is definitely
protection by obscurity. If you knew exactly how it worked, you could
Charles Mills wrote:
Our key (licensing, whatever you want to call it) is definitely protection
by obscurity. If you knew exactly how it worked, you could defeat it, and run
our product forever on every mainframe in the world.
So this is a slightly different topic, but it's been my experience
Perhaps the simplest way would be to somehow have an entire subroutine
encrypted. The subroutine would be self relocating in order to avoid
address constants. The encryption key would be somehow tied to the CPUID
and the date. When you get a new key, you also get a new encrypted
subroutine. The
In 099ee5bc-1948-4595-96ce-5115309e9...@yahoo.com, on 06/18/2013
at 08:30 PM, Scott Ford scott_j_f...@yahoo.com said:
We don't worry about we have customers who sign NDAs ...but I am old
school I resist providing source code,
That's not old school; old school is we don't provide object code -
In 51c127d4.6020...@blackhillsoftware.com, on 06/19/2013
at 01:39 PM, Andrew Rowley and...@blackhillsoftware.com said:
How many vendors do allow you to audit their authorized code? I know
IBM is very reluctant to divulge any information that might allow
you to exploit a vulnerability.
Until
In
b870629719727b4ba82a6c06a31c291239e0e0c...@hqmailsvr01.voltage.com,
on 06/19/2013
at 06:08 AM, Phil Smith p...@voltage.com said:
I suspect that the general attitude is a synthesis of the comments
here:
A few more possibilities:
- Customers may lack the resources to audit every
On Wed, 19 Jun 2013 09:17:09 -0700, Phil Smith wrote:
So this is a slightly different topic, but it's been my experience that CPUIDs
(keys, whatever you want to call 'em) are more trouble than they're worth.
Any sysprog worth his salary can break them in minutes if desired; the hassles
at the
Paul Gilmartin wrote:
Apparently. I've held the same job for three different employers
through corporate acquisitions. The latest one required that we
scrub all our keys, forthwith,
I'm sorry, I must be dense-I don't understand what this means. The keys were
dirty? :) Seriously, what did they
On 6/19/2013 9:17 AM, Phil Smith wrote:
So this is a slightly different topic, but it's been my experience
that CPUIDs (keys, whatever you want to call 'em) are more trouble
than they're worth.
We once had a situation in which a foreign distributor had numerous
off-book customers using our
On Wed, Jun 19, 2013 at 8:22 AM, John McKown
john.archie.mck...@gmail.com wrote:
Perhaps there is a place for a trusted third party who can audit the
source and issue some sort of assurance that the vendor could then attach.
Of course, this suffers from a number of problems. Such as cost. The
Ed Jaffe wrote:
We once had a situation in which a foreign distributor had numerous off-book
customers using our software illegally. It's not clear whether the customers
actually realized they were pirating the software. In any case, the
implementation of so-called keys put a stop to all
This was true in DOS 6.X. The object modules would be loaded into
memory, and the first thing the program would do was decompress the
rest of the module into another memory area and run from there. This
was when software to compress DOS disks was becoming popular. But it
would run on any PC.
On Wed, 19 Jun 2013 11:01:20 -0700, Phil Smith wrote:
I'm sorry, I must be dense-I don't understand what this means. The keys were
dirty? :) Seriously, what did they have you do with them?
I took a verbal shortcut. I should have said we had to scrub all our
software to cleanse away the filthy
Subject: Re: Auditing vendor source code
On 6/19/2013 9:17 AM, Phil Smith wrote:
So this is a slightly different topic, but it's been my experience
that CPUIDs (keys, whatever you want to call 'em) are more trouble
than they're worth.
We once had a situation in which a foreign distributor had
On Wed, 19 Jun 2013 15:00:00 -0500, Mike Schwab wrote:
Marketing your product through IBM Partner World is essential a seal
of approval from IBM.
Is it really?
They have at least tested it and should be able to find any problems
with the product that a customer reports.
Who has? IBM?
--
Tom
I wondered about those assertions ...
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Tom Marchant
Sent: Wednesday, June 19, 2013 2:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Auditing vendor source code
On Wed, 19 Jun
Tom Marchant wrote:
Marketing your product through IBM Partner World is essential a seal
of approval from IBM.
Is it really?
Um, no. Well...maybe some customers see it as such, but they should know better.
They have at least tested it and should be able to find any problems
with the product
On Wed, 19 Jun 2013 14:34:25 -0700, Phil Smith wrote:
They have at least tested it and should be able to find any problems
with the product that a customer reports.
Who has? IBM?
Again, no. IBM doesn't test products before letting vendors list them on PWD!
Even the App Store claims to do
John:
I would be extremely reluctant to buy any such product.
In one place I worked the serial numbers changed continuously
(monthly) and we had one or two vendors that stuck it to us because
of a bad key they sent and we literally had to back out of CPU
upgrades because they didn't have
In
b870629719727b4ba82a6c06a31c291239e0e0c...@hqmailsvr01.voltage.com,
on 06/19/2013
at 09:17 AM, Phil Smith p...@voltage.com said:
So this is a slightly different topic, but it's been my experience
that CPUIDs (keys, whatever you want to call 'em) are more trouble
than they're worth.
Mike:
That might work for small ISV's but companies like CA would not go
for it as they slice and dice prices to get a sale.
Ed
On Jun 19, 2013, at 3:00 PM, Mike Schwab wrote:
On Wed, Jun 19, 2013 at 8:22 AM, John McKown
john.archie.mck...@gmail.com wrote:
Perhaps there is a place for a
List IBM-MAIN@LISTSERV.UA.EDU
Subject: Auditing vendor source code
When you are dealing with vendors of a smaller scale than IBM, BMC or CA,
and you are installing a product that will run APF authorized, how do you
assure yourselves that the product is not stealing your secrets, or allowing
others
it requires
a trust relationship.
- Original Message -
From: Sam Siegel s...@pscsi.net
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Tuesday, June 18, 2013 3:46:10 PM
Subject: Re: Auditing vendor source code
On Tue, Jun 18, 2013 at 3:41 PM, Ted MacNEIL eamacn...@yahoo.ca wrote
used patient immunization records to obtain credit cards online
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Sam Siegel
Sent: Tuesday, June 18, 2013 3:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Auditing vendor source code
think that Charles is asking the opposite question. He works for a vendor
and some of their code runs authorized. He is asking what audit requirements
customers typically have for authorized code from small vendors.
He specifically asked about 'stealing secrets'.
That's more than audit
39 matches
Mail list logo
