Skip to content

feat: Sign endpoints #205

@oSumAtrIX

Description

@oSumAtrIX

Feature description

Endpoints such as /patches,/about,/manager, and co should be signed with the signing key used for patches/manager. The signature alongside the actual fields can be provided in two separate fields, with the signature verified by consuming applications:

Before:

{
  "createdAt": {
    "value": "string"
  },
  "description": "string",
  "downloadUrl": "string",
  "signatureDownloadUrl": "string",
  "version": "string"
}

After:

{
  "data": {
	  "createdAt": {
	    "value": "string"
	  },
	  "description": "string",
	  "downloadUrl": "string",
	  "signatureDownloadUrl": "string",
	  "version": "string"
	},
  "signature": "<base64 of data>"
}

The signature would be compared to that of the assets to match authenticity under a Trust On First Use (TOFU) model. If the patches for example is added to ReVanced Manager for the first time, and the signature of the endpoint does not match that of the patches, the endpoint would be marked as invalid.

For patches endpoint the patches signature may be used, for manager the manager signature, but for about its yet unclear how we can do TOFU.

Motivation

Endpoints such as/patches are vulnerable to MITM attacks. While assets such as the patches or the manager are signed and immutable via MITM, fields like patches are not. Descriptions or entire fields, as seen in /about (e.g., donation links), can be compromised. A bad actor can swap descriptions to link to bad places, or alter the about to redirect funds. Signing ensures the system is secure against unauthorized distribution. Manager and co. Won't accept the distribution if it's unauthentic.

The respective author signs the endpoints (can be done automatically by API)

Acknowledgements

  • I have checked all open and closed feature requests and this is not a duplicate
  • I have chosen an appropriate title.
  • All requested information has been provided properly.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Feature requestRequesting a new feature that's not implemented yet

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions