Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pass private key? #133

Open
Psy-Kai opened this issue Oct 28, 2021 · 3 comments
Open

Pass private key? #133

Psy-Kai opened this issue Oct 28, 2021 · 3 comments

Comments

@Psy-Kai
Copy link

Psy-Kai commented Oct 28, 2021

Hello,

I would really like to use this library. But since the rsa key and library configuration is compiled into the library I have to create workarounds when packaging the library.

Would it be possible to change the library interface to pass the rsa key and configuration into the library?

I would contribute these changes if this proposal would be accepted :)

Thanks

@gcontini
Copy link
Member

gcontini commented Nov 7, 2021

Well just to be precise, the private key never leaves the key generator machine. What is compiled into the code is the public key. But ok...

That said i don't see why you would want to pass a key from outside, it looks to me complicating the software and adding security risks (the pointer is intercepted when you call the api, an attacker could replace the public key).

Please describe the feature you are implementing on your application (you want to verify multiple licenses? dynamic licenses?), let's see if what you request is useful.

@Psy-Kai
Copy link
Author

Psy-Kai commented Nov 8, 2021

Yeah, sorry, I meant the public key.

I just want to compile and distribute one single licensecc library (via a package manager like conan). With the current model this is just not possible.

One could compile and distribute a library for every key-pair. But just passing the public key feels like a more easy solution which also would simplify building (just) the library.

How would passing the public key to a static linked library be a security risk? One could also hook into the openssl calls since you also pass a pointer there.

I don't have a specific new feature in mind. I am just a fan of dependency injection and loose coupling. The currents library design with the pregenerated public key header violates these principles.

@gcontini
Copy link
Member

gcontini commented Nov 10, 2021

Well the original idea was that you have to compile and modify the library on your own before you use it, that's why the current model makes it impossible to deploy it on package managers. If you look closely there is an automated code generation step that in future may be extended. This is to prevent a "generic patch util" to be released via package manager too ;-)

But i agree with you, a distributed version of the library for the people that don't have extreme security needs is a nice to have. Contributions are welcome. If you implement it please make the new parameter in the api activable with a cmake flag.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants