Fork me on GitHub
#unrepl
<
2017-07-21
>
richiardiandrea07:07:16

Another thing to note was the some use case seem to demand for eval or read override, like the one above for security purposes

richiardiandrea07:07:02

And that there is still the problem of code dependencies to solve when injecting the blob..

richiardiandrea07:07:23

For instance yesterday I tried to hookup compliment in unravel and I had to do it server side because I would have to concat and send to many blobs + deps to the repl otherwise

cgrand13:07:54

Definitely a good case to figure out the unrepl way.

richiardiandrea07:07:32

In general many people showed up

richiardiandrea07:07:24

Some more concerned about ide integration then streaming repls (there was a question on a better clj-refactor as well)

thheller07:07:57

I assume “security” is related to having a REPL into a production system? or during development also?

richiardiandrea07:07:24

No security was for prod, one idea was to blacklist or whitelist forms, another was to have a read-only repl where you can only read but not modify vars

cgrand13:07:35

Both cases seem difficult too do right. Whitelist too little and you get a poor copy of JMX. Too much and you have exploits. Read-only is difficult to harden too.

dominicm14:07:58

The real thing that is needed for PCI compliance is: * Logging inputs (viable with changing the socket repl server) * authentication via arbitrary process: approval via other people for PCI specifically The other stuff was really an expansion. I think it doesn't need to be perfect, it's just to reduce accidental leaks I think.

dominicm14:07:32

We really want nice tooling, live dynamic environment & such despite the compliance regime we're under. So that's where this line of thought is coming from. Even better is the "bring your own tooling" situation.

cgrand12:07:44

What does PCI require (or forbid) exactly?

malcolmsparks13:07:52

@cgrand PCI is a large compliance regime which is hard to fully explain in this thread, but it mostly boils down to knowing who your users are, ensuring that a single bad-actor can't steal information or inject vulnerabilities/backdoors into your systems.

malcolmsparks13:07:02

It is easier to satisfy some of security requirements if users don't have the ability to mutate the system (other than by the allowed routes through a change management process)

malcolmsparks13:07:51

Emergency diagnostic access to systems via a REPL environment is a major advantage to Clojure systems, in my view. The knee-jerk reaction of most security regimes is to ban REPLs but I think this is a poor compromise - therefore I'm particularly interested in various strategies to secure REPLs - logging, authentication, monitoring, encryption, etc.

cgrand16:07:22

What a logging proxy for a start – it may be a hack with netcat and tee.

thheller07:07:00

I think production REPLs have quite different concerns from development REPLs

thheller07:07:12

and should probably be built differently to begin with

thheller07:07:32

you can already override read and eval

thheller07:07:53

just not with nREPL

dominicm08:07:54

Is it confusing to have separate unrepl and "tooling" (lsp) protocols?

dominicm08:07:50

And when I say confusing, I mean from a UX perspective, not in simple/complex terminology.

cgrand09:07:05

For dynamic deps loading, do you remember me rambling about "side loading"?

cgrand09:07:58

A 3rd connection (ideally) where control is inverted: the repl asks for resources to the client.

richiardiandrea09:07:25

Yes I remember that, one very nice property of the current implementation is that there are no dependency. For dependencies, a repl could ask for a data structure defining coordinates, but then it would need to resolve them. Or it can ask for already resolved jar paths (and actually Cognitect is coming up with a little command line too for doing dep resolution and classpath dump)

dominicm10:07:40

@cgrand I do yep, I had the sudden "Oh, derp, that makes total sense" last night whilst thinking about it 🙂

cgrand13:07:56

@richiardiandrea my solution would do dep resolution on the client and would not assume a shared file system.

cgrand13:07:35

Both cases seem difficult too do right. Whitelist too little and you get a poor copy of JMX. Too much and you have exploits. Read-only is difficult to harden too.

richiardiandrea14:07:14

One thing that @dominicm came up with would be to enable unrepl to start connections to other "helper" servers (or repls?). One process, Chrome for instance, then could be dedicated to render data structures nicely, accepting unrepl messages and partially understanding the protocol in order to do stuff

richiardiandrea14:07:24

Don't know yet how I feel about this though 😁

richiardiandrea14:07:25

It is funny because as soon as I say that Paul Grander started talking about linkerd

dominicm14:07:32

We really want nice tooling, live dynamic environment & such despite the compliance regime we're under. So that's where this line of thought is coming from. Even better is the "bring your own tooling" situation.

richiardiandrea14:07:28

If unrepl supported the concept of peers so that you can offload tasks on the socket we would not need to pass too many things in the blob

richiardiandrea14:07:36

But you open a connection to your peer and it does the job (render a map, refactor a file maybe)

dominicm14:07:25

Extensions to unrepl could provide different "render-X" forms which would be evaluated with the form to send data via ws to chrome, or via the connection to emacs as svg, etc

cgrand16:07:47

@richiardiandrea could you elaborate on what you mean by peer?

cgrand19:07:38

@richiardiandrea so far I always thought of a star topology with the client as the hub and the server as one spike.