Closed timotheosh closed 9 months ago
Hi @timotheosh,
My two-part answer:
First, most immediately, we are awaiting a new release of the cognitect http client library which will depend on Jetty 9.4.53 (the latest 9.4.x as of this writing, and which fixes the vulnerability you mention). Once it is available, and I'm told it will be soon, we will release a new version of aws-api with it. I expect this to happen within a matter of not very many weeks, at worst.
Second, longer term, we have been working on a different http client implementation, one which depends only on the JDK's java.net.http
module starting with JDK 11.
Solving the Jetty 9.x transitive dependency problem is our top priority.
Hello again @timotheosh,
I'm going to close this as fixed with the release of 0.8.692 which pulls in Jetty 9.4.53, the latest Jetty 9.x.
Current version of the aws-api have started throwing Snyk alerts on us because of the outdated jetty dependency of Cognitect's http-client
I realize this is an http server issue and not a client issue, so does not affect the aws-api directly, but we are having to put in Snyk exceptions for every project we use this library for with a maximum expiration of 90 days (imposed by our Security team).
Jetty 9.4.x only supports Java 8, while latter supported versions support Java 11+. While this, as far as we can tell, does not directly impact our use of aws-api, I think this is an important enough issue to start tracking. Since Cognitect's http-client is not open source (as far as we can tell) we can't offer any PR's for it.
We also noticed that it looks like aws-api already has the makings of its own http-client (src/cognitect/aws/http.clj). Is there any reason why aws-api should need to use the older Cognitect library over its own?
This issue is related to #245 that an associate of mine submitted a month ago.