cloud issueshttps://community.opengroup.org/groups/osdu/platform/system/lib/cloud/-/issues2021-12-16T10:08:33Zhttps://community.opengroup.org/osdu/platform/system/lib/cloud/ibm/os-core-lib-ibm/-/issues/2Log4J Expedient Updates and Patches2021-12-16T10:08:33ZDavid Diederichd.diederich@opengroup.orgLog4J Expedient Updates and PatchesThis issue associates MRs that were applied to this project quickly to get a patched version ready as soon as possible. The intent is to provide a reference point for later, more thoughtful, analysis.This issue associates MRs that were applied to this project quickly to get a patched version ready as soon as possible. The intent is to provide a reference point for later, more thoughtful, analysis.M9 - Release 0.12https://community.opengroup.org/osdu/platform/system/lib/cloud/gcp/os-test-core-lib-gcp/-/issues/2Log4J Expedient Updates and Patches2021-12-15T12:11:29ZDavid Diederichd.diederich@opengroup.orgLog4J Expedient Updates and PatchesThis issue associates MRs that were applied to this project quickly to get a patched version ready as soon as possible. The intent is to provide a reference point for later, more thoughtful, analysis.This issue associates MRs that were applied to this project quickly to get a patched version ready as soon as possible. The intent is to provide a reference point for later, more thoughtful, analysis.M9 - Release 0.12https://community.opengroup.org/osdu/platform/system/lib/cloud/gcp/os-core-lib-gcp/-/issues/2Log4J Expedient Updates and Patches2021-12-15T12:11:27ZDavid Diederichd.diederich@opengroup.orgLog4J Expedient Updates and PatchesThis issue associates MRs that were applied to this project quickly to get a patched version ready as soon as possible. The intent is to provide a reference point for later, more thoughtful, analysis.This issue associates MRs that were applied to this project quickly to get a patched version ready as soon as possible. The intent is to provide a reference point for later, more thoughtful, analysis.M9 - Release 0.12https://community.opengroup.org/osdu/platform/system/lib/cloud/azure/os-core-lib-azure/-/issues/14Log4J Expedient Updates and Patches2021-12-15T12:11:25ZDavid Diederichd.diederich@opengroup.orgLog4J Expedient Updates and PatchesThis issue associates MRs that were applied to this project quickly to get a patched version ready as soon as possible. The intent is to provide a reference point for later, more thoughtful, analysis.This issue associates MRs that were applied to this project quickly to get a patched version ready as soon as possible. The intent is to provide a reference point for later, more thoughtful, analysis.M9 - Release 0.12https://community.opengroup.org/osdu/platform/system/lib/cloud/aws/os-core-lib-aws/-/issues/3Log4J Expedient Updates and Patches2021-12-15T12:11:22ZDavid Diederichd.diederich@opengroup.orgLog4J Expedient Updates and PatchesThis issue associates MRs that were applied to this project quickly to get a patched version ready as soon as possible. The intent is to provide a reference point for later, more thoughtful, analysis.This issue associates MRs that were applied to this project quickly to get a patched version ready as soon as possible. The intent is to provide a reference point for later, more thoughtful, analysis.M9 - Release 0.12https://community.opengroup.org/osdu/platform/system/lib/cloud/gcp/oqm/-/issues/1Upgrade to Log4J 2.17.1 to address CVE-2021-448322022-08-23T21:24:23ZDavid Diederichd.diederich@opengroup.orgUpgrade to Log4J 2.17.1 to address CVE-2021-44832Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack when a configuration uses a JDBC Appender with a JNDI LDAP data source URI when an ...Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack when a configuration uses a JDBC Appender with a JNDI LDAP data source URI when an attacker has control of the target LDAP server.
This issue is fixed by limiting JNDI data source names to the java protocol in Log4j2 versions 2.17.1, 2.12.4, and 2.3.2.
_(Description from [nist.gov](https://nvd.nist.gov/vuln/detail/CVE-2021-44832) for CVE-2021-44832)_M10 - Release 0.13https://community.opengroup.org/osdu/platform/system/lib/cloud/gcp/obm/-/issues/1Upgrade to Log4J 2.17.1 to address CVE-2021-448322022-08-23T21:24:22ZDavid Diederichd.diederich@opengroup.orgUpgrade to Log4J 2.17.1 to address CVE-2021-44832Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack when a configuration uses a JDBC Appender with a JNDI LDAP data source URI when an ...Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack when a configuration uses a JDBC Appender with a JNDI LDAP data source URI when an attacker has control of the target LDAP server.
This issue is fixed by limiting JNDI data source names to the java protocol in Log4j2 versions 2.17.1, 2.12.4, and 2.3.2.
_(Description from [nist.gov](https://nvd.nist.gov/vuln/detail/CVE-2021-44832) for CVE-2021-44832)_M10 - Release 0.13https://community.opengroup.org/osdu/platform/system/lib/cloud/ibm/os-core-lib-ibm/-/issues/4Upgrade to Log4J 2.17.1 to address CVE-2021-448322022-01-18T19:13:03ZDavid Diederichd.diederich@opengroup.orgUpgrade to Log4J 2.17.1 to address CVE-2021-44832Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack when a configuration uses a JDBC Appender with a JNDI LDAP data source URI when an ...Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack when a configuration uses a JDBC Appender with a JNDI LDAP data source URI when an attacker has control of the target LDAP server.
This issue is fixed by limiting JNDI data source names to the java protocol in Log4j2 versions 2.17.1, 2.12.4, and 2.3.2.
_(Description from [nist.gov](https://nvd.nist.gov/vuln/detail/CVE-2021-44832) for CVE-2021-44832)_M10 - Release 0.13https://community.opengroup.org/osdu/platform/system/lib/cloud/gcp/os-core-lib-gcp/-/issues/4Upgrade to Log4J 2.17.1 to address CVE-2021-448322022-01-18T19:12:59ZDavid Diederichd.diederich@opengroup.orgUpgrade to Log4J 2.17.1 to address CVE-2021-44832Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack when a configuration uses a JDBC Appender with a JNDI LDAP data source URI when an ...Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack when a configuration uses a JDBC Appender with a JNDI LDAP data source URI when an attacker has control of the target LDAP server.
This issue is fixed by limiting JNDI data source names to the java protocol in Log4j2 versions 2.17.1, 2.12.4, and 2.3.2.
_(Description from [nist.gov](https://nvd.nist.gov/vuln/detail/CVE-2021-44832) for CVE-2021-44832)_M10 - Release 0.13https://community.opengroup.org/osdu/platform/system/lib/cloud/azure/os-core-lib-azure/-/issues/16Upgrade to Log4J 2.17.1 to address CVE-2021-448322022-01-18T19:23:41ZDavid Diederichd.diederich@opengroup.orgUpgrade to Log4J 2.17.1 to address CVE-2021-44832Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack when a configuration uses a JDBC Appender with a JNDI LDAP data source URI when an ...Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack when a configuration uses a JDBC Appender with a JNDI LDAP data source URI when an attacker has control of the target LDAP server.
This issue is fixed by limiting JNDI data source names to the java protocol in Log4j2 versions 2.17.1, 2.12.4, and 2.3.2.
_(Description from [nist.gov](https://nvd.nist.gov/vuln/detail/CVE-2021-44832) for CVE-2021-44832)_M10 - Release 0.13https://community.opengroup.org/osdu/platform/system/lib/cloud/aws/os-core-lib-aws/-/issues/5Upgrade to Log4J 2.17.1 to address CVE-2021-448322022-01-18T19:12:49ZDavid Diederichd.diederich@opengroup.orgUpgrade to Log4J 2.17.1 to address CVE-2021-44832Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack when a configuration uses a JDBC Appender with a JNDI LDAP data source URI when an ...Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack when a configuration uses a JDBC Appender with a JNDI LDAP data source URI when an attacker has control of the target LDAP server.
This issue is fixed by limiting JNDI data source names to the java protocol in Log4j2 versions 2.17.1, 2.12.4, and 2.3.2.
_(Description from [nist.gov](https://nvd.nist.gov/vuln/detail/CVE-2021-44832) for CVE-2021-44832)_M10 - Release 0.13https://community.opengroup.org/osdu/platform/system/lib/cloud/azure/os-core-lib-azure/-/issues/32Undelete (restore) of soft deleted blob doesn't work anymore2023-07-19T19:28:41ZAlok JoshiUndelete (restore) of soft deleted blob doesn't work anymorePlease refer to [this](https://community.opengroup.org/osdu/platform/system/lib/cloud/azure/os-core-lib-azure/-/merge_requests/216) original implementation of the feature.
We started seeing issues with the restore blob functionality in ...Please refer to [this](https://community.opengroup.org/osdu/platform/system/lib/cloud/azure/os-core-lib-azure/-/merge_requests/216) original implementation of the feature.
We started seeing issues with the restore blob functionality in our envs. We are seeing an unexpected error of type `com.fasterxml.jackson.core.JsonParseException` with every restore request. Investigation narrowed down the root cause to be [this](https://community.opengroup.org/osdu/platform/system/lib/cloud/azure/os-core-lib-azure/-/merge_requests/278) change, particularly the upgrade in `azure-core` version.
Steps to reproduce the issue (use Storage service APIs):
- Create a record
- Manually soft-delete only the record blob (don't touch cosmos metadata)
- Get record
The expected behavior is that Storage service attempts to restore the blob and getRecord API returns successfully. This isn't happening atm due to the mentioned issue.
None of the other later versions of `azure-core` fixes this. It seems this issue persists with any version `1.35.0` and higher
There are no observed vulnerabilities with `1.34.0`, therefore suggesting to revert back to this version.
~~[MR](https://community.opengroup.org/osdu/platform/system/lib/cloud/azure/os-core-lib-azure/-/merge_requests/300) for fix (abandoned)~~
After some discussion, we decided to make this [fix](https://community.opengroup.org/osdu/platform/system/storage/-/merge_requests/726) exclusively in StorageM19 - Release 0.22Alok JoshiAlok Joshihttps://community.opengroup.org/osdu/platform/system/lib/cloud/gcp/os-core-lib-gcp/-/issues/7ADR: OSDU API Versioning Strategy from Service Integration Perspective.2024-02-27T08:23:54ZRustam Lotsmanenko (EPAM)rustam_lotsmanenko@epam.comADR: OSDU API Versioning Strategy from Service Integration Perspective.TBDTBDhttps://community.opengroup.org/osdu/platform/system/lib/cloud/aws/os-core-lib-aws/-/issues/8Improper return value prevents local mode operation2023-07-11T14:51:14ZMark ChanceImproper return value prevents local mode operationWith LOCAL_MODE true, the Search Service (and possibly others) does not start due to NullPointerException in this library.
In org.opengroup.osdu.core.aws.ssm.K8sLocalParameterProvider:93
```java
// this is for credentials, credentials...With LOCAL_MODE true, the Search Service (and possibly others) does not start due to NullPointerException in this library.
In org.opengroup.osdu.core.aws.ssm.K8sLocalParameterProvider:93
```java
// this is for credentials, credentials mounted by CSI is a json string
// if in local mode, it returns an empty HashMap, it is the responsibility of end user to getDefault
public Map<String, String> getCredentialsAsMap(String parameterKey) throws K8sParameterNotFoundException, JsonProcessingException {
if (localMode) {
return null;
}
return objectMapper.readValue(this.getParameterAsString(parameterKey), typeRef);
```
Despite the comment to the contrary, the return value causes problems for example in
org.opengroup.osdu.core.aws.entitlements.ServiceAccountJwtAwsClientImpl:50
```java
private void init() {
K8sLocalParameterProvider provider = new K8sLocalParameterProvider();
try {
client_credentials_clientid = provider.getParameterAsString("CLIENT_CREDENTIALS_ID");
client_credentials_secret = provider.getCredentialsAsMap("CLIENT_CREDENTIALS_SECRET").get("client_credentials_client_secret");
...
```
If we change "return null;" to "return new HashMap<>();" it works better.Yong ZengYong Zenghttps://community.opengroup.org/osdu/platform/system/lib/cloud/azure/os-core-lib-azure/-/issues/30use of RequestMappingHandlerMapping in Slf4jMDCFilter2023-03-09T18:33:59ZNeelesh Thakuruse of RequestMappingHandlerMapping in Slf4jMDCFilter`Slf4jMDCFilter` is being used in quite a few services and it's invoked on each API request. It's throwing following exception:
![image](/uploads/f955b40cbc4d8652ca927fa26c00a111/image.png)
Based on traffic, we are seeing millions of s...`Slf4jMDCFilter` is being used in quite a few services and it's invoked on each API request. It's throwing following exception:
![image](/uploads/f955b40cbc4d8652ca927fa26c00a111/image.png)
Based on traffic, we are seeing millions of such exceptions are thrown across different services in several environments.https://community.opengroup.org/osdu/platform/system/lib/cloud/azure/os-core-lib-azure/-/issues/29Minimize Request Units (RUs) consumption on CosmosStore pageable query method2023-03-09T18:37:49ZYurii KondakovMinimize Request Units (RUs) consumption on CosmosStore pageable query methodCurrently, using the existing synchronous CosmosClient in a CosmosStore#queryItemsPage method, a certain number of extra (prefetch) queries are performed when retrieve records from the database page by page. For example, when we retrieve...Currently, using the existing synchronous CosmosClient in a CosmosStore#queryItemsPage method, a certain number of extra (prefetch) queries are performed when retrieve records from the database page by page. For example, when we retrieve 5000 records at 1000 records per page, the total number of queries that will be executed on the database will be 15 (not 5 as we expect).
Increasing the number of records we will have the following number of queries:
- 10000 records at 1000 records per page -> 45 requests (35 requests are unnecessary)
- 20000 records at 1000 records per page -> 105 requests (85 requests are unnecessary)
This increases the consumption of Cosmos DB Requests Units.
To prevent extra (prefetch) queries, we need to add an asynchronous client and an appropriate method for retrieving records from the database using this asynchronous client.
This solution to the problem was proposed in the course of e-mail correspondence with the Microsoft Azure team.
https://community.opengroup.org/osdu/platform/system/lib/cloud/azure/os-core-lib-azure/-/merge_requests/273Yurii KondakovYurii Kondakovhttps://community.opengroup.org/osdu/platform/system/lib/cloud/azure/os-core-lib-azure/-/issues/25Exception handling2022-07-28T19:09:58ZArsen GrigoryanException handlingWhen we called the method getIdToken and pass invalid parameters especially "clientSecret", throws NullPointerException for resolving this issue was added logic that checks, that if the response status is not 200 then returned AppExcept...When we called the method getIdToken and pass invalid parameters especially "clientSecret", throws NullPointerException for resolving this issue was added logic that checks, that if the response status is not 200 then returned AppException.Arsen GrigoryanArsen Grigoryanhttps://community.opengroup.org/osdu/platform/system/lib/cloud/azure/os-core-lib-azure/-/issues/22Lack of retries control in AbstractMessageHandler2022-06-07T12:36:26ZYauheni LesnikauLack of retries control in AbstractMessageHandlerIn AbstractMessageHandler whe have some retry mechanism, but the current implementation contains one drawback:
after failing processing of the message we abandon the one and in this case we can't controll repeated consumption and there i...In AbstractMessageHandler whe have some retry mechanism, but the current implementation contains one drawback:
after failing processing of the message we abandon the one and in this case we can't controll repeated consumption and there is high chance that message will be received immediate.
We are doing the thread sleep for exponential backoff behavior, but it is innaficient because thread appears busy during the sleeping time. On the other hand, we unable to control max delivery count from the code, because it is an attribute of the topic subscribtion, not our services.
It would be good if we could have more control for retry behavior using service bus client infrastructure principally.Yauheni LesnikauYauheni Lesnikauhttps://community.opengroup.org/osdu/platform/system/lib/cloud/azure/os-core-lib-azure/-/issues/19Unit service fails to start.2022-02-14T05:41:51ZRostislav Vatolinvatolinrp@gmail.comUnit service fails to start.Unit service fails to start. Exception:
Application run failed org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'buildDataLakeClientFactory' defined in class path resource \[org/opengroup/o...Unit service fails to start. Exception:
Application run failed org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'buildDataLakeClientFactory' defined in class path resource \[org/opengroup/osdu/azure/datalakestorage/DataLakeProvider.class\]: Unsatisfied dependency expressed through method 'buildDataLakeClientFactory' parameter 1; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'partitionServiceClient': Unsatisfied dependency expressed through field 'partitionFactory'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'partitionServiceFactory': Unsatisfied dependency expressed through field 'partitionServiceConfiguration'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'partitionServiceConfiguration': Injection of autowired dependencies failed; nested exception is java.lang.IllegalArgumentException: Could not resolve placeholder 'PARTITION_API' in value "${PARTITION_API}"
Please make sure DataLakeProvider spring bean is a conditional bean, because it causes the error.https://community.opengroup.org/osdu/platform/system/lib/cloud/gcp/osm/-/issues/1Upgrade to Log4J 2.17.1 to address CVE-2021-448322022-08-23T21:24:06ZDavid Diederichd.diederich@opengroup.orgUpgrade to Log4J 2.17.1 to address CVE-2021-44832Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack when a configuration uses a JDBC Appender with a JNDI LDAP data source URI when an ...Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack when a configuration uses a JDBC Appender with a JNDI LDAP data source URI when an attacker has control of the target LDAP server.
This issue is fixed by limiting JNDI data source names to the java protocol in Log4j2 versions 2.17.1, 2.12.4, and 2.3.2.
_(Description from [nist.gov](https://nvd.nist.gov/vuln/detail/CVE-2021-44832) for CVE-2021-44832)_