This PR "deprecates" gargle's existing secret_* functions, in favor of httr2's.
I use quotes around "deprecate" because gargle never actually exported these functions, so it's a semi-internal matter. We've always viewed encryption as a development-time task, so those functions didn't need to be exported from gargle. As for decryption, I call gargle's unexported functions via :::, which works because I'm the common maintainer of all the relevant packages. Other developers might do the same (?) or we've also said one could just inline the decryption logic.
Why switch to httr2's functions?
gargle's legacy approach is too heavily hard-wired for secrets inside a package, in terms of the interface around the encryption key and filepaths. This was regrettable and makes the functions basically impossible to use in non-package projects.
I see the guts of the functions in httr2 are a bit different and, I assume, those changes are neutral to positive. Hopefully one day gargle will depend on httr2 and we'll just remove most of this and use the httr2 functions directly.
What's new?
gargle is actually exporting some secret_* functions, i.e. the ones mentioned below.
secret_encrypt_json() and secret_decrypt_json() are new gargle-specific wrappers around httr2's secret functions.
gargle has really specific needs for encrypting JSON (probably found in a file, but maybe in a string) and decrypting it (to a string), e.g. service account tokens and OAuth clients.
I want the decrypted result to be suitable as the path argument of credentials_service_account() and gargle_oauth_client_from_json().
secret_write_rds() and secret_read_rds() are being exported to make it easier to secure a user token, which is relevant for gmailr, where it's practically impossible to use a service account token.
Other exports include secret_make_key() and secret_has_key().
This PR "deprecates" gargle's existing
secret_*functions, in favor of httr2's.I use quotes around "deprecate" because gargle never actually exported these functions, so it's a semi-internal matter. We've always viewed encryption as a development-time task, so those functions didn't need to be exported from gargle. As for decryption, I call gargle's unexported functions via
:::, which works because I'm the common maintainer of all the relevant packages. Other developers might do the same (?) or we've also said one could just inline the decryption logic.Why switch to httr2's functions?
What's new?
secret_*functions, i.e. the ones mentioned below.secret_encrypt_json()andsecret_decrypt_json()are new gargle-specific wrappers around httr2's secret functions.pathargument ofcredentials_service_account()andgargle_oauth_client_from_json().secret_write_rds()andsecret_read_rds()are being exported to make it easier to secure a user token, which is relevant for gmailr, where it's practically impossible to use a service account token.secret_make_key()andsecret_has_key().