> if it's time to re-visit that practice of not updating through minor
openssl versions; it's risky to try.
As an upstream OpenSSL maintainer we try very hard to ensure that stable
releases remain stable across patch releases. We only allow bug fixes
(no new features etc) into our patch releases
FYI, upstream have now also merged a fix in the 1.1.1 branch:
https://github.com/openssl/openssl/commit/e04ba889594d84a8805f3d0caeadf0527470e508
If Ubuntu pulls in that patch I expect that this bug should be fixed by
it.
--
You received this bug notification because you are a member of Ubuntu
FYI, upstream merged a fix for the underlying problem in OpenSSL 3.0:
https://github.com/openssl/openssl/commit/8b63b174b00b0e8c5cefcea12989d90450e04b24
I expect a similar fix to be backported to 1.1.1 soon. Although the
specific issue that this bug report is about doesn't impact upstream, I
Thanks for your analysis. Based on your description I was able to find
an instance of this bug that impacts an unmodified upstream OpenSSL
directly. I've raised an issue for it here:
https://github.com/openssl/openssl/issues/18047
That particular instance only impacts OpenSSL 3.0 - but its the
Public bug reported:
Launching openssl s_server as follows:
$ openssl s_server -nocert -psk 01020304 -dtls1
And using openssl s_client to connect to it like this:
$ openssl s_client -dtls1 -psk 01020304
Results in s_server entering an infinite loop:
Using default temp DH parameters
ACCEPT
** Attachment added: "ufw.tar.gz"
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856/+attachment/5222404/+files/ufw.tar.gz
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ufw in Ubuntu.
** Attachment added: "dpkg.list"
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856/+attachment/5222403/+files/dpkg.list
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ufw in Ubuntu.
** Attachment added: "ufw.raw"
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856/+attachment/5222405/+files/ufw.raw
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ufw in Ubuntu.
I rebooted and confirmed that ufw still reports itself as inactive.
Attached are the requested files. Note: I only included the last 25000
lines from journal.full - otherwise I would have to upload 250Mb!
** Attachment added: "journal.full"
I made the change to /lib/ufw/ufw-init as requested and confirmed that
after reboot I was still hitting the issue (Ubuntu 18.04.1 LTS):
$ sudo ufw status
Status: inactive
Attached is the requested journalctl output.
** Attachment added: "journalctl.log"
I just tried:
After=network.target
After 5 reboot tests I got mixed results:
The first two reboots failed to start networking at all and ufw reported its
status as "inactive" immediately after boot.
The next two reboots networking started successfully, and ufw reported as
active.
The final
I just tried that:
$ diff -u ufw.service.orig ufw.service
--- ufw.service.orig2018-05-26 13:45:48.696356561 +0100
+++ ufw.service 2018-07-17 16:50:45.545596167 +0100
@@ -2,7 +2,8 @@
Description=Uncomplicated firewall
Documentation=man:ufw(8)
DefaultDependencies=no
-Before=network.target
Unfortunately, after a few reboots using these settings it seems this is
not the answer. While it does seem to work intermittently, it also
sometimes fails. I've also had some issues with network not working at
all. I'm not 100% sure that this change is the culprit - but for now I
have reverted
This issue still seems to be a problem in 18.04.
If found a solution:
https://askubuntu.com/questions/1040539/how-do-i-get-ufw-to-start-on-boot/1040584
I edited /lib/systemd/system/ufw.service as follows:
$ diff -u ufw.service.orig ufw.service
--- ufw.service.orig2018-05-26
Hi Seth,
This is what I get:
matt@matt-laptop:~$ sudo ufw status
Status: inactive
matt@matt-laptop:~$ journalctl -u ufw.service
-- Logs begin at Tue 2017-10-24 22:48:54 BST, end at Wed 2017-10-25 00:03:54
BST. --
Oct 24 22:48:54 matt-laptop systemd[1]: Started Uncomplicated firewall.
Public bug reported:
Whenever I boot into 17.10 ufw is always inactive, even though
/etc/ufw/ufw.conf has this:
# Set to yes to start on boot. If setting this remotely, be sure to add a rule
# to allow your remote connection before starting ufw. Eg: 'ufw allow 22/tcp'
ENABLED=yes
ProblemType:
16 matches
Mail list logo
