search

ReVanced / revanced-api

🚀 API server for ReVanced
https://api.revanced.app
GNU Affero General Public License v3.0
90 stars 14 forks source link

feat: Add new field "keys" for members #150

Closed oSumAtrIX closed 9 months ago

oSumAtrIX commented 9 months ago

Issue

Since the API does not provide any data source for public GPG keys, websites such as https://revanced.app can not display them.

Solution

Add a new field, "keys", which holds an array of public GPG keys from https://api.github.com/users/<user>/keys.

Ushie commented 9 months ago

What is the motivation of this? why do we need to display public keys? and whose keys are thsse?

oSumAtrIX commented 9 months ago

The public GPG keys are a verification method for your identity across platforms. With your commits being signed and publicly accessible on revanced.app, you can always mathematically prove your identity with your signature. So if someone requests your identity on say Discord, they can request your sign and match it to the commits you have done to verify that the person behind the commits is the person they are talking to on Discord. As a general security practice, it's a good thing to have in place in case you lose access to any important accounts and, thus your identity.

You can see my keys here and verify all commits signed with them.

Ushie commented 9 months ago

So if someone requests your identity on say Discord, they can request your sign and match it to the commits you have done to verify that the person behind the commits is the person they are talking to on Discord.

What is the likeliness of this happening? there are better more straightforward ways of verifying who you're talking to, in the example of Discord, connections can be used, but generally a email exchange is also simple and straightforward if verification is necessary

Plus, I don't see how this is relevant to ReVanced, as it seems like it's intended for personal exchanges

oSumAtrIX commented 9 months ago

So if someone requests your identity on say Discord, they can request your sign and match it to the commits you have done to verify that the person behind the commits is the person they are talking to on Discord.

What is the likeliness of this happening? there are better more straightforward ways of verifying who you're talking to, in the example of Discord, connections can be used, but generally a email exchange is also simple and straightforward if verification is necessary

Plus, I don't see how this is relevant to ReVanced, as it seems like it's intended for personal exchanges

It is very unlikely that you need to verify your identity. It is also very unlikely that someone logs into your phone and yet as a security practice you protect it from unauthorized access. GPG is as straightforward as it gets to verify one's identity, Discord and co are not an option, including Email exchange as they are not mathematically safe and can be hijacked or lost. Having GPG keys is strong evidence of one's identity and should be added as a common security practice.

Ushie commented 9 months ago

That does not address this:

Plus, I don't see how this is relevant to ReVanced, as it seems like it's intended for personal exchanges

Yes, you're always welcome to use GPG keys to confirm your identity, but I don't see how this is relevant to the ReVanced Website, situations where you'd resort to using GPG keys to verify your identity are most likely personal exchanges and not related to ReVanced, why go through the ReVanced Website? it would be better to go through the source of truth which is on GitHub directly

oSumAtrIX commented 9 months ago

As GitHub is a third party platform it is not where we would want to publish the keys primarily, unlike our first party platform @ revanced.app. People would not need to visit GitHub to verify that you on Discord are who you claim to be on ReVanced, dependently of GitHub whereas the ultimate fallback and source of truth, where the user consumes from, is the revanced.app domain. It goes as far as that the user also is not dependant on GitHub in terms of the source code we write, as all source is available on git.revanced.app as well. GPG signing in itself has nothing to do with code, as to why it is not a good idea to only make it accessible in relation to that. Instead it is good to present them in a primary accessible location such as the website, as the key can be used to verify your identity for any general purpose. The API uses GitHub as a data source, but this is something that is not a concern of the website and as the API already fetches the member data of GitHub, it is convenient to also fetch the keys from there and supply them to the website.

alexandreteles commented 9 months ago

This can be done. It would generally be available through a keyring containing all keys, but it can also be added to the members endpoint. It is also important to have a project-level key to sign packages and binaries or add the information about which key to check against in each project releases. If we are implementing signage, we should also take the opportunity to add action artifacts for verification and the hashes for all files generated for release.

It is also important to note that not everyone uses their main key on Github, so if they are using a different key to sign commits and assets and didn't make it available on GH we'll need to pull them from whatever keyserver they are using or require that the keys are added to Github.

oSumAtrIX commented 9 months ago

Asset signage will be introduced, too. In this case, is the API supposed to publish the public keys of the signage? This issue is mainly for the members. As you identified correctly, if a member does not release their keys on GitHub, the API will not be able to pull it from there. An alternative data source would have to be consumed by the API or the member would have to upload their keys. If no key is provided, the member will have no keys by default. Regarding the signage process, should we have a primary key, with which we sign the keys of members? Do we ask the user to trust the keys served by the API? What are similar technicalities that should be questioned?

oSumAtrIX commented 9 months ago

@KTibow suggested to consider the endpoint https://api.github.com/<user>.gpg

Ushie commented 9 months ago

https://github.com/<user>.gpg also works

alexandreteles commented 9 months ago

Asset signage will be introduced, too. In this case, is the API supposed to publish the public keys of the signage?

Yes. But that will require its own issue when we get to that.

This issue is mainly for the members. As you identified correctly, if a member does not release their keys on GitHub, the API will not be able to pull it from there. An alternative data source would have to be consumed by the API or the member would have to upload their keys. If no key is provided, the member will have no keys by default.

That's the plan. Initially I will only provide keys available on GitHub, because searching keys on key servers is highly unreliable.

Regarding the signage process, should we have a primary key, with which we sign the keys of members? Do we ask the user to trust the keys served by the API? What are similar technicalities that should be questioned?

Also, something we can discuss on a different issue.