This fixes temporary file information disclosure vulnerability due to the use
of the vulnerable `File.createTempFile()` method. The vulnerability is fixed by
using the `Files.createTempFile()` method which sets the correct posix permissions.
Weakness: CWE-377: Insecure Temporary File
Severity: Medium
CVSSS: 5.5
Detection: CodeQL & OpenRewrite (https://public.moderne.io/recipes/org.openrewrite.java.security.SecureTempFileCreation)
Reported-by: Jonathan Leitschuh <Jonathan.Leitschuh@gmail.com>
Signed-off-by: Jonathan Leitschuh <Jonathan.Leitschuh@gmail.com>
Bug-tracker: https://github.com/JLLeitschuh/security-research/issues/18
Co-authored-by: Moderne <team@moderne.io>
* JCLOUDS-1617: Fix HTTPS support in OkHttpCommandExecutorService
Added support for proxy server type = HTTPS
* Update DelegatingSocketFactory.java
Added java doc
This has an incompatibility with JAXB motivating this removal.
jclouds GAE has not seen any development or issues in recent years and
uses a very old appengine-api-1.0-sdk dependency. Further it appears
to have modern Guava incompatibilities as seen in JCLOUDS-836.
All OkHttp components get shipped with any OSGi metadata. Tracking the progress of that issue from version 5 onwards, OkHttp finally provides OSGi support. Because JClouds OkHttp dependencies got renewed from 2.2.0 to the latest 3 (3.14.9), the respective bundles from Apache Servicemix got used in a deployment scenario. On the other hand, the problem with Servicemix is that there is no full match of published OkHttp dependencies to the respective bundle equivalent.
https://mvnrepository.com/artifact/org.apache.servicemix.bundles/org.apache.servicemix.bundles.okhttp
My test shows that none of the version 3 bundles work because of a missing package dependency "javax.annotation.meta". Sure higher version of 9 strips the javax.annotation module entirely, but the meta package is not there in JDK 8 either. As you can see from the link above, only two versions of 3.14 got published in the service mix; it is not clear to which version the bundle equivalents relate. From my understanding, it is much more important to use identical versions of OkHttp dependencies used in JClouds.
To utilize the original OKHttp libraries, consumer projects have to ensure those libraries get loaded using OSGi helper tools such as the wrap protocol provided by Apache Karaf or similar.
To reduce OSGi noise, I removed the OSGi import range of okio dependency entirely. A declaration like that does not make sense; otherwise, a set of Okhttp ranges must also be defined.
Note: The wildcard (*) declaration provides a way out, which allows any version of a package used in JClouds but itself does not give any OSGi metadata. Hopefully, I do not confuse you too much.
JClouds is apparently exclusively using the Payload object from the HTTP
response to fill in the size of the BlobMetadata (when calling
blobStore.blobMetadata(...) ) - adapt this driver accordingly otherwise
we systematically get null size BlobMetadata out of it.
Because the Java type BasicHttpParams wasn't matching the one returned
by provider "newBasicHttpParams" (which is returning a HttpParams type), it was configuring the Apache HTTP client with default settings (including connection and socket timeout), ignoring the ones of JClouds which were must safer in this regard (JCloudsones are currently 60sec for both, while Apache HC ones are -1, so infinite). It also prevented to override those default/infinite timeout settings with JClouds ones.
Jclouds sends default user agent string with each request to cloud
services. But some of the application would like to overide this and
send custom user agent instead.
This commit define a string property to overide this default user agent
string. This property will be applied to all outgoing http request to
cloud services
JCLOUDS-819
OSGi bundle for jclouds-okhttp should import okio package with correct
version range.
Currently, there is no version range specified, causing it to be wired
to a higher version than intended in complex environments that have more
than one bundle for okio installed.
Readers can confuse this with 1. Found via error-prone. Fixed via:
find -name \*.java | xargs sed -i 's/\( [0-9][0-9]*\)l/\1L/g'
find -name \*.java | xargs sed -i 's/\(([0-9][0-9]*\)l/\1L/g'
