Release signing keys (PGP)

maltfield commented 1 month ago

Please add the official sublinks release signing keys to this repo.

I recommend adding a KEYS file to the root of your repo (located along-side files like LICENSE and README.md), per the KEYS standard established by Apache

https://infra.apache.org/release-signing#keys-policy

If sublinks doesn't yet a cryptographic keypair for signing releases, then please generate them.

maltfield commented 1 month ago

For more best-practices, see also:

lazyguru commented 1 month ago

This can be done closer to MVP release. Right now we don't actually have any releases (only nightly/bleeding-edge builds) and no one should be running Sublinks in any kind of "production"/"live" state.

But yes, we'll have stuff available for verification of binaries.

maltfield commented 1 month ago

Yep, I just wanted to make sure this infrastructure and process got setup properly before the first release.

This is yet another thing that I hope Sublinks fixes, as opposed to mistakes made by the Lemmy project.

Just read the Lemmy issue. The one thing I will add here is that our preferred way for people to install Sublinks will be Docker. So while I'm not saying we won't do this issue, I am saying that we might not support downloading the binaries and running the service in a way that aligns with what you are asking for unless Docker fixes their stuff.

maltfield commented 1 month ago

While I do think it's reasonable to provide an insecure-yet-convenient method to install your software, I think it's very important that you provide at least one way for users to obtain your software securely.

Docker's security issues have been around for years; I honestly don't think docker pull will ever be secure. At least not in the next 10 years..

Please consider at least providing an alternative download/install method for at-risk users to be able to confidently obtain authentic versions of the Sublinks software.

lazyguru commented 1 month ago

I'll clarify. When I say we might not support it, I mean that while we may generate and sign the binaries according to this feature request, if users have issues running the platform from those binaries our answer will likely be to tell them to use docker instead.

(As bad as this next part can come off, I really don't mean it that way. Text communication is hard due to the lack of context clues).

This is an open source project that currently receives little to no funding. All issues are open to anyone to pickup (though I recognize this specific one will require at least SOME support from the core devs). We simply are not going to be equipped to provide support for users attempting to run the platform on any number of possible hardware or OS configurations. If someone is willing to write up instructions for getting things running on a specific OS and architecture we will gladly accept those PRs. But I also want to be realistic in that issues opened for problems running on configurations other than docker will likely go unanswered or receive a comment asking the reporter to use docker instead (we may even go as far as closing the issue and asking the reporter to ask for help in a community forum instead). So while I agree with the idea behind this feature request, in practice it may only end up being useful to a very small number of instance owners. (Again, I'm in favor of keeping this open and implementing it in the future. I'm just not sure it will actually solve any problems. The more realistic approach to solving the security problems presented here would be to push for one of the container platforms out there to fix the issue on their side allowing for us as well as others like Lemmy to be able to provide secure downloads using a convenient install/run mechanism)

maltfield commented 1 month ago

I'm just not sure it will actually solve any problems.

The problem that it solves is watering hole attacks on instance admins who may (without any way to verify the authenticity of your releases) end-up downloading software with malware in it, which then compromises their users and their user's data.

By signing your releases, you'll provide a way for instance admins to verify the authenticity of your releases, and thus protect them (and their users) from these sorts of attacks.

The more realistic approach to solving the security problems presented here would be to push for one of the container platforms out there to fix the issue on their side

Unfortunately, I don't think that's realistic at all. Many, many users have been pushing Docker to fix their security issues, and it looks like they don't care enough to do so. The reason I opened this ticket so early was to make sure that Sublinks would be aware of such issues and intentionally avoid developing lock-in with technologies that are fundamentally broken.

Or, at least, to design your processes to not be totally dependent on them (eg alternative download instructions where all downloaded assets can be cryptographically verified after download and before install).

All issues are open to anyone to pickup

I appreciate your approach to leave the ticket open instead of closing it. If there's anything that I can do to help with this ticket, please let me know.

Pdzly commented 1 month ago

We will be doing our best, to secure it.

But for docker images, we can just note the SHA256 hash of the docker image that is "authentic" released by us.

maltfield commented 1 month ago

just to be clear: hashes do not provide any security/authenticity unless they're cryptographically signed (with a key whoose private key is stored offline).

sublinks / sublinks-api

Release signing keys (PGP) #382

See also