On Tuesday, 7 June 2016 at 23:05:49 UTC, Walter Bright wrote:
On 6/7/2016 2:28 PM, Steven Schveighoffer wrote:
I can attest that figuring out why something isn't inferred
@safe isn't always
easy, and the "slap a @safe: tag at the top" isn't always
going to help.
Having a -safe compiler switch to make @safe the default won't
improve that in the slightest.
I think it's useful here to compare one aspect of Perl's approach
to
security, its "taint" mode. It tags insecure data to make sure it
does not affect the security of the application, and blocks
actions
where insecure actions would otherwise occur. The Perl invocation
accepts a couple of flags to control how taint mode works:
-t Like -T, but taint checks will issue warnings rather than
fatal
errors. These warnings can now be controlled normally with
"no
warnings qw(taint)".
Note: This is not a substitute for "-T"! This is meant to
be used
only as a temporary development aid while securing legacy
code:
for real production code and for new secure code written
from
scratch, always use the real -T.
-T turns on "taint" so you can test them. Ordinarily these
checks
are done only when running setuid or setgid. It's a good
idea to
turn them on explicitly for programs that run on behalf of
someone
else whom you might not necessarily trust, such as CGI
programs or
any internet servers you might write in Perl. See perlsec
for
details. For security reasons, this option must be seen by
Perl
quite early; usually this means it must appear early on the
command line or in the "#!" line for systems which support
that
construct.
The point being, such flags provide a very simple means for the
user
to check the execution of their code, without being terribly
intrusive.
They can be a great convenience as a stepstone to discovering
where
problems exist and addressing them.
