0xPolygon · marcello33 · Feb 21, 2025 · Dec 20, 2024 · Dec 20, 2024 · Jan 28, 2025
diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
@@ -71,19 +71,3 @@ jobs:
 
       - name: "Run integration tests"
         run: make test-integration
-
-  test-ledger:
-    name: test-ledger
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-
-      - name: Install Go
-        uses: actions/setup-go@v5
-        with:
-          go-version: 1.23.x
-          cache: true
-          cache-dependency-path: go.sum
-
-      - name: "Run ledger tests"
-        run: make test-ledger-mock
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -39,6 +39,13 @@ Ref: https://keepachangelog.com/en/1.0.0/
 ## [Unreleased]
 
 
+## [v0.50.12](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.50.12) - 2025-02-20
+
+### Bug Fixes
+
+* [GHSA-x5vx-95h7-rv4p](https://github.com/cosmos/cosmos-sdk/security/advisories/GHSA-x5vx-95h7-rv4p) Fix Group module can halt chain when handling a malicious proposal
+
+
 ## [v0.50.11](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.50.11) - 2024-12-16
 
 ### Features

diff --git a/RELEASE_NOTES.md b/RELEASE_NOTES.md
@@ -1,26 +1,16 @@
-# Cosmos SDK v0.50.11 Release Notes
+# Cosmos SDK v0.50.12 Release Notes
 
 💬 [**Release Discussion**](https://github.com/orgs/cosmos/discussions/58)
 
 ## 🚀 Highlights
 
-We are back on schedule for our monthly v0.50.x patch releases.
-The last two months, next to ramping up on v0.52 and v2, we added a few bug fixes and (UX) improvements.
+This patch release fixes [GHSA-x5vx-95h7-rv4p](https://github.com/cosmos/cosmos-sdk/security/advisories/GHSA-x5vx-95h7-rv4p).
+It resolves a `x/group` module issue that can halt chain when handling a malicious proposal.
+Only users of the `x/group` module are affected by this issue.
 
-Notable changes:
-
-* Fix [ABS-0043/ABS-0044](https://github.com/cosmos/cosmos-sdk/security/advisories/GHSA-8wcc-m6j2-qxvm).
-* New Linux-only backend that adds Linux kernel's `keyctl` support
-* Skip sims test when running dry on validators
+We recommended to upgrade to this patch release as soon as possible.
+When upgrading from <= v0.50.11, please use a chain upgrade to ensure that 2/3 of the validator power upgrade to v0.50.12.
 
 ## 📝 Changelog
 
-Check out the [changelog](https://github.com/cosmos/cosmos-sdk/blob/v0.50.11/CHANGELOG.md) for an exhaustive list of changes, or [compare changes](https://github.com/cosmos/cosmos-sdk/compare/v0.50.10...v0.50.11) from the last release.
-
-## Maintenance Policy
-
-Cosmos SDK Olympus (v0.52) final release is approaching really soon. That means the Eden line (v0.50.x) will soon only be supported for bug fixes only, as per our release policy. Earlier versions are not maintained.  
-
-Note, that the next SDK release, v0.52, does not include `x/params` migration, when migrating from < v0.47, v0.50.x **or** v0.47.x, is a mandatory migration.
-
-Start integrating with [Cosmos SDK Eden (v0.52)](https://github.com/cosmos/cosmos-sdk/blob/main/UPGRADING.md#v052x) and enjoy and the new features and performance improvements.
+Check out the [changelog](https://github.com/cosmos/cosmos-sdk/blob/v0.50.12/CHANGELOG.md) for an exhaustive list of changes, or [compare changes](https://github.com/cosmos/cosmos-sdk/compare/v0.50.11...v0.50.12) from the last release.
diff --git a/client/v2/CHANGELOG.md b/client/v2/CHANGELOG.md
@@ -36,6 +36,10 @@ Ref: https://keepachangelog.com/en/1.0.0/
 
 ## [Unreleased]
 
+## [v2.0.0-beta.8] - 2025-01-29
+
+* [#23544](https://github.com/cosmos/cosmos-sdk/pull/23544) Support map in queries for autocli.
+
 ## [v2.0.0-beta.7] - 2024-12-10
 
 ### Bug Fixes

diff --git a/client/v2/autocli/query.go b/client/v2/autocli/query.go
@@ -124,6 +124,7 @@ func (b *Builder) BuildQueryMethodCommand(_ context.Context, descriptor protoref
 		EnumAsString:       true,
 		DoNotSortFields:    true,
 		AminoNameAsTypeURL: true,
+		MarshalMappings:    true,
 		TypeResolver:       b.TypeResolver,
 		FileResolver:       b.FileResolver,
 	}

diff --git a/client/v2/go.mod b/client/v2/go.mod
@@ -7,10 +7,10 @@ require (
 	cosmossdk.io/core v0.11.1
 	cosmossdk.io/depinject v1.0.0
 	cosmossdk.io/math v1.4.0
-	cosmossdk.io/x/tx v0.13.7
+	cosmossdk.io/x/tx v0.13.8
 	github.com/cockroachdb/errors v1.11.3
 	github.com/cosmos/cosmos-proto v1.0.0-beta.5
-	github.com/cosmos/cosmos-sdk v0.50.11
+	github.com/cosmos/cosmos-sdk v0.50.12
 	github.com/spf13/cobra v1.8.1
 	github.com/spf13/pflag v1.0.5
 	github.com/stretchr/testify v1.10.0
@@ -181,6 +181,7 @@ require (
 )
 
 // HV2 related packages
+// TODO HV2: add x/tx replacement (see https://polygon.atlassian.net/browse/POS-2756)
 replace (
 	cosmossdk.io/api => github.com/0xPolygon/cosmos-sdk/api v0.7.5
 	cosmossdk.io/collections => github.com/0xPolygon/cosmos-sdk/collections v0.4.0
@@ -190,7 +191,6 @@ replace (
 	cosmossdk.io/log => github.com/0xPolygon/cosmos-sdk/log v1.4.1
 	cosmossdk.io/math => github.com/0xPolygon/cosmos-sdk/math v1.4.0
 	cosmossdk.io/store => github.com/0xPolygon/cosmos-sdk/store v1.1.2-0.20241126102051-89dc71d02611
-	cosmossdk.io/x/tx => github.com/0xPolygon/cosmos-sdk/x/tx v0.13.6-0.20241126102051-89dc71d02611
 	github.com/cometbft/cometbft => github.com/0xPolygon/cometbft v0.1.3-beta-polygon
 	github.com/cosmos/cosmos-sdk => ./../../
 	github.com/ethereum/go-ethereum => github.com/maticnetwork/bor v1.5.5

diff --git a/client/v2/go.sum b/client/v2/go.sum
@@ -1,5 +1,7 @@
 cloud.google.com/go v0.26.0/go.mod h1:aQUYkXzVsufM+DwF1aE+0xfcU+56JwCaLick0ClmMTw=
 cloud.google.com/go v0.34.0/go.mod h1:aQUYkXzVsufM+DwF1aE+0xfcU+56JwCaLick0ClmMTw=
+cosmossdk.io/x/tx v0.13.8 h1:dQwC8jMe7awx/edi1HPPZ40AjHnsix6KSO/jbKMUYKk=
+cosmossdk.io/x/tx v0.13.8/go.mod h1:V6DImnwJMTq5qFjeGWpXNiT/fjgE4HtmclRmTqRVM3w=
 dmitri.shuralyov.com/gpu/mtl v0.0.0-20190408044501-666a987793e9/go.mod h1:H6x//7gZCb22OMCxBHrMx7a5I7Hp++hsVxbQ4BYO7hU=
 filippo.io/edwards25519 v1.0.0 h1:0wAIcmJUqRdI8IJ/3eGi5/HwXZWPujYXXlkrQogz0Ek=
 filippo.io/edwards25519 v1.0.0/go.mod h1:N1IkdkCkiLB6tki+MYJoSx2JTY9NUlxZE7eHn5EwJns=
@@ -21,8 +23,6 @@ github.com/0xPolygon/cosmos-sdk/math v1.4.0 h1:2cXVfURXPAzOvuWbhJseo28QLCnZYnUz9
 github.com/0xPolygon/cosmos-sdk/math v1.4.0/go.mod h1:O5PkD4apz2jZs4zqFdTr16e1dcaQCc5z6lkEnrrppuk=
 github.com/0xPolygon/cosmos-sdk/store v1.1.2-0.20241126102051-89dc71d02611 h1:aU2c4vQffstBG94t524ep53PsLtnHDA4w2bH+A3A/E4=
 github.com/0xPolygon/cosmos-sdk/store v1.1.2-0.20241126102051-89dc71d02611/go.mod h1:pADXCBZJK5hHx5qhx5jsZQWNRPB3a7mEEZBCRfn9dEw=
-github.com/0xPolygon/cosmos-sdk/x/tx v0.13.6-0.20241126102051-89dc71d02611 h1:Z1yl7tjFgtjsKgLq5RtrrV3PsIVw4SyPljhsuhHIyFs=
-github.com/0xPolygon/cosmos-sdk/x/tx v0.13.6-0.20241126102051-89dc71d02611/go.mod h1:ZCQM9tU2LeW5kIuaq0q02KRHhMWAvNtj4cmVRyLfZmQ=
 github.com/0xPolygon/heimdall-v2 v0.1.0 h1:Kdp3stpjd7sPjy5iB5XpkHZMG1f2qzwVqEHJfKPqeTc=
 github.com/0xPolygon/heimdall-v2 v0.1.0/go.mod h1:WBimMV/zK1xFgQ69KoKOEEHLHkwjG0A74OTbDk5ZBFM=
 github.com/99designs/go-keychain v0.0.0-20191008050251-8e49817e8af4 h1:/vQbFIOMbk2FiG/kXiLl8BRyzTWDw7gX/Hz7Dd5eDMs=

diff --git a/docs/docs/build/building-modules/02-messages-and-queries.md b/docs/docs/build/building-modules/02-messages-and-queries.md
@@ -24,17 +24,16 @@ When a transaction is relayed from the underlying consensus engine to the Cosmos
 
 Defining Protobuf `Msg` services is the recommended way to handle messages. A Protobuf `Msg` service should be created for each module, typically in `tx.proto` (see more info about [conventions and naming](../../learn/advanced/05-encoding.md#faq)). It must have an RPC service method defined for each message in the module.
 
-
 Each `Msg` service method must have exactly one argument, which must implement the `sdk.Msg` interface, and a Protobuf response. The naming convention is to call the RPC argument `Msg<service-rpc-name>` and the RPC response `Msg<service-rpc-name>Response`. For example:
 
 ```protobuf
-  rpc Send(MsgSend) returns (MsgSendResponse);
+rpc Send(MsgSend) returns (MsgSendResponse);
 ```
 
 See an example of a `Msg` service definition from `x/bank` module:
 
 ```protobuf reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/proto/cosmos/bank/v1beta1/tx.proto#L13-L36
+https://github.com/cosmos/cosmos-sdk/blob/28fa3b8/x/bank/proto/cosmos/bank/v1beta1/tx.proto#L13-L41
 ```
 
 ### `sdk.Msg` Interface
@@ -47,8 +46,7 @@ To attach a `ValidateBasic()` method to a message then you must add methods to t
 https://github.com/cosmos/cosmos-sdk/blob/9c1e8b247cd47b5d3decda6e86fbc3bc996ee5d7/types/tx_msg.go#L84-L88
 ```
 
-In 0.50+ signers from the `GetSigners()` call is automated via a protobuf annotation. 
-
+Signers from the `GetSigners()` call is automated via a protobuf annotation. 
 Read more about the signer field [here](./05-protobuf-annotations.md).
 
 ```protobuf reference 
@@ -58,23 +56,32 @@ https://github.com/cosmos/cosmos-sdk/blob/e6848d99b55a65d014375b295bdd7f9641aac9
 If there is a need for custom signers then there is an alternative path which can be taken. A function which returns `signing.CustomGetSigner` for a specific message can be defined. 
 
 ```go
-func ProvideBankSendTransactionGetSigners() signing.CustomGetSigner {
-
-			// Extract the signer from the signature.
-			signer, err := coretypes.LatestSigner(Tx).Sender(ethTx)
-      if err != nil {
-				return nil, err
-			}
-
-			// Return the signer in the required format.
-			return [][]byte{signer.Bytes()}, nil
+func ProvideCustomMsgTransactionGetSigners() signing.CustomGetSigner {
+	// Extract the signer from the signature.
+	signer, err := coretypes.LatestSigner(Tx).Sender(ethTx)
+	if err != nil {
+		return nil, err
+	}
+
+	// Return the signer in the required format.
+	return signing.CustomGetSigner{
+		MsgType: protoreflect.FullName(gogoproto.MessageName(&types.CustomMsg{})),
+		Fn: func(msg proto.Message) ([][]byte, error) {
+			return [][]byte{signer}, nil
+		}
+	}
 }
 ```
 
-When using dependency injection (depinject) this can be provided to the application via the provide method.
+This can be provided to the application using depinject's `Provide` method in the module that defines the type:
 
-```go
-depinject.Provide(banktypes.ProvideBankSendTransactionGetSigners)
+```diff
+func init() {
+	appconfig.RegisterModule(&modulev1.Module{},
+-		appconfig.Provide(ProvideModule),
++		appconfig.Provide(ProvideModule, ProvideCustomMsgTransactionGetSigners),
+	)
+}
 ```
 
 The Cosmos SDK uses Protobuf definitions to generate client and server code:
@@ -84,7 +91,7 @@ The Cosmos SDK uses Protobuf definitions to generate client and server code:
 
 A `RegisterMsgServer` method is also generated and should be used to register the module's `MsgServer` implementation in `RegisterServices` method from the [`AppModule` interface](./01-module-manager.md#appmodule).
 
-In order for clients (CLI and grpc-gateway) to have these URLs registered, the Cosmos SDK provides the function `RegisterMsgServiceDesc(registry codectypes.InterfaceRegistry, sd *grpc.ServiceDesc)` that should be called inside module's [`RegisterInterfaces`](01-module-manager.md#appmodulebasic) method, using the proto-generated `&_Msg_serviceDesc` as `*grpc.ServiceDesc` argument.
+In order for clients (CLI and gRPC-gateway) to have these URLs registered, the Cosmos SDK provides the function `RegisterMsgServiceDesc(registry codectypes.InterfaceRegistry, sd *grpc.ServiceDesc)` that should be called inside module's [`RegisterInterfaces`](01-module-manager.md#appmodulebasic) method, using the proto-generated `&_Msg_serviceDesc` as `*grpc.ServiceDesc` argument.
 
 
 ## Queries
@@ -93,7 +100,7 @@ A `query` is a request for information made by end-users of applications through
 
 ### gRPC Queries
 
-Queries should be defined using [Protobuf services](https://developers.google.com/protocol-buffers/docs/proto#services). A `Query` service should be created per module in `query.proto`. This service lists endpoints starting with `rpc`.
+Queries should be defined using [Protobuf services](https://protobuf.dev/programming-guides/proto2/). A `Query` service should be created per module in `query.proto`. This service lists endpoints starting with `rpc`.
 
 Here's an example of such a `Query` service definition:
 
@@ -105,26 +112,6 @@ As `proto.Message`s, generated `Response` types implement by default `String()`
 
 A `RegisterQueryServer` method is also generated and should be used to register the module's query server in the `RegisterServices` method from the [`AppModule` interface](./01-module-manager.md#appmodule).
 
-### Legacy Queries
-
-Before the introduction of Protobuf and gRPC in the Cosmos SDK, there was usually no specific `query` object defined by module developers, contrary to `message`s. Instead, the Cosmos SDK took the simpler approach of using a simple `path` to define each `query`. The `path` contains the `query` type and all the arguments needed to process it. For most module queries, the `path` should look like the following:
-
-```text
-queryCategory/queryRoute/queryType/arg1/arg2/...
-```
-
-where:
-
-* `queryCategory` is the category of the `query`, typically `custom` for module queries. It is used to differentiate between different kinds of queries within `BaseApp`'s [`Query` method](../../learn/advanced/00-baseapp.md#query).
-* `queryRoute` is used by `BaseApp`'s [`queryRouter`](../../learn/advanced/00-baseapp.md#query-routing) to map the `query` to its module. Usually, `queryRoute` should be the name of the module.
-* `queryType` is used by the module's [`querier`](./04-query-services.md#legacy-queriers) to map the `query` to the appropriate `querier function` within the module.
-* `args` are the actual arguments needed to process the `query`. They are filled out by the end-user. Note that for bigger queries, you might prefer passing arguments in the `Data` field of the request `req` instead of the `path`.
-
-The `path` for each `query` must be defined by the module developer in the module's [command-line interface file](./09-module-interfaces.md#query-commands).Overall, there are 3 mains components module developers need to implement in order to make the subset of the state defined by their module queryable:
-
-* A [`querier`](./04-query-services.md#legacy-queriers), to process the `query` once it has been [routed to the module](../../learn/advanced/00-baseapp.md#query-routing).
-* [Query commands](./09-module-interfaces.md#query-commands) in the module's CLI file, where the `path` for each `query` is specified.
-* `query` return types. Typically defined in a file `types/querier.go`, they specify the result type of each of the module's `queries`. These custom types must implement the `String()` method of [`fmt.Stringer`](https://pkg.go.dev/fmt#Stringer).
 
 ### Store Queries
 

diff --git a/docs/docs/user/run-node/00-keyring.md b/docs/docs/user/run-node/00-keyring.md
@@ -29,12 +29,14 @@ is a list of the most popular operating systems and their respective passwords m
 * GNU/Linux:
     * [libsecret](https://gitlab.gnome.org/GNOME/libsecret)
     * [kwallet](https://api.kde.org/frameworks/kwallet/html/index.html)
+    * [keyctl](https://www.kernel.org/doc/html/latest/security/keys/core.html)
 
 GNU/Linux distributions that use GNOME as default desktop environment typically come with
 [Seahorse](https://wiki.gnome.org/Apps/Seahorse). Users of KDE based distributions are
 commonly provided with [KDE Wallet Manager](https://userbase.kde.org/KDE_Wallet_Manager).
 Whilst the former is in fact a `libsecret` convenient frontend, the latter is a `kwallet`
-client.
+client. `keyctl` is a secure backend leverages the Linux's kernel security key management system
+to store cryptographic keys securely in memory.
 
 `os` is the default option since operating system's default credentials managers are
 designed to meet users' most common needs and provide them with a comfortable
@@ -93,6 +95,15 @@ GNU/Linux distributions that ships KDE as default desktop environment. Please re
 [KWallet Handbook](https://docs.kde.org/stable5/en/kdeutils/kwallet5/index.html) for more
 information.
 
+### The `keyctl` backend
+
+The *Kernel Key Retention Service*  is a security facility that
+has been added to the Linux kernel relatively recently. It allows sensitive
+cryptographic data such as passwords, private key, authentication tokens, etc
+to be stored securely in memory.
+
+The `keyctl` backend is available on Linux platforms only.
+
 ### The `test` backend
 
 The `test` backend is a password-less variation of the `file` backend. Keys are stored

diff --git a/orm/CHANGELOG.md b/orm/CHANGELOG.md
diff --git a/orm/Makefile b/orm/Makefile