packet-forward-middleware v8.1.0

Summary

Updates to PFM include dependency upgrades to IBC v8.1.1 and Cosmos SDK v0.50.5, aligning log messages with function names, and removing the unused refundTimeout parameter. Additionally, The ability to take a fee for each forwarded packet has been removed, simplifying the middleware's functionality. Lastly, a fix was implemented to properly remove timed out in-flight transactions from the blockchain's state, addressing a potential storage leak.

What's Changed

• docs: update PFM references by @rootulp in #177
• CI: link lint + spell check by @Reecepbcups in #179
• Add unnecessary loop test by @agouin in #180
• deps!(pfm): ibc v8.1.1 and cosmos-sdk v0.50.5 by @hoank101 in #184
• chore(pfm): update log line to match function name by @LuqiPan in #190
• chore(pfm): remove unused refundTimeout by @Reecepbcups in #193
• refactor: remove the ability to take a fee for each forwarded packet by @jtieri in #202
• docs: update maintained branches table by @jtieri in #212
• refactor: remove processed key and handling code by @jtieri in #216
• feat: add storage leak test by @joelsmith-2019 in #222

New Contributors

• @rootulp made their first contribution in #175
• @hoank101 made their first contribution in #184
• @LuqiPan made their first contribution in #190
• @joelsmith-2019 made their first contribution in #222

Full Changelog: middleware/packet-forward-middleware/v8.0.2...middleware/packet-forward-middleware/v8.1.0

packet-forward-middleware v7.2.0

Summary

Packet Forward Middleware has removed the ability to take a fee for each forwarded packet, simplifying the middleware's functionality. Additionally, a fix was implemented to properly remove timed out in-flight transactions from the blockchain's state, addressing a potential storage leak.

What's Changed

• refactor: backport changes to remove the ability to take a fee for each forwarded packet by @jtieri in #210
• [BP: release/v7 <- #216] refactor: remove processed key and handling code by @mergify in #218
• [BP: release/v7 <- #222] feat: add storage leak test by @mergify in #223

Full Changelog: middleware/packet-forward-middleware/v7.1.3...middleware/packet-forward-middleware/v7.2.0

polytone v1.1.0

What's Changed

• feat: add polytone by @Reecepbcups in #169

Original Implementation

https://github.com/DA0-DA0/polytone/releases/tag/v1.1.0

ibc-rate-limiting v7.0.0

Summary

The module is meant as a safety control in the event of a bug, attack, or economic failure of an external zone. It prevents massive inflows or outflows of IBC tokens in a short time frame.

Imported from Stride-Labs/ibc-rate-limiting.

Implementation

require (
    github.com/cosmos/ibc-apps/modules/rate-limiting/v7 v7.0.0
)

Review the README for further integration instructions and app setup.

ibc-rate-limiting v8.0.0

Summary

The module is meant as a safety control in the event of a bug, attack, or economic failure of an external zone. It prevents massive inflows or outflows of IBC tokens in a short time frame.

Imported from Stride-Labs/ibc-rate-limiting.

Implementation

require (
    github.com/cosmos/ibc-apps/modules/rate-limiting/v8 v8.0.0
)

Review the README for further integration instructions and app setup.

packet-forward-middleware v8.0.2

Note

This release includes the patch for the Mandrake vulnerability

We recommend that you upgrade to the patched version, create a new release for your chain binary, and coordinate an upgrade with validators as soon as reasonable.

In addition to patching packet-forward-middleware, it is imperative that you check the balances of each escrow account against the total supply of each asset on the associated counterparty chain. Failure to verify parity between the escrow accounts and the counterparty total supply can result in a type of Denial-of-Service where users may not be able to unwind their assets through your chain. You can use our escrow checker tool or whatever means you deem fit to validate these balances against the counterparty total supply. If a discrepancy is found, you will need to build an upgrade handler that mints and transfers assets to the escrow account(s) with the discrepancy. Strangelove has provided an example upgrade handler or you can see the upgrade handler used by the Cosmos Hub.

What's Changed

• Remove gogo/protobuf replace directive in async-icq/v8 by @Taztingo in #168
• fix: mint and transfer funds back to escrow account on timeout or ack error by @jtieri in #170

Full Changelog: middleware/packet-forward-middleware/v8.0.1...middleware/packet-forward-middleware/v8.0.2

packet-forward-middleware v7.1.3

Note

This release includes the patch for the Mandrake vulnerability

We recommend that you upgrade to the patched version, create a new release for your chain binary, and coordinate an upgrade with validators as soon as reasonable.

In addition to patching packet-forward-middleware, it is imperative that you check the balances of each escrow account against the total supply of each asset on the associated counterparty chain. Failure to verify parity between the escrow accounts and the counterparty total supply can result in a type of Denial-of-Service where users may not be able to unwind their assets through your chain. You can use our escrow checker tool or whatever means you deem fit to validate these balances against the counterparty total supply. If a discrepancy is found, you will need to build an upgrade handler that mints and transfers assets to the escrow account(s) with the discrepancy. Strangelove has provided an example upgrade handler or you can see the upgrade handler used by the Cosmos Hub.

What's Changed

• update PFM integration docs by @Reecepbcups in #147
• Add PFM example by @bd21 in #145
• feat: auto label pull request by @Reecepbcups in #148
• fix: mint and transfer funds back to escrow account on timeout or ack error by @jtieri in #171

Full Changelog: middleware/packet-forward-middleware/v7.1.2...middleware/packet-forward-middleware/v7.1.3

packet-forward-middleware v6.1.2

Note

This release includes the patch for the Mandrake vulnerability

We recommend that you upgrade to the patched version, create a new release for your chain binary, and coordinate an upgrade with validators as soon as reasonable.

In addition to patching packet-forward-middleware, it is imperative that you check the balances of each escrow account against the total supply of each asset on the associated counterparty chain. Failure to verify parity between the escrow accounts and the counterparty total supply can result in a type of Denial-of-Service where users may not be able to unwind their assets through your chain. You can use our escrow checker tool or whatever means you deem fit to validate these balances against the counterparty total supply. If a discrepancy is found, you will need to build an upgrade handler that mints and transfers assets to the escrow account(s) with the discrepancy. Strangelove has provided an example upgrade handler or you can see the upgrade handler used by the Cosmos Hub.

What's Changed

• [BP: release/v6 <- #102] Spelling, grammar, and formatting fixes. by @mergify in #111
• [BP: release/v6 <- #88] test: use non-deprecated gomock package & fix unit tests by @mergify in #115
• [BP: release/v6 <- #118] rename: router -> packetforward by @mergify in #121
• [BP: release/v6 <- #70] Add warning to ibc-hooks docs by @mergify in #125
• [BP: release/v6 <- #132] chore: export the GetReceiver function by @mergify in #135
• [BP: release/v6 <- #86] fix!: queries that panic should return ack-err by @mergify in #139
• fix: mint and transfer funds back to escrow account on timeout or ack error by @jtieri in #172

Full Changelog: middleware/packet-forward-middleware/v6.1.1...middleware/packet-forward-middleware/v6.1.2

packet-forward-middleware v5.2.2

Note

This release includes the patch for the Mandrake vulnerability

We recommend that you upgrade to the patched version, create a new release for your chain binary, and coordinate an upgrade with validators as soon as reasonable.

In addition to patching packet-forward-middleware, it is imperative that you check the balances of each escrow account against the total supply of each asset on the associated counterparty chain. Failure to verify parity between the escrow accounts and the counterparty total supply can result in a type of Denial-of-Service where users may not be able to unwind their assets through your chain. You can use our escrow checker tool or whatever means you deem fit to validate these balances against the counterparty total supply. If a discrepancy is found, you will need to build an upgrade handler that mints and transfers assets to the escrow account(s) with the discrepancy. Strangelove has provided an example upgrade handler or you can see the upgrade handler used by the Cosmos Hub.

What's Changed

• [BP: release/v5 <- #88] test: use non-deprecated gomock package & fix unit tests by @mergify in #114
• [BP: release/v5 <- #118] rename: router -> packetforward by @mergify in #120
• [BP: release/v5 <- #70] Add warning to ibc-hooks docs by @mergify in #124
• [BP: release/v5 <- #132] chore: export the GetReceiver function by @mergify in #134
• [BP: release/v5 <- #86] fix!: queries that panic should return ack-err by @mergify in #138
• fix: mint and transfer funds back to escrow account on timeout or ack error by @jtieri in #173

Full Changelog: middleware/packet-forward-middleware/v5.2.1...middleware/packet-forward-middleware/v5.2.2

packet-forward-middleware v4.1.2

Note

This release includes the patch for the Mandrake vulnerability

We recommend that you upgrade to the patched version, create a new release for your chain binary, and coordinate an upgrade with validators as soon as reasonable.

In addition to patching packet-forward-middleware, it is imperative that you check the balances of each escrow account against the total supply of each asset on the associated counterparty chain. Failure to verify parity between the escrow accounts and the counterparty total supply can result in a type of Denial-of-Service where users may not be able to unwind their assets through your chain. You can use our escrow checker tool or whatever means you deem fit to validate these balances against the counterparty total supply. If a discrepancy is found, you will need to build an upgrade handler that mints and transfers assets to the escrow account(s) with the discrepancy. Strangelove has provided an example upgrade handler or you can see the upgrade handler used by the Cosmos Hub.

What's Changed

• [BP: release/v4 <- #88] test: use non-deprecated gomock package & fix unit tests by @mergify in #113
• [BP: release/v4 <- #118] rename: router -> packetforward by @mergify in #119
• [BP: release/v4 <- #70] Add warning to ibc-hooks docs by @mergify in #123
• [BP: release/v4 <- #132] chore: export the GetReceiver function by @mergify in #133
• [BP: release/v4 <- #86] fix!: queries that panic should return ack-err by @mergify in #137
• fix: mint and transfer funds back to escrow account on timeout or ack error by @jtieri in #174

Full Changelog: middleware/packet-forward-middleware/v4.1.1...middleware/packet-forward-middleware/v4.1.2