Fork me on GitHub

@seancorfield what's the security issue?


@dominicm The PR I accepted for 0.2.1 allows for depstar to tree walk through the file system and overwrite files outside the temporary directory.


I didn't realize until it failed to build an uberjar on our CI system -- which had always worked before, strangely -- but failed once it tried to create the parent directory (new in 0.2.1).


(so I'm not entirely certain the bug was introduced in 0.2.1 but that was the build that first caused "random" directories to be created if you tree-walked, which wasn't good)

Alex Miller (Clojure team)04:07:45

and yet you want Clojure to create classes directories... ;)


The security issue isn't technically the auto-creation of the directory...


...I suspect the bug's been there for quite a few releases prior but the behavior was masked until the mkdirs on the parent folder was added.


(and the behavior was somewhat benign before 0.2.1)


I'm using reply (the one that comes with lein) and it initiates a nrepl server . Problem was the it starts nrepl in a way that it does not write .nrepl-port file that my beloved Fireplace (vim) needs to connect to nrepl. In case you have the same problem I'm asking reply at init to do this by using the snippet attached


@seancorfield I'm using your dotclojure file. the reply section was made by you. I've checked today and you do not have reply anymore. What repl client are you using ?


I don't remember ever having reply in there @geraldodev but it does have both the old and new nREPL aliases. I use a Socket REPL and Chlorine for Atom for editing or unravel/unrepl from the command line.


@seancorfield you are right I've probably associated with you because I've forked


@geraldodev do you use the reply in the terminal? If not I would recommend using nrepl.cmdline, which does write the .nrepl-port file (and deletes it afterwards).


@dominicm I use reply on terminal. Since I've looked up reply on sean's dot-clojure I've seen this nrepl.cmline there and I've invoked to see if it would be less complicated than the eval parameter that I'm passing to reply. But no, it writes .nrepl-port but I would have to invoke reply (the client) as another proccess which I was doing before. Invoking reply directly it 1) starts nrepl 2) writes .nrepl-port and Fireplace can consume this. I get one less java process. I dealt with this problem because I'm working with 2 repls . One for server and another (swing) for client. That would be 4 process and one more tmux screen.


I'm a fellow fireplace user, I understand, mostly! I don't find myself reaching for the terminal repl at all.