OTP part of the yubikey, there is now upstream support for FreeBSD's
uhid(4) (as well as more modern uhidraw) so it seems a bit closer to
what we need, but still doesn't work directly with our uhid(4).
this had been held off because the OTP management functions changed to
a different HID backend in 4.x which doesn't work with OpenBSD, but
in the meantime the old ones got broken by a libffi update, so there's
no point keeping 3.x around for that any more.
ykman fido appears to be slightly less stall-y with this version,
though you still need to sometimes unplug/replug the key (similar has
been seen just using py-fido2 directly so it's probably in there somewhere,
and it's not new)
of py3-fido.
should be a noop. if it doesn't work currently or only partially works
(like mine which times out usb transactions for many operations) then
this won't help, if it does work then this shouldn't break things.
but this gets ykman out of the way of updates to the main py-fido port.
if a port needs 2.x then set MODPY_VERSION=${MODPY_DEFAULT_VERSION_2}.
This commit doesn't change any versions currently used; it may be that
some ports have MODPY_DEFAULT_VERSION_2 but don't require it, those
should be cleaned up in the course of updating ports where possible.
Python module ports providing py3-* packages should still use
FLAVOR=python3 so that we don't have a mixture of dependencies some
using ${MODPY_FLAVOR} and others not.
The YubiKey Manager can configure FIDO2, OTP and PIV functionality on
a YubiKey. It works with any currently supported YubiKey. You can also
use the tool to check the type and firmware of a YubiKey. In addition,
you can use the extended settings to specify other features, such as to
configure 3-second long touch.
Follow the upstream recommendations for packagers and switch to
multi-packages:
devel/gettext -> devel/gettext,-runtime
devel/gettext-tools -> devel/gettext,-tools
(new) devel/gettext,-textstyle
some existing COMPILER lines with arch restrictions etc. In the usual
case this is now using "COMPILER = base-clang ports-gcc base-gcc" on
ports with c++ libraries in WANTLIB.
This is basically intended to be a noop on architectures using clang
as the system compiler, but help with other architectures where we
currently have many ports knocked out due to building with an unsuitable
compiler -
- some ports require c++11/newer so the GCC version in base that is used
on these archirtectures is too old.
- some ports have conflicts where an executable is built with one compiler
(e.g. gcc from base) but a library dependency is built with a different
one (e.g. gcc from ports), resulted in mixing incompatible libraries in the
same address space.
devel/gmp is intentionally skipped as it's on the path to building gcc -
the c++ library there is unused in ports (and not built by default upstream)
so intending to disable building gmpcxx in a future commit.
