On Mon, 14 Aug 2023, Siddhesh Poyarekar wrote:
> There's no practical (programmatic) way to do such validation; it has to be a > manual audit, which is why source code passed to the compiler has to be > *trusted*. No, I do not think that is a logical conclusion. What is the problem with passing untrusted code to a sandboxed compiler? > Right, that's what we're essentially trying to convey in the security policy > text. It doesn't go into mechanisms for securing execution (because that's > really beyond the scope of the *project's* policy IMO) but it states > unambiguously that input to the compiler must be trusted: > > """ > ... It is necessary that > all source code inputs to the compiler are trusted, since it is > impossible for the driver to validate input source code beyond > conformance to a programming language standard... > """ I see two issues with this. First, it reads as if people wishing to build not-entirely-trusted sources need to seek some other compiler, as somehow we seem to imply that sandboxing GCC is out of the question. Second, I take issue with the last part of the quoted text (language conformance): verifying standards conformance is also impossible (consider UB that manifests only during linking or dynamic loading) so GCC is only doing that on a best-effort basis with no guarantees. Alexander
