FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=releng%2F14.4 2023-08-16T17:54:42Z 2023-08-16T17:54:42Z Warner Losh imp@FreeBSD.org 2023-08-16T17:54:42Z urn:sha1:1d386b48a555f61cb7325543adbbb5c3f3407a66 Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/ 2023-05-12T16:44:03Z Warner Losh imp@FreeBSD.org 2023-05-10T15:40:58Z urn:sha1:4d846d260e2b9a3d4d0a701462568268cbfe7a5b 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 2021-12-07T00:24:19Z Jessica Clarke jrtc27@FreeBSD.org 2021-12-06T22:28:10Z urn:sha1:7d232d647e3583b495d431b12eaa9343bb29b271 This was rendered obsolete in 2012 by a0ee974f0bad, since auth_getval was the only reason the header was included. MFC after: 1 week 2017-11-26T02:00:33Z Pedro F. Giffuni pfg@FreeBSD.org 2017-11-26T02:00:33Z urn:sha1:5e53a4f90f82c4345f277dd87cc9292f26e04a29 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. 2016-08-10T15:16:28Z Ed Schouten ed@FreeBSD.org 2016-08-10T15:16:28Z urn:sha1:5f521d7ba72145092ea23ff6081d8791ad6c1f9d 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 2014-10-09T16:45:11Z Dag-Erling Smørgrav des@FreeBSD.org 2014-10-09T16:45:11Z urn:sha1:e4978d34f2125682d3cdb066668b2e26a50d0c61 PR: 192277 MFC after: 3 days 2014-05-28T16:50:18Z Hajimu UMEMOTO ume@FreeBSD.org 2014-05-28T16:50:18Z urn:sha1:0cb06892fa69b835eac75073f88b582e04799562 just 2 bytes to salt. MFC after: 1 week 2014-04-26T11:50:25Z Dag-Erling Smørgrav des@FreeBSD.org 2014-04-26T11:50:25Z urn:sha1:5280a314787806c5c19e63cfd8200b5c25b3fd77 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 2014-02-15T10:53:44Z Dag-Erling Smørgrav des@FreeBSD.org 2014-02-15T10:53:44Z urn:sha1:e401beb7235567d33e0c31582b4ed65dfd4a8feb 2012-06-12T17:14:19Z Dag-Erling Smørgrav des@FreeBSD.org 2012-06-12T17:14:19Z urn:sha1:a0ee974f0badd8a8fafb686be71a49094e2798f6 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