| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
OpenBSD-Commit-ID: bdea29bb3ed2a5a7782999c4c663b219d2270483
|
|
|
|
|
|
|
|
|
|
| |
was initialized. This fixes a potential uninitialized use of 'limits' in
sftp_init() if sftp_get_limits() returned early because of an unexpected
message type.
ok djm@
OpenBSD-Commit-ID: 1c177d7c3becc1d71bc8763eecf61873a1d3884c
|
|
|
|
|
|
| |
contain symlinks to other directories (similar to bz3611)
OpenBSD-Commit-ID: 7e19d2ae09b4f941bf8eecc3955c9120171da37f
|
|
|
|
|
|
|
|
|
|
|
|
| |
OpenSSH and it shows - the function names are terrible.
Rename do_blah() to sftp_blah() to make them less so.
Completely mechanical except for sftp_stat() and sftp_lstat() which
change from returning a pointer to a static variable (error-prone) to
taking a pointer to a caller-provided receiver.
OpenBSD-Commit-ID: eb54d6a72d0bbba4d623e2175cf5cc4c75dc2ba4
|
|
|
|
|
|
|
| |
directories that contain symlinks to other directories. In scp mode, the
links would be followed, but in SFTP mode they were not. bz3611, ok dtucker@
OpenBSD-Commit-ID: 9760fda668eaa94a992250d7670dfbc62a45197c
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
requests.
sftp/scp will ftruncate the destination file after a transfer completes,
to deal with the case where a longer destination file already existed.
We tracked the highest contiguous block transferred to deal with this
case, but our naive tracking doesn't deal with servers that reorder
requests - a misfeature strictly permitted by the protocol but seldom
implemented.
Adjust the logic to ftruncate() at the highest absolute block received
when the transfer is successful. feedback deraadt@ ok markus@
prompted by https://github.com/openssh/openssh-portable/commit/9b733#commitcomment-110679778
OpenBSD-Commit-ID: 4af7fac75958ad8507b4fea58706f3ff0cfddb1b
|
|
|
|
|
|
|
|
|
| |
make_absolute_pwd_glob work in the same way as make_absolute: you
pass it a dynamically allocated string and it either returns it, or
frees it and allocates a new one. Patch from emaste at freebsd.org and
https://reviews.freebsd.org/D37253 ok djm@
OpenBSD-Commit-ID: 85f7404e9d47fd28b222fbc412678f3361d2dffc
|
|
|
|
|
|
| |
ok miod@ millert@
OpenBSD-Commit-ID: 7be168a570264d59e96a7d2d22e927d45fee0e4c
|
|
|
|
|
|
| |
requests too
OpenBSD-Commit-ID: c4965f62fa0ba850940fd66ae3f60cf516bbcd56
|
|
|
|
|
|
| |
extension
OpenBSD-Commit-ID: c5b023e0954693ba9a5376e4280c739b5db575f8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
control over some SFTP protocol knobs: the copy buffer length and
the number of inflight requests, both of which are used during
upload/download.
Previously these could be controlled in sftp(1) using the -b/-R options.
This makes them available in both SFTP protocol clients using the same
option character sequence.
ok dtucker@
OpenBSD-Commit-ID: 27502bffc589776f5da1f31df8cb51abe9a15f1c
|
|
|
|
|
|
| |
users-groups-by-id@openssh.com; ok markus@
OpenBSD-Commit-ID: ddb2f33a2da6349a9a89a8b5bcb9ca7c999394de
|
|
|
|
|
|
|
| |
all cases, not just at the start of a transfer. This could cause overwrites
of larger files to leave junk at the end. Spotted by tb@
OpenBSD-Commit-ID: b189f19cd68119548c8e24e39c79f61e115bf92c
|
|
|
|
|
|
|
|
|
|
|
|
| |
early
previous behavious of unconditionally truncating the destination file
would cause "scp ~/foo localhost:" and "scp localhost:foo ~/" to
delete all the contents of their destination.
spotted by solene@ sthen@, also bz3431; ok dtucker@
OpenBSD-Commit-ID: ca39fdd39e0ec1466b9666f15cbcfddea6aaa179
|
|
|
|
|
|
|
| |
copying of files. Useful for this task and for testing the copy-data
extension. Patch from Mike Frysinger; ok dtucker@
OpenBSD-Commit-ID: 1bb1b950af0d49f0d5425b1f267e197aa1b57444
|
| |
|
|
|
|
|
|
| |
the general form of "[local/remote] operation path: error message"; ok markus
OpenBSD-Commit-ID: 61364cd5f3a9fecaf8d63b4c38a42c0c91f8b571
|
|
|
|
|
|
|
|
| |
failures; provides better experience for scp in sftp mode, where ~user paths
are more likely to be used; spotted jsg, feedback jsg & deraadt ok jsg &
markus
OpenBSD-Commit-ID: fc610ce00ca0cdc2ecdabbd49ce7cb82033f905f
|
|
|
|
|
|
| |
ok jsg & markus
OpenBSD-Commit-ID: 43618c692f3951747b4151c477c7df22afe2bcc8
|
|
|
|
| |
OpenBSD-Commit-ID: bfc7ba74c22c928de2e257328b3f1274a3dfdf19
|
|
|
|
|
|
| |
gmail.com via github PR#283, ok markus@
OpenBSD-Commit-ID: ec1fa7d305d46226861c3ca6fb9c9beb2ada2892
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
O_CREAT, the 3rd (variadic) mode_t parameter is irrelevant. Many developers
in the past have passed mode_t (0, 044, 0644, or such), which might lead
future people to copy this broken idiom, and perhaps even believe this
parameter has some meaning or implication or application. Delete them all.
This comes out of a conversation where tb@ noticed that a strange (but
intentional) pledge behaviour is to always knock-out high-bits from mode_t on
a number of system calls as a safety factor, and his bewilderment that this
appeared to be happening against valid modes (at least visually), but no
sorry, they are all irrelevant junk. They could all be 0xdeafbeef. ok
millert
OpenBSD-Commit-ID: 503d11633497115688c0c6952686524f01f53121
|
|
|
|
|
|
|
| |
The subsequent call to stat_to_attrib clears the struct as its first step
anyway. From pmeinhardt via github PR#220, ok djm@
OpenBSD-Commit-ID: f5234fc6d7425b607e179acb3383f21716f3029e
|
|
|
|
|
|
|
|
|
|
| |
~-prefixed paths, in particular ~user ones. Allows scp in sftp mode to accept
these paths, like scp in rcp mode does.
prompted by and much discussion deraadt@
ok markus@
OpenBSD-Commit-ID: 7d794def9e4de348e1e777f6030fc9bafdfff392
|
|
|
|
|
|
|
| |
more useful with long paths (that may truncate) and better matches
traditional scp behaviour; spotted by naddy@ ok deraadt@
OpenBSD-Commit-ID: 26b544d0074f03ebb8a3ebce42317d8d7ee291a3
|
|
|
|
|
|
| |
remove unused variable
OpenBSD-Commit-ID: 233ac6c012cd23af62f237167a661db391055a16
|
| |
|
|
|
|
|
|
|
|
|
|
| |
tracking expected status replies from the server to what do_download() was
using.
Refactor it to use the same structure and factor out some common
code into helper functions.
OpenBSD-Commit-ID: 0c167df8ab6df4a5292c32421922b0cf379e9054
|
|
|
|
|
|
| |
traditional scp(1) ok markus@
OpenBSD-Commit-ID: 97255e55be37e8e26605e4ba1e69f9781765d231
|
|
|
|
|
|
| |
transfers; ok markus@
OpenBSD-Commit-ID: 64b2abaa5635a2be65ee2e77688ad9bcebf576c2
|
|
|
|
|
|
| |
sent/received over the wire
OpenBSD-Commit-ID: f68c4e207b08ef95200a8b2de499d422808e089b
|
|
|
|
|
|
|
| |
scp(1) by suppressing "Retrieving [path]" lines that were emitted to support
the interactive sftp(1) client. ok markus@
OpenBSD-Commit-ID: 06be293df5f156a18f366079be2f33fa68001acc
|
|
|
|
|
|
| |
and crossloading; ok markus@
OpenBSD-Commit-ID: 96eede24d520569232086a129febe342e4765d39
|
|
|
|
|
|
|
|
| |
downloading from one SFTP server while simultaneously uploading to another.
feedback & ok markus@
OpenBSD-Commit-ID: 3982878e29d8df0fa4ddc502f5ff6126ac714235
|
|
|
|
|
|
| |
"looks fine" markus@
OpenBSD-Commit-ID: d3dea2153f08855c6d9dacc01973248944adeffb
|
|
|
|
|
|
|
| |
limits@openssh.com extension but fails when the client tries to invoke it.
Reported by Hector Martin via bz3318
OpenBSD-Commit-ID: bd9d1839c41811616ede4da467e25746fcd9b967
|
|
|
|
|
|
| |
and bad indentation on continuation lines. Prompted by GHPR#185
OpenBSD-Commit-ID: e5c81f0cbdcc6144df1ce468ec1bac366d8ad6e9
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
client select good limits based on what the server supports. Split the
download and upload buffer sizes to allow them to be chosen independently.
In practice (and assuming upgraded sftp/sftp-server at each end), this
increases the download buffer 32->64KiB and the upload buffer
32->255KiB.
Patches from Mike Frysinger; ok dtucker@
OpenBSD-Commit-ID: ebd61c80d85b951b794164acc4b2f2fd8e88606c
|
|
|
|
|
|
| |
for us; patch from Mike Frysinger
OpenBSD-Commit-ID: 565516495ff8362a38231e0f1a087b8ae66da59c
|
|
|
|
|
|
| |
Jakub Jelen
OpenBSD-Commit-ID: fdeb1aae1f6149b193f12cd2af158f948c514a2a
|
|
|
|
|
|
|
|
|
| |
read-only directory, ensure that the directory is created with write and
execute permissions in the interim so that we can actually complete the
transfer, then set the directory permission as the final step. (The execute
bit is only likely to be an issue with a non-POSIX server). bz#3222, ok djm@
OpenBSD-Commit-ID: a82606212f2796e31f0e1af94a63355a7ad5d903
|
|
|
|
|
|
| |
__func__ and appending ssh_err(r) manually; ok markus@
OpenBSD-Commit-ID: 1f14b80bcfa85414b2a1a6ff714fb5362687ace8
|
|
|
|
|
|
|
|
| |
one more concurrent request that desired. This prevented using sftp(1) in
unpipelined request/response mode, which is useful when debugging. Patch from
Stephen Goetze in bz#3054
OpenBSD-Commit-ID: 41b394ebe57037dbc43bdd0eef21ff0511191f28
|
|
|
|
|
|
| |
krishnaiah.bommu@intel.com, ok dtucker
OpenBSD-Commit-ID: d031853f3ecf47b35a0669588f4d9d8e3b307b3c
|
|
|
|
|
|
|
|
| |
requested for resumed download but was considered already complete.
bz#2978 ok dtucker
OpenBSD-Commit-ID: f32084b26a662f16215ee4ca4a403d67e49ab986
|
|
|
|
|
|
|
| |
end of each transfer. Fixes the problem recently introduces where very quick
transfers do not display the progressmeter at all. Spotted by naddy@
OpenBSD-Commit-ID: 68dc46c259e8fdd4f5db3ec2a130f8e4590a7a9a
|
|
|
|
|
|
|
|
| |
the progressmeter formatting outside of signal handler context and have the
atomicio callback called for EINTR too. bz#2434 with contributions from djm
and jjelen at redhat.com, ok djm@
OpenBSD-Commit-ID: 1af61c1f70e4f3bd8ab140b9f1fa699481db57d8
|
|
|
|
|
|
|
|
|
| |
request they do not follow symlinks. Requires recently-committed
lsetstat@openssh.com extension on the server side.
ok markus@ dtucker@
OpenBSD-Commit-ID: f93bb3f6f7eb2fb7ef1e59126e72714f1626d604
|
|
|
|
|
|
| |
in bz#2366 feedback and ok dtucker@
OpenBSD-Commit-ID: 8402bbae67d578bedbadb0ce68ff7c5a136ef563
|
|
|
|
|
|
|
|
| |
download and fsync). These should return -1 on error, not a sftp status code.
patch from Petr Cerny in bz#2871
OpenBSD-Commit-ID: 651aa0220ad23c9167d9297a436162d741f97a09
|