NetBSD/external
christos 74cc861970 https://www.phoronix.com/news/IWD-WPA-WiFi-Auth-Vulns
https://www.top10vpn.com/research/wifi-vulnerabilities/

PEAP client: Update Phase 2 authentication requirements

The previous PEAP client behavior allowed the server to skip Phase 2
authentication with the expectation that the server was authenticated
during Phase 1 through TLS server certificate validation. Various PEAP
specifications are not exactly clear on what the behavior on this front
is supposed to be and as such, this ended up being more flexible than
the TTLS/FAST/TEAP cases. However, this is not really ideal when
unfortunately common misconfiguration of PEAP is used in deployed
devices where the server trust root (ca_cert) is not configured or the
user has an easy option for allowing this validation step to be skipped.

Change the default PEAP client behavior to be to require Phase 2
authentication to be successfully completed for cases where TLS session
resumption is not used and the client certificate has not been
configured. Those two exceptions are the main cases where a deployed
authentication server might skip Phase 2 and as such, where a more
strict default behavior could result in undesired interoperability
issues. Requiring Phase 2 authentication will end up disabling TLS
session resumption automatically to avoid interoperability issues.

Allow Phase 2 authentication behavior to be configured with a new phase1
configuration parameter option:
'phase2_auth' option can be used to control Phase 2 (i.e., within TLS
tunnel) behavior for PEAP:
 * 0 = do not require Phase 2 authentication
 * 1 = require Phase 2 authentication when client certificate
   (private_key/client_cert) is no used and TLS session resumption was
   not used (default)
 * 2 = require Phase 2 authentication in all cases
2024-02-13 18:43:45 +00:00
..
amdgpu-firmware
apache2 mDNSPlatformInit(): If we fail to create an IPv6 socket, ignore the 2023-12-13 07:15:40 +00:00
atheros
broadcom risc-v: Add bwfm(4) firmware files to release image 2024-01-20 08:09:13 +00:00
bsd https://www.phoronix.com/news/IWD-WPA-WiFi-Auth-Vulns 2024-02-13 18:43:45 +00:00
cddl dtrace: add support for SMAP 2023-11-03 09:07:56 +00:00
gpl2 mention if we are prunning. 2024-02-04 21:42:24 +00:00
gpl3 also link in libiberty's unlink-if-ordinary.c. 2023-12-31 22:52:49 +00:00
historical
ibm-public Install postfix-tls-script (for "postfix tls") 2024-01-01 18:56:53 +00:00
intel-fw-eula
intel-fw-public
lgpl3 add turbosparc to the list of known sparc machines. 2024-02-07 07:12:17 +00:00
mit Revert previous (stop building static libfb.a module for Xorg 1.10). 2024-01-27 10:57:04 +00:00
mpl make things compile again. 2024-02-13 15:34:22 +00:00
nvidia-firmware Import nvidia firmware from linux-firmware repository at commit: 2023-11-28 15:01:52 +00:00
ofl
public-domain Complete tzdata2024a update (using tzdata2024agtz) by fixing files that 2024-02-05 21:52:38 +00:00
realtek
zlib/pigz
Makefile
README add missing 2023-08-15 22:02:36 +00:00

README

$NetBSD: README,v 1.19 2023/08/15 22:02:36 christos Exp $

Organization of Sources:

This directory hierarchy is using an organization that separates
source for programs that we have obtained from external third
parties (where NetBSD is not the primary maintainer) from the
system source.

The hierarchy is grouped by license, and then package per license,
and is organized as follows:

	external/

	    Makefile
			Descend into the license sub-directories.

	    <license>/
			Per-license sub-directories.

		Makefile
			Descend into the package sub-directories.

		<package>/
			Per-package sub-directories.

		    Makefile
			Build the package.

		    dist/
			The third-party source for a given package.

		    bin/
		    lib/
		    sbin/
			BSD makefiles "reach over" from these into
			"../dist/".

This arrangement allows for packages to be easily disabled or
excised as necessary, either on a per-license or per-package basis.

The licenses currently used are:

	apache2		Apache 2.0 license.
			http://www.opensource.org/licenses/apache2.0.php

	atheros		Atheros License.

	broadcom	Broadcom licenses for rpi firmware and bfwm. See
			*/dist/LICENSE.broadcom*

	bsd		BSD (or equivalent) licensed software, possibly with
			the "advertising clause".
			http://www.opensource.org/licenses/bsd-license.php

	cddl		Common Development and Distribution License (the sun
			license which is based on the Mozilla Public License
			version 1.1).
			http://www.opensource.org/licenses/cddl1.php

	gpl2		GNU Public License, version 2 (or earlier).
			http://www.opensource.org/licenses/gpl-2.0.php

	gpl3		GNU Public License, version 3.
			http://www.opensource.org/licenses/gpl-3.0.html

	historical	Lucent's old license:
			http://www.opensource.org/licenses/historical.php

	ibm-public	IBM's public license:
			http://www.opensource.org/licenses/ibmpl.php

	intel-fw-eula	Intel firmware license with redistribution
			restricted to OEM.

	intel-fw-public	Intel firmware license permitting redistribution with
			terms similar to BSD licensed software.

	intel-public	Intel license permitting redistribution with
			terms similar to BSD licensed software.

	lgpl2		GNU Lesser General Public License, version 2 (or earlier).
			https://opensource.org/license/lgpl-2-1/

	lgpl3		GNU Lesser General Public License, version 3 (or earlier).
			https://opensource.org/license/lgpl-3-0/

	mit		MIT (X11) style license.
			http://www.opensource.org/licenses/mit-license.php

	mpl		Mozilla Public license.
			https://opensource.org/licenses/MPL-2.0

	nvidia-firmware	NVIDIA firmware license permitting redistribution for
			use on operating systems distributed under the terms
			of an OSI-approved open source license.

	ofl		SIL Open Font License
			https://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=OFL

	public-domain	Non-license for code that has been explicitly put
			into the Public Domain.

	realtek		RealTek license.

	zlib		Zlib (BSD-like) license.
			http://www.zlib.net/zlib_license.html

If a package has components covered by different licenses
(for example, GPL2 and the LGPL), use the <license> subdirectory
for the more restrictive license.

If a package allows the choice of a license to use, we'll
generally use the less restrictive license.

If in doubt about where a package should be located, please
contact <core@NetBSD.org> for advice.


Migration Strategy:


Eventually src/dist (and associated framework in other base source
directories) and src/gnu will be migrated to this hierarchy.


Maintenance Strategy:

The sources under src/external/<license>/<package>/dist/ are
generally a combination of a published distribution plus changes
that we submit to the maintainers and that are not yet published
by them.

Make sure all changes made to the external sources are submitted
to the appropriate maintainer, but only after coordinating with
the NetBSD maintainers.