i think I have a trace where the issue is:
openssl3 openssl's options is a uint64_t, but in qsslsocket_openssl.cpp the
method is defined as
long QSslSocketBackendPrivate::setupOpenSslOptions(QSsl::SslProtocol protocol,
QSsl::SslOptions sslOptions)
long on 64bit platforms is 64 bit long, but on
this should fix the issue
this however requires openssl3.0, but that should be ok for ubuntu going
forward
** Patch added: "openssl3_set_options.patch"
https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1981807/+attachment/5603721/+files/openssl3_set_options.patch
--
You r
actually the first patch was missing something and did not compile
** Patch added: "openssl3_set_options.diff"
https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1981807/+attachment/5603782/+files/openssl3_set_options.diff
** Patch removed: "openssl3_set_options.patch"
h
https://bugreports.qt.io/browse/QTBUG-105041
this however has priority low.
additionally openssl1.1 and openssl3 are not compatible in this case if libssl
is loaded in runtime
for 32bit this is only solvable if compiletime forces openssl version to
3 OR 1.1, but then the corresponding version MU
just a side node on the findings while hunting down this issue in gdb:
on armhf I think the calling convention is that integers are passed on
registers. uint64 is not a (32bit) integer and since the value passed to
SSL_CTX_set_options was not related in any way to the value passed in
q_SSL_CTX_set
@mitya57 the patch is now submitted to codereview. I am however only
able to submit to the dev branch (took me a while to get this, never
used gerrit before). This also means that the patch I submitted is for
qt6. There is no way i send a codereview for qt5 anymore, so I don't
know who will do the
This is my suggested backport of the upstream patch.
since, as you might know, the file locations changed a bit, lso the file
defining the new datatype moved from qsslsocket_openssl_symbols_p.h to
qsslsocket_openssl_p.h since it is required there (setupOpenSslOptions
is defined there, but qsslsock
I have a version with the last attached patch in my ppa. This version works for
me.
Is there a change we get a SRU for this? Who would make that request?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to qtbase-opensource-src i
looking at the regression log, I see that it fails to launch jackd (exec of
JACK server (command = "/usr/bin/jackd") failed: No such file or directory).
Other platforms (amd64) do not have that log output.
I suspect this is because drumkv1_jack was not started yet (and so the test is
flaky). Ess
Just tested the proposed version on two armhf systems. Both server and
client mode now negotiate to tls1.3 if applicable. The other qt
applications do still work. Of corse the test application in this thread
also works (outputs 15)
Package: libqt5network5
Version: 5.15.3+dfsg-2ubuntu0.2
Package: l
*** This bug is a duplicate of bug 1951832 ***
https://bugs.launchpad.net/bugs/1951832
this is probably not a duplicate but this
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/961
#1951832 does talk about a issue with xl2tpd, looking at this log
output, the ppp session
I think the biggest issue is the automatic upgrade from "classic" to
systemd.socket
It is very hard to consistently migrate every configuration.
I was hit by this issue because I had set
/proc/sys/net/ipv6/bindv6only=1, so ipv4 was disabled
If ubuntu wants to use .socket, then please do this onl
Public bug reported:
update failed...
ProblemType: Package
DistroRelease: Ubuntu 22.10
Package: openssh-server 1:9.0p1-1ubuntu7
ProcVersionSignature: Ubuntu 5.15.0-48.54-generic 5.15.53
Uname: Linux 5.15.0-48-generic x86_64
NonfreeKernelModules: cpuid tcp_diag inet_diag tls authenc echainiv esp4
sshdconfig.txt actually does NOT contain a line with Port 22 (it is
commented out)
the beginning of the file is:
Include /etc/ssh/sshd_config.d/*.conf
#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
ListenAddress [fd12:2017:8387:80:3897:7aff:fe15:4de6]:22
ListenAddress [::]:
> Why do you mention this? I don't see anything in the log file that
mentions Port settings.
Because the automatically attached file has that setting and thus does
not reflect my real configuration
anyway, a issue seems to be that hostnames_to_addresses does not handle
ListenAddress 1.2.3.4:1234,
slightly off-topic for those who find this before the 22.10 documentation:
https://discourse.ubuntu.com/t/sshd-now-uses-socket-based-activation-ubuntu-22-10-and-later/30189
This bug is about the postinst script not being able to convert (or
keep) every configuration around.
In my case this is bec
@crhis34 actually socket activated ssh is not that difficult to setup.
The issue for me is only that the upgrade of the configuration did not
work quite right (and I think it is really challenging to do that right)
but simply put you take the file
/etc/systemd/system/ssh.socket.d/addresses.conf
a
I've checked that it did not do the rollback if I manually enabled
ssh.socket with the "configuration" ssh.socket.d/00-sockets.conf (and
addresses.conf missing)
LGTM
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in
Public bug reported:
Since systemd-234-2ubuntu8 systemd-networkd is enabled by default.
This causes problems existing configurations
ex1: if the network has ipv6 enables (the host recieves a router
advertisement), networkmanager does not configure the network anymore so you
get only ipv6 and no
this was a upgrade so the ifupdown problem should not happen with clean
installs.
How is the migration planned?
If for example one will do a upgrade from 16.04 to the next 18.04 such
problems are a clear show stopper since breaking the network for most
servers will mean needing physical access.
Here are the files of the networkmanager systemd-networkd conflict (I
already removed ifupdown, the problem is the same, so we say for sure
networkmanager or systemd-networkd causes the problem)
the output of ip a is the following:
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen
The example 2 in my first posting is not an bug since the package
contains /lib/systemd/network/80-container-host0.network. As I wrote
this only affects systemd-nspawn containers
the unexpected "thing" is that when you upgrade you do not expect a
system wide configuration that is active in paralle
22 matches
Mail list logo
