From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,dbf84a1c2794f4fb X-Google-Attributes: gid103376,public From: Jeff Carter Subject: Re: packages and private parts Date: 1997/02/10 Message-ID: <32FF4D8D.167EB0E7@innocon.com>#1/1 X-Deja-AN: 217825615 references: <32F170C8.6A88F208@cam.org> <32FA4C67.48D9@watson.ibm.com> <32FB27FF.794BDF32@innocon.com> content-type: text/plain; charset=us-ascii organization: DIGEX mime-version: 1.0 newsgroups: comp.lang.ada x-mailer: Mozilla 2.0 (X11; U; SunOS 4.1.3 sun4m) Date: 1997-02-10T00:00:00+00:00 List-Id: Robert Dewar wrote: > As for the "destroying safety and robustness issue", I think this is > totally bogus. > > The safety and robustness of a system depends on the integrity of > the sources. If anyone can go changing sources then of course any > guarantees on private part integrity are destroyed, and furthermore > the user of the package has potentially no knowledge that it has > been destroyed in this way. Clearly this is swomething that CM > systems must protect against. Except, of course, that anyone can write a child without changing sources, but with the same effect. Putting the sources under CM doesn't prevent this. > Child packages are much safer. If you have a set of packages from > a "great designer", and want to use them, then use them, do NOT > use any suspicious non-official children! Remember that a program > is only affected by the presence of child packages if it directly > or indirectly with's these children. How do you know which children are official and which are not? How do you know whether a programmer has written and used an unauthorized child that is not known to the rest of the system? > Remember also that the integrity of private parts is always > attackable using unchecked convrsion. You expect to be able to > defend against this with rules that limit the use of UC, so put > into palce appropriate rules that limit the use of child packages > if you are concerned about this problem, and possibly enforce > them with your CM package, if this is useful. Unchecked_Conversion and overlays using an address clause are easy to detect. Child packages are very difficult to detect. -- Jeff Carter Innovative Concepts, Inc. Now go away, or I shall taunt you a second time.