-
-
Notifications
You must be signed in to change notification settings - Fork 34
Description
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.