Revision tags: release/13.4.0, release/14.1.0, release/13.3.0, release/14.0.0, release/13.2.0, release/12.4.0, release/13.1.0 |
|
#
e7a629c8 |
| 08-Mar-2022 |
Kyle Evans <kevans@FreeBSD.org> |
libmd, kern, stand: consolidate md5 implementations (NFC)
Reduce the number of md5c.c between the three of these from two to one by just reaching into the kernel build for both userland builds. The
libmd, kern, stand: consolidate md5 implementations (NFC)
Reduce the number of md5c.c between the three of these from two to one by just reaching into the kernel build for both userland builds. The precedent for this already exists for sha2 in both cases.
_libmd_ symbol privatization bits have been moved to sys/md5.h and md5.h remains to #include <sys/md5.h> for compatibility.
This stops exporting MD5Pad() in the process because the kernel stopped exporting it in 502a35d60f4c. soversion is bumped accordingly.
This also renames the libc version of stack_protector.c; it previously only worked by coincidence because .PATH ordering worked out such that we got the right one, but this is not the case anymore. Remove the landmine.
PR: 280784 (exp-run) Reviewed by: allanjude, delphij Differential Revision: https://reviews.freebsd.org/D34497
show more ...
|
#
0c47b9c2 |
| 16-Jul-2024 |
Kyle Evans <kevans@FreeBSD.org> |
include: ssp: don't shadow the mempcpy builtin
GCC emits a warning about shadowing a builtin with our mempcpy declaration, so switch it to using the same model as memcpy() and use the apparently-exi
include: ssp: don't shadow the mempcpy builtin
GCC emits a warning about shadowing a builtin with our mempcpy declaration, so switch it to using the same model as memcpy() and use the apparently-existing __builtin___mempcpy_chk().
Reviewed by: kib (earlier version), markj Sponsored by: Klara, Inc. Sponsored by: Stormshield Differential Revision: https://reviews.freebsd.org/D45976
show more ...
|
#
cf8e5289 |
| 13-Jul-2024 |
Kyle Evans <kevans@FreeBSD.org> |
include: ssp: round out fortification of current set of headers
ssp/ssp.h needed some improvements: - `len` isn't always a size_t, it may need casted - In some cases we may want to use a len that
include: ssp: round out fortification of current set of headers
ssp/ssp.h needed some improvements: - `len` isn't always a size_t, it may need casted - In some cases we may want to use a len that isn't specified as a parameter (e.g., L_ctermid), so __ssp_redirect() should be more flexible. - In other cases we may want additional checking, so pull all of the declaration bits out of __ssp_redirect_raw() so that some functions can implement the body themselves.
strlcat/strlcpy should be the last of the fortified functions that get their own __*_chk symbols, and these cases are only done to be consistent with the rest of the str*() set.
Reviewed by: markj Sponsored by: Klara, Inc. Sponsored by: Stormshield Differential Revision: https://reviews.freebsd.org/D45679
show more ...
|
#
8b068264 |
| 13-May-2024 |
Kyle Evans <kevans@FreeBSD.org> |
Fix the GCC build after _FORTIFY_SOURCE import
We haven't exposed gets(3) in a long time, rip out __gets_chk before it's too late and something builds a gets(3) user with it enabled.
|
#
be04fec4 |
| 13-May-2024 |
Kyle Evans <kevans@FreeBSD.org> |
Import _FORTIFY_SOURCE implementation from NetBSD
This is a mostly-unmodified copy of the various *_chk implementations and headers from NetBSD, without yet modifying system headers to start actuall
Import _FORTIFY_SOURCE implementation from NetBSD
This is a mostly-unmodified copy of the various *_chk implementations and headers from NetBSD, without yet modifying system headers to start actually including them. A future commit will also apply the needed bits to fix ssp/unistd.h.
Reviewed by: imp, pauamma_gundo.com (both previous versions), kib Sponsored by: Stormshield Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D32306
show more ...
|
#
d0b2dbfa |
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
Remove $FreeBSD$: one-line sh pattern
Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/
|
Revision tags: release/12.3.0, release/13.0.0, release/12.2.0, release/11.4.0 |
|
#
371f3da6 |
| 01-May-2020 |
John Baldwin <jhb@FreeBSD.org> |
Remove the SYMVER build option.
This option was added as a transition aide when symbol versioning was first added. It was enabled by default in 2007 and is supported even by the old GPLv2 binutils.
Remove the SYMVER build option.
This option was added as a transition aide when symbol versioning was first added. It was enabled by default in 2007 and is supported even by the old GPLv2 binutils. Trying to disable it currently fails to build in libc and at this point it isn't worth fixing the build.
Reported by: Michael Dexter Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D24637
show more ...
|
Revision tags: release/12.1.0, release/11.3.0, release/12.0.0, release/11.2.0, release/10.4.0, release/11.1.0, release/11.0.1, release/11.0.0 |
|
#
d6084013 |
| 05-Apr-2016 |
Glen Barber <gjb@FreeBSD.org> |
MFH
Sponsored by: The FreeBSD Foundation
|
Revision tags: release/10.3.0 |
|
#
c38dac68 |
| 15-Mar-2016 |
Ed Maste <emaste@FreeBSD.org> |
libc: don't build compat functions if building WITHOUT_SYMVER
WITHOUT_SYMVER necessarily implies building a system without symver backwards compatability.
Sponsored by: The FreeBSD Foundation
|
#
11d38a57 |
| 28-Oct-2015 |
Baptiste Daroussin <bapt@FreeBSD.org> |
Merge from head
Sponsored by: Gandi.net
|
#
f94594b3 |
| 12-Sep-2015 |
Baptiste Daroussin <bapt@FreeBSD.org> |
Finish merging from head, messed up in previous attempt
|
#
00176600 |
| 09-Sep-2015 |
Navdeep Parhar <np@FreeBSD.org> |
Merge r286744-r287584 from head.
|
#
23a32822 |
| 25-Aug-2015 |
Baptiste Daroussin <bapt@FreeBSD.org> |
Merge from HEAD
|
#
6fdf637e |
| 17-Aug-2015 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r286697 through r286857.
|
#
fe0d386c |
| 14-Aug-2015 |
Pedro F. Giffuni <pfg@FreeBSD.org> |
Move the stack protector to a new "secure" directory
As part of the code refactoring to support FORTIFY_SOURCE we want a new subdirectory "secure" to keep the files related to security. Move the sta
Move the stack protector to a new "secure" directory
As part of the code refactoring to support FORTIFY_SOURCE we want a new subdirectory "secure" to keep the files related to security. Move the stack protector functions to this new directory.
No functional change.
Differential Review: https://reviews.freebsd.org/D3333
show more ...
|