4 ms·
They are as deterministic and repeatable as any lock file from any tool that has lock files (npm, poetry, pipenv, cargo, ...). They just don't offer a way to ge
by remram 5y ago
They are as deterministic and repeatable as any lock file from any tool that has lock files (npm, poetry, pipenv, cargo, ...). They just don't offer a way to generate that manifest (which is a lock file) correctly automatically, instead you have to do that dependency resolution yourself.
Is that reasonable? I certainly don't think so. This sheds light on why log4j is such a large-scale issue.
- shagie 5y agoBy "reasonable" I mean "can be reasoned about" - not "is it the best way". http://the-whiteboard.github.io/coding/debugging/2016/04/07/reasonable-code.html http://the-whiteboard.github.io/coding/debugging/2016/04/07/... While that speaks of code - the key in there is the ability to look at it and figure out how it works and how to change it. With Log4j, we had to select one of those approaches, rebuild, and redeploy. In the Java community, repeatable builds are valued - the "I build the jar today" should have the same result tomorrow as the default. It is possible to change the way maven specifies its versions to do ranges, just most people don't do that. I don't want my oracle ojdbc jar to suddenly jump to a different version that doesn't work with the backend I'm running. --- https://www.sonatype.com/resources/log4j-vulnerability-resource-center https://www.sonatype.com/resources/log4j-vulnerability-resou... If you look at the "downloads per hour" you'll see that about half the people using it downloaded it and continued to update their code as new releases came out. It is concerning that 41% of the builds out there are still specifying a vulnerable version.