chore: Release prep v0.2.1.3 (#19)

CHANGELOG.md

@@ -1,95 +1,48 @@
 # Changelog
 
-## [x.x.x] - UNRELEASED
+## [x.x.x.x] - UNRELEASED
 
 ### Overview
 
-Backports a security flaw fix from https://github.com/eclipse-edc/Connector/pull/3719/files
-
-#### Why do we need this?
-
-Fix the security flaw in `0.2.1`.
-
-#### How does it work?
-
-Imported the patch from `0.5`
-
-#### How do we resolve this conflict?
-
-Update to `0.5+`
+#### Requirements
 
-## [0.2.1.2] - 2024-04-24
+#### Implementation
 
-### Overview
+#### Compatibility
 
-Re-release of `0.2.1-sovity1.0` as an official version following the established branches and version conventions.
+#### Resolution plan
 
-## [0.2.1-sovity1.0] - 2024-04-12
+## [0.2.1.3] - 2024-06-05
 
 ### Overview
 
-Adds a workaround to preserve the asset parameterization feature from pre-0.1 releases in a *provider push* scenario.
+Security fix
 
-#### Requirements
+#### Changes
 
-Eclipse EDC before version `0.1` used a different communication protocol that was capable of sending the parameterization data to the provider.
+- Fix security flaw in logging
 
-This is not possible anymore due to the current IDS specification for [transfer messages](https://docs.internationaldataspaces.org/ids-knowledgebase/v/dataspace-protocol/transfer-process/transfer.process.protocol#21-transfer-request-message).
+#### Details
 
-This feature is needed by one of our clients.
+See the [fork's documentation](docs/developer/fork/0.2.1.X.md#fix-security-flaw-in-logging): `Fix security flaw in logging`
 
-#### Implementation
+## [0.2.1.2] - 2024-04-24
 
-The only field (as of IDS version `2024-01`) that lets us send data in the concerned message is the `DataAddress`'s properties. This is the field, in combination with specific properties, that we use in this workaround to transfer the missing information to the provider.
-This extra information is extracted on the provider's side and put back where it used to be, in the `properties` of the `DataFlowRequest`.
-
-The workaround happens at this location:
-
-`org.eclipse.edc.connector.transfer.dataplane.flow.ProviderPushTransferDataFlowController.createRequest`
-
-With this workaround, a parameterized asset can be requested with the following query:
-
-```json
-{
-  "@type": "https://w3id.org/edc/v0.0.1/ns/TransferRequest",
-  "https://w3id.org/edc/v0.0.1/ns/assetId": "{{ASSET_ID}}",
-  "https://w3id.org/edc/v0.0.1/ns/contractId": "{{CONTRACT_ID}}",
-  "https://w3id.org/edc/v0.0.1/ns/connectorAddress": "https://{{PROVIDER_EDC_FQDN}}/api/dsp",
-  "https://w3id.org/edc/v0.0.1/ns/connectorId": "{{PROVIDER_EDC_PARTICIPANT_ID}}",
-  "https://w3id.org/edc/v0.0.1/ns/dataDestination": {
-    "https://w3id.org/edc/v0.0.1/ns/type": "HttpData",
-    "https://w3id.org/edc/v0.0.1/ns/baseUrl": "{{DATA_SINK_URL}}",
-    "https://sovity.de/workaround/proxy/param/pathSegments": "{{PARAMETERIZATION_PATH}}",
-    "https://sovity.de/workaround/proxy/param/method": "{{PARAMETERIZATION_METHOD}}",
-    "https://sovity.de/workaround/proxy/param/queryParams": "{{PARAMETERIZATION_QUERY}}",
-    "https://sovity.de/workaround/proxy/param/mediaType": "{{PARAMETERIZATION_CONTENTTYPE}}",
-    "https://sovity.de/workaround/proxy/param/body": "{{PARAMETERIZATION_BODY}}"
-  },
-  "https://w3id.org/edc/v0.0.1/ns/privateProperties": {},
-  "https://w3id.org/edc/v0.0.1/ns/protocol": "dataspace-protocol-http",
-  "https://w3id.org/edc/v0.0.1/ns/managedResources": false
-}
-```
-
-Where the `https://sovity.de/workaround/proxy/param/*` carry the parameterization data.
+### Overview
 
-#### Resolution plan
+Re-release of `0.2.1-sovity1.0` as an official version following the established branches and version conventions.
 
-There is a ticket open on the [IDS side](https://github.com/International-Data-Spaces-Association/ids-specification/discussions/262)
+## [0.2.1-sovity1.0] - 2024-04-12
 
-The goal is to
-* have this feature standardized
-* have it implemented in core EDC
-* use the new core EDC version
 
-#### Compatibility
+### Overview
 
-This change is targeting the *provider push* use-case only. The *consumer pull* use-case is not affected.
+Re-implementing the assets parameterization
 
-The parameterization feature must work between 2 EDCs that use this forked version.
+#### Changes
 
-The parameterization must work from an unpatched Consumer EDC, targeting a patched EDC provider, using the request mentioned in the Implementation section.
+- Add assets parametrization for provider push scenario
 
-The parametrization will not work if the provider EDC is not using this patched version.
+#### Details
 
-Expecting no other incompatibilities with core EDC 0.2.1.
+See the [fork's documentation](docs/developer/fork/0.2.1.X.md#Add-assets-parametrization-for-provider-push-scenario): `Add assets parametrization for provider push scenario`

docs/developer/fork/0.2.1.X.md

@@ -0,0 +1,83 @@
+# Fork
+
+## Changes implemented in `0.2.1`'s fork
+
+### Fix security flaw in logging
+
+Imported a security patch from `0.5` into `0.2.1` https://github.com/eclipse-edc/Connector/pull/3719/files
+
+#### Compatibility
+
+This only changes the log's output, removing potentially sensitive data.
+
+#### Resolution plan
+
+Update to Eclipse EDC `0.5+`.
+
+---
+
+### Add assets parametrization for provider push scenario
+
+Adds a workaround to preserve the assets' parameterization feature from pre-0.1 releases in a *provider push* scenario.
+
+Eclipse EDC before version `0.1` used a different communication protocol that was capable of sending the parameterization data to the provider in a *provider push* scenario.
+
+This is not possible anymore due to the current IDS specification for [transfer messages](https://docs.internationaldataspaces.org/ids-knowledgebase/v/dataspace-protocol/transfer-process/transfer.process.protocol#21-transfer-request-message).
+
+This feature is needed by one of our clients.
+
+#### Implementation
+
+The only field (as of IDS version `2024-01`) that lets us send data in the concerned message is the `DataAddress`'s properties. This is the field, in combination with specific properties, that we use in this workaround to transfer the missing information to the provider.
+This extra information is extracted on the provider's side and put back where it used to be, in the `properties` of the `DataFlowRequest`.
+
+The workaround happens at this location:
+
+`org.eclipse.edc.connector.transfer.dataplane.flow.ProviderPushTransferDataFlowController.createRequest`
+
+With this workaround, a parameterized asset can be requested with the following query:
+
+```json
+{
+  "@type": "https://w3id.org/edc/v0.0.1/ns/TransferRequest",
+  "https://w3id.org/edc/v0.0.1/ns/assetId": "{{ASSET_ID}}",
+  "https://w3id.org/edc/v0.0.1/ns/contractId": "{{CONTRACT_ID}}",
+  "https://w3id.org/edc/v0.0.1/ns/connectorAddress": "https://{{PROVIDER_EDC_FQDN}}/api/dsp",
+  "https://w3id.org/edc/v0.0.1/ns/connectorId": "{{PROVIDER_EDC_PARTICIPANT_ID}}",
+  "https://w3id.org/edc/v0.0.1/ns/dataDestination": {
+    "https://w3id.org/edc/v0.0.1/ns/type": "HttpData",
+    "https://w3id.org/edc/v0.0.1/ns/baseUrl": "{{DATA_SINK_URL}}",
+    "https://sovity.de/workaround/proxy/param/pathSegments": "{{PARAMETERIZATION_PATH}}",
+    "https://sovity.de/workaround/proxy/param/method": "{{PARAMETERIZATION_METHOD}}",
+    "https://sovity.de/workaround/proxy/param/queryParams": "{{PARAMETERIZATION_QUERY}}",
+    "https://sovity.de/workaround/proxy/param/mediaType": "{{PARAMETERIZATION_CONTENTTYPE}}",
+    "https://sovity.de/workaround/proxy/param/body": "{{PARAMETERIZATION_BODY}}"
+  },
+  "https://w3id.org/edc/v0.0.1/ns/privateProperties": {},
+  "https://w3id.org/edc/v0.0.1/ns/protocol": "dataspace-protocol-http",
+  "https://w3id.org/edc/v0.0.1/ns/managedResources": false
+}
+```
+
+Where the `https://sovity.de/workaround/proxy/param/*` carry the parameterization data.
+
+#### Resolution plan
+
+There is a ticket open on the [IDS side](https://github.com/International-Data-Spaces-Association/ids-specification/discussions/262)
+
+The goal is to
+* have this feature standardized
+* have it implemented in core EDC
+* use the new core EDC version
+
+#### Compatibility
+
+This change is targeting the *provider push* use-case only. The *consumer pull* use-case is not affected.
+
+The parameterization feature must work between 2 EDCs that use this forked version.
+
+The parameterization must work from an unpatched Consumer EDC, targeting a patched EDC provider, using the request mentioned in the Implementation section.
+
+The parametrization will not work if the provider EDC is not using this patched version.
+
+Expecting no other incompatibilities with core EDC 0.2.1.

gradle.properties

@@ -1,5 +1,5 @@
 group=org.eclipse.edc
-version=0.2.1-SNAPSHOT
+version=0.2.1.3
 # for now, we're using the same version for the autodoc plugin, the processor and the runtime-metamodel lib, but that could
 # change in the future
 annotationProcessorVersion=0.2.1-SNAPSHOT