[Feature Request] react-native support

Open
  • Is something wrong?
#226 3 comments 1 reaction 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
15/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Quiet
Tech stack
cpp, javascript, kotlin, react-native, rust, swift, typescript
Domain
mobile, security

Research direction

Start by reading the project documentation and existing configuration or secret handling entry points to understand what Varlock currently supports. The issue proposes a broad React Native integration across JavaScript and native platforms, with security protections and optional integrations, but does not identify files or tests. First define a limited, testable scope with the maintainers; done criteria need agreement before implementation.

Written by the indexing model from the issue text.

Description

enhancement
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.

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.

Dominant language
TypeScript
Stars
4.9k
Forks
140
Avg merge
2d 3h
Merged PRs (30d)
35

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from dmno-dev/varlock

All issues in dmno-dev/varlock

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.