SHA256(x) is a hash function that transforms some string x (of any length) into a fixed size output.
SHA256(x) is deterministic. Every x maps to one 256-bit output.
SHA256(predictable junk) is going to look random, but will actually be predictable. This becomes security theater.
I mean the process of putting secrets in a web site is fraught, but:
a) KDFs in general are deterministic, not sure about your point here.
b) As long as you have sufficient input entropy, using SHA256 to mix some stuff down to key size is fine. You don't need a heavyweight KDF unless your input entropy is really bad.
File an issue if you're really sure, I guess?
This is how encryption_key gets invoked: https://github.com/onetimesecret/onetimesecret/blob/8ba0511e...
This is where the entropy is sourced from: https://github.com/onetimesecret/onetimesecret/blob/8ba0511e...
The global secret comes from: https://github.com/onetimesecret/onetimesecret/blob/8ba0511e...
self.key comes from gibbler.base(36): https://github.com/onetimesecret/onetimesecret/blob/8ba0511e...
At no point is anything touching /dev/urandom, which is how cryptography keys should be generated.
(Additionally, HKDF-SHA-256 should be used for splitting a master key into multiple sub-keys.)
I don't know if I want to file an issue for this on Github or not. Usually when the crypto is this bad, there's a lot of cargo-culting and I don't have the emotional bandwidth to deal with a vim-crypt style debate.
I really wouldn't trust that KDF.