Remove $FreeBSD$: one-line .c pattern

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

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 ...

libcrypt: Drop inclusion of libutil.h

This was rendered obsolete in 2012 by a0ee974f0bad, since auth_getval
was the only reason the header was included.

MFC after: 1 week

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 ...

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 ...

Change the hardcoded default back from SHA512 to DES.

PR: 192277
MFC after: 3 days

Don't break the legacy applications which set
just 2 bytes to salt.

MFC after: 1 week

r261913 broke DES passwords, because the only way they could work,
since they don't have an easily recognizable signature, was if they
were the default. This commit rewrites crypt_set_format(3) etc

r261913 broke DES passwords, because the only way they could work,
since they don't have an easily recognizable signature, was if they
were the default. This commit rewrites crypt_set_format(3) etc to
address this:

- Use a pointer instead of an index to identify the default format.
This pointer is initialized at compile time to point to the first
first element in the list of supported formats, eliminating the
need for crypt_setdefault(). Using a pointer also simplifies
iterating through the list.

- Associate DES with the magic string "_", which takes care of the
Extended DES format.

- Finally, as a special case, if the salt does not match any known
magic string but matches ^[./0-9A-Za-z]{13}$, it is assumed to be a
DES password and is passed on to crypt_des().

MFC after: 1 week

show more ...

Switch the hardcoded default hash function from MD5 / DES to SHA512.

Stop using auth_getval() now that it always returns NULL. Instead,
hardcode the default to what it would be if we didn't hardcode it,
i.e. DES if supported and MD5 otherwise.

MFC after: 3 weeks

s/shaN_crypt/crypt_shaN/g to be a more consistent with the existing naming.

Reviewed by: markm

Add SHA256/512 ($5$ and $6$) to crypt(3). Used in linux-world, doesn't
hurt us.

PR: misc/124164
Submitted by: KIMURA Yasuhiro < yasu utahime org >
MFC after: 1 month

Add a new hash type. This "NT-hash" is compatible with the password
hashing scheme used in Microsoft's NT machines. IT IS NOT SECURE!
DON'T USE IT! This is for the use of competent sysadmins only!

S

Add a new hash type. This "NT-hash" is compatible with the password
hashing scheme used in Microsoft's NT machines. IT IS NOT SECURE!
DON'T USE IT! This is for the use of competent sysadmins only!

Submitted by: Michael Bretterklieber

show more ...

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

Implement __FBSDID()

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

Add OpenBSD-style blowfish password hashing. This makes one less
gratuitous difference between us and our sister project.

This was given to me _ages_ ago. May apologies to Paul for the length
of tim

Add OpenBSD-style blowfish password hashing. This makes one less
gratuitous difference between us and our sister project.

This was given to me _ages_ ago. May apologies to Paul for the length
of time its taken me to commit.

Obtained from: Niels Provos <[email protected]>/OpenBSD
Submitted by: Paul Herman <[email protected]>

show more ...

Hindsight is wonderful, but I got cold feet over the crypt(3) default
so I am backing it out for now. The problem is that some random program
calling crypt() could be passing a DES salt and the cryp

Hindsight is wonderful, but I got cold feet over the crypt(3) default
so I am backing it out for now. The problem is that some random program
calling crypt() could be passing a DES salt and the crypt(3) library
would encrypt it in md5 mode and there would be a password mismatch as a
result. I wrote a validater function for the DES code to verify that
a salt is valid for DES, but I realized there were too many strange things
to go wrong. passwd(1), pw(8) etc still generate md5 passwords by default
for /etc/master.passwd, so this is almost academic. It is a big deal for
things that have their own crypt(3)-ed password strings (.htaccess,
etc etc). Those are the things I do not want to break.

My DES salt recognizer basically checked if the salt was either 2 or
13 characters long, or began with '_' (_PASSWORD_EFMT1). I think it
would have worked but I have seen way too much crypt() mishandling
in the past.

show more ...

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 ...

Still have to support libscrypt for now :( Add #defines to take DES
out for it.

Add working and easy crypt(3)-switching. Yes, we need a whole new API
for crypt(3) by now. In any case:

Add crypt_set_format(3) + documentation to -lcrypt.
Add login_setcryptfmt(3) + documentation

Add working and easy crypt(3)-switching. Yes, we need a whole new API
for crypt(3) by now. In any case:

Add crypt_set_format(3) + documentation to -lcrypt.
Add login_setcryptfmt(3) + documentation to -lutil.
Support for switching crypt formats in passwd(8).
Support for switching crypt formats in pw(8).

The simple synopsis is:
edit login.conf; add a passwd_format field set to "des" or "md5"; go nuts :)

Reviewed by: peter

show more ...

Zap SHA1 password support. This will be re-implemented at a later date.

Never return NULL, always return a hash.

Submitted by: dt

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

$Header$ -> $FreeBSD$