Re: RFC: Adding a SECURITY.md document to the Binutils
Ian Lance Taylor via Gdb <[email protected]>
| Newsgroups | gmane.comp.gdb.devel,gmane.comp.gnu.binutils |
|---|---|
| Message-ID | <CAKOQZ8wzHN+2RDXnOVtFyBmtSYhqD5HSC2dNi1PacbVKcgOD5g@mail.gmail.com> |
On Fri, Apr 14, 2023 at 12:45 PM DJ Delorie <[email protected]> wrote: > > Ian Lance Taylor via Gdb <[email protected]> writes: > > Compilers and linkers must behave in a reasonable manner when given > > untrusted input. > > Are we confusing trusted with well-behaved? I mean, if I download a > source tree from the FSF's git server, I trust it, but it may still be > ill-behaved. Meanwhile, sources from a public mailing list may be > well-behaved but not trusted. > > I'm only posting this because Carlos and I had long discussions about > this before we set up the glibc pre-commit CI. This process takes > random patches from the public glibc mailing list, and builds them. > WHOA! That's dangerous! Yes. The patches may produce well-defined > code, but are not trusted. Those builds run in a tight sandbox to > mitigate any attack attempts. Security here is outside the scope of the > build tools. I don't expect gcc to scan for viruses or prevent people > from doing "#include </etc/passwd>". I agree that GCC does not have to scan for viruses or strange #include statements. I am saying that you should not need to set up a sandbox merely to build code. Clearly if you want to execute untrusted code, some sort of sandbox is a minimal requirement. I'm only talking about building code (and, for objdump and friends, inspecting code). Ian