This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (38)
- # announcements (42)
- # aws (3)
- # babashka (8)
- # beginners (165)
- # calva (36)
- # chlorine-clover (14)
- # cider (6)
- # clj-kondo (5)
- # cljsrn (33)
- # clojure (27)
- # clojure-australia (1)
- # clojure-czech (1)
- # clojure-doc (1)
- # clojure-europe (26)
- # clojure-nl (6)
- # clojure-spec (6)
- # clojure-uk (3)
- # clojurescript (10)
- # code-reviews (20)
- # conjure (1)
- # core-logic (5)
- # cursive (3)
- # data-science (5)
- # datomic (35)
- # emacs (1)
- # figwheel-main (3)
- # fulcro (10)
- # honeysql (1)
- # introduce-yourself (4)
- # jobs (3)
- # jobs-discuss (4)
- # minecraft (2)
- # missionary (28)
- # nextjournal (3)
- # off-topic (45)
- # pathom (7)
- # polylith (1)
- # portal (22)
- # practicalli (2)
- # re-frame (4)
- # reagent (19)
- # releases (3)
- # remote-jobs (3)
- # reveal (1)
- # rum (4)
- # shadow-cljs (37)
- # spacemacs (14)
- # sql (1)
- # tools-build (7)
- # tools-deps (16)
- # vim (13)
- # xtdb (15)
Thanks to the prompting of @viebel https://clojure-doc.github.io/ now has Klipse integration and the "Introduction to Clojure" and "Laziness in Clojure" pages now have interactive examples that you can experiment with, in the browser! Contributors are very welcome, please! Follow-up in #clojure-doc
it’s really well done 👏. Sublime 4 is so refreshingly fast that I’m almost reconsidering my current relationship.
Sublime has been my go-to text editor of choice since at least 1.0, simply because of its speed. It starts faster than the built-in Notes app on my mac.
I use vim now, but if I was teaching code (clojure) to someone, I now think I would throw sublime back in the miix
Looks super sweet! I love that he makes the case for #nrepl. It is such a wonderful piece of software!
so many great options now. it's very different to when I started with slime and swank in '12. what a great community 🙂
👍:skin-tone-2: For ! FWIW, I responded to some of the points regarding Tutkain over at Reddit (https://www.reddit.com/r/Clojure/comments/rflhxf/comment/hoi250s/).
@https://app.slack.com/team/U4ZDX466T thank you for writing this up! What are to-go REPL choices for CLJS today? I’m afraid I’ve been out of touch for too long and they change it again?
All that said, I know plenty of folks use nREPL-based ClojureScript REPLs successfully every day, so maybe this is just me being somewhat particular about the whole thing. I guess to me it all just feels way too complicated. 🙂
From a UX point of view, I don't really care about connecting to a CLJS REPL directly either. I want to "connect to my project", and somehow have that magically mean that I'm connected both to CLJ and CLJS as necessary, and have things eval in the correct place depending on which file I'm in. This is not trivial, of course, and
.cljc makes that ambiguous as well. If I remember correctly, both Proto-REPL and Chlorine handle this pretty well.
Our current setup is to start the Shadow server with Integrant, which exposes a socket REPL and an NREPL (so that either can be used, based on editor/preference), then use
shadow/repl <build-target> to get to CLJS. Using Shadow gives us access to build control via the REPL, as well as provide a nice dashboard and tap target on port
> From a UX point of view, I don't really care about connecting to a CLJS REPL directly either. I want to "connect to my project", and somehow have that magically mean that I'm connected both to CLJ and CLJS as necessary I do care about connecting to a CLJS REPL. There are ClojureScript-only projects, too. And I definitely want no magic. 🙂 I'm with you on the editor having to know whether to evaluate Clojure or ClojureScript, though (which Tutkain does as well: https://tutkain.flowthing.me/dialect.mov).
If it's a CLJS-only project, then it's obvious that you want to connect to CLJS. I think the point stands. It's not magic (poor word choice), it's just about how closely you can model the intention of the person using the tool.
You know, "magic", in the sense that things that are frictionless in places where friction usually is encountered can feel like magic. (Until you get acclimated, and then the previous friction spurs anger when it's encountered again. Clojure itself is an example of this with regards to certain aspects)
Right, I think I understand. Something like that might make sense if it could be neatly composed of existing functionality. But to me, connecting to a Clojure(Script) runtime with Tutkain (or something like Chlorine, I think, although I've only tried it briefly) already has so little friction that I don't see it as a huge priority. Anyway, although I feel like saying more, I'm slightly worried we'd be veering a bit too far off topic. 🙂
logback has a new release (1.2.8) that addresses a harder to exploit, yet critical, vulnerability. they're urging users of logback to upgrade asap http://mailman.qos.ch/pipermail/announce/2021/000164.html
Thanks, although judging by the post the issue is a bit overblown. When attacker has write access to the code (this is where config files are), the system is already compromised enough for this vulnerability to matter IMO
something like this allows an attacker to easily establish a remote shell while not disrupting the running services otherwise. it's not overblown, it's just not as trivial to attack as the log4j vulnerability. a lot of hacking is moving horizontally, combining multiple stages of vulnerabilities to establish persistent access. the fewest changes an attacker can make to establish a permanent foothold, the better (for them).
and writable configuration files don't necessarily mean writable application files, especially if the vulnerability you're using to rewrite files can only rewrite plaintext
I tend to concur with Vlad here, the authors in their post of the vunerability have not deemed it as a critical vunerability. It takes an existing compromised system to exploit this one, and whilst there is merit in getting in via the "back door", if you have that level of access to a system running with logback and a writeable file, then you have bigger worries than the one here. Naturally, practicing caution is good and ensuring you update to the latest library is a given, but it doesn't have the same criticality as the log4j exploit.
I never said it has the same criticality of the log4j exploit, I even said it was harder to exploit
they're urging everyone to update as soon as possible and have ripped out functionality wholesale because it's so dangerous. I guarantee you people taking the OSCP in years to come will be checking for this vulnerability as a relatively easy way to get a reverse shell. it's a big deal. so 1) they want everyone to update as soon as possible, and 2) it's a really big deal. I call it critical and I'm out of line? come on
The news item on the logback home page
, even says that this exploit and the log4j exploit are "....uttterly different severity levels".
it still gives you a remote shell and was deemed dangerous enough to rip out wholesale, by the software authors you're pointing to for judgement on how critical the bug is
Right, totally agree, but in terms of announcing to the community that this is a "critical" update, when no such mention of the word is used, and that it requires chaining of exploits, is I feel unduely panicy.
I agree there, like any good author of software that has a security vunderability, that is totally due diligience.
like even by the authority you're pointing to it's something to handle as soon as you can
But they would say the same if it even had a minor vunerability, or major, or omg, the world is about to explode if you even run this software.
look: this argument is really boring and I'm grouchy. if you want to make another post with whatever language you want to use then go right ahead
A tiny library hack to load bhauman/devcards with only the essential npm packages required, v0.1.0 https://github.com/ikappaki/devcards-loader
nice! in case you didn't know, you could add highlight and marked to a deps.cljs file so they get installed automatically