libxcrypt: fork from https://github.com/besser82/libxcrypt

代码拉取完成,页面将自动刷新

richgiteeai

Watch

不关注关注所有动态仅关注版本发行动态关注但不提醒动态

1 Star 0 Fork 0

SourceCodeSync/libxcrypt

代码 Issues 0 Pull Requests 0 Wiki 统计流水线

服务

加入 Gitee

与超过 1400万开发者一起发现、参与优秀开源项目,私有仓库也完全免费 :)

免费加入

已有帐号? 立即登录

克隆/下载

HTTPS SSH SVN SVN+SSH 下载ZIP

提示

下载代码请复制以下命令到终端执行

为确保你提交的代码身份被 Gitee 正确识别,请执行以下命令完成配置

git config --global user.name userName 
git config --global user.email userEmail

初次使用 SSH 协议进行代码克隆、推送等操作时,需按下述提示完成 SSH 配置

1 生成 RSA 密钥

2 获取 RSA 公钥内容,并配置到 SSH公钥中

在 Gitee 上使用 SVN,请访问使用指南

使用 HTTPS 协议时,命令行会出现如下账号密码验证步骤。基于安全考虑,Gitee 建议配置并使用私人令牌替代登录密码进行克隆、推送等操作

Username for 'https://gitee.com': userName

Password for 'https://userName@gitee.com': # 私人令牌

新建文件新建 Diagram 文件

新建子模块

上传文件

分支 20

标签 55

贡献代码

同步代码

创建 Pull Request

了解更多

对比差异通过 Pull Request 同步

同步更新到分支

通过 Pull Request 同步

将会在向当前分支创建一个 Pull
Request,合入后将完成同步

Björn Esser Update NEWS. 55ea777

813 次提交

.github/workflows

build-aux

doc

lib

test

.gitignore

.packit.yaml

.perlcriticrc

.perltidyrc

AUTHORS

COPYING.LIB

ChangeLog

LICENSING

Makefile.am

NEWS

README

README.md

THANKS

TODO

TODO.md

autogen.sh

codecov.yml

configure.ac

libxcrypt.spec.rpkg

rpkg.conf

rpkg.macros

README

LGPL-2.1

[![Build matrix](https://github.com/besser82/libxcrypt/actions/workflows/config-matrix.yml/badge.svg)](https://github.com/besser82/libxcrypt/actions/workflows/config-matrix.yml)
[![Memcheck](https://github.com/besser82/libxcrypt/actions/workflows/memcheck.yml/badge.svg)](https://github.com/besser82/libxcrypt/actions/workflows/memcheck.yml)
[![Distcheck](https://github.com/besser82/libxcrypt/actions/workflows/distcheck.yml/badge.svg)](https://github.com/besser82/libxcrypt/actions/workflows/distcheck.yml)
[![COPR Build Status](https://copr.fedorainfracloud.org/coprs/besser82/libxcrypt_CI/package/libxcrypt/status_image/last_build.png)](https://copr.fedorainfracloud.org/coprs/besser82/libxcrypt_CI)
[![codecov](https://codecov.io/gh/besser82/libxcrypt/branch/develop/graph/badge.svg)](https://codecov.io/gh/besser82/libxcrypt)
[![Coverity Scan Build Status](https://scan.coverity.com/projects/17073/badge.svg)](https://scan.coverity.com/projects/besser82-libxcrypt)
[![Codacy Badge](https://api.codacy.com/project/badge/Grade/1ebaa2314aca4bab92e14130906d5096)](https://www.codacy.com/manual/besser82/libxcrypt?utm_source=github.com&amp;utm_medium=referral&amp;utm_content=besser82/libxcrypt&amp;utm_campaign=Badge_Grade)

README for libxcrypt
====================

libxcrypt is a modern library for one-way hashing of passwords. It
supports a wide variety of both modern and historical hashing methods:
yescrypt, gost-yescrypt, scrypt, bcrypt, sha512crypt, sha256crypt,
md5crypt, SunMD5, sha1crypt, NT, bsdicrypt, bigcrypt, and descrypt.
It provides the traditional Unix `crypt` and `crypt_r` interfaces, as
well as a set of extended interfaces pioneered by Openwall Linux,
`crypt_rn`, `crypt_ra`, `crypt_gensalt`, `crypt_gensalt_rn`, and
`crypt_gensalt_ra`.

libxcrypt is intended to be used by `login(1)`, `passwd(1)`, and other
similar programs; that is, to hash a small number of passwords during
an interactive authentication dialogue with a human. It is not
suitable for use in bulk password-cracking applications, or in any
other situation where speed is more important than careful handling of
sensitive data. However, it *is* intended to be fast and lightweight
enough for use in servers that must field thousands of login attempts
per minute.

Authorship and Licensing
------------------------

libxcrypt is currently maintained by Björn Esser and Zack Weinberg.
Many people have contributed to the code making up libxcrypt, often
under the aegis of a different project. Please see the AUTHORS and
THANKS files for a full set of credits.

libxcrypt as a whole is licensed under the GNU Lesser General Public
License (version 2.1, or at your option, any later version). However,
many individual files may be reused under more permissive licenses if
separated from the library. Please see the LICENSING file for a
comprehensive inventory of licenses, and COPYING.LIB for the terms of
the LGPL.

Bug Reports, Feature Requests, Contributions, Etc.
--------------------------------------------------

libxcrypt is currently maintained at Github: the canonical repository
URL is <https://github.com/besser82/libxcrypt>. Please file bug
reports at <https://github.com/besser82/libxcrypt/issues>. This is
also the appropriate place to suggest new features, offer patches,
etc. All your feedback is welcome and will eventually receive a
response, but this is a spare-time project for all of the present
maintainers, so please be patient.

Build Requirements and Instructions
-----------------------------------

To build from a tarball release, the tools required are the standard
Unix shell environment, a C compiler, and Perl (version 5.14 or
later). Follow the generic build and installation instructions in the
file `INSTALL`. There are several package-specific configure options;
run `./configure --help` for more detail on these options.
Run `man -l crypt.5` for more detail on the hashing algorithms that
can be enabled or disabled by `--enable-hashes`. You can do both of
these things before building the software.

Building from a Git checkout additionally requires the Autotools
suite: `autoconf`, `automake`, `libtool`, and `pkg-config`.
Run `./autogen.sh` at the top level of the source tree, and then
follow the instructions in `INSTALL` (which is created by that command).

The oldest versions of Autotools components that are known to work
are: autoconf 2.69, automake 1.14, libtool 2.4.6, pkg-config 0.29.
If you test with an older version of one of these and find that it
works, please let us know. We are not deliberately requiring newer
versions; we just can’t conveniently test older versions ourselves.

Portability Notes
-----------------

libxcrypt should be buildable with any ISO C1999-compliant C compiler,
with one critical exception: the symbol versioning macros in
`crypt-port.h` only work with compilers that implement certain GCC and
GNU Binutils extensions (`__attribute__((alias))`, GCC-style `asm`,
and `.symver`).

A few C2011 features are used; the intention is not to use any of them
without a fallback, but we do not currently test this. A few POSIX
and nonstandard-but-widespread Unix APIs are also used; again, the
intention is not to use any of them without a fallback, but we do not
currently test this. In particular, the crypt_gensalt functions may
not always be able to retrieve cryptographically-sound random numbers
from the operating system; if you call these functions with a null
pointer for the "rbytes" argument, be prepared for them to fail.

As of mid-2018, GCC and LLVM don’t support link-time optimization of
libraries that use symbol versioning. If you build libxcrypt with
either of these compilers, do not use `-flto`. See [GCC bug 48200][1]
for specifics; the problem is very similar for LLVM. Because this is,
at its root, a set of missing compiler features, we expect link-time
optimization won’t work in other C compilers either, but we haven’t
tested it ourselves.

[1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200

Compatibility Notes
-------------------

On Linux-based systems, by default libxcrypt will be binary backward
compatible with the libcrypt.so.1 shipped as part of the GNU C
Library. This means that all existing binary executables linked
against glibc’s libcrypt should work unmodified with this library’s
libcrypt.so.1. We have taken pains to provide exactly the same symbol
versions as were used by glibc on various CPU architectures, and to
account for the variety of ways in which the Openwall extensions were
patched into glibc’s libcrypt by some Linux distributions. (For
instance, compatibility symlinks for SUSE’s "libowcrypt" are provided.)

However, the converse is not true: programs linked against libxcrypt
will not work with glibc’s libcrypt. Also, programs that use certain
legacy APIs supplied by glibc’s libcrypt (`encrypt`, `encrypt_r`,
`setkey`, `setkey_r`, and `fcrypt`) cannot be *compiled* against
libxcrypt.

Binary backward compatibility can be disabled by supplying the
`--disable-obsolete-api` switch to `configure`, in which case libxcrypt
will install libcrypt.so.2 instead of libcrypt.so.1. This
configuration is always used on all operating systems other than
Linux. We are willing to consider adding binary backward
compatibility for other operating systems’ existing libcrypts, but we
don’t currently plan to do that work ourselves.

Individual hash functions may be enabled or disabled by use of the
`--enable-hashes` switch to `configure`. The default is to enable all
supported hashes. Disabling the traditional ‘des’ hash algorithm
implies `--disable-obsolete-api`. Security-conscious environments
without backward compatibility constraints are encouraged to use
`--enable-hashes=strong`, which enables only the hash functions that
are strong enough to be safe for newly hashed passwords.

The original implementation of the SunMD5 hashing algorithm has a bug,
which is mimicked by libxcrypt to be fully compatible with hashes
generated on (Open)Solaris. According to the only existing
[documentation of this algorithm][2], its hashes were supposed to have
the format `$md5[,rounds=%u]$<salt>$<checksum>`, and include only the
bare string `$md5[,rounds=%u]$<salt>` in the salt digest
step. However, almost all hashes encountered in production
environments have the format `$md5[,rounds=%u]$<salt>$$<checksum>`
(note the double $$). Unfortunately, it is not merely a cosmetic
difference: hashes of this format incorporate the first $ after the
salt within the salt digest step, so the resulting checksum is
different. The documentation hints that this stems from a bug within
the production implementation’s parser. This bug causes the
implementation to return `$$`-format hashes when passed a
configuration string that ends with `$`. It returns the intended
original format and checksum only if there is at least one letter
after the `$`, e.g. `$md5[,rounds=%u]$<salt>$x`.

The NT algorithm, in its original implementation, never came with any
`gensalt` function, because the algorithm does not use any. libxcrypt
ships a bogus `gensalt` function for the NT algorithm, which simply
returns `3ドル$`.

glibc’s libcrypt could optionally be configured to use Mozilla’s NSS
library’s implementations of the cryptographic primitives md5crypt,
sha256crypt, and sha512crypt. This option is not available in
libxcrypt, because we do not currently believe it is a desirable
option. The stated rationale for the option was to source all
cryptographic primitives from a library that has undergone FIPS
certification, but we believe FIPS certification would need to cover
all of libxcrypt itself to have any meaningful value. Moreover, the
strongest hashing methods, yescrypt and bcrypt, use cryptographic
primitives that are not available from NSS, so the certification
would not cover any part of what will hopefully be the most used code
paths.

[2]: https://dropsafe.crypticide.com/article/1389