> On Jul 29, 2020, at 3:28 PM, Gary Gregory <garydgreg...@gmail.com> wrote:
>
> On Wed, Jul 29, 2020 at 4:33 PM Matt Sicker <boa...@gmail.com> wrote:
>
>> ICLAs aren't required for trivial contributions, though they are
>> required for committers. Are bots committers? Alternatively, if we
>> only merge PRs from the bot using the Merge button rather than the
>> @dependabot comment commands, then that ensures a committer is the one
>> who introduces the merge commit itself into the git repo.
>>
>
> IMO, a committer needs to validate the PR and push the merge button.
>
>
>>
>> As for dependencies, I've been facing an opposite constraint: the
>> endless security scanners complaining about every possible CVE or
>> proprietary vulnerability published about OSS libraries that have
>> patches available. As more and more companies embrace security, one of
>> the low-hanging fruits of software development is keeping dependencies
>> up to date [1]. As for ensuring things still work in older versions of
>> a library, perhaps we should have some way to run tests with old
>> versions of the library periodically to ensure we aren't breaking
>> compatibility unnecessarily.
>>
>
> At work, we have tooling that checks for CVEs on all third party libraries
> we deliver. A CVE on an old library will cause us to update it.
Yes, and that is the key. The version is controlled by your application. You
don’t rely on the version provided by Log4j. It really shouldn’t matter what
Log4j has for transitive dependencies. A good application should be declaring
the version of every dependency that will end up as part of the app.
But you guys are correct in that a Log4j release should be compatible with the
latest release of any components it is using. But somehow users need to be
informed that they can upgrade Log4j without having to be required to update
their other dependencies if they are compatible.
Ralph
