I've reported the upgrade-blocking regression caused by the emergency
quirk introduced in this bug as
https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-
upgrader/+bug/1931112 - added a patch to remove the unknown-vendor side
of the quirk (leaving the block at Apple-only for now, although I
Public bug reported:
v 1:20.10.16
DistUpgradeQuirks.py, in _test_and_fail_on_apple fails if
_readDMIVendor() returns null i.e. if /sys/class/dmi/id/sys_vendor is
unknown.
However, this is a very common case - it means almost all non-x86
hardware and many VMs (including my test case, WSL2 20.10
That's because _test_and_fail_on_apple in DistUpgradeQuirks.py (see line
377) in the upgrader itself, is set to fail if vendor.startswith('Apple
Inc.') OR if vendor is unknown i.e. /sys/class/dmi/id/sys_vendor is null
(for example as it will be in WSL or just about any other system where
DMI isn't
Should add to this: 1.1.1 is the LTS version of OpenSSL; 1.1.0 is no
longer supported upstream. It's not going to be practical to backport
anything to 1.1.0.
1.1.1 has no API breakage beyond 1.1.0 (which you already did) and you
should upgrade this during bionic. 1.1.1 also adds TLSv1.3.
If you
Warning: Both RC4 and MD5 are INSECURE. They are susceptible to
practical attacks. Do not use them.
MD5 is already disabled by default. Real collisions have been produced,
and used to forge certificates in the wild; its use as an HMAC is also
strongly discouraged. It must never be used.
RC4
