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

Use system memlock limit to set the secure memory pool size #32

Merged
merged 2 commits into from
Dec 26, 2017

Conversation

paolostivanin
Copy link
Owner

No description provided.

When using Gcrypt's secure memory, the amount of needed memory must be
greater than the current memlock OS limit (ulimit -l). On some systems,
this value is very low (64 KB), thus causing the software to not even
start up.
A few possibilities were evaluated:
1. use setcap on installation phase: easy, but not achievable with
flatpak, appimage, and Co.
2. force the user to play with ulimit: cumbersome and absolutely not
user-friendly
3. set the max available secure memory to the current system memlock
value
Option 3 is the one that got implemented with this commit. This has a
small drawback though because if a user needs to store more than ~130
tokens, each one using very long (128 chars) label and issuer and long
(64 chars) secret, the user won't be able to do that, unless he/she does
something with either setcap or ulimit.

- fix #31
- update readme
- show a warning when memlock limit is less than 256KB
@paolostivanin paolostivanin merged commit 20a2e05 into master Dec 26, 2017
@paolostivanin paolostivanin deleted the fix-mlock branch December 26, 2017 11:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant