Description
Since you are building a complete set in this library, I thought to also request react-native support, but done in a better way.
Motivation
A better option in the react-native ecosystem. As it lacks a complete and maintained secure option.
Proposed Solution
It could be encrypted in runtime while also served at runtime (as one of the options), but it would require other protections in place most likely. I supose the more options you support given what you already do, the better, as long as you clearly state the security tradeoffs.
It should support, js, native and common used files from native setup that is used by packages sometimes.
Alternatives
Currently there is
But the first two are not very secure. It's not like it's possible to be. Although there is a alternative that does it better. But they do not maintain it very well.
https://github.com/numandev1/react-native-keys
Ideally, yours would be a better version than react-native-keys, from the get-go.
Additional Information
You could use Swift and Kotlin for the native part. Ideally support both old and new arch. There is another suggestion below.
Should work with Proguard / R8 or any other obfuscation / minification tool.
I would suggest to cover other parts that can contribute to being easy to reverse-engineer and get the env vars, that's why it should be a better option than react-native-keys. There are other factors that can still facilitate, perhaps if other security measures were added / in place. Against rooted, emulators, have rasp protections, etc... Perhaps even integrity checks, it could help, once the main parts were addressed.
Currently I have a gist, that could help make sense of this in some parts. https://gist.github.com/dougg0k/60e02f2fd99df129a7e329c92309fd5e
In all points of it, performance are important, but security even more, as stated, if possible have further things done, perhaps even checks within the library using other security related libraries.
Another thing to do would be scramble env vars if compromised. Using the other libraries and anything from the single native impl, if done like so.
Perhaps have optional integrations with other libraries for more security, including tradeoffs, if any. Rather than just including as dependencies since they can also be used for other things in an app, they should be optional and installed by the dev.
Research and understand all the points that can cause env vars to be compromised. Perhaps more counter-measures would be found in the process, to counter any sort of reverse engineering or at least make even more difficult. I would say that AI can help figure out other things on this, so should be used to understand, but if possible, find actual user proof, since AI are known to not be precise / true sometimes.
https://medium.com/@derya.cortuk/reverse-engineering-tools-fccc151f0a82 - This may help see how difficult based on the implementation. But optional, to someone who knows how.
Here are some perspectives from AI
https://oss.callstack.com/react-native-builder-bob/create - If only mobile native and js.
Not sure how viable it is, but I suppose Rust or C++ could be used for a single implementation and then spread to native and js.
Description
Since you are building a complete set in this library, I thought to also request react-native support, but done in a better way.
Motivation
A better option in the react-native ecosystem. As it lacks a complete and maintained secure option.
Proposed Solution
It could be encrypted in runtime while also served at runtime (as one of the options), but it would require other protections in place most likely. I supose the more options you support given what you already do, the better, as long as you clearly state the security tradeoffs.
It should support, js, native and common used files from native setup that is used by packages sometimes.
Alternatives
Currently there is
But the first two are not very secure. It's not like it's possible to be. Although there is a alternative that does it better. But they do not maintain it very well.
https://github.com/numandev1/react-native-keys
Ideally, yours would be a better version than
react-native-keys, from the get-go.Additional Information
You could use Swift and Kotlin for the native part. Ideally support both old and new arch. There is another suggestion below.
Should work with Proguard / R8 or any other obfuscation / minification tool.
I would suggest to cover other parts that can contribute to being easy to reverse-engineer and get the env vars, that's why it should be a better option than react-native-keys. There are other factors that can still facilitate, perhaps if other security measures were added / in place. Against rooted, emulators, have rasp protections, etc... Perhaps even integrity checks, it could help, once the main parts were addressed.
Currently I have a gist, that could help make sense of this in some parts. https://gist.github.com/dougg0k/60e02f2fd99df129a7e329c92309fd5e
In all points of it, performance are important, but security even more, as stated, if possible have further things done, perhaps even checks within the library using other security related libraries.
Another thing to do would be scramble env vars if compromised. Using the other libraries and anything from the single native impl, if done like so.
Perhaps have optional integrations with other libraries for more security, including tradeoffs, if any. Rather than just including as dependencies since they can also be used for other things in an app, they should be optional and installed by the dev.
Research and understand all the points that can cause env vars to be compromised. Perhaps more counter-measures would be found in the process, to counter any sort of reverse engineering or at least make even more difficult. I would say that AI can help figure out other things on this, so should be used to understand, but if possible, find actual user proof, since AI are known to not be precise / true sometimes.
https://medium.com/@derya.cortuk/reverse-engineering-tools-fccc151f0a82 - This may help see how difficult based on the implementation. But optional, to someone who knows how.
Here are some perspectives from AI
https://oss.callstack.com/react-native-builder-bob/create - If only mobile native and js.
Not sure how viable it is, but I suppose Rust or C++ could be used for a single implementation and then spread to native and js.