kernel, and all the ssh tools. The dynamic objects are entirely ret-clean,
static binaries will contain a blend of cleaning and non-cleaning callers.
OpenBSD-Commit-ID: 112aacedd3b61cc5c34b1fa6d9fb759214179172
long-running setgid program carrying keys with some (not very powerful)
communication channels. solution for testing the binary from dtucker.
agreement from djm. Will add it into /etc/rc in a few days.
OpenBSD-Commit-ID: 2fe8d707ae35ba23c7916adcb818bb5b66837ba0
a Makefile by concatenating two Makefiles and was incredibly fragile. In the
new way a narrow-purposed install.sh script is created and shipped with the
objects. A recently commited /etc/rc script understands these files.
OpenBSD-Commit-ID: ef9341d5a50f0d33e3a6fbe995e92964bc7ef2d3
../Makefile.inc and Makfile are concatenated for reuse, which hopefully won't
be too fragile, we'll see if we need a different approach. The resulting sshd
binary is tested with the new sshd -V option before installation. As the
binary layout is now semi-unknown (meaning relative, fixed, and gadget
offsets are not precisely known), change the filesystem permissions to 511 to
prevent what I call "logged in BROP". I have ideas for improving this further
but this is a first step ok djm
OpenBSD-Commit-ID: 1e0a2692b7e20b126dda60bf04999d1d30d959d8
Have ssh-add accept a list of "destination constraints" that allow
restricting where keys may be used in conjunction with a ssh-agent/ssh
that supports session ID/hostkey binding.
Constraints are specified as either "[user@]host-pattern" or
"host-pattern>[user@]host-pattern".
The first form permits a key to be used to authenticate as the
specified user to the specified host.
The second form permits a key that has previously been permitted
for use at a host to be available via a forwarded agent to an
additional host.
For example, constraining a key with "user1@host_a" and
"host_a>host_b". Would permit authentication as "user1" at
"host_a", and allow the key to be available on an agent forwarded
to "host_a" only for authentication to "host_b". The key would not
be visible on agent forwarded to other hosts or usable for
authentication there.
Internally, destination constraints use host keys to identify hosts.
The host patterns are used to obtain lists of host keys for that
destination that are communicated to the agent. The user/hostkeys are
encoded using a new restrict-destination-v00@openssh.com key
constraint.
host keys are looked up in the default client user/system known_hosts
files. It is possible to override this set on the command-line.
feedback Jann Horn & markus@
ok markus@
OpenBSD-Commit-ID: 6b52cd2b637f3d29ef543f0ce532a2bce6d86af5
FALLTHROUGH */ comments, which is the style we currently use, and gives too
many boring warnings. ok djm
OpenBSD-Commit-ID: 07b5031e9f49f2b69ac5e85b8da4fc9e393992a0
wrote a stack protector for reverse-stack architectures, and i don't think
anyone else did either. a warning per compiled file is just annoying.
OpenBSD-Commit-ID: 14806a59353152f843eb349e618abbf6f4dd3ada
split client/server kex; only ssh-keygen needs
uuencode.o; only scp/sftp use progressmeter.o; ok djm@
OpenBSD-Commit-ID: f2c9feb26963615c4fece921906cf72e248b61ee
ssh/lib hasn't worked towards our code-sharing goals for
a quit while, perhaps it is too verbose? Change each */Makefile to
specifying exactly what sources that program requires, compiling it seperate.
Maybe we'll iterate by sorting those into seperatable chunks, splitting up
files which contain common code + server/client specific code, or whatnot.
But this isn't one step, or we'd have done it a long time ago.. ok dtucker
markus djm
OpenBSD-Commit-ID: 5317f294d63a876bfc861e19773b1575f96f027d
Previously portable OpenSSH has synced against a conversion of OpenBSD's
CVS repository made using the git cvsimport tool, but this has become
increasingly unreliable.
As of this commit, portable OpenSSH now tracks a conversion of the
OpenBSD CVS upstream made using the excellent cvs2gitdump tool from
YASUOKA Masahiko: https://github.com/yasuoka/cvs2gitdump
cvs2gitdump is considerably more reliable than gitcvsimport and the old
version of cvsps that it uses under the hood, and is the same tool used
to export the entire OpenBSD repository to git (so we know it can cope
with future growth).
These new conversions are mirrored at github, so interested parties can
match portable OpenSSH commits to their upstream counterparts.
https://github.com/djmdjm/openbsd-openssh-srchttps://github.com/djmdjm/openbsd-openssh-regress
An unfortunate side effect of switching upstreams is that we must have
a flag day, across which the upstream commit IDs will be inconsistent.
The old commit IDs are recorded with the tags "Upstream-ID" for main
directory commits and "Upstream-Regress-ID" for regress commits.
To make it clear that the commit IDs do not refer to the same
things, the new repository will instead use "OpenBSD-ID" and
"OpenBSD-Regress-ID" tags instead.
Apart from being a longwinded explanation of what is going on, this
commit message also serves to synchronise our tools with the state of
the tree, which happens to be:
OpenBSD-ID: 9c43a9968c7929613284ea18e9fb92e4e2a8e4c1
OpenBSD-Regress-ID: b33b385719420bf3bc57d664feda6f699c147fef
rationalise the long list of manual CDIAGFLAGS that we
add; most of these were redundant to -Wall -Wextra
Upstream-ID: ea80f445e819719ccdcb237022cacfac990fdc5c
Change COMPILER_VERSION tests which limited additional
warnings to gcc4 to instead skip them on gcc3 as clang can handle
-Wpointer-sign and -Wold-style-definition.
Upstream-ID: 5cbe348aa76dc1adf55be6c0e388fafaa945439a
deraadt@openbsd.org
naddy@openbsd.org
miod@openbsd.org
semarie@openbsd.org
dtucker@openbsd.org
djm@openbsd.org
bluhm@openbsd.org
markus@openbsd.org
Damien Miller
espie@openbsd.org
Darren Tucker
jsg@openbsd.org