riscv/musl - musl - Gitea: Git with a cup of tea

1731 Commits

2 Branches

78 Tags

7.6 MiB

Tree: bc1a8d2ae3

Commit Graph

Author	SHA1	Message	Date
Rich Felker	cdf51506ce	replace old and ugly crypt implementation the new version is largely the work of Solar Designer, with minor changes for integration with musl. compared to the old code, text size is reduced by about 7k, stack space usage by about 70k, and performance is greatly improved by avoiding expensive calculation of constant tables on each run. this version also adds support for extended des-based password hashes, which allow for unlimited key (password) length and configurable iteration counts. i've also published the interface for crypt_r in a new crypt.h header. especially since this is not a standard interface, i did not feel compelled to match the glibc abi for the crypt_data structure. the glibc structure is way too big to allocate on the stack; in fact it's so big that the first usage may cause the main thread to exceed its pre-committed stack size of 128k and thus could cause the program to crash even on systems with overcommit disabled. the only legitimate use of crypt_data for crypt_r is to store the hash string to return, so i've reserved 256 bytes, which should be more than sufficient (longest known password hashes are ~60 characters, and beyond that is possibly even exceeding some implementations' passwd file field size limit).	14 years ago

Author

SHA1

Message

Date

Rich Felker

cdf51506ce

replace old and ugly crypt implementation

the new version is largely the work of Solar Designer, with minor
changes for integration with musl. compared to the old code, text size
is reduced by about 7k, stack space usage by about 70k, and
performance is greatly improved by avoiding expensive calculation of
constant tables on each run.

this version also adds support for extended des-based password hashes,
which allow for unlimited key (password) length and configurable
iteration counts.

i've also published the interface for crypt_r in a new crypt.h header.
especially since this is not a standard interface, i did not feel
compelled to match the glibc abi for the crypt_data structure. the
glibc structure is way too big to allocate on the stack; in fact it's
so big that the first usage may cause the main thread to exceed its
pre-committed stack size of 128k and thus could cause the program to
crash even on systems with overcommit disabled. the only legitimate
use of crypt_data for crypt_r is to store the hash string to return,
so i've reserved 256 bytes, which should be more than sufficient
(longest known password hashes are ~60 characters, and beyond that is
possibly even exceeding some implementations' passwd file field size
limit).

14 years ago

1 Commits (bc1a8d2ae3837a7303f14d381a4c37218f0c8fcb)