History log of /freebsd/lib/libcrypt/crypt-md5.c (Results 1 – 25 of 32)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# a2c0d202 10-Oct-2024 Robert Clausecker <fuz@FreeBSD.org>

lib/libcrypt: use explicit_bzero() to clear sensitive buffers

Prevent a potentially sufficiently smart compiler from optimising
away our attempts to clear sensitive buffers.

A related change was di

lib/libcrypt: use explicit_bzero() to clear sensitive buffers

Prevent a potentially sufficiently smart compiler from optimising
away our attempts to clear sensitive buffers.

A related change was discussed and rejected in D16059, but I don't
believe the reasoning there applies: the code clearly documents its
intent that the `memset` calls clear sensitive buffers so they don't
hang around. `explicit_bzero` is the appropriate function for this
purpose. A potential performance disadvantage seems less important:
the functions in crypt are specifically designed to be slow, so a
few extra calls to guarantee that sensitive buffers are cleared does
not significantly affect runtime.

See also: D16059
Reviewed by: delphij, kevans
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D47037

show more ...


Revision tags: release/13.4.0, release/14.1.0, release/13.3.0
# a2f733ab 24-Nov-2023 Warner Losh <imp@FreeBSD.org>

lib: Automated cleanup of cdefs and other formatting

Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.

Remov

lib: Automated cleanup of cdefs and other formatting

Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.

Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/
Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/
Remove /\n+#if.*\n#endif.*\n+/
Remove /^#if.*\n#endif.*\n/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/

Sponsored by: Netflix

show more ...


Revision tags: release/14.0.0
# 1d386b48 16-Aug-2023 Warner Losh <imp@FreeBSD.org>

Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/


# 4d846d26 10-May-2023 Warner Losh <imp@FreeBSD.org>

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.

Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix

show more ...


Revision tags: release/13.2.0, release/12.4.0, release/13.1.0, release/12.3.0, release/13.0.0, release/12.2.0, release/11.4.0, release/12.1.0, release/11.3.0, release/12.0.0, release/11.2.0
# 5e53a4f9 26-Nov-2017 Pedro F. Giffuni <pfg@FreeBSD.org>

lib: further adoption of SPDX licensing ID tags.

Mainly focus on files that use BSD 2-Clause license, however the tool I
was using mis-identified many licenses so this was mostly a manual - error
pr

lib: further adoption of SPDX licensing ID tags.

Mainly focus on files that use BSD 2-Clause license, however the tool I
was using mis-identified many licenses so this was mostly a manual - error
prone - task.

The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.

show more ...


Revision tags: release/10.4.0, release/11.1.0, release/11.0.1, release/11.0.0
# 27067774 16-Aug-2016 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r303250 through r304235.


# 569e9018 13-Aug-2016 Enji Cooper <ngie@FreeBSD.org>

MFhead @ r304038


# 5f521d7b 10-Aug-2016 Ed Schouten <ed@FreeBSD.org>

Make libcrypt thread-safe. Add crypt_r(3).

glibc has a pretty nice function called crypt_r(3), which is nothing
more than crypt(3), but thread-safe. It accomplishes this by introducing
a 'struct cry

Make libcrypt thread-safe. Add crypt_r(3).

glibc has a pretty nice function called crypt_r(3), which is nothing
more than crypt(3), but thread-safe. It accomplishes this by introducing
a 'struct crypt_data' structure that contains a buffer that is large
enough to hold the resulting string.

Let's go ahead and also add this function. It would be a shame if a
useful function like this wouldn't be usable in multithreaded apps.
Refactor crypt.c and all of the backends to no longer declare static
arrays, but write their output in a provided buffer.

There is no need to do any buffer length computation here, as we'll just
need to ensure that 'struct crypt_data' is large enough, which it is.
_PASSWORD_LEN is defined to 128 bytes, but in this case I'm picking 256,
as this is going to be part of the actual ABI.

Differential Revision: https://reviews.freebsd.org/D7306

show more ...


Revision tags: release/10.3.0, release/10.2.0, release/10.1.0, release/9.3.0, release/10.0.0, release/9.2.0, release/8.4.0, release/9.1.0, release/8.3.0_cvs, release/8.3.0, release/9.0.0, release/7.4.0_cvs, release/8.2.0_cvs, release/7.4.0, release/8.2.0, release/8.1.0_cvs, release/8.1.0, release/7.3.0_cvs, release/7.3.0, release/8.0.0_cvs, release/8.0.0, release/7.2.0_cvs, release/7.2.0, release/7.1.0_cvs, release/7.1.0, release/6.4.0_cvs, release/6.4.0, release/7.0.0_cvs, release/7.0.0, release/6.3.0_cvs, release/6.3.0, release/6.2.0_cvs, release/6.2.0, release/5.5.0_cvs, release/5.5.0, release/6.1.0_cvs, release/6.1.0, release/6.0.0_cvs, release/6.0.0, release/5.4.0_cvs, release/5.4.0, release/4.11.0_cvs, release/4.11.0, release/5.3.0_cvs, release/5.3.0, release/4.10.0_cvs, release/4.10.0, release/5.2.1_cvs, release/5.2.1, release/5.2.0_cvs, release/5.2.0, release/4.9.0_cvs, release/4.9.0, release/5.1.0_cvs, release/5.1.0
# d8e82636 02-Jun-2003 Mark Murray <markm@FreeBSD.org>

Tidy the code up a fraction. Re-release with a 2-clause BSD license
with the kind permission of the author/copyright holder.

Thanks to: phk


Revision tags: release/4.8.0_cvs, release/4.8.0, release/5.0.0_cvs, release/5.0.0, release/4.7.0_cvs, release/4.6.2_cvs, release/4.6.2, release/4.6.1, release/4.6.0_cvs
# fe681e19 25-Mar-2002 Poul-Henning Kamp <phk@FreeBSD.org>

Fix grammer in comment.

Submitted by: Engin Gunduz <engin@ripe.net>


# adf75add 25-Mar-2002 Poul-Henning Kamp <phk@FreeBSD.org>

Modernize my email-address.


# bbf177c2 07-Mar-2002 Mark Murray <markm@FreeBSD.org>

Darn. There is (now was) a signed/unsigned issue that resulted in a
very long loop.

Reported by: nnd@mail.nsk.ru (Nickolay Dudorov)


# f2ac424a 06-Mar-2002 Mark Murray <markm@FreeBSD.org>

No functional change, but big code cleanup. WARNS, lint(1) and style(9).


Revision tags: release/4.5.0_cvs, release/4.4.0_cvs
# e67f5b9f 16-Sep-2001 Matthew Dillon <dillon@FreeBSD.org>

Implement __FBSDID()


# 8af1452c 13-Aug-2001 Ruslan Ermilov <ru@FreeBSD.org>

Removed duplicate VCS ID tags, as per style(9).


Revision tags: release/4.3.0_cvs, release/4.3.0
# 9886bcdf 28-Dec-2000 Peter Wemm <peter@FreeBSD.org>

Merge into a single US-exportable libcrypt, which only provides
one-way hash functions for authentication purposes. There is no more
"set the libcrypt->libXXXcrypt" nightmare.
- Undo the libmd.so ha

Merge into a single US-exportable libcrypt, which only provides
one-way hash functions for authentication purposes. There is no more
"set the libcrypt->libXXXcrypt" nightmare.
- Undo the libmd.so hack, use -D to hide the md5c.c internals.
- Remove the symlink hacks in release/Makefile
- the algorthm is set by set_crypt_format() as before. If this is
not called, it tries to heuristically figure out the hash format, and
if all else fails, it uses the optional auth.conf entry to chose the
overall default hash.
- Since source has non-hidden crypto in it there may be some issues with
having the source it in some countries, so preserve the "secure/*"
division. You can still build a des-free libcrypt library if you want
to badly enough. This should not be a problem in the US or exporting
from the US as freebsd.org had notified BXA some time ago. That makes
this stuff re-exportable by anyone.
- For consistancy, the default in absence of any other clues is md5. This
is to try and minimize POLA across buildworld where folk may suddenly
be activating des-crypt()-hash support. Since the des hash may not
always be present, it seemed sensible to make the stronger md5 algorithm
the default.
All things being equal, no functionality is lost.

Reviewed-by: jkh

(flame-proof suit on)

show more ...


Revision tags: release/4.2.0, release/4.1.1_cvs, release/4.1.0, release/3.5.0_cvs, release/4.0.0_cvs, release/3.4.0_cvs
# e67c7c99 17-Dec-1999 Peter Wemm <peter@FreeBSD.org>

Make a dlopen failure consistant with dlsym(). "Shouldn't happen."


# 1f4aad4d 17-Dec-1999 Peter Wemm <peter@FreeBSD.org>

Remove -lmd. Use dlopen() and dlsym() instead for calls to the MD5* and
SHA* routines so that callers of libcrypt are not exposed to the internal
implementation.


# e9a56ad5 20-Sep-1999 Mark Murray <markm@FreeBSD.org>

Big code cleanup. (Inspired by Brandon Gillespie). Also move as
much as possible away from secure/ to make extending easier.


Revision tags: release/3.3.0_cvs, release/3.2.0, release/3.1.0
# da5c7089 21-Jan-1999 Brandon Gillespie <brandon@FreeBSD.org>

Rewrite of crypt library to be more modular, and addition of the
Secure Hashing Algorithm - 1 (SHA-1), along with the further
refinement of what $x$salt$hash means. With this new crypt the
following

Rewrite of crypt library to be more modular, and addition of the
Secure Hashing Algorithm - 1 (SHA-1), along with the further
refinement of what $x$salt$hash means. With this new crypt the
following are all acceptable:

$1$
$MD5$
$SHA1$

Note: $2$ is used by OpenBSD's Blowfish, which I considered adding
as $BF$, but there is no actual need for it with SHA-1. However,
somebody wishing to add OpenBSD password support could easilly add
it in now.

There is also a malloc_crypt() available in the library now, which
behaves exactly the same as crypt(), but it uses a malloced buffer
instead of a static buffer. However, this is not standard so will
likely not be used much (at all).

Also, for those interested I did a brief speed test Pentium 166/MMX,
which shows the DES crypt to do approximately 2640 crypts a CPU second,
MD5 to do about 62 crypts a CPU second and SHA1 to do about 18 crypts
a CPU second.

Reviewed by: Mark Murray

show more ...


Revision tags: release/10.3.0, release/10.2.0, release/10.1.0, release/9.3.0, release/10.0.0, release/9.2.0, release/8.4.0, release/9.1.0, release/8.3.0_cvs, release/8.3.0, release/9.0.0, release/7.4.0_cvs, release/8.2.0_cvs, release/7.4.0, release/8.2.0, release/8.1.0_cvs, release/8.1.0, release/7.3.0_cvs, release/7.3.0, release/8.0.0_cvs, release/8.0.0, release/7.2.0_cvs, release/7.2.0, release/7.1.0_cvs, release/7.1.0, release/6.4.0_cvs, release/6.4.0, release/7.0.0_cvs, release/7.0.0, release/6.3.0_cvs, release/6.3.0, release/6.2.0_cvs, release/6.2.0, release/5.5.0_cvs, release/5.5.0, release/6.1.0_cvs, release/6.1.0, release/6.0.0_cvs, release/6.0.0, release/5.4.0_cvs, release/5.4.0, release/4.11.0_cvs, release/4.11.0, release/5.3.0_cvs, release/5.3.0, release/4.10.0_cvs, release/4.10.0, release/5.2.1_cvs, release/5.2.1, release/5.2.0_cvs, release/5.2.0, release/4.9.0_cvs, release/4.9.0, release/5.1.0_cvs, release/5.1.0
# d8e82636 02-Jun-2003 Mark Murray <markm@FreeBSD.org>

Tidy the code up a fraction. Re-release with a 2-clause BSD license
with the kind permission of the author/copyright holder.

Thanks to: phk


Revision tags: release/4.8.0_cvs, release/4.8.0, release/5.0.0_cvs, release/5.0.0, release/4.7.0_cvs, release/4.6.2_cvs, release/4.6.2, release/4.6.1, release/4.6.0_cvs
# fe681e19 25-Mar-2002 Poul-Henning Kamp <phk@FreeBSD.org>

Fix grammer in comment.

Submitted by: Engin Gunduz <engin@ripe.net>


# adf75add 25-Mar-2002 Poul-Henning Kamp <phk@FreeBSD.org>

Modernize my email-address.


# bbf177c2 07-Mar-2002 Mark Murray <markm@FreeBSD.org>

Darn. There is (now was) a signed/unsigned issue that resulted in a
very long loop.

Reported by: nnd@mail.nsk.ru (Nickolay Dudorov)


# f2ac424a 06-Mar-2002 Mark Murray <markm@FreeBSD.org>

No functional change, but big code cleanup. WARNS, lint(1) and style(9).


12