311–320 of 335 posts
Earlier quoted context omitted.
Would less funding have uncovered it?
Would less funding have prevented the feature being implemented? Maybe?
Earlier quoted context omitted.
Not sure what you are answering. If you for instance expose an endpoint by accident and then can't show logs for the access to it, you are going to have a problem in one of those GDPR hearings. The irony of GDPR is that you may end up with more logging of user data, not less.
Explain 'one of those GDPR hearings'. I'm pretty familiar with the GDPR and everything that comes with it, I've never even heard of the term 'GDPR hearing'.
Earlier quoted context omitted.
You act as if “restarting” the logging system is easy and doesn’t require the same facade that you decry for a reconfigurable one. With dependency injection, there are loggers everywhere in the system, possibly in sections of the code you didn’t even rewrite. Restarting such a system while continuing to run everything else is just as complex as reconfiguring, possibly more complex. Also, I noticed you didn’t answer m…
> about whether you’re a Java developer I was once, but haven't used it professionally for a while. It's on my "I'd rather not" list, but not strongly so. Oh, and now that you described it with so many details, the attachment to complexity does look more like addiction than love.
This is why I ask. Java has changed a lot since ~1.8, and it is super common to see ex or non java developers making grandiose and sweeping statements about a community and language that they are no longer part of. Having developed in Java on and off since ~1.7 and Spring 3, I can certainly say that I have seen a strong movement towards less complexity and more convention. It's not perfect by any stretch, but I think saying that the space is "in love with complexity" is incorrect.
You of course don't have to go and re-use Java on my suggestion. We all have our preferences, and that's ok! But I would generally recommend against such sweeping and dismissive general statements about a culture that you are no longer part of. Things change, and your experience back then is probably not representative of things today.
> Oh, and now that you described it with so many details, the attachment to complexity does look more like addiction than love.
There's a fine line between disagreement and insult, and you are over it.
Earlier quoted context omitted.
It's worse than that. When Java finally added a logging library, they added one that no-one had ever heard of before, and which had fundamental flaws. That's why no-one uses it. At the time, log4j existed and was in wide use, but was not represented on the committee. The author of log4j eventually decided to go a different way and created slf4j / logback. This offering is compatible with log4j and considerably simple…
> Having not been in the Java world for many years, I was surprised log4j was still in widespread use. It's Java; the ecosystem is, politely, rather conservative and slow moving.
Earlier quoted context omitted.
> wide range of output formats Not to mention a wide range of destinations, too. Want to log to a database table? You’re covered. What about log messages to a chat server (xmpp, slack) or email but only fatal errors? You’re covered. Now roll your own logging system that supports those destinations safely and get back to me to do pen testing. I bet we’ll find some vulns in your code.
This is the job of a log collector, not a log producer/library. The logging library itself should have no mechanism for shipping files anywhere except a file / stdout / stderr.
Most of us have log4j in our system because it's used by some various dependency of one type or another, and up until now it has generally just worked.
Earlier quoted context omitted.
You log and collect everything, then use your log aggregator to filter the appropriate content.
This turns gigabytes per hour of logs to hundreds of terabytes per hour during normal operation, in many cases it's an inferior solution for problems which pop up in a fraction of infrastructure several times a month.
Earlier quoted context omitted.
I think you could take this further. There's another "log4j" vulnerability out there right now, I guarantee it. It might be exploited, it might not be. But there's no patch. What are you doing about it? With log4j you have a brutal combination of: 1. RCE 2. Exposure RCE happens frequently but often attackers don't have an easy time getting to the exploitable code. With log4j it's trivial - every app can be owned. But…
it's definitely time for a language with a capabilities based security model that allows scope to the function/method level, at minimum not just for security either. i can't count the number of times i've traced a performance problem or bug to a piece of code that was doing some io when it didn't need to
Earlier quoted context omitted.
Explain 'one of those GDPR hearings'. I'm pretty familiar with the GDPR and everything that comes with it, I've never even heard of the term 'GDPR hearing'.
Maybe it is not handled the same way depending on where you operate from but where I live you are supposed to report any potential data leak of GDPR sensitive data to the local authorities. I do not know what the criteria is that makes you end up being questioned about it though. I been at such meetings over silly things.
Once you get to that stage there can be a follow up to gather more information, and that follow up then usually results in some advice or no further action. In rare cases - typically the ones where gross negligence or willful transgression of the rules was established - there will be a fine and if it is a repeat occurrence that fine can be quite substantial.
Also you don't have to report 'potential leaks', only actual leaks.
So I think that in the case of your hypothetical end-point the logging isn't a GDPR requirement, but if your endpoint ends up leaking data then the log can help you to establish if and if so how much data was exfiltrated. But that does not mean that the GDPR requires you to have logs, though, having access logs for your endpoints is a fairly standard thing and not having them is going to raise a few eyebrows, especially if you are also reporting a breach.
Where there are logging requirements: data retention laws, SOX, fintech, tax regulation, AML.
Earlier quoted context omitted.
This turns gigabytes per hour of logs to hundreds of terabytes per hour during normal operation, in many cases it's an inferior solution for problems which pop up in a fraction of infrastructure several times a month.
Ok? One you need to disable debug logging and two I still don’t see a problem with that amount of data. You also don’t need to keep logs more than a month or so. How much log data do you think cloudwatch and the other majors filter per hour? much more than terabytes.
> How much log data do you think cloudwatch and the other majors filter per hour?
How much do you think the major providers pay for that infrastructure per hour, and are you willing to shoulder that cost too?
(Hint: log ingestion is $0.50 per gigabyte in cloudwatch. So a terabyte of logs an hour is $512/hr)