This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-12-06
Channels
- # adventofcode (71)
- # aleph (1)
- # announcements (6)
- # aws (1)
- # babashka (27)
- # beginners (60)
- # biff (7)
- # calva (3)
- # clj-kondo (3)
- # clj-yaml (1)
- # clojure (60)
- # clojure-europe (43)
- # clojure-nl (3)
- # clojure-norway (75)
- # clojurescript (16)
- # code-reviews (7)
- # css (4)
- # cursive (47)
- # datascript (4)
- # events (5)
- # fulcro (37)
- # gratitude (5)
- # hyperfiddle (4)
- # introduce-yourself (4)
- # joyride (23)
- # juxt (4)
- # malli (4)
- # membrane (64)
- # nbb (8)
- # off-topic (12)
- # other-languages (6)
- # pathom (6)
- # polylith (9)
- # random (3)
- # rdf (66)
- # reitit (3)
- # releases (2)
- # shadow-cljs (18)
- # tree-sitter (10)
Current https://bitbucket.org/snakeyaml/snakeyaml/issues/561/cve-2022-1471-vulnerability-in#comment-64573493 on CVE from Andrey, the SnakeYAML maintainer: > Won’t fix means that there is no problem. > Please read the issue - it is still under analysis/investigation. > It only affects those who take untrusted data from unknown source - no one has presented a valid use case so far. > Those who trust false positives may try to use the proposed solution - use SafeConstructor The clj-yaml lib uses the SafeConstructor by default and I added this https://github.com/clj-commons/clj-yaml/blob/master/doc/01-user-guide.adoc#unsafe a while back. From the clj-yaml side, I think we are good. As of this writing, as Andrey mentioned, https://nvd.nist.gov/vuln/detail/CVE-2022-1471. I'll keep an eye on this and see how it plays out.