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
Add m_hash_crypt module #246
Open
Elizafox
wants to merge
10
commits into
inspircd:master
Choose a base branch
from
Elizafox:hash-crypt
base: master
Could not load branches
Branch not found: {{ refName }}
Could not load tags
Nothing to show
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is a crypt(3)-based hash function for compatibility with Unix crypt and other IRC daemons that use it. This relies on the system crypt which may unfortunately be deficient, hence there are ugly ifdef's.
Turns out that you can't depend on pkg-config just picking up -lcrypt everywhere. It doesn't work on my Debian box for example.
genius3000
reviewed
Nov 28, 2020
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left a line comment about the names.
Basically, we know that linux, freebsd, and netbsd require -lcrypt. openbsd and darwin don't (and the build will fail on at least macos if we add that flag). So, add the known systems to the LinkerFlags and go on our merry way. The reason we can't use pkg-config is because libcrypt-dev is not widely available yet (Debian stale notably does not have it) and operating systems like FreeBSD are unlikely to really ever have it.
These are insecure and should not be generated. crypt-generic is introduced instead, for access to the system crypt directly. This shouldn't be used to generate passwords, but can be used for password checking.
I deliberately broke the macOS build because their crypt really sucks and it's not worth the trouble. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a crypt(3)-based hash module for compatibility with Unix crypt and other IRC daemons that use it. This relies on the system crypt which may unfortunately be deficient, hence there are ugly ifdef's.
At some point I plan on implementing shims for deficient systems, but this will do for now.
Note: I've tried to make this build on macOS, but it's a terrible idea to use this module there. macOS has a really bad crypt that doesn't support any modern hash functions. All it will support for now is DES, and needless to say this is not what you want most likely.