| a613d68f | 07-Oct-2021 |
Ed Maste <[email protected]> |
ssh: enable FIDO/U2F keys
Description of FIDO/U2F support (from OpenSSH 8.2 release notes,
https://www.openssh.com/txt/release-8.2):
This release adds support for FIDO/U2F hardware authenticators
ssh: enable FIDO/U2F keys
Description of FIDO/U2F support (from OpenSSH 8.2 release notes,
https://www.openssh.com/txt/release-8.2):
This release adds support for FIDO/U2F hardware authenticators to
OpenSSH. U2F/FIDO are open standards for inexpensive two-factor
authentication hardware that are widely used for website
authentication. In OpenSSH FIDO devices are supported by new public
key types "ecdsa-sk" and "ed25519-sk", along with corresponding
certificate types.
ssh-keygen(1) may be used to generate a FIDO token-backed key, after
which they may be used much like any other key type supported by
OpenSSH, so long as the hardware token is attached when the keys are
used. FIDO tokens also generally require the user explicitly
authorise operations by touching or tapping them.
Generating a FIDO key requires the token be attached, and will
usually require the user tap the token to confirm the operation:
$ ssh-keygen -t ecdsa-sk -f ~/.ssh/id_ecdsa_sk
Generating public/private ecdsa-sk key pair.
You may need to touch your security key to authorize key generation.
Enter file in which to save the key (/home/djm/.ssh/id_ecdsa_sk):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/djm/.ssh/id_ecdsa_sk
Your public key has been saved in /home/djm/.ssh/id_ecdsa_sk.pub
This will yield a public and private key-pair. The private key file
should be useless to an attacker who does not have access to the
physical token. After generation, this key may be used like any
other supported key in OpenSSH and may be listed in authorized_keys,
added to ssh-agent(1), etc. The only additional stipulation is that
the FIDO token that the key belongs to must be attached when the key
is used.
To enable FIDO/U2F support, this change regenerates ssh_namespace.h,
adds ssh-sk-helper, and sets ENABLE_SK_INTERNAL (unless building
WITHOUT_USB).
devd integration is not included in this change, and is under
investigation for the base system. In the interim the security/u2f-devd
port can be installed to provide appropriate devd rules.
Reviewed by: delphij, kevans
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D32509
(cherry picked from commit e9a994639b2af232f994ba2ad23ca45a17718d2b)
show more ...
|
| c437ff14 | 07-Oct-2021 |
Ed Maste <[email protected]> |
Add libfido2 to the build
From https://github.com/Yubico/libfido2:
libfido2 provides library functionality and command-line tools to
communicate with a FIDO device over USB, and to verify a
Add libfido2 to the build
From https://github.com/Yubico/libfido2:
libfido2 provides library functionality and command-line tools to
communicate with a FIDO device over USB, and to verify attestation
and assertion signatures.
libfido2 supports the FIDO U2F (CTAP 1) and FIDO 2.0 (CTAP 2)
protocols.
libfido2 will be used by ssh to support FIDO/U2F keys. It is currently
intended only for use by ssh, and so is installed as a PRIVATELIB and is
placed in the ssh pkgbase package.
This is currently disabled for the 32-bit library build as libfido2 is
not compatible with the COMPAT_32BIT hack in usb_ioctl.h.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D32448
(cherry picked from commit 7b1e19ad78c6a3f84f81cb1a16a39500f0337062)
(cherry picked from commit 93942379cced89ad4ac653f262ac8277a8550853)
show more ...
|
| bbe50acc | 09-Oct-2021 |
Ed Maste <[email protected]> |
Belatedly track private lib renaming for OptionalObsoleteFiles.inc
Reviewed by: kevans
Fixes: 5551c573554e ("Rework PRIVATELIB")
Sponsored by: The FreeBSD Foundation
Differential Revision: https://
Belatedly track private lib renaming for OptionalObsoleteFiles.inc
Reviewed by: kevans
Fixes: 5551c573554e ("Rework PRIVATELIB")
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D32384
(cherry picked from commit 032448cd2c52161aa03fd4ee5bf243d78d61b53e)
show more ...
|
| b5ed0dcc | 01-Dec-2021 |
Ed Maste <[email protected]> |
OptionalObsoleteFiles.inc: remove MK_CXX rule for usr/bin/c++
In fact MK_CXX does not control whether /usr/bin/c++ is built -- it is
installed as a link to Clang (which is always a C/C++ compiler),
OptionalObsoleteFiles.inc: remove MK_CXX rule for usr/bin/c++
In fact MK_CXX does not control whether /usr/bin/c++ is built -- it is
installed as a link to Clang (which is always a C/C++ compiler), and it
already exists in OptionalObsoleteFiles under MK_TOOLCHAIN.
Sponsored by: The FreeBSD Foundation
(cherry picked from commit c3f345ae3c0fac0684f83cff72ae23da18468777)
show more ...
|
| 77a3ace8 | 01-Dec-2021 |
Ed Maste <[email protected]> |
OptionalObsoleteFiles: move /usr/bin/CC to MK_TOOLCHAIN section
/usr/bin/CC is installed by usr.bin/clang/clang/Makefile, as with
/usr/bin/cc, /usr/bin/cpp, etc., and is not controlled by MK_CXX.
Mo
OptionalObsoleteFiles: move /usr/bin/CC to MK_TOOLCHAIN section
/usr/bin/CC is installed by usr.bin/clang/clang/Makefile, as with
/usr/bin/cc, /usr/bin/cpp, etc., and is not controlled by MK_CXX.
Move it to the same section as those tools.
(It may be that these should all be under
MK_TOOLCHAIN == no || MK_CLANG_IS_CC == no, but that seems like
unnecessary complexity.)
Sponsored by: The FreeBSD Foundation
(cherry picked from commit f7ea22e2115329b7a4f2c6620e59e644f509a4ca)
show more ...
|
| 62b958cb | 15-Dec-2021 |
Jessica Clarke <[email protected]> |
cross-build: Add comment missing from 9e5b0d9eac5b
Whilst the commit message documented some of the details, I had intended
to include this comment in the actual header, but failed to amend the
comm
cross-build: Add comment missing from 9e5b0d9eac5b
Whilst the commit message documented some of the details, I had intended
to include this comment in the actual header, but failed to amend the
commit properly.
Fixes: 9e5b0d9eac5b ("cross-build: Fix bmake bootstrap with glibc 2.34")
MFC after: 1 week
(cherry picked from commit aee99ab4fe38bdc1dd1be88755d99ff4ee78ec09)
show more ...
|
| e8a66862 | 15-Dec-2021 |
Jessica Clarke <[email protected]> |
cross-build: Fix bmake bootstrap with glibc 2.34
As of glibc 2.34, our unistd.h wrapper's inclusion of stdlib.h exposes
fragility in glibc's sys/wait.h and corresponding part of stdlib.h,
leading to
cross-build: Fix bmake bootstrap with glibc 2.34
As of glibc 2.34, our unistd.h wrapper's inclusion of stdlib.h exposes
fragility in glibc's sys/wait.h and corresponding part of stdlib.h,
leading to "error: use of undeclared identifier 'WNOHANG'" and similar
errors when bootstrapping bmake.
Work around this by wrapping sys/wait.h to force stdlib.h's inclusion
first before it's implicitly included during the problematic window in
sys/wait.h.
MFC after: 1 week
(cherry picked from commit 9e5b0d9eac5b240dc0ee280870291fd11d499046)
show more ...
|
| 102717f7 | 06-Dec-2021 |
Jessica Clarke <[email protected]> |
cross-build: Provide _PASSWORD_EFMT1 for libcrypt on Linux
Linux's pwd.h does not define _PASSWORD_EFMT1 (macOS's does), so we need
to define it in order to be able to bootstrap libcrypt (crypt-des.
cross-build: Provide _PASSWORD_EFMT1 for libcrypt on Linux
Linux's pwd.h does not define _PASSWORD_EFMT1 (macOS's does), so we need
to define it in order to be able to bootstrap libcrypt (crypt-des.c uses
it) on non-FreeBSD, which will be done in a subsequent commit.
MFC after: 1 week
(cherry picked from commit e0cb1fe7dd34e9786320befa623b181d29d6bdf9)
show more ...
|
| 94b6c9ba | 06-Dec-2021 |
Jessica Clarke <[email protected]> |
cross-build: Define crypt_data in unistd.h for libcrypt
This is where it's defined in the base system, so is where libcrypt
expects it to exist when being built, and will be needed when being
bootst
cross-build: Define crypt_data in unistd.h for libcrypt
This is where it's defined in the base system, so is where libcrypt
expects it to exist when being built, and will be needed when being
bootstrapped in a subsequent commit.
MFC after: 1 week
(cherry picked from commit 8ceba27a5d51e2fcc0ea547d5051bd859d15233c)
show more ...
|
| e06a2465 | 06-Dec-2021 |
Jessica Clarke <[email protected]> |
tools: Also create ${WORLDTMP}/legacy/usr/libdata/pkgonfig
This is needed for the next commit which will make libz a bootstrap
library as needed by ctfconvert. We could just not install the .pc file
tools: Also create ${WORLDTMP}/legacy/usr/libdata/pkgonfig
This is needed for the next commit which will make libz a bootstrap
library as needed by ctfconvert. We could just not install the .pc file
as it's not needed, but that requires a per-library hack every time a
bootstrap library gains a .pc file, so this keeps bootstrap-tools
looking as much like a normal build as possible.
MFC after: 1 week
(cherry picked from commit 7ba31d58f00197b491828c981228faf6ae99a6c2)
show more ...
|
| cd7a8308 | 06-Dec-2021 |
Jessica Clarke <[email protected]> |
Makefile.boot: Fix copy/paste error in LIBNV's crossbuild override
Only noticed due to needing to change the surrounding lines, so
presumably nothing currently needs this.
MFC after: 1 week
(cherr
Makefile.boot: Fix copy/paste error in LIBNV's crossbuild override
Only noticed due to needing to change the surrounding lines, so
presumably nothing currently needs this.
MFC after: 1 week
(cherry picked from commit 5022d54e061a91b8ccc6a621ceb94ba9e56209c4)
show more ...
|
| 18ae2f6f | 07-Dec-2021 |
Mark Johnston <[email protected]> |
depend-cleanup.sh: Handle commit cbdec8db18b5
That commit changed libc to use the MI pdfork implementation, but with
an incremental build the object file for the pdfork.S stub lingers and
causes a l
depend-cleanup.sh: Handle commit cbdec8db18b5
That commit changed libc to use the MI pdfork implementation, but with
an incremental build the object file for the pdfork.S stub lingers and
causes a linker error.
Cleaning the depend file is not enouch, so modify clean_deps() to remove
object files as well, and add a call to ensure that pdfork.*o is
cleaned. The new file is _pdfork.o.
Reported by: jhb
Reviewed by: emaste
Fixes: cbdec8db18b5 ("libc: Add pdfork to the list of interposed system calls")
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 187fe192ce0ab1fc9787840ddb4f721a72de5942)
show more ...
|