[OT] NSA guidance on software security
Siarhei Siamashka
siarhei.siamashka at gmail.com
Fri Nov 11 19:51:33 UTC 2022
On Friday, 11 November 2022 at 18:24:46 UTC, Nick Treleaven wrote:
>>> Just declare main @safe.
>>
>> Have you missed my comment, which was talking about exactly
>> that?
>
> You didn't mention main.
I apologise. I didn't think that you are unfamiliar with this
particular language construct. Check
https://dlang.org/spec/attribute.html and search the "affects all
declarations until the end" substring to find the relevant part
of documentation.
Basically you can put "@safe:" in the beginning of your program
and all functions (the main function too) will be @safe by
default.
>
>>> Memory unsafety is non deterministic. Overflow/underflow is,
>>> so it's much less important.
>>
>> Neither is deterministic. Unless you have strictly
>> deterministic input data.
>
> Whatever the input data, without memory safety you can't
> trigger the bug through testing alone. It might never occur
> on your system, only on your client's.
There may be certain input data patterns, which are not properly
stressed by your local testing setup. And only manifest
themselves on a client's system. If that's not enough to convince
you, there are also many CVEs that mention "integer overflow".
Moreover, paged virtual memory used in modern computers already
provides some kind of rudimentary memory safety (with page
granularity). Your client may get a "segmentation fault" error
with a core dump or a crash dump file, which can be used by you
to debug the issue. Debugging an arithmetic overflow bug may be a
lot more tricky.
> That's why the NSA recognises memory safety bugs as
> categorically worse
> than logic bugs or overflow/underflow.
Can you prove this claim by providing a citation?
More information about the Digitalmars-d
mailing list