<feed xmlns='http://www.w3.org/2005/Atom'>
<title>src/lib/libcrypt/crypt-md5.c, branch main</title>
<subtitle>FreeBSD source tree</subtitle>
<id>http://cgit.freebsd.org/src/atom?h=main</id>
<link rel='self' href='http://cgit.freebsd.org/src/atom?h=main'/>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/'/>
<updated>2024-10-25T14:02:38Z</updated>
<entry>
<title>lib/libcrypt: use explicit_bzero() to clear sensitive buffers</title>
<updated>2024-10-25T14:02:38Z</updated>
<author>
<name>Robert Clausecker</name>
<email>fuz@FreeBSD.org</email>
</author>
<published>2024-10-10T09:08:35Z</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=a2c0d2026fb422ade2171da4bc6d5d2773b268a6'/>
<id>urn:sha1:a2c0d2026fb422ade2171da4bc6d5d2773b268a6</id>
<content type='text'>
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
</content>
</entry>
<entry>
<title>lib: Automated cleanup of cdefs and other formatting</title>
<updated>2023-11-27T05:23:59Z</updated>
<author>
<name>Warner Losh</name>
<email>imp@FreeBSD.org</email>
</author>
<published>2023-11-24T20:12:57Z</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=a2f733abcff64628b7771a47089628b7327a88bd'/>
<id>urn:sha1:a2f733abcff64628b7771a47089628b7327a88bd</id>
<content type='text'>
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+&lt;sys/cdefs.h&gt;.*\n/
Remove /\n+#include\s+&lt;sys/cdefs.h&gt;.*\n+#if.*\n#endif.*\n+/
Remove /\n+#if.*\n#endif.*\n+/
Remove /^#if.*\n#endif.*\n/
Remove /\n+#include\s+&lt;sys/cdefs.h&gt;\n#include\s+&lt;sys/types.h&gt;/
Remove /\n+#include\s+&lt;sys/cdefs.h&gt;\n#include\s+&lt;sys/param.h&gt;/
Remove /\n+#include\s+&lt;sys/cdefs.h&gt;\n#include\s+&lt;sys/capsicum.h&gt;/

Sponsored by:		Netflix
</content>
</entry>
<entry>
<title>Remove $FreeBSD$: one-line .c pattern</title>
<updated>2023-08-16T17:54:42Z</updated>
<author>
<name>Warner Losh</name>
<email>imp@FreeBSD.org</email>
</author>
<published>2023-08-16T17:54:42Z</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=1d386b48a555f61cb7325543adbbb5c3f3407a66'/>
<id>urn:sha1:1d386b48a555f61cb7325543adbbb5c3f3407a66</id>
<content type='text'>
Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
</content>
</entry>
<entry>
<title>spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD</title>
<updated>2023-05-12T16:44:03Z</updated>
<author>
<name>Warner Losh</name>
<email>imp@FreeBSD.org</email>
</author>
<published>2023-05-10T15:40:58Z</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=4d846d260e2b9a3d4d0a701462568268cbfe7a5b'/>
<id>urn:sha1:4d846d260e2b9a3d4d0a701462568268cbfe7a5b</id>
<content type='text'>
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
</content>
</entry>
<entry>
<title>lib: further adoption of SPDX licensing ID tags.</title>
<updated>2017-11-26T02:00:33Z</updated>
<author>
<name>Pedro F. Giffuni</name>
<email>pfg@FreeBSD.org</email>
</author>
<published>2017-11-26T02:00:33Z</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=5e53a4f90f82c4345f277dd87cc9292f26e04a29'/>
<id>urn:sha1:5e53a4f90f82c4345f277dd87cc9292f26e04a29</id>
<content type='text'>
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.
</content>
</entry>
<entry>
<title>Make libcrypt thread-safe. Add crypt_r(3).</title>
<updated>2016-08-10T15:16:28Z</updated>
<author>
<name>Ed Schouten</name>
<email>ed@FreeBSD.org</email>
</author>
<published>2016-08-10T15:16:28Z</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=5f521d7ba72145092ea23ff6081d8791ad6c1f9d'/>
<id>urn:sha1:5f521d7ba72145092ea23ff6081d8791ad6c1f9d</id>
<content type='text'>
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
</content>
</entry>
<entry>
<title>Tidy the code up a fraction. Re-release with a 2-clause BSD license</title>
<updated>2003-06-02T21:43:14Z</updated>
<author>
<name>Mark Murray</name>
<email>markm@FreeBSD.org</email>
</author>
<published>2003-06-02T21:43:14Z</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=d8e82636a47bdb528ce827b84b4fc33f99a79ad8'/>
<id>urn:sha1:d8e82636a47bdb528ce827b84b4fc33f99a79ad8</id>
<content type='text'>
with the kind permission of the author/copyright holder.

Thanks to:	phk
</content>
</entry>
<entry>
<title>Fix grammer in comment.</title>
<updated>2002-03-25T15:55:36Z</updated>
<author>
<name>Poul-Henning Kamp</name>
<email>phk@FreeBSD.org</email>
</author>
<published>2002-03-25T15:55:36Z</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=fe681e195526e3bae6ab4c2eaeac8d0f148b2e2d'/>
<id>urn:sha1:fe681e195526e3bae6ab4c2eaeac8d0f148b2e2d</id>
<content type='text'>
Submitted by:	Engin Gunduz &lt;engin@ripe.net&gt;
</content>
</entry>
<entry>
<title>Modernize my email-address.</title>
<updated>2002-03-25T13:48:53Z</updated>
<author>
<name>Poul-Henning Kamp</name>
<email>phk@FreeBSD.org</email>
</author>
<published>2002-03-25T13:48:53Z</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=adf75add2d3fb898c9c9c8abb7cedc609060170a'/>
<id>urn:sha1:adf75add2d3fb898c9c9c8abb7cedc609060170a</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Darn. There is (now was) a signed/unsigned issue that resulted in a</title>
<updated>2002-03-07T10:41:11Z</updated>
<author>
<name>Mark Murray</name>
<email>markm@FreeBSD.org</email>
</author>
<published>2002-03-07T10:41:11Z</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=bbf177c2a974ab490fad87961bb286b3ce660325'/>
<id>urn:sha1:bbf177c2a974ab490fad87961bb286b3ce660325</id>
<content type='text'>
very long loop.

Reported by:	nnd@mail.nsk.ru (Nickolay Dudorov)
</content>
</entry>
</feed>
