regression tests for certificates with empty principals sections
(which are now unconditionally refused) and for certificates with
wildcard principals (which should only be accepted in host certs)
When certificate support was added to OpenSSH, certificates were
originally specified to represent any principal if the principals
list was empty.
This was, in retrospect, a mistake as it created a fail-open
situation if a CA could be convinced to accidentally sign a
certificate with no principals. This actually happened in a 3rd-
party CA product (CVE-2024-7594).
Somewhat fortunately, the main pathway for using certificates in
sshd (TrustedUserCAKeys) never supported empty-principals
certificates, so the blast radius of such mistakes was
substantially reduced.
This change removes this footcannon and requires all certificates
include principals sections. It also fixes interpretation of
wildcard principals, and properly enables them for host
certificates only.
[4 lines not shown]
Don't misuse the sftp limits extension's open-handles field.
This value is supposed to be the number of handles a server will allow
to be opened and not a number of outstanding read/write requests
that can be sent during an upload/download.
ok markus@
add a "ssh -O channels user at host" multiplexing command to get a
running mux process to show information about what channels are
currently open; ok dtucker@ markus@
pixman: Use endian.h to determine byte order
Replace architecture-specific checks with BYTE_ORDER from
<endian.h>. This covers m88k in addition to sparc64 and powerpc, which
prevents graphical programs like xeyes from behaving strangely on
luna88k.
ok matthieu@ jsg@
Use a better riscv patch for upstream
Always zero "auxv" before calling getauxval() or elf_aux_info(3).
I doubt that many systems out there with riscv support and sys/auxv.h,
but no getauxval(3) or elf_aux_info(3) support. But the updated patch is
just easier to reason about. No functional change for us.
ok ajacoutot@
Really disable building ld.bfd, except where explicitely intended
make(1) .if checks can be misleading, here properly check that the
expansion doesn't yield an empty string. Missed while reviewing
previous.
Spotted in aarch64 bulk build reports where the build failed. On sparc64
the port erroneously built ld.bfd with support for only elf64_sparc and
elf32_sparc and no support for our OpenBSD/sparc64 target.
I still think that adding elf_x86_64 ld(1) support to this port
isn't the right way to go.
