Fork me on GitHub
#clojure-europe
<
2021-02-04
>
dharrigan07:02:02

Good Morning!

jkxyz07:02:00

Good morning!

thomas08:02:12

and the ice does look ideal for ice skating @pez

plexus08:02:41

me: why is emacs getting so slow? htop:

plexus08:02:00

23GB... something, somewhere, has gone horribly wrong

ordnungswidrig08:02:22

I have this too, once in a while

ordnungswidrig08:02:40

Restarting helps, I never had the motivation to debug this

hkjels09:02:14

You can use profile start/end and report to see what’s going on

borkdude09:02:46

maybe a sub-process getting out of control? (this is one reason I usually don't use jack-in)

ordnungswidrig10:02:05

@U04V15CAJ that’s probabily the main cause when it happened to me. E.g. having a repl producing 1M of output can easily freez your emacs.

hkjels12:02:39

Cider has an option of clearing it’s buffers past a certain threshold. Would likely mitigate this

👍 3
ordnungswidrig08:02:52

@pez when the time allows it I need to go to Skandinavia just of ice lake skating

pez09:02:37

It is pretty rare with that kind of ice, though. I live by a lake since 21 years and have seen it happen three times. And in the archipelago it has to be even less common. But I’ll holler your way if I think it is about to happen. 😃

slipset10:02:39

So, hypothetically speaking. Let’s imagine a company uses friend , which is somewhat retired. Then it comes to the company’s attention that there is a CVE on friend, because a lib that friend depends on has a vulnerability. There is a newer version of the vulnerable lib available, which works. Now, do you 1. exclude said library in your project.clj and add an explicit dep on the newer version of said libary 2. beg cemerick to issue a new version of friend with a version bump on the dep 3. finally get clj-commons to take on friend and have them version bump the dep 4. rewrite to buddy and hope for the best 5. say f*ck it, the vulnerability is not likely to hit us.

borkdude10:02:02

friends don't let friends use friend

borkdude10:02:56

(half kidding, as I don't know friend very well, it seemed too complex for me to ever get started with, but I would not invest that much energy in a lib that was abandoned for too long)

ordnungswidrig10:02:02

#1 and #2 are basically the same. Somebody would need to to a propery assesmenton the impact and verify the bug is actually fixed with the version bumb.

jkxyz10:02:28

You could also re-write just the credential fn to use an updated BCrypt lib. That fn is quite simple

ordnungswidrig10:02:30

Not familiar with that case but from what I read in the CVE the dependency bump should be stract forward.

3
ordnungswidrig10:02:34

@josh604 that’s actually not a bad idea. But when it comes to crypto or security, you better used some canned libraries. Also because due dilligence in corporate environments.

ordnungswidrig10:02:46

Saying that “#4” might be the best option in the long run.

slipset10:02:57

The reason this came up, is that we ran lein-nvd on our backend, and it showed, well more than three cve’s, so there is some work ahead.

jkxyz10:02:49

Well, Friend is just calling a fn in some Java lib to verify the password and hash, and returning a map or nil https://github.com/cemerick/friend/blob/master/src/cemerick/friend/credentials.clj#L20

jkxyz10:02:26

IIRC Buddy is more pluggable in that it has a separate hashing library which plugs into the auth stuff

slipset10:02:28

(btw I used a patched version with this PR https://github.com/rm-hull/lein-nvd/pull/43, the patch is quite neat as it gives you not only the vulnerabilities, but the libs that includes them)

ordnungswidrig10:02:53

@josh604 nice. Pluggability for the win!

borkdude11:02:14

You can also use all of these hashing functions from babashka via https://github.com/babashka/pod-babashka-buddy

jkxyz11:02:58

Nice “plug” 😉

🔌 9