Now we're on to Modules, Macros, Languages https://school.racket-lang.org/2019/plan/wed-mor-lecture.html
@feonixrift @_emacsomancer Yes, I think this is a key thing often missed: reading parenthetical syntax can be *more readable* than non-parenthetical syntax by a dramatic amount with rainbow parentheses https://dustycloud.org/tmp/emacs_lisp_setup.png
And that's not even including how parenthetical structure makes code flow more obvious.
@cwebber I think other than initially looking a bit funny or being unfamiliar to people who learned programming with non-Lispy languages, #Lisp #parentheses have more advantages than disadvantages. I mentioned to Matthew Flatt (re: paren-less Racket langs) that I think the parens could make Racket/Lisp potentially easier for getting #linguistics students into non-trivial programming than other langs, since linguists are used to dealing with #trees and bracket-notation for trees.
@carlozancanaro Not sure if this is also you, but happy to see that someone is showing that I am not urgently correct ;) https://github.com/slime/slime/issues/286#issuecomment-509993349
SLIME seems not as in as bad of a position as Guile was. That's good! Unix domain socket support would still be nice but it appears that from web browsers SLIME isn't as at risk as I thought it was.
@cwebber Looking through what I can find, the Guile protocol is just sending forms, which is vulnerable to this attack because it ends up ignoring the GET and other extra bits.
SLIME's protocol is s-expression based, and thus the GET will cause the message to be malformed (and, according to my tests, will cause swank on the CL side to terminate the connection).
I'm not sure this is as serious a vulnerability as it was in Guile.
Kind of disappointing to see response to this SLIME bug as "overblown and theoretical" https://github.com/slime/slime/issues/286#issuecomment-491267916
We had to fix this in Guile, and we had demonstration attacks against it. I linked to them... it isn't theoretical. https://github.com/slime/slime/issues/286#issuecomment-252942726
#lang dungeon is my vague plan for an ocap-safe module layer for Racket
The thing that's semi-evil is it doesn't *look* like maybe-evil-macro is likely to inject bindings into your current scope. Admittedly this isn't much of a concern in present Racket programs, but could more seriously break security considerations in something like #lang dungeon
One other thing that I hadn't considered before today is that a hygenic macro can actually install definitions in the current scope. For example:
(define x 2)
(define y 3)))
(maybe-evil-macro) ; binds x and y
(+ x y))
In fact I have used such macros before, but hadn't considered the security risk they could pose: you could "surprise" a user by shadowing variables in a previous scope.
I wonder how W7 deals with it?
@cwebber We called the process of local-expanding and digging out an unexported identifier to use "dumpster diving", and it requires active remediation with dyepacks and syntax-arm/disarm
Good news that Matthew Flatt told me they planned for this, and it should be possible for me to make a safe racket #lang
Jay showing how to break hygeine.
Jay and Matthias: "but don't do it"
Me: but wait... you can't use this to exfiltrate information from a module that it didn't provide can you?
Them: yes but just don't do it
Me: but this has security implications for the stuff I'm working on
Them: Yep, talk to these people afterwards, we shouldn't distract the class
Me, internally: aaaaaaaaaaaa