4 ms·

Why is this so hard? It should be very easy to fix this. Set the correct version in the pom.xml. Commit and push to master and deploy. right? easy. It should

Why is this so hard? It should be very easy to fix this. Set the correct version in the pom.xml. Commit and push to master and deploy. right? easy. It should be a half an hour thing. But at my employer, we still have dozens of teams struggling. Two reasons: - Branching hell.- Many teams don't do continuous integration. They have branches over branches over branches. There are many changes that are not in prod. Continuous integration is about integrating several times a day. David Farley frequently talks about this. https://www.youtube.com/watch?v=Xl62gQpAl1w https://www.youtube.com/watch?v=Xl62gQpAl1w - Microservices hell. - The advantage of microservices is that teams can deploy independently of each other. But many companies ended up with way too many of them. We have a few hundred. I suspect, many of them abandon. Their teams already moved to new things and noone knows how to deploy them. They haven't been deployed in a long time.

da_chicken 5y ago
You're worried about patching the system that you're developing and releasing. Most people aren't doing that. Most people are patching systems they bought from some other guy. Indeed, they're scanning and patching dozens of systems they bought from a dozen other guys, each of whom sourced libraries from other guys, who sourced things from still other guys. Somewhere way down at the bottom of the vendor chain is Log4j. For example, we operate an information system we bought from a nationwide vendor. The primary application is not vulnerable. The admin interface is not vulnerable. The secondary application is not vulnerable. However, there's a reporting system from a third party that was provided to us. That is vulnerable. Now we have to wait for the third party to patch so that the vendor can patch so that we can patch. Plus there's all the other things you find that are clearly stupid, but aren't immediately important. Like this: C:\Program Files (x86)\Microsoft Visual Studio\2017\SQL\Common7\IDE\CommonExtensions\Microsoft\SSIS\150\Extensions\Common\Jars\log4j-1.2.17.jar
- avidphantasm 5y ago
  Plus, older systems may have multiple applications deployed to the same Servlet container (e.g., Tomcat server), even if only one app uses log4j, upgrading it may require updates to transitive shared dependencies that can break "non-affected" apps. Given the prevalence of such Java apps, fixing this is likely to take a long time. Mitigating with firewall rules is a good first step for now.
hu3 5y ago
> Many teams don't do continuous integration. They have branches over branches over branches. There are many changes that are not in prod. Continuous integration is about integrating several times a day. David Farley frequently talks about this. https://www.youtube.com/watch?v=Xl62gQpAl1w https://www.youtube.com/watch?v=Xl62gQpAl1w Preach. As a consultant, I have been trying to implement continuous integration in a team and it has been so hard to convince project owners that delivering frequently and continuously to production behind feature flags is a net gain over accumulating "features" in dozens of branches that get outdated, poorly documented and even forgotten. Some days the team crawls to snail pace trying to pick arbitrary branches to merge into integration branch. Then it takes days to be tested, adjusted, approved and merged into master. The process is so convoluted and cognitively loaded that it has been a major source of bugs. They need better tests and continuous integration to become nimble.
- corpMaverick 5y ago
  Yes. I have encounter similar behaviors in several places already.

da_chicken 5y ago

You're worried about patching the system that you're developing and releasing. Most people aren't doing that. Most people are patching systems they bought from some other guy. Indeed, they're scanning and patching dozens of systems they bought from a dozen other guys, each of whom sourced libraries from other guys, who sourced things from still other guys. Somewhere way down at the bottom of the vendor chain is Log4j. For example, we operate an information system we bought from a nationwide vendor. The primary application is not vulnerable. The admin interface is not vulnerable. The secondary application is not vulnerable. However, there's a reporting system from a third party that was provided to us. That is vulnerable. Now we have to wait for the third party to patch so that the vendor can patch so that we can patch. Plus there's all the other things you find that are clearly stupid, but aren't immediately important. Like this: C:\Program Files (x86)\Microsoft Visual Studio\2017\SQL\Common7\IDE\CommonExtensions\Microsoft\SSIS\150\Extensions\Common\Jars\log4j-1.2.17.jar

avidphantasm 5y ago
Plus, older systems may have multiple applications deployed to the same Servlet container (e.g., Tomcat server), even if only one app uses log4j, upgrading it may require updates to transitive shared dependencies that can break "non-affected" apps. Given the prevalence of such Java apps, fixing this is likely to take a long time. Mitigating with firewall rules is a good first step for now.

hu3 5y ago

> Many teams don't do continuous integration. They have branches over branches over branches. There are many changes that are not in prod. Continuous integration is about integrating several times a day. David Farley frequently talks about this. https://www.youtube.com/watch?v=Xl62gQpAl1w https://www.youtube.com/watch?v=Xl62gQpAl1w Preach. As a consultant, I have been trying to implement continuous integration in a team and it has been so hard to convince project owners that delivering frequently and continuously to production behind feature flags is a net gain over accumulating "features" in dozens of branches that get outdated, poorly documented and even forgotten. Some days the team crawls to snail pace trying to pick arbitrary branches to merge into integration branch. Then it takes days to be tested, adjusted, approved and merged into master. The process is so convoluted and cognitively loaded that it has been a major source of bugs. They need better tests and continuous integration to become nimble.

corpMaverick 5y ago
Yes. I have encounter similar behaviors in several places already.