From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA32569 for caml-red; Fri, 9 Jun 2000 19:32:50 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id AAA25502 for ; Fri, 9 Jun 2000 00:39:32 +0200 (MET DST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by nez-perce.inria.fr (8.10.0/8.10.0) with ESMTP id e58MdVj24973 for ; Fri, 9 Jun 2000 00:39:31 +0200 (MET DST) Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.117.200.23]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA90572 for ; Thu, 8 Jun 2000 18:37:33 -0400 Received: from BLDVMA.boulder.ibm.com (bldvma.boulder.ibm.com [9.99.64.30]) by northrelay03.pok.ibm.com (8.8.8m3/NCO v4.9) with SMTP id SAA271314 for ; Thu, 8 Jun 2000 18:39:20 -0400 Received: by BLDVMA.boulder.ibm.com (IBM VM SMTP Level 310) via spool with SMTP id 6970 ; Thu, 08 Jun 2000 16:40:01 MDT Reply-To: "Daniel Ortmann" Received: from neon.rchland.ibm.com by po1 (AIX 3.2/UCB 5.64/4.7) id for caml-list@inria.fr; Thu, 8 Jun 2000 17:36:38 -0500 Received: by neon.rchland.ibm.com (AIX4.3/UCB 8.8.8/4.7) id ; Thu, 8 Jun 2000 17:36:38 -0500 To: luther@dpt-info.u-strasbg.fr Cc: caml-list@inria.fr Subject: Re: Reverse-Engineering Bytecode: A Possible Commercial Objection To O'Caml References: <200006062047.QAA08876@northrelay03.pok.ibm.com> <20000608105446.A10624@lambda.u-strasbg.fr> From: Daniel Ortmann Date: 08 Jun 2000 17:36:38 -0500 In-Reply-To: Sven LUTHER's message of "Thu, 8 Jun 2000 10:54:46 +0200" Message-Id: X-Mailer: Gnus v5.7/Emacs 20.5 Sender: weis Note that althought I brought up the idea of such encryption, I don't really have much opinion as to whether it is a good idea. I *do* believe it should be discussed. ... and not mainly philosophically. But technically. Hopefully that email got some people thinking. If so, then that small mission of mine has been accomplished. Also, isn't "information hiding" part of the purpose of .cmi files? What I am suggesting might be viewed as an stronger type of .cmi file ... with REAL "implementation hiding". :-) Sven LUTHER writes: > This surely is the philosophy of those who want to make more money using all > the free software that other people have developped for free. I brought it up precisely because I thought "Maybe this is an idea that occurs to me merely *because* I work in a commercial engineering environment? If so, then it might not occur to people who are more academically oriented." Your response shows the virtue of my email: you were motivated to respond. (I wanted to post on this topic a couple of months ago ... but since I know the high skill level of the people on this list I had to "work myself up to it".) > Anyway, i personnaly are not at all in favor for a scheme such as what you > propose. Ivan Galamian, violin instructor and long time head of the Julliard string department said, "A particular technique might go out of style, but the ability to do it never goes out of style." The ability to manage encrypted byte code, even if provided, might not be used. But the ability to do so would not go out of style. Today, even when companies "work together" and use each other's chips, models, and other circuitry, they distribute encrypted SPICE models or blackbox driver specifications called "IBIS". We're stuck with encryption. Worse, with multiple incompatible encryption. :-( > But then i am a Debian GNU/Linux developper and my opinion might be a bit > biased on this. I know MANY people inside IBM who are actively lobbying for much more use of Linux ... as well as general support for the Open Source movement (i.e. more than in words). While I personally use FreeBSD at home, I would love to see Linux and GNU use increase. At work. In homes. Everywhere. The problem is that many upper level people who control the money often believe that the Open Source movement is anti-business. (Hint, hint:-) > Still, please remmeber a few things : > 1) Reverse engineering is legal in many european countries. I did not know that. Is "making it hard to reverse engineer" illegal? :-) > 2) Encryption is illegal in many countries, or at least export restricted, i > think france changed this some time ago, but if not, it would not be > possible for inria to distribute such a product. I believe the US has just lightened up on some of the restrictions. ... But the answer would be: Don't distribute the actual encryptiong directly with O'Caml, just the hooks. Have the actual files containing the encryption available from non-restricted sites just as FreeBSD does. (I'd guess that Linux does something similar?:-) > 3) Well this would be a big step back in what the has been achieved in > freedom of software and sharing of ressources. I would interpret the idea as "allowing people do have control over what they wish to share and what they wish to keep private." > Caml has a too small community today that you can permit to hamper it by > being overly protectionist. And despite what you may think, it would be more > important fro ocaml to be adopted by the "free" software community (that is > all the linux/*bsd/whatever users), than by the "non-free" one (that is the > people you have in mind). I believe you are correct. However, the options are not mutually exclusive for the following reasons: a) I am NOT saying "Everything should be encrypted". Absolutely not. I am saying "Consider what might need to be done technically to make such a thing possible." b) "Aiding the Open Source movement" is not the same thing as "restricting business possibilies". c) If O'Caml is good for Open Source, it is certainly good for business. Any territory gained by O'Caml in business is not taken from Open Source. Are there specific ways and reasons how and why adding such possibilities would hurt the Open Source movement? I am especially interested in technical problems. > Since the former surely will contain all the programmers in formation who > will later become programmers and decider of the second group. Also > remember that many big companies are going for the "free" movement, like IBM > and SGI for example. I've heard words and slogans ... and some larger plans. But the real interest is in the popular movement inside IBM. In fact "the deciders" are most often Myer-Briggs "ISTJ" types who think "long term" means "next month". :-/ In fact I've seen people with ideas desparately avoid becoming managers, even skipping meetings to establish a reputation as non-manager material. :-) > 4) Is there really a need for this, would the complexity of doing so not > outweigh the benefit ? I don't know. I am admittedly the only one that I know of who has asked the question. But how hard would it be? a) If it's easy, then why not do it? b) If it's hard, does the difficulty point out any technical flaws in O'Caml? c) If a) or b), then might the answer be "do it in either case"? :-) > 5) In particluar there is a theory that says that security though peer > review permitted by open source developpment model is higher than security > trough hiding which you are suggesting. Or else you will find yourself with > a microsoftian type of product (buggy, hidden, expensive, ...), which i > doubt is something the ocaml community wish to be associated with. I believe you are likely correct. > 6) If someone is good enough to reverse engineer your ocaml bytecode, i > think he is good enough also to reverse engineer your encrypted stuff, or at > least to find holes in the security of it. I just "reverse engineered" emacs byte code by doing x r ~/.emacs.elc ... and easily viewed actual lisp code. That's how easy it was. That's the kind of thing I was thinking about avoiding. > 7) If you think the bytecode security is not enough for you, just use native > code, it is faster anyway, and i doubt you will have less hideance in this > than writting in C or C++, ... Yes, that is a possibility. But what if someone wants to develop a special mathematical toolbox and provide it via byte code? The byte code is platform independent ... but in this case you want it somewhat hidden. After all, isn't that the purpose of .cmi files? Hiding information? What I am suggesting could be viewed as an stronger type of .cmi file ... with REAL "implementation hiding". :-) If you don't agree with that, could you tell me why one type of hiding is good and the other bad? (The question is rhetorical, of course.) > 8) Finally, if all the above don't convince you, Ocaml is now available > under a free license, and thus you are free to implement such a scheme, if > you want so. This may not be the best fro the ocaml community, but still you > can do it. Ummmm... This suggestion troubles me more than any of the rest. :-( Leaving some things up to users is good, but *not* everything. Consider what happened with Scheme. Here is a quote from a news post by Olin Shivers: Programming in Scheme is an extremely unportable task if you do anything serious. Scheme is much less portable than, say, tcl or C. So we are unable to build on each other's work, but must instead keep re-inventing the wheel. If you *union* up the technology and features in all the Scheme implementations out there, you have an amazing tool. But each implementation is different, and all lack some important features. You don't hear people saying, "I wrote my program in SGI's implementation of C -- I can't run it on your Linux box because the struct declarations are different, and Linux's C implementation doesn't have do-while loops. Also, the interface the Unix write() function is different, so I'd have to rewrite all the I/O." I couldn't solve my problem in Scheme. And I am tolerably well acquainted with the language and its implementations. I could solve my problem with tcl. The server we were running had a tcl interpreter linked in, and the tcl system had hooks to an RDBM interface. Took an evening. As long as this situation persists, the Scheme community can snipe about what a lousy, poorly-designed language tcl is, but they aren't in a position to offer a credible alternative. So it is just empty flaming. So why post? Go fix the problem. -- Olin Shivers I personally *am* a strong believer in "reinventing the wheel" ... because it makes me good at reinventing. :-) But then I compare against standard prefix stuff, re-work the code, and do it also the "right" way. > As a personal note, if it is not confidential, what are the personal > interrest that make you ask yourself this kind of questions, are you aware > of a particular company which ask this kind of question when faced with > ocaml ? It's not confidential. I'm the only one I know who has asked the question. In fact, I've not yet implemented *any* actual solutions with it here at IBM in O'Caml. I've tried to be sensitive to the concerns of my colleagues and hold back on some change for awhile. (I am the sort of person who always helped everyone else with their homework and forgot to do my own.:-) The problems I've run into have included things such as: a) Public relations about O'Caml, (informing people around me gains me more freedom to act in the future.) I've had to hold back and limit myself to reading and informing ... I think I've built enough trust to start using it soon. b) Compiling problems. I've had very poor results with local versions of GNU GCC on our AIX/RS6000 systems. Can't link to various libraries, problems with shared libraries, problems with compiler crashes, problems with crashes of programs compiled with GCC, etc, etc. (It works great on FreeBSD.) c) Whenever I recompile *anything* ... I recompile *everything*, including almost all supporting libraries. I dread it. :-( d) Lately I've even had some problems compiling with using our own compiler on my system. I think I need to reinstall or upgrade the OS. > And i hope this few remarks can contribute to this discution, please don't > take them negatively, if i was unexact or maybe offending somewhere. I actually have a GENERAL PURPOSE 2-step problem solving process which can be used to solve ANY problem. The advantage is that the second step is trivial, and the first step applies to ALL problems. The steps are, 1) learn everything in the universe, 2) solve problem. I'm still working on the first step. :-) -- Daniel Ortmann, IBM Circuit Technology, Rochester, MN 55901-7829 ortmann@vnet.ibm.com or ortmann@us.ibm.com and 507.253.6795 (external) ortmann@rchland.ibm.com and tieline 8.553.6795 (internal) ortmann@isl.net and 507.288.7732 (home) "The answers are so simple, and we all know where to look, but it's easier just to avoid the question." -- Kansas