Clojurians Log v2

It seems like I managed to kick it hard enough to make it run

Thanks, I see the fruits of your kick! But... I just pushed an empty commit on my PR. That should have kicked off a CircleCI job (I think), but I don't see one.

I turned on building from forked repos? Kind’a hoping your PR was from a forked repo?

Yep

I could close and resubmit the PR if you think that's worth trying.

Try one more commit

Building

tada!

Thanks!

Thank you!

If it all looks good to you, we should probably cut a new release of this old lib!

Merged

Releasing

Thanks!

Again, thank you 🙂

My pleasure!

Dang! It’s a much downloaded lib

Yep, folks still use it, but also nice to see that folks seem to have migrated to babashka/fs!

Really appreciate you being on the CVE’s though. We use nvd-whatever at work, and some projects take forever to even reply to PRs with upgraded libs.

Just stumbled on this one. Cljdoc still uses this lib, and I did an NVD scan on cljdoc, and it burped out the CVEs.

> We use nvd-whatever at work, and some projects take forever to even reply to PRs with upgraded libs. I don't know about you, but in my experience with Aleph, CVEs are kind of a mixed bag. Though not as bad as it is for some https://daniel.haxx.se/blog/2023/08/26/cve-2020-19909-is-everything-that-is-wrong-with-cves/, apparently. The idea is theoretically sound, but there's low-quality CVEs, incorrect CVEs, and little way to fix the issues. It seems like it's been getting worse, too. The last one we had was a Netty issue that people started clamoring for that was an amplification DoS attack on some standard HTTP/2 behavior. Sounds like a good candidate for a fix...but I hadn't released the HTTP/2 version of Aleph at the time, so it wasn't vulnerable. If there was a way to tell MITRE that Aleph wasn't affected, I'd have done that, but that's not possible afaik. In that case, it wasn't much of a burden to upgrade, but I do have to check the complete Netty changelog every time to try and make sure nothing will break. It's not hard to imagine a scenario where the burden isn't worth it (younger libs, fewer maintainers, less time, worsening CVE quality, etc). All of which is why I no longer personally ring the alarm bell when a CVE comes in. Just my $.02.

We regularly add to our cve ignore file, after we analyzed the cve. We’re somewhat required to do this by contract.

In essence, every CVE reported against libs we use need to be mitigated in some way, either by upgrading a lib, removing it, or ignoring the CVE in an ignore file.

Is that commonplace? I haven't tried telling anyone to ignore a CVE officially yet.

We’re not telling anyone, since it’s all internal. But you could imagine closing a “CVE-WHATEVER” issue with “Not applicable”, and then let your clients act accordingly.

Hmmm 🤔 I'll have to try that the next time an applicable CVE comes in

Thx!

@kingmob clj-yaml is a light wrapper for SnakeYAML. There was a CVE raised against SnakeYAML that did not affect clj-yaml because clj-yaml did not expose the problematic usage. But yeah, like slipset, I have a look at reported CVEs, mark false positives in ignore configs, and bump deps.