Email list hosting service & mailing list manager

Escape via unhygienic macros Phil Hofer (03 Jul 2019 22:59 UTC)
Re: Escape via unhygienic macros John Cowan (04 Jul 2019 03:59 UTC)
Re: Escape via unhygienic macros Marc Nieper-Wißkirchen (04 Jul 2019 05:57 UTC)
Re: Escape via unhygienic macros John Cowan (04 Jul 2019 17:03 UTC)
Re: Escape via unhygienic macros Phil Hofer (04 Jul 2019 17:42 UTC)
Re: Escape via unhygienic macros John Cowan (04 Jul 2019 18:55 UTC)
(missing)
Fwd: Escape via unhygienic macros Marc Nieper-Wißkirchen (08 Jul 2019 12:20 UTC)
Re: Escape via unhygienic macros Marc Nieper-Wißkirchen (08 Jul 2019 12:37 UTC)
Re: Escape via unhygienic macros John Cowan (08 Jul 2019 16:27 UTC)
Re: Escape via unhygienic macros Lassi Kortela (04 Jul 2019 19:45 UTC)
Re: Escape via unhygienic macros Lassi Kortela (04 Jul 2019 19:56 UTC)
Re: Escape via unhygienic macros John Cowan (08 Jul 2019 04:56 UTC)
Re: Escape via unhygienic macros Marc Nieper-Wißkirchen (04 Jul 2019 20:26 UTC)
Re: Escape via unhygienic macros Lassi Kortela (14 Jul 2019 15:41 UTC)
Re: Escape via unhygienic macros John Cowan (14 Jul 2019 17:59 UTC)

Re: Escape via unhygienic macros Lassi Kortela 04 Jul 2019 19:45 UTC

Interesting discussion of an interesting proposal.

Indeed guarantees are always subjective, and even many security experts
look at things from an economic standpoint: how much protection can we
get for a given amount of effort.

VM security is extremely difficult to make airtight. Some analysts say
the JVM is one of the biggest generally unacknowledged security risks
around the world. A lot of holes are found, and it's on so many devices
that are patched late, if at all.

Closest comparisons to this SRFI that spring to mind are the Dhall
language (basically an extremely restricted Haskell for writing
configuration files that are not supposed to have side effects) and
OpenBSD's new pledge() system call which can be used to disable all but
the given groups of Unix syscalls for the remainder of the life of the
current process (e.g. programs that don't use the network can disable
all socket operations).

OpenBSD's stance was precisely that while there are fancier security
frameworks with fine-grained configurable policies, they are so
intricate that people won't use them as intended. pledge() buys a good
amount of protection while being so simple that programmers will
actually use it. Perhaps you intended to make a similar argument in this
thread, John? That the SRFI provides a simple protection that is worth
its small cost and should be combined with other precautions.