Path: utzoo!attcan!uunet!husc6!uwvax!oddjob!ncar!ames!ucsd!ucsdhub!hp-sdd!hplabs!pyramid!octopus!pete From: pete@octopus.UUCP (Pete Holzmann) Newsgroups: news.admin Subject: Re: Author's Reliability (was Re: Malicious Posting Worries...) Message-ID: <279@octopus.UUCP> Date: 3 Jul 88 04:20:40 GMT References: <266@octopus.UUCP> <11518@agate.BERKELEY.EDU> <271@octopus.UUCP> <11589@agate.BERKELEY.EDU> Reply-To: pete@octopus.UUCP (Pete Holzmann) Organization: Octopus Enterprises, Cupertino CA Lines: 51 In article <11589@agate.BERKELEY.EDU> weemba writes: >>>One can, however, scan source code for inordinately complicated monkey- >>>shines, comments that don't appear to match code, etc. >>>I cannot do this with *any* "short little" binaries. >> >I wrote: >>I certainly can! The equivalent to quickly scanning a source program, >>is to try out a binary in a controlled environment. >That's not much of an equivalent. [He can do non-trivial quick scans of >short <10K source files] Well, this discussion could go on for some time. There are plenty of PC-based tools for binary analysis that can be quickly run over reasonble- sized programs (and slowly run over big programs). String searches, automatic disassemblers that produce comments for anything that touches the external environment (system memory, I/O ports, interrupts, system calls), etc. One of the nice things about having millions of hardware- compatible systems, is that we've got automatic tools to do what must be done by 'hand' in Unix. [BIG disclaimer: there are many things that Unix has that DOS can't touch. I don't want to imply that I'm knocking Unix!] >No!! If Billy Binary compiles his binary with an infected compiler, a >virus could spread via Usenet, without Billy's knowledge or intent. En- >crypting won't protect him. What happens with source is that the risk of >infection from bad compilers rests squarely with the end user. If we follow a rule of "Author's reliability", then it is Billy Binary's worry as to whether or not his development tools are reliable or not. If we must go so far as to have real worries about our development tools, then yes, a reliable binary posting is more worrisome than a reliable source posting. On the other hand, the most probable problem a user is going to see is that of a *bug* in the program. Bugs tend to be independant of the distribution method (source or binary) [actually, binary would tend to be better here, since a tested binary produced with known good tools may be better than a binary produced with lesser tools in the hands of the user]. And bugs point back to the author. I think that, when all is said and done, what we need to settle on is some kind of author's reliability/responsibility policy. That is practical, workable, reasonable, and should free us from a lot of worries! Pete -- OOO __| ___ Peter Holzmann, Octopus Enterprises OOOOOOO___/ _______ USPS: 19611 La Mar Court, Cupertino, CA 95014 OOOOO \___/ UUCP: {hpda,pyramid}!octopus!pete ___| \_____ Phone: 408/996-7746