Our great sponsors
-
> Then apache decides to put new people on log4j, do a backward incompatible v2 design that nevertheless is worse than slf4j. Why?
slf4j itself isn't a logging framework. It's a facade to logging frameworks.
Simple Logging Facade for Java ( https://www.slf4j.org )
It needs a logging framework behind it - log4j, log4j2, logback, commons, JUL.
The question is "why do log4j2?"
Logback went from the log4j1.x path ( https://logback.qos.ch )
Log4j2 has a lot of features that weren't present when the project started ( https://en.wikipedia.org/wiki/Log4j#Apache_Log4j_2 ).
There is a licensing difference between Logback (LGPL) and Log4jx (Apache Commons).
-
> Then apache decides to put new people on log4j, do a backward incompatible v2 design that nevertheless is worse than slf4j. Why?
slf4j itself isn't a logging framework. It's a facade to logging frameworks.
Simple Logging Facade for Java ( https://www.slf4j.org )
It needs a logging framework behind it - log4j, log4j2, logback, commons, JUL.
The question is "why do log4j2?"
Logback went from the log4j1.x path ( https://logback.qos.ch )
Log4j2 has a lot of features that weren't present when the project started ( https://en.wikipedia.org/wiki/Log4j#Apache_Log4j_2 ).
There is a licensing difference between Logback (LGPL) and Log4jx (Apache Commons).
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
log4shell-tools
Tool that runs a test to check whether one of your applications is affected by the recent vulnerabilities in log4j: CVE-2021-44228 and CVE-2021-45046
I'm seeing this as well. While the amount of traffic has certainly decreased compared to the first couple of days after the CVE was announced, https://log4shell.tools is still being used by people every day.
-
keychain-swift
Helper functions for saving text in Keychain securely for iOS, OS X, tvOS and watchOS.
The only one of those that I didn't write, was KeychainSwift[0]. It makes dealing with the Keychain easy, and is a very simple dependency. If it went off the rails, I'd write something like it, myself.
All the others, are in my own repos, as top-shelf-quality open-source modules.
-
public-pentesting-reports
A list of public penetration test reports published by several consulting firms and academic security groups.
I'd say don't let yourself be discouraged by GP. Just look into a company before you apply. Many have public reports you could look at or security research they publish, both of which you could use as indicators.
Here's a repo with lots of public audit reports by various companies, you could use that as a starting point: https://github.com/juliocesarfort/public-pentesting-reports
-
java.util.logging was braindead because it wanted to know the class and method doing the logging. If not provided, it threw an exception and filtered the stack trace to detect its own caller. Throwing an exception was a very slow operation.
I see they did some optimizations to do this work lazily if needed. But when log4j 1 was on its peak, that wasn't done, and using the built in logger was slow enough to have measurable impact .
See https://github.com/openjdk/jdk/blob/6765f902505fbdd02f25b599... at the bottom.
-
lunasec
LunaSec - Dependency Security Scanner that automatically notifies you about vulnerabilities like Log4Shell or node-ipc in your Pull Requests and Builds. Protect yourself in 30 seconds with the LunaTrace GitHub App: https://github.com/marketplace/lunatrace-by-lunasec/
This is compliance vs security. Finding vulns checks a box for SOC2, but in reality detection is the easy part. Figuring out what to fix, based on real-world usage and risk, requires much more work and is often ignored.
I'm sorry you're on the receiving end of this problem!
Shill notice: I'm working on an Open Source tool[0] that makes this problem less horrible. My colleague wrote a post about our hypothesis[1] about how we can avoid this false positive trap.
I'd love to chat with anybody feeling this pain (even just as therapy lol).
0: https://github.com/lunasec-io/lunasec
1: https://www.lunasec.io/docs/blog/the-issue-with-vuln-scanner...
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
> I don't think I could in good conscience recommend your approach as a general practice.
I can live with that, but ... (There's always a "but")
I am not happy at all, with the general industry practice of writing every project to be something that can be understood by inexperienced, undisciplined coders.
Every language and programming methodology has an "advanced" type of thing, requiring people to have experience and/or book-larnin'.
I write Swift at a fairly advanced level. I am not at the level of some heavy-duty advanced Swift people, but I am pretty "idiomatic," in my approach. It is not "rewritten TypeScript," like so much code out there.
My code is very well-documented, and I hold myself to standards of Quality that most folks in the industry consider to be obsessive to the point of insanity. My testing code usually dwarfs my implementation code, and my documentation is, let's say ... complete. You can see what I mean in my latest module[0].
I won't write junk, so that someone used to junk, can comprehend it. If people aren't willing to learn enough to understand my middle-of-the-road semi-advanced Swift, then I can't help them. Swift is an awesome language. I feel that we are doing ourselves a disservice, if we do not explore it.
I write for myself. I write code and documentation that I want to use (and I use it). I really don't care, whether or not someone else "approves" of it. I am not relying on others to review, maintain, or patch my code.
When I do use other people's code, I vet it fairly carefully. Including a dependency is a really serious matter. I'm handing full control of my execution context to code that someone else wrote. I'd damn well better take that Responsibility seriously.
Related posts
- Log4j 2.15.0 – Previously suggested mitigations may not be enough
- Analysis of the 2nd Log4j CVE published earlier (CVE-2021-45046 / Log4Shell2)
- Preventing SQL injection attacks in Node.js
- Smooth Packaging: Flowing from Source to PyPi with GitLab Pipelines
- Launch HN: Slauth (YC S22) – auto-generate secure IAM policies for AWS and GCP