Make pixlet encrypt/decrypt easier to use #1071
Comments
dinosaursrarr
added a commit
to dinosaursrarr/tidbyt-pixlet
that referenced
this issue
May 7, 2024
We've all done it. It's too easy to use the wrong key to encrypt with, whether you use the app name, the folder name, or get the hyphens wrong. Cropped up again recently with tidbyt#1071. If you're running pixlet encrypt from within the community repo, this will add a check that the provided key matches the ID field from some existing manifest. If not, you get an error. Thought about @jmanske's suggestions but I don't think pixlet can assume there'll be exactly one manifest in the commit to check against. You might be updating multiple apps, in which case, which should you check? Or you might be fixing a bad encryption, and not have any local edits. App names are generally unique enough that I think this works.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
One thing I see people get wrong all the time when encrypting API keys is that they do not use the right
id. They will typically use their app name or something like that, and their secrets will not be decrypted properly.The other hard-to-use aspect of this is that
secret.decryptwill simply fail if theidused to encrypt the key doesn't match that of the manifest; instead, it should returnNone, so that developers can handle this in their code more gracefully and show the right kind of error screen if the key was encrypted inappropriately.Another idea could be that the user never even passes the
id; the command should look it up from the local manifest so that a developer cannot do it wrong.Lastly, there ought to be some way for developers to test this before submitting PRs. It is frustrating for developers to submit a PR and see their app fail to render because they messed up something in
secret.decrypt. Canpixlet checkbe enhanced to somehow determine ifsecret.decryptis being used, and if so, see whatidwas used to encrypt the secret? If we can't do that locally, can the build/test pipeline check for this in some way?The text was updated successfully, but these errors were encountered: