src/init.c:118:9: warning: incompatible implicit declaration of built-in
function 'fprintf' [enabled by default]
fprintf(stderr, "Error in auto_init()\n");
^
Signed-off-by: Andreas Schneider <asn@cryptomilk.org>
Reviewed-by: Norbert Pocs <npocs@redhat.com>
src/dh.c:824:5: warning: incompatible implicit declaration of built-in
function 'fprintf' [enabled by default]
fprintf(stderr, "%s\n", fingerprint);
^
Signed-off-by: Andreas Schneider <asn@cryptomilk.org>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Adjust some subtle usage of argv string handling in the pkd
test options: rather than conditionally overwrite the two
mkdtemp strings with a newly-allocated buffer to be later
freed, keep the original const argv pointer around in its
own dedicated field.
See also these changes in the same area that were due to the
previous arrangement, which was a bit too subtle:
- 61ce3310b864802a101cb01ff103f0bc2da936e6
- e1a8b359c1
Addresses:
- https://gitlab.com/libssh/libssh-mirror/-/merge_requests/320#note_1173911211
Signed-off-by: Jon Simons <jon@jonsimons.org>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Use the new `-L` flag for the pkd tests so that they use a
unique temporary directory for scratch space while running.
Note the choice of `pkd_scratch_XXXXXX` in contrast to a
path living under `/tmp`: by using a relative path, one can
gather the full set of log artifacts from the GitLab CI jobs
in the event that there is a test failure. The logs contain
lots of information to help pinpoint what went wrong.
Resolves https://gitlab.com/libssh/libssh-mirror/-/issues/143.
Testing notes:
- In the GitLab CI jobs I can see the flag being used, and
can observe that I am able to gather the full set of
detailed `pkd` logs in the event of a legitimate test
failure.
Signed-off-by: Jon Simons <jon@jonsimons.org>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Teach `pkd` a new flag `-L, --temp-dir=<mkdtemp-template>` to enable
behavior whereby `pkd` creates a new temporary directory and uses it
for a workspace while running.
The original design of `pkd` assumed that it could freely use the
current working directory from wherever it happened to be invoked.
But, this could pose a problem when multiple `pkd` instances are run
in parallel from the same working directory, due to the usage of
various temporary files within that directory.
To avoid the problem of multiple `pkd` instances interfering with
each other, expose a `-L` flag for optionally specifying a `mkdtemp`
template string such that a temporary scratch space is used instead.
Testing notes:
- I ran handfuls of iterations locally using the new flag
and observed `pkd` is indeed using scratch space as desired.
Resolves https://gitlab.com/libssh/libssh-mirror/-/issues/143.
Signed-off-by: Jon Simons <jon@jonsimons.org>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Relax the `pthread_kill` result assertion in `pkd_stop` to tolerate
`ESRCH`, and guard against only `EINVAL` and `ENOTSUP`.
On macOS what can happen is that the `pthread_kill` returns `ESRCH` due
to the accept thread being already terminated. For that case, the
teardown path should proceed to `pthread_join`.
Testing notes:
- On my macOS setup I consistently encountered `ESRCH` in this
codepath, causing pkd tests to fail unnecessarily. With the
change, I observe the tests passing.
Signed-off-by: Jon Simons <jon@jonsimons.org>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Fix this warning generated by cmake 3.24.3 on macOS:
CMake Warning (dev) at /opt/homebrew/Cellar/cmake/3.24.3/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:438 (message):
The package name passed to `find_package_handle_standard_args` (ARGP) does
not match the name of the calling package (Argp). This can lead to
problems in calling code that expects `find_package` result variables
(e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
cmake/Modules/FindArgp.cmake:63 (find_package_handle_standard_args)
CMakeLists.txt:107 (find_package)
This warning is for project developers. Use -Wno-dev to suppress it.
Testing notes:
- With this change, the warning is gone on my macOS setup.
Signed-off-by: Jon Simons <jon@jonsimons.org>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
In e1a8b359c1 a missing `free` was
added to `pkd_cleanup_socket_wrapper` to free a string allocated
for the socket wrapper directory name.
Move that `free` such that it also runs in the error-out paths in
`pkd_cleanup_socket_wrapper`, to avoid a leak in those cases, too.
Signed-off-by: Jon Simons <jon@jonsimons.org>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
It should be possible to use features to add,remove,prioritize
algorithms in the algorithm list from the config file.
Signed-off-by: Norbert Pocs <npocs@redhat.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
These features allow for options Ciphers, HostKeyAlgorithms, KexAlgorithms and
MACs to append, remove and prepend to the default list of algorithms
respectively
Signed-off-by: Norbert Pocs <npocs@redhat.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
The funcions can:
- add a list to the default list
- remove a list from the default list
- prepend a list to the default list
Signed-off-by: Norbert Pocs <npocs@redhat.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Functions `ssh_remove_all_matching` and `ssh_prefix_without_duplicates` were
added; a little test suite will suite them.
Signed-off-by: Norbert Pocs <npocs@redhat.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
"template" is a c++ keyword which will make the build fail.
Signed-off-by: Norbert Pocs <npocs@redhat.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
To make sure c++ name mangling works correctly c code should be noted "extern"
Signed-off-by: Norbert Pocs <npocs@redhat.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
EVP_DigestSign and EVP_DigestVerify are implicitly included in new (>1.1.1)
openssl versions, no need to use the old functions.
Signed-off-by: Norbert Pocs <npocs@redhat.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
POLY1305 is implicitly included in new (>1.1.1) openssl version, no need
to check it explicitly.
CHACHA20 is implicitly included too, but it can be turned off at config
in openssl, so we still need to check it.
Signed-off-by: Norbert Pocs <npocs@redhat.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
X25519 is implicitly included in new (>1.1.1) openssl version, no need
to check it explicitly.
Signed-off-by: Norbert Pocs <npocs@redhat.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
ED25519 is implicitly included in new (>1.1.1) openssl version, no need
to check it explicitly.
Signed-off-by: Norbert Pocs <npocs@redhat.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Removing support for older openssl versions than 1.1.1 makes some functions
implicitly included; we do not have to check the availability of these
functions.
Signed-off-by: Norbert Pocs <npocs@redhat.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
The c7s uses not longer supported openssl version which will make
the CI fail when we remove the supported of the old openssl versions.
Signed-off-by: Norbert Pocs <npocs@redhat.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
As openssl 1.1.0, 1.0.2, 1.0.1, 1.0.0 and 0.9.8 are no longer supported
let's remove them.
Signed-off-by: Norbert Pocs <npocs@redhat.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
As openssl 1.1.0, 1.0.2, 1.0.1, 1.0.0 and 0.9.8 are no longer supported
let's remove them.
Signed-off-by: Norbert Pocs <npocs@redhat.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
As openssl 1.1.0, 1.0.2, 1.0.1, 1.0.0 and 0.9.8 are no longer supported
let's remove them.
Signed-off-by: Norbert Pocs <npocs@redhat.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
libsofthsm detection is broken in i686 architecture. The approach is to export
the path found by cmake to `tests_config.h` and the script
setup-softhsm-tokens.sh gets that value through cli parameters.
Signed-off-by: Norbert Pocs <npocs@redhat.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
The error was the following
/builds/libssh/libssh-mirror/examples/sshnetcat.c:241:18: error: a function
declaration without a prototype is deprecated in all versions of C
[-Werror,-Wstrict-prototypes]
void cleanup_pcap(){
^
void
and similar
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Anderson Toshiyuki Sasaki <ansasaki@redhat.com>
Let's check tests in fips mode with an up to date system too as we already
found some issues running the tests there.
Signed-off-by: Norbert Pocs <npocs@redhat.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
uint32_t should be formated by PRI?32
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Change-Id: I811cfd764010f9e8bb599b370155ac065ee1905c
When we decide we need to rekey, we enqueue any further packets until we've sent
our SSH2_MSG_NEWKEYS message, after which we dequeue these packets and send them
to the other side. This enqueueing is done based on ssh_packet_in_rekey checking
the session flags and whether DH handshake state is marked as finished.
However, the handshake state is not reset to DH_STATE_FINISHED until the other
side has sent us their new keys. This leaves a gap between sending our new keys
and receiving the other side's new keys where we would still decide to enqueue a
packet.
These enqueued packets will not be dequeued as we've already sent our new keys.
Once we've received the other side's new keys, we'll go back to a finished
handshake and we will send out our caller's new data, skipping however much data
we've enqueued.
Fix this by changing ssh_packet_in_rekey to return false once we've sent our new
keys.
Signed-off-by: Carlos Martín Nieto <carlosmn@github.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
These warning should be logging when something fatal happens and give
information on the error to the user.
Signed-off-by: Norbert Pocs <npocs@redhat.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
