Show more

@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 dustycloud.org/tmp/emacs_lisp_

And that's not even including how parenthetical structure makes code flow more obvious.

@_emacsomancer @cwebber and rainbow highlighting does more for readability than brackets do.

@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 ;) github.com/slime/slime/issues/

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.

This is one reason I don't hack on common lisp these days.

Kind of disappointing to see response to this SLIME bug as "overblown and theoretical" github.com/slime/slime/issues/

We had to fix this in Guile, and we had demonstration attacks against it. I linked to them... it isn't theoretical. github.com/slime/slime/issues/

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 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-simple-macro (maybe-simple-macro)
(begin
(define x 2)
(define y 3)))

(define (foo)
(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?

Maybe I need to spend the entire evening going through this part of the class

@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

It sounds like there's a path forward so I'm not too worried but hoo boy

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

Show more
Octodon

Octodon is a nice general purpose instance. more