Re: RFC: Adding a SECURITY.md document to the Binutils

On 2023-04-14 16:46, Ian Lance Taylor wrote:
> On Fri, Apr 14, 2023 at 11:27 AM Siddhesh Poyarekar <[email protected]> wrote:
>>
>> A compiler crash, core dump, etc. is definitely a serious bug and we
>> consider them as P1/P2 in almost all cases.  However to be considered a
>> security issue, the input has to be crafted and that's where the user
>> comes in; their responsibility is to ensure that they don't build
>> untrusted code (e.g. when they're trying to study malware or virus
>> sources or binaries) outside of sandboxes.
> 
> I believe I understand what you are saying, and I don't agree.
> 
> We live in a time where free software has succeeded.  People routinely
> rely on gigantic libraries provided as source code by people across
> the Internet.  10% of the projects on GitHub are written at least
> partially in C++.  To argue that people should not even compile
> untrusted code is to speak about a world that simply does not exist
> today.  Very few people working on application level code can trust
> their entire software supply chain.
> 
> This means that software development must be secure at every level.
> We must not rely on the single layer of defense of trusting source
> code, a defense that very few people can maintain.  We must defend at
> other levels.
> 
> The binutils developers must play their own small part in this, which
> is to assemble and link code correctly, and to not make the assembler,
> linker, and related tools themselves into vectors for security issues.

I don't disagree with that as an end goal (I even suggested that in that 
previous thread last year), I think our disagreement is in how we get 
there in terms of policy, which is a result of that conversation from 
last year and from exploring how llvm and rust are handling it.

>> If as a project we decide to treat untrusted input as a valid use case,
>> it is going to shift the goalposts for binutils (and gcc, if we take the
>> same stand there). I suppose golang does try to adhere to these higher
>> standards somewhat but I am not well versed with their formal position
>> on this.  I've seen them consider bugs due to untrusted regex inputs as
>> security issues whereas even glibc currently doesn't, except for some
>> very specific conditions.
> 
> Yes, the Go project does aim to adhere to these higher standards,
> because, in my opinion, they are the correct standards.
> 
> And, honestly, these are not standards that are unusually difficult to
> meet.  Don't dump core, don't use up all of memory, don't have buffer
> overflows.  Treat failures of this sort as security bugs to be fixed
> ASAP in minor releases.  These are achievable goals.

Sure, they're achievable with adequate resources, but I'm not sure if 
the binutils project has that; that was in essence the conclusion of 
last year's conversation FWIW.  That of course is a question for the 
maintainers of the project.

Thanks,
Sid