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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e6ea6a59056d4060 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-03-28 08:04:23 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!unlisys!news.snafu.de!cs.tu-berlin.de!uni-duisburg.de!not-for-mail From: Georg Bauhaus Newsgroups: comp.lang.ada Subject: Re: GNAT 3.14p and Red Hat 7.2 Date: Thu, 28 Mar 2002 16:04:22 +0000 (UTC) Organization: GMUGHDU Message-ID: References: <3C9F40A2.5AF3920D@raytheon.com> <87g02nm7gm.fsf@deneb.enyo.de> <87sn6m4438.fsf@deneb.enyo.de> NNTP-Posting-Host: l1-hrz.uni-duisburg.de X-Trace: a1-hrz.uni-duisburg.de 1017331462 23318 134.91.4.34 (28 Mar 2002 16:04:22 GMT) X-Complaints-To: usenet@news.uni-duisburg.de NNTP-Posting-Date: Thu, 28 Mar 2002 16:04:22 +0000 (UTC) User-Agent: tin/1.5.8-20010221 ("Blue Water") (UNIX) (HP-UX/B.11.00 (9000/800)) Xref: archiver1.google.com comp.lang.ada:21765 Date: 2002-03-28T16:04:22+00:00 List-Id: Florian Weimer wrote: : "David C. Hoos, Sr." writes: : :>> The first warning is issued because the code *does* contain a security :>> problem (your Ada application will be affected only if it uses :>> temporary files, though). Ignoring it won't make it go away. ;-) :> :> More correctly, one should say "your Ada application will be affected :> only if it uses GNAT.OS_Lib.Create_Temp_File." :> :> One can certainly safely use temporary files in Ada programs. : : But not using the mechanism in A.8.2(4). :-/ I recall a discussion of OS security in the Minix book by Tanenbaum, where he points out that you should not believe in security because your system manual tells you some part of the system has been secured. On the contrary, the mechanism should be open to cracking attempts, to be tested. On the surface, this seems unrelated, and mkstemp() (or whatever its name is) is open to testing of all kinds. But the mindset seems related, at least to me. If programmers feel they have written a secure program because they are told their compiler doesn't use insecure OS facilities, I wouldn't, necessarily, as a user of their program. Proven security...? Improved security due to the removal of one possible hole? Let me argue in favour of documenting possible holes. If program writers learn to pay attention to the outcome of the compilation process, and they must, once they now even an Ada program doesn't just use RM virtuality, they will care about what OS facilities operate behind the scenes. Who knows what will happen to a running Ada program if the OS kernel supports modifying the hardware clock... I don't, right know, but if my program depends on that device, I will pay attention, and hope to find a note somewhere near the Clock documentation. - Georg