Re: [Touch-packages] [Bug 1990216] Re: backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" to Jammy
On Mon, Dec 04, 2023 at 04:42:48PM -, Adrien Nader wrote:
> The affected code is in libcrypto which I think sees fewer important security
> fixes. Therefore it's possible to build it and put it in your library search
> path. This should fix the issue without being too terrible wrt security
> updates.
[...]
> I'll prepare a PPA on tomorrow with only this change on tomorrow; I will
> probably add a few things to prevent using the package directly however
> since I expect the proper approach would be to 'dpkg -x' the package or
> equivalent and use its libcrypto.so and LD_LIBRARY_PATH or similar
> specifically when needed.
Note that as far as I understand from my own testing, the library file
that is affected by this particular upstream bugfix (OpenSSL
issue #18359/PR #18362) is ossl-modules/legacy.so ...
... and as such it is possible to work around the bug in the
systemwide libssl3 package copy of that library by
setting the OPENSSL_MODULES environment variable (rather than
touching LD_LIBRARY_PATH).
(See LP: #1972939 comment 11 for a brief bit of additional detail.)
If you are considering building a PPA to resolve this in Jammy,
here are a few possible approaches I can envision:
A) a "full" libssl3 package that contains the upstream patch applied
directly to ossl-modules/legacy.so , and would be installed
in place of the standard libssl3 package.
B) a "full" libssl3 package (installed in place of the standard
one) that contains the standard legacy.so file and then also a
ossl-modules/legacy-fixedBF.so file with a copy of the
legacy.so library patched by the fix.
C) a "special" libssl3 package (e.g. named libssl3-fixedbf) which
would contain only the ossl-modules/legacy-fixedBF.so file, and
would be installed alongside the standard libssl3 package.
The idea behind options B and C is that both the
broken/original-Jammy behavior and the fixed behavior would be
available simultaneously on the system, with the user selecting
which behavior they are looking for based on which module they
load at run time. In both cases the ossl-modules/ directory
would contain both legacy.so and legacy-fixedBF.so files (once
the PPA package in question was installed).
With option A only the corrected library would be available
(at run time with the PPA package installed), and it would be
found under the standard "legacy" module name. This would
certainly be the easiest-to-use approach in the Tinc-interop
case, but limits flexibility for sites which need compatibility
with both the default-Jammy and corrected behavior at the same
time.
(The names "legacy-fixBF.so" and "libssl3-fixedbf" just names I
made up to provide these examples; some other scheme like
"legacy-issue18359.so" or whatever would work similarly from the
user's standpoint.)
Nathan
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1990216
Title:
backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL
1.1 with blowfish in OFB or CFB modes" to Jammy
Status in openssl package in Ubuntu:
Fix Released
Status in openssl source package in Jammy:
In Progress
Status in openssl source package in Lunar:
Fix Released
Bug description:
=== SRU information ===
[Meta]
(This bug was once the fourth in a series of bugs grouped for a single SRU,
with
the "central" bug with the global information and debdiff being
http://pad.lv/2033422 . However, this particular bug is no longer included in
that SRU effort.)
[Impact]
Decryption for Blowfish with OFB and CFB modes fails due to using a key
shorter than expected by default.
Encryption will also use a key shorter than expected.
Exchange of encrypted data from/to Jammy using BF OFB/CFB will therefore lead
to decryption issues.
[Test plan]
On Focal, run the following and copy the output to your clipboard
for cipher in bf-cbc bf-cfb bf-ecb bf-ofb; do echo "Test with ${cipher}"
| openssl enc -${cipher} -k test -pbkdf2 -out "pouet.${cipher}"; done
tar c pouet.bf-* | xz | base64 -w 60
You can also run this on Lunar or Mantic if you add "-provider legacy
-provider default" to the "openssl enc" invocation.
On Jammy, run the following and paste your clipboard
base64 -d | xz -d | tar x
for cipher in bf-cbc bf-cfb bf-ecb bf-ofb; do openssl enc -d -provider
legacy -provider default -${cipher} -k test -pbkdf2 -d -in "pouet.${cipher}";
done
Only "Test with bf-cbc" and "Test with bf-ecb" will be properly
decrypted: the other two will result in garbage on screen.
Here is the result of the enc + tar + xz + base64 on Focal (works with
Lunar/Mantic too but you need to added ):
/Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4Cf/ARBdADgbyxDlZ/1Xd7bAmZw7
8pbqQTu5j8StVybo1p1B2ydBc5VcodF6fu0hEp801tvirgSFNMSAHk5HMN/w
[Touch-packages] [Bug 1990216] Re: backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" to Jammy
** Description changed:
=== SRU information ===
[Meta]
- This bug was the fourth in a series of bugs for a single SRU.
- The "central" bug with the global information and debdiff is
http://pad.lv/2033422
+ (This bug was once the fourth in a series of bugs grouped for a single SRU,
with
+ the "central" bug with the global information and debdiff being
http://pad.lv/2033422 . However, this particular bug is no longer included in
that SRU effort.)
[Impact]
Decryption for Blowfish with OFB and CFB modes fails due to using a key
shorter than expected by default.
Encryption will also use a key shorter than expected.
Exchange of encrypted data from/to Jammy using BF OFB/CFB will therefore lead
to decryption issues.
[Test plan]
On Focal, run the following and copy the output to your clipboard
for cipher in bf-cbc bf-cfb bf-ecb bf-ofb; do echo "Test with ${cipher}"
| openssl enc -${cipher} -k test -pbkdf2 -out "pouet.${cipher}"; done
tar c pouet.bf-* | xz | base64 -w 60
You can also run this on Lunar or Mantic if you add "-provider legacy
-provider default" to the "openssl enc" invocation.
On Jammy, run the following and paste your clipboard
base64 -d | xz -d | tar x
for cipher in bf-cbc bf-cfb bf-ecb bf-ofb; do openssl enc -d -provider
legacy -provider default -${cipher} -k test -pbkdf2 -d -in "pouet.${cipher}";
done
Only "Test with bf-cbc" and "Test with bf-ecb" will be properly
decrypted: the other two will result in garbage on screen.
Here is the result of the enc + tar + xz + base64 on Focal (works with
Lunar/Mantic too but you need to added ):
/Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4Cf/ARBdADgbyxDlZ/1Xd7bAmZw7
8pbqQTu5j8StVybo1p1B2ydBc5VcodF6fu0hEp801tvirgSFNMSAHk5HMN/w
hCgU1BIr/nK51g3A3Lkdv7QNbaUw2ux1AmO/MpCLKLffCB9ElFZH4tuOS5AR
m9CJMzi6LQOw9wytGKm2IK3Ph7WpU6JQ/3HJilffQwHbFLnukiWGpLNO5v0O
D/4AJikrU9iemfChT0jXDbIRZ8a8VpVhJqu0u6eYOheVTqmSRiHHpIC/p1VA
ecFb0mACF/TQhjxcMUWGSGO/mtof+VaLiyg0KB87GKlChfwXTEvgbNuP9hmu
GL64VhX568Oy9EakSxlcXiIRk14kJKv0MdHQqY1R22wAACzqSr/nzpwqAAGs
AoBQAACjzq5WscRn+wIABFla
Here is the same but from Jammy if you want to test encryption on Jammy
and decryption on Lunar/Mantic:
/Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4Cf/ARFdADgbyxDlZ/1Xd7bAmZw7
8pbqQTu5j8StVybo1p1B2ydBc1zK4HR2g3CiLJet+R++nZy/gph6RscQ6hI3
HySjdDOFRfjIVttiNK3DvRsZb37r8SXkj/JCYWicZGjWPZxVE3OAZhEed5qe
jrFv871QAbm4jVGD4oIc4cOb5V/xDN7KWgwEzpWQy6+tcfPm3KLPQvULx56N
2qQf60hP//p5EXS3RpCitUsrGUoYzTynjOUIRy2yCmgZDh62RmchUshyWePa
k0nEYlDbl5/dSHXbWEWESqW+QDj136MZRwQRY+QC4MvLXg2Bo8H+Dl/xvNDF
/5J4layZdFlh76lWOtFRVoIbX6JtpAP34g4zx1422GSNAABRzyqPdCqX
1AABrQKAUAAABh3ynbHEZ/sCAARZWg==
The contents are expected to be different due to the use of randomness.
Don't try to compare the base64 outputs: I'm only using them to ease
testing across containers.
[Where problems could occur]
This patch makes openssl match the documented default (see "man openssl-enc"
and search for "Blowfish" for instance) and fixes decryption from an up-to-date
Jammy to pretty much everything else, but it also create an issue for data
encrypted on Jammy without this patch and Jammy with this patch.
There are two possible cases: encrypted data being streamed across this
boundary or data at rest being transferred or read later.
Streaming is probably not an issue in practice because it's rather the
current situation that has been an issue and it's easy to remedy by
updating everything (which is relatively few machines since that's only
Jammy and not any other OS or distribution).
Data at rest is more annoying since updating Jammy will make it
impossible to read the data again without updates to other pieces of
software. That sounds like a really bad thing and it kind of is but at
the same, the benefits are much larger than the issues. Indeed, there is
already an incompatibility at the moment between Jammy and everything
else and the more time passes by, the more such problematic files can be
created. Luckily very few people are using blowfish nowadays and it's
not even enabled by default anymore in openssl. Moreover the software
update to work around the issue should be a single API call which is
documented in the upstream bug report (
https://github.com/openssl/openssl/issues/18359 ). Finally, I have
warned the two projects that I am aware are impacted; this is made
easier by the fact that they encountered the initial incompatibility.
[Patches]
The patches come directly from upstream and apply cleanly.
https://github.com/openssl/openssl/issues/18359
*
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-Fix-regression-in-default-key-length-for-Blowfish-CF.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0
*
Re: [Touch-packages] [Bug 1990216] Re: backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" to Jammy
On Fri, Nov 24, 2023 at 05:39:24PM -, Jeremy Sowden wrote:
> On 2023-11-24, at 17:25:11 -0000, Nathan Stratton Treadway wrote:
> > On Fri, Nov 24, 2023 at 12:04:59PM -, Adrien Nader wrote:
> > > FWIW, there's just been another report of the same issue with a
> > > different scenario but that's half-way between the "streaming" case and
> > > the "data at rest" one.
> >
> > Is this report you mention an LP bug? I look through the bug list for
> > the OpenSSL package but didn't immediately see a bug that seemed related
> > to this.
>
> I created this report a couple of days ago:
>
> https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2044391
>
> J.
Ah, thanks, got it. (I see now that it's not included in the
default listing for OpenSSL bugs that I was looking through since
it's already been marked as a duplicate.)
(Am I correct in understanding that if you didn't implement a fixed
version of Blowfish on your Jammy systems, your application
would also have the same trouble migrating from Jammy to the next
generation of Linux distribution that you chose in the future?)
In any case, it sounds like it could help your site, too, if
Ubuntu somehow provided an alternative legacy.so file with the
Blowfish fix already included, thus saving you from having to
maintain your own such package?
Nathan
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1990216
Title:
backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL
1.1 with blowfish in OFB or CFB modes" to Jammy
Status in openssl package in Ubuntu:
Fix Released
Status in openssl source package in Jammy:
In Progress
Status in openssl source package in Lunar:
Fix Released
Bug description:
=== SRU information ===
[Meta]
This bug was the fourth in a series of bugs for a single SRU.
The "central" bug with the global information and debdiff is
http://pad.lv/2033422
[Impact]
Decryption for Blowfish with OFB and CFB modes fails due to using a key
shorter than expected by default.
Encryption will also use a key shorter than expected.
Exchange of encrypted data from/to Jammy using BF OFB/CFB will therefore lead
to decryption issues.
[Test plan]
On Focal, run the following and copy the output to your clipboard
for cipher in bf-cbc bf-cfb bf-ecb bf-ofb; do echo "Test with ${cipher}"
| openssl enc -${cipher} -k test -pbkdf2 -out "pouet.${cipher}"; done
tar c pouet.bf-* | xz | base64 -w 60
You can also run this on Lunar or Mantic if you add "-provider legacy
-provider default" to the "openssl enc" invocation.
On Jammy, run the following and paste your clipboard
base64 -d | xz -d | tar x
for cipher in bf-cbc bf-cfb bf-ecb bf-ofb; do openssl enc -d -provider
legacy -provider default -${cipher} -k test -pbkdf2 -d -in "pouet.${cipher}";
done
Only "Test with bf-cbc" and "Test with bf-ecb" will be properly
decrypted: the other two will result in garbage on screen.
Here is the result of the enc + tar + xz + base64 on Focal (works with
Lunar/Mantic too but you need to added ):
/Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4Cf/ARBdADgbyxDlZ/1Xd7bAmZw7
8pbqQTu5j8StVybo1p1B2ydBc5VcodF6fu0hEp801tvirgSFNMSAHk5HMN/w
hCgU1BIr/nK51g3A3Lkdv7QNbaUw2ux1AmO/MpCLKLffCB9ElFZH4tuOS5AR
m9CJMzi6LQOw9wytGKm2IK3Ph7WpU6JQ/3HJilffQwHbFLnukiWGpLNO5v0O
D/4AJikrU9iemfChT0jXDbIRZ8a8VpVhJqu0u6eYOheVTqmSRiHHpIC/p1VA
ecFb0mACF/TQhjxcMUWGSGO/mtof+VaLiyg0KB87GKlChfwXTEvgbNuP9hmu
GL64VhX568Oy9EakSxlcXiIRk14kJKv0MdHQqY1R22wAACzqSr/nzpwqAAGs
AoBQAACjzq5WscRn+wIABFla
Here is the same but from Jammy if you want to test encryption on
Jammy and decryption on Lunar/Mantic:
/Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4Cf/ARFdADgbyxDlZ/1Xd7bAmZw7
8pbqQTu5j8StVybo1p1B2ydBc1zK4HR2g3CiLJet+R++nZy/gph6RscQ6hI3
HySjdDOFRfjIVttiNK3DvRsZb37r8SXkj/JCYWicZGjWPZxVE3OAZhEed5qe
jrFv871QAbm4jVGD4oIc4cOb5V/xDN7KWgwEzpWQy6+tcfPm3KLPQvULx56N
2qQf60hP//p5EXS3RpCitUsrGUoYzTynjOUIRy2yCmgZDh62RmchUshyWePa
k0nEYlDbl5/dSHXbWEWESqW+QDj136MZRwQRY+QC4MvLXg2Bo8H+Dl/xvNDF
/5J4layZdFlh76lWOtFRVoIbX6JtpAP34g4zx1422GSNAABRzyqPdCqX
1AABrQKAUAAABh3ynbHEZ/sCAARZWg==
The contents are expected to be different due to the use of
randomness. Don't try to compare the base64 outputs: I'm only using
them to ease testing across containers.
[Where problems could occur]
This patch makes openssl match the documented default (see "man openssl-enc"
and search for "Blowfish" for instance) and fixes decryption from an up-to-date
Jammy to pretty much everything else, but it also cr
Re: [Touch-packages] [Bug 1990216] Re: backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" to Jammy
On Fri, Nov 24, 2023 at 12:04:59PM -, Adrien Nader wrote:
> FWIW, there's just been another report of the same issue with a
> different scenario but that's half-way between the "streaming" case and
> the "data at rest" one.
Is this report you mention an LP bug? I look through the bug list for
the OpenSSL package but didn't immediately see a bug that seemed related
to this.
> The reason this fix is difficult to integrate in a stable release is
> because while we know we would introduce breakage, we do not and cannot
Yes, understood.
> I see two ways to improve this, tinc side.
>
> 1) Switch to another cipher. Blowfish uses a 64-bit block size which is
> small and limits how much data can be safely encrypted with the same key
> (
> https://en.wikipedia.org/wiki/Blowfish_(cipher)#Weakness_and_successors
> ). I guess this requires cooperation from the server which you might not
> control but it is the best long-term solution (and would also help
[...]
> 2) Modify tinc because there's apparently a portable work-around as I've
Blowfish is only needed for backward compatibility with now-obsolete
versions of Tinc, so I don't think making changes on the Tinc side is
feasible/helpful. (More-recent versions of Tinc have switched to using
a newer algorythm.)
What would be helpful from a Tinc-network-administrator standpoint is
some easier way to install a fixed version of the libssl3 legacy.so
file, though I am not sure what the best way to get there would be.
(I would imagine having such an option could also be helpful to any
users who have custom applications affected by this Blowfish bug as they
prepare to upgrade from Jammy to later releases of Ubuntu.)
Nathan
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1990216
Title:
backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL
1.1 with blowfish in OFB or CFB modes" to Jammy
Status in openssl package in Ubuntu:
Fix Released
Status in openssl source package in Jammy:
In Progress
Status in openssl source package in Lunar:
Fix Released
Bug description:
=== SRU information ===
[Meta]
This bug was the fourth in a series of bugs for a single SRU.
The "central" bug with the global information and debdiff is
http://pad.lv/2033422
[Impact]
Decryption for Blowfish with OFB and CFB modes fails due to using a key
shorter than expected by default.
Encryption will also use a key shorter than expected.
Exchange of encrypted data from/to Jammy using BF OFB/CFB will therefore lead
to decryption issues.
[Test plan]
On Focal, run the following and copy the output to your clipboard
for cipher in bf-cbc bf-cfb bf-ecb bf-ofb; do echo "Test with ${cipher}"
| openssl enc -${cipher} -k test -pbkdf2 -out "pouet.${cipher}"; done
tar c pouet.bf-* | xz | base64 -w 60
You can also run this on Lunar or Mantic if you add "-provider legacy
-provider default" to the "openssl enc" invocation.
On Jammy, run the following and paste your clipboard
base64 -d | xz -d | tar x
for cipher in bf-cbc bf-cfb bf-ecb bf-ofb; do openssl enc -d -provider
legacy -provider default -${cipher} -k test -pbkdf2 -d -in "pouet.${cipher}";
done
Only "Test with bf-cbc" and "Test with bf-ecb" will be properly
decrypted: the other two will result in garbage on screen.
Here is the result of the enc + tar + xz + base64 on Focal (works with
Lunar/Mantic too but you need to added ):
/Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4Cf/ARBdADgbyxDlZ/1Xd7bAmZw7
8pbqQTu5j8StVybo1p1B2ydBc5VcodF6fu0hEp801tvirgSFNMSAHk5HMN/w
hCgU1BIr/nK51g3A3Lkdv7QNbaUw2ux1AmO/MpCLKLffCB9ElFZH4tuOS5AR
m9CJMzi6LQOw9wytGKm2IK3Ph7WpU6JQ/3HJilffQwHbFLnukiWGpLNO5v0O
D/4AJikrU9iemfChT0jXDbIRZ8a8VpVhJqu0u6eYOheVTqmSRiHHpIC/p1VA
ecFb0mACF/TQhjxcMUWGSGO/mtof+VaLiyg0KB87GKlChfwXTEvgbNuP9hmu
GL64VhX568Oy9EakSxlcXiIRk14kJKv0MdHQqY1R22wAACzqSr/nzpwqAAGs
AoBQAACjzq5WscRn+wIABFla
Here is the same but from Jammy if you want to test encryption on
Jammy and decryption on Lunar/Mantic:
/Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4Cf/ARFdADgbyxDlZ/1Xd7bAmZw7
8pbqQTu5j8StVybo1p1B2ydBc1zK4HR2g3CiLJet+R++nZy/gph6RscQ6hI3
HySjdDOFRfjIVttiNK3DvRsZb37r8SXkj/JCYWicZGjWPZxVE3OAZhEed5qe
jrFv871QAbm4jVGD4oIc4cOb5V/xDN7KWgwEzpWQy6+tcfPm3KLPQvULx56N
2qQf60hP//p5EXS3RpCitUsrGUoYzTynjOUIRy2yCmgZDh62RmchUshyWePa
k0nEYlDbl5/dSHXbWEWESqW+QDj136MZRwQRY+QC4MvLXg2Bo8H+Dl/xvNDF
/5J4layZdFlh76lWOtFRVoIbX6JtpAP34g4zx1422GSNAABRzyqPdCqX
1AABrQKAUAAABh3ynbHEZ/sCAARZWg==
The contents are expected to be different due to the use of
randomness. Don't try to compare the base64 outputs: I'm only using
them to ease testing across containers.
[Where problems could occur]
This patch makes openssl match the
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
** Description changed: === SRU information === [ATTENTION] This SRU contains THREE changes which are listed in the section below. [Meta] This bug is part of a series of three bugs for a single SRU. This ( #2033422 ) is the "central" bug with the global information and debdiff. This SRU addresses three issues with Jammy's openssl version: - http://pad.lv/1994165: ignored SMIME signature errors - http://pad.lv/2023545: imbca engine dumps core - http://pad.lv/2033422: very high CPU usage for concurrent TLS connections (this one) - The SRU information has been added to the fthree bug reports and I am + The SRU information has been added to the three bug reports and I am attaching the debdiff here only for all three. All the patches have been included in subsequent openssl 3.0.x releases which in turn have been included in subsequent Ubuntu releases. There has been no report of issues when updating to these Ubuntu releases. I have rebuilt the openssl versions and used abi-compliance-checker to compare the ABIs of the libraries in jammy and the one for the SRU. Both matched completely (FYI, mantic's matched completely too). I have also pushed the code to git (without any attempt to make it git- ubuntu friendly). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru I asked Brian Murray about phasing speed and he concurs a slow roll-out is probably better for openssl. There is a small uncertainty because a security update could come before the phasing is over, effectively fast-forwarding the SRU. Still, unless there is already a current pre-advisory, this is probably better than a 10% phasing which is over after only a couple days anyway. NB: at the moment openssl doesn't phase slowly so this needs to be implemented. [Impact] Severely degraded performance for concurrent operations compared to openssl 1.1. The performance is so degraded that some workloads fail due to timeouts or insufficient resources (noone magically has 5 times more machines). As a consequence, a number of people use openssl 1.1 instead and do not get security updates. [Test plan] Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . To test, follow these steps: - run "time python3 main.py" # using the aforementioned main.py script - apt install -t jammy-proposed libssl3 - run "time python3 main.py" - compare the runtimes for the two main.py runs You can run this on x86_64, Raspberry Pi 4 or any machine, and get a very large speed-up in all cases. The improvements are not architecture- dependant. Using this changeset, I get the following numbers for ten runs on my laptop: 3.0.2: real 2m5.567s user 4m3.948s sys 2m0.233s this SRU: real 0m23.966s user 2m35.687s sys 0m1.920s As can be easily seen, the speed-up is massive: system time is divided by 60 and overall wall clock time is roughly five times lower. In http://pad.lv/2009544 , Rafael also shared his performance numbers and they are relatable to these. He used slightly different versions (upstreams rather than patched with cherry-picks) but at least one of the version used does not include other performance change. He also used different hardware and this performance issue seems to depend on the number of CPUs available but also obtained a performance several times better. Results on a given machine vary also very little across runs (less than 2% variation on runs of size 10). They are also very similar on a Raspberry Pi 4 (8GB). The benchmark uses https://www.google.com/humans.txt which takes around 130ms to download on my machine but I modified the script to download something only 20ms away. Results are so close to the ones using humans.txt that they are within the error margin. This is consistent with the high-concurrency in the benchmark which both saturates CPU, and "hides" latencies that are relatively low. Finally, there are positive reports on github. Unfortunately they are not always completely targeted at these patches only and therefore I will not link directly to them but they have also been encouraging. [Where problems could occur] The change is spread over several patches which touch the internals of openssl. As such, the engine and provider functionality could be broken by these changes. Fortunately, in addition to upstream's code review, these patches are included in openssl 3.0.4 (iirc) and therefore in kinetic. No issue related to these changes was reported on launchpad or upstream. However, it is possible that there were more patch dependencies than these in either 3.0.3 or 3.0.4. In that case there could be problems. [Patches] The patches come directly from
Re: [Touch-packages] [Bug 1990216] Re: backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" to Jammy
On Wed, Nov 01, 2023 at 02:39:27PM -, Adrien Nader wrote:
> This one is indeed not in the SRU at the moment. The description edit
> itself did not make much sense.
(Okay, that's what I thought. For what it's worth, I noticed afterwards
that the description for LP: #2033422 still has the "four bugs" version
of that sentence.)
> As far as I understand, tinc could fairly easily work around this issue
> by explicitely setting the key size before doing operations. This is the
> safest approach. It might even be faster than waiting for the SRU and
> corresponding phased updates.
Actually this isn't really easy on the Tinc side (at least for
Ubuntu end users).
In particular, the Tinc package actually hasn't changed at all in
several Ubuntu releases, so the big surprise here was that Tinc
1.0.36 on Jammy fails to connect in a network where Tinc 1.0.36
on Focal worked fine (even after making the configuration
adjustments that were expected due to the openssl 1.1 -> 3
transition).
Tinc does not provide any user-level control on these parameters,
and I don't think it even sets the parameters explicitly
internally in the code; rather, it relies on the default settings
for the algorithm, which is what was broken in that brief range
of OpenSSL v3 upstream releases. (Presumably if it already set
the parameters explicitly then it wouldn't have been affected by
this bug.)
In any case, solving this from the Tinc side would involve
(someone) making a Ubuntu-specific customization to the Tinc
source code -- which seems a lot more fraught than simply using a
fixed libssl3 library...
One thought that occurred to me is the idea of a semi-official
PPA build with this Blowfish patch included in it.
"Semi-official" in that you (or someone involved in the OpenSSL
Ubuntu packaging work) would publish it, building on top of the
official Ubuntu package, and thus it would track any other fixes
that were published to the main OpenSSL Jammy package -- but
since it's in a PPA it would be opt-in for those who need it.
This would be certainly be preferable to me over my current
situation using an "orphan" version of the legacy.so library
file, but I don't know how much effort it would be to provide
that on your end...
Nathan
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1990216
Title:
backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL
1.1 with blowfish in OFB or CFB modes" to Jammy
Status in openssl package in Ubuntu:
Fix Released
Status in openssl source package in Jammy:
In Progress
Status in openssl source package in Lunar:
Fix Released
Bug description:
=== SRU information ===
[Meta]
This bug was the fourth in a series of bugs for a single SRU.
The "central" bug with the global information and debdiff is
http://pad.lv/2033422
[Impact]
Decryption for Blowfish with OFB and CFB modes fails due to using a key
shorter than expected by default.
Encryption will also use a key shorter than expected.
Exchange of encrypted data from/to Jammy using BF OFB/CFB will therefore lead
to decryption issues.
[Test plan]
On Focal, run the following and copy the output to your clipboard
for cipher in bf-cbc bf-cfb bf-ecb bf-ofb; do echo "Test with ${cipher}"
| openssl enc -${cipher} -k test -pbkdf2 -out "pouet.${cipher}"; done
tar c pouet.bf-* | xz | base64 -w 60
You can also run this on Lunar or Mantic if you add "-provider legacy
-provider default" to the "openssl enc" invocation.
On Jammy, run the following and paste your clipboard
base64 -d | xz -d | tar x
for cipher in bf-cbc bf-cfb bf-ecb bf-ofb; do openssl enc -d -provider
legacy -provider default -${cipher} -k test -pbkdf2 -d -in "pouet.${cipher}";
done
Only "Test with bf-cbc" and "Test with bf-ecb" will be properly
decrypted: the other two will result in garbage on screen.
Here is the result of the enc + tar + xz + base64 on Focal (works with
Lunar/Mantic too but you need to added ):
/Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4Cf/ARBdADgbyxDlZ/1Xd7bAmZw7
8pbqQTu5j8StVybo1p1B2ydBc5VcodF6fu0hEp801tvirgSFNMSAHk5HMN/w
hCgU1BIr/nK51g3A3Lkdv7QNbaUw2ux1AmO/MpCLKLffCB9ElFZH4tuOS5AR
m9CJMzi6LQOw9wytGKm2IK3Ph7WpU6JQ/3HJilffQwHbFLnukiWGpLNO5v0O
D/4AJikrU9iemfChT0jXDbIRZ8a8VpVhJqu0u6eYOheVTqmSRiHHpIC/p1VA
ecFb0mACF/TQhjxcMUWGSGO/mtof+VaLiyg0KB87GKlChfwXTEvgbNuP9hmu
GL64VhX568Oy9EakSxlcXiIRk14kJKv0MdHQqY1R22wAACzqSr/nzpwqAAGs
AoBQAACjzq5WscRn+wIABFla
Here is the same but from Jammy if you want to test encryption on
Jammy and decryption on Lunar/Mantic:
/Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4Cf/ARFdADgbyxDlZ/1Xd7bAmZw7
8pbqQTu5j8StVybo1p1B2ydBc1zK4HR2g3CiLJet+R++nZy/gph6RscQ6hI3
HySjdDOFRfjIVttiNK3DvRsZb37r8SXkj/JCYWicZGjWPZxVE3OAZhEed5qe
Re: [Touch-packages] [Bug 1990216] Re: backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" to Jammy
On Tue, Oct 31, 2023 at 01:13:11PM -, Adrien Nader wrote:
> ** Description changed:
>
> === SRU information ===
> [Meta]
> - This bug is part of a series of four bugs for a single SRU.
> + This bug is part of a series of three bugs for a single SRU.
> The "central" bug with the global information and debdiff is
> http://pad.lv/2033422
>
> [Impact]
> Decryption for Blowfish with OFB and CFB modes fails due to using a key
> shorter than expected by default.
Adrien, am I correct that this particular bug (1990216) is actually no longer
included at all in the LP:#2033422 SRU ?
Nathan
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1990216
Title:
backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL
1.1 with blowfish in OFB or CFB modes" to Jammy
Status in openssl package in Ubuntu:
Fix Released
Status in openssl source package in Jammy:
In Progress
Status in openssl source package in Lunar:
Fix Released
Bug description:
=== SRU information ===
[Meta]
This bug is part of a series of three bugs for a single SRU.
The "central" bug with the global information and debdiff is
http://pad.lv/2033422
[Impact]
Decryption for Blowfish with OFB and CFB modes fails due to using a key
shorter than expected by default.
Encryption will also use a key shorter than expected.
Exchange of encrypted data from/to Jammy using BF OFB/CFB will therefore lead
to decryption issues.
[Test plan]
On Focal, run the following and copy the output to your clipboard
for cipher in bf-cbc bf-cfb bf-ecb bf-ofb; do echo "Test with ${cipher}"
| openssl enc -${cipher} -k test -pbkdf2 -out "pouet.${cipher}"; done
tar c pouet.bf-* | xz | base64 -w 60
You can also run this on Lunar or Mantic if you add "-provider legacy
-provider default" to the "openssl enc" invocation.
On Jammy, run the following and paste your clipboard
base64 -d | xz -d | tar x
for cipher in bf-cbc bf-cfb bf-ecb bf-ofb; do openssl enc -d -provider
legacy -provider default -${cipher} -k test -pbkdf2 -d -in "pouet.${cipher}";
done
Only "Test with bf-cbc" and "Test with bf-ecb" will be properly
decrypted: the other two will result in garbage on screen.
Here is the result of the enc + tar + xz + base64 on Focal (works with
Lunar/Mantic too but you need to added ):
/Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4Cf/ARBdADgbyxDlZ/1Xd7bAmZw7
8pbqQTu5j8StVybo1p1B2ydBc5VcodF6fu0hEp801tvirgSFNMSAHk5HMN/w
hCgU1BIr/nK51g3A3Lkdv7QNbaUw2ux1AmO/MpCLKLffCB9ElFZH4tuOS5AR
m9CJMzi6LQOw9wytGKm2IK3Ph7WpU6JQ/3HJilffQwHbFLnukiWGpLNO5v0O
D/4AJikrU9iemfChT0jXDbIRZ8a8VpVhJqu0u6eYOheVTqmSRiHHpIC/p1VA
ecFb0mACF/TQhjxcMUWGSGO/mtof+VaLiyg0KB87GKlChfwXTEvgbNuP9hmu
GL64VhX568Oy9EakSxlcXiIRk14kJKv0MdHQqY1R22wAACzqSr/nzpwqAAGs
AoBQAACjzq5WscRn+wIABFla
Here is the same but from Jammy if you want to test encryption on
Jammy and decryption on Lunar/Mantic:
/Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4Cf/ARFdADgbyxDlZ/1Xd7bAmZw7
8pbqQTu5j8StVybo1p1B2ydBc1zK4HR2g3CiLJet+R++nZy/gph6RscQ6hI3
HySjdDOFRfjIVttiNK3DvRsZb37r8SXkj/JCYWicZGjWPZxVE3OAZhEed5qe
jrFv871QAbm4jVGD4oIc4cOb5V/xDN7KWgwEzpWQy6+tcfPm3KLPQvULx56N
2qQf60hP//p5EXS3RpCitUsrGUoYzTynjOUIRy2yCmgZDh62RmchUshyWePa
k0nEYlDbl5/dSHXbWEWESqW+QDj136MZRwQRY+QC4MvLXg2Bo8H+Dl/xvNDF
/5J4layZdFlh76lWOtFRVoIbX6JtpAP34g4zx1422GSNAABRzyqPdCqX
1AABrQKAUAAABh3ynbHEZ/sCAARZWg==
The contents are expected to be different due to the use of
randomness. Don't try to compare the base64 outputs: I'm only using
them to ease testing across containers.
[Where problems could occur]
This patch makes openssl match the documented default (see "man openssl-enc"
and search for "Blowfish" for instance) and fixes decryption from an up-to-date
Jammy to pretty much everything else, but it also create an issue for data
encrypted on Jammy without this patch and Jammy with this patch.
There are two possible cases: encrypted data being streamed across
this boundary or data at rest being transferred or read later.
Streaming is probably not an issue in practice because it's rather the
current situation that has been an issue and it's easy to remedy by
updating everything (which is relatively few machines since that's
only Jammy and not any other OS or distribution).
Data at rest is more annoying since updating Jammy will make it
impossible to read the data again without updates to other pieces of
software. That sounds like a really bad thing and it kind of is but at
the same, the benefits are much larger than the issues. Indeed, there
is already an incompatibility at the moment between Jammy and
everything else and the more time passes by, the more such problematic
files can be
[Touch-packages] [Bug 1990216] Re: backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" to Jammy
On Thu, Oct 26, 2023 at 09:54:51AM -, Simon Chopin wrote:
> I'm very much against uploading this fix as an SRU. While it is a shame
> that we have interop problems with the rest of the world, fixing this in
> Jammy right now means we *will* break production for anyone that stores
> Blowfish-encrypted data.
Simon, just to clarify: the original issue I ran into was not
"interop problems with the rest of the world" exactly, but rather
interop between Tinc nodes running on different versions of
Ubuntu (i.e. a Tinc node running Jammy can't connect to existing
nodes running on older releases). (Though obviously interop will
fail with the rest of the world, too.)
I am not particularly involved in the OpenSSL community, but have
been trying to keep an eye on this specific issue since I ran
into it, and as far as I have noticed/found on the internet there
haven't been any mentions about this OpenSSL bug other than in
the two LP bugs related to this Tinc issue and the related
Github-for-tinc bug ( https://github.com/gsliepen/tinc/issues/414
).
So while I certainly agree in general with need for "apt upgrade"
to be a very safe operation, in this particular case I am not
sure how to weigh the chance that someone might possibly have a
custom app using Blowfish to encrypt local data (while at the
same time not already having in place mechanisms to deal with
this compatibility issue for pre-and-post Jammy Ubuntu) with the
publicly-raised-by-at-least-a-few-people problem of Tinc
incompatibility between nodes that this causes
Nathan
** Bug watch added: github.com/gsliepen/tinc/issues #414
https://github.com/gsliepen/tinc/issues/414
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1990216
Title:
backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL
1.1 with blowfish in OFB or CFB modes" to Jammy
Status in openssl package in Ubuntu:
Fix Released
Status in openssl source package in Jammy:
In Progress
Status in openssl source package in Lunar:
Fix Released
Bug description:
=== SRU information ===
[Meta]
This bug is part of a series of three bugs for a single SRU.
The "central" bug with the global information and debdiff is
http://pad.lv/2033422
[Impact]
Decryption for Blowfish with OFB and CFB modes fails due to using a key
shorter than expected by default.
Encryption will also use a key shorter than expected.
Exchange of encrypted data from/to Jammy using BF OFB/CFB will therefore lead
to decryption issues.
[Test plan]
On Focal, run the following and copy the output to your clipboard
for cipher in bf-cbc bf-cfb bf-ecb bf-ofb; do echo "Test with ${cipher}"
| openssl enc -${cipher} -k test -pbkdf2 -out "pouet.${cipher}"; done
tar c pouet.bf-* | xz | base64 -w 60
You can also run this on Lunar or Mantic if you add "-provider legacy
-provider default" to the "openssl enc" invocation.
On Jammy, run the following and paste your clipboard
base64 -d | xz -d | tar x
for cipher in bf-cbc bf-cfb bf-ecb bf-ofb; do openssl enc -d -provider
legacy -provider default -${cipher} -k test -pbkdf2 -d -in "pouet.${cipher}";
done
Only "Test with bf-cbc" and "Test with bf-ecb" will be properly
decrypted: the other two will result in garbage on screen.
Here is the result of the enc + tar + xz + base64 on Focal (works with
Lunar/Mantic too but you need to added ):
/Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4Cf/ARBdADgbyxDlZ/1Xd7bAmZw7
8pbqQTu5j8StVybo1p1B2ydBc5VcodF6fu0hEp801tvirgSFNMSAHk5HMN/w
hCgU1BIr/nK51g3A3Lkdv7QNbaUw2ux1AmO/MpCLKLffCB9ElFZH4tuOS5AR
m9CJMzi6LQOw9wytGKm2IK3Ph7WpU6JQ/3HJilffQwHbFLnukiWGpLNO5v0O
D/4AJikrU9iemfChT0jXDbIRZ8a8VpVhJqu0u6eYOheVTqmSRiHHpIC/p1VA
ecFb0mACF/TQhjxcMUWGSGO/mtof+VaLiyg0KB87GKlChfwXTEvgbNuP9hmu
GL64VhX568Oy9EakSxlcXiIRk14kJKv0MdHQqY1R22wAACzqSr/nzpwqAAGs
AoBQAACjzq5WscRn+wIABFla
Here is the same but from Jammy if you want to test encryption on
Jammy and decryption on Lunar/Mantic:
/Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4Cf/ARFdADgbyxDlZ/1Xd7bAmZw7
8pbqQTu5j8StVybo1p1B2ydBc1zK4HR2g3CiLJet+R++nZy/gph6RscQ6hI3
HySjdDOFRfjIVttiNK3DvRsZb37r8SXkj/JCYWicZGjWPZxVE3OAZhEed5qe
jrFv871QAbm4jVGD4oIc4cOb5V/xDN7KWgwEzpWQy6+tcfPm3KLPQvULx56N
2qQf60hP//p5EXS3RpCitUsrGUoYzTynjOUIRy2yCmgZDh62RmchUshyWePa
k0nEYlDbl5/dSHXbWEWESqW+QDj136MZRwQRY+QC4MvLXg2Bo8H+Dl/xvNDF
/5J4layZdFlh76lWOtFRVoIbX6JtpAP34g4zx1422GSNAABRzyqPdCqX
1AABrQKAUAAABh3ynbHEZ/sCAARZWg==
The contents are expected to be different due to the use of
randomness. Don't try to compare the base64 outputs: I'm only using
them to ease testing across containers.
[Where problems could occur]
This patch makes openssl match the documented default (see "man openssl-enc"
and search
[Touch-packages] [Bug 1972939] Re: Jammy tinc incompatibile with older (e.g. Xenial) tinc nodes
*** This bug is a duplicate of bug 1990216 *** https://bugs.launchpad.net/bugs/1990216 Just to have links in both directions between various bug trackers: "connecting tinc 1.0.36/libssl3 to older nodes #414" https://github.com/gsliepen/tinc/issues/414 ** Bug watch added: github.com/gsliepen/tinc/issues #414 https://github.com/gsliepen/tinc/issues/414 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1972939 Title: Jammy tinc incompatibile with older (e.g. Xenial) tinc nodes Status in Release Notes for Ubuntu: New Status in openssl package in Ubuntu: Fix Released Status in tinc package in Ubuntu: Invalid Status in openssl source package in Jammy: Confirmed Status in tinc source package in Jammy: Invalid Bug description: The tinc included in Jammy (1.0.36-2build1 linked with libssl3) cannot connect to tinc nodes running e.g. tinc from Xenial (1.0.26-1). (Tinc from Impish, which is also v1.0.36-2 but is linked to libssl1.1, can connect to these nodes without problems.) The symptom is a log message (on the system running Jammy) during the metadata channel negotiation (with debug level set to 5): Error during initialisation of cipher from tinc_xenial [...] error:0308010C:digital envelope routines::unsupported To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1972939/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1990216] Re: backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" to Jammy
Yes, libssl3 3.0.2-0ubuntu1.11~ppa2 appears to fix the Blowfish incompatibility (at least for the original case of connecting to Tinc running on old distributions of Ubuntu). Test steps: disabled the OPENSSL_MODULES workaround I had in place on a my Jammy node, and confirmed that Tinc was unable to connect to the remote Tinc node, and generated "Bogus data received from" syslog error messages (as expected due to this bug). enabled the adrien-n/openssl-jammy-sru PPA, and installed the ...ubuntu1.11~ppa2 versions of openssl and libssl3. restarted the Tinc service... and saw that the Jammy node was once again able to connect to the remote node (without the OPENSSL_MODULES workaround). Let me know if I can provide any other information. (Do you have an ETA for publishing this package to Jammy?) Thanks. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1990216 Title: backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" to Jammy Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Jammy: In Progress Status in openssl source package in Lunar: Fix Released Bug description: OpenSSL upstream implemented a fix for their issue #18359 "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" https://github.com/openssl/openssl/issues/18359 as of libssl3 3.0.4 (and thus it is included in recent libssl3 versions in Kinetic). Could this fix be backported to libssl3 in Jammy? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1990216/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1966203] Re: Syslog shows "systemd-udevd[2837]: nvme0n1: Process ... failed with exit code 1." in Ubuntu 22.04
Seeing this warning message in Jammy, with snapd 2.58+22.04.1 installed. ** Also affects: snapd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1966203 Title: Syslog shows "systemd-udevd[2837]: nvme0n1: Process ... failed with exit code 1." in Ubuntu 22.04 Status in snapd: Confirmed Status in snapd package in Ubuntu: New Status in systemd package in Ubuntu: Invalid Bug description: Configuration: OS:jammy-live-server20220320-amd64.iso CPU:AMD EPYC 7702 64-Core Processor UEFI Version:D8E119A BMC Version:D8BT19I SSD:Intel 1.60TB NVMe SSD Boot mode:legacy Reproduce Steps: 1.Boot into BIOS and set boot mode to legacy 2.install ubuntu 22.04 on NVMe SSD 3.Check syslog log Current behaviors: syslog shows systemd-udevd errors in Ubuntu 22.04 Feb 9 10:16:19 len systemd-udevd[2837]: nvme0n1: Process '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/nvme0n1' failed with exit code 1. Feb 9 10:16:19 len systemd-udevd[2877]: nvme0n1p3: Process '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/nvme0n1p3' failed with exit code 1. Feb 9 10:16:19 len systemd-udevd[2876]: nvme0n1p2: Process '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/nvme0n1p2' failed with exit code 1. Feb 9 10:16:19 len systemd-udevd[2837]: nvme0n1p1: Process '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/nvme0n1p1' failed with exit code 1. Feb 9 10:16:19 len systemd-udevd[2828]: sr0: Process '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/sr0' failed with exit code 1. Feb 9 10:16:19 len systemd-udevd[2850]: dm-0: Process '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/dm-0' failed with exit code 1. To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1966203/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1972939] Re: Jammy tinc incompatibile with older (e.g. Xenial) tinc nodes
(I've opened LP:#1990216 to request that the fix for upstream "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes #18359" be backported to libssl3 in Jammy.) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1972939 Title: Jammy tinc incompatibile with older (e.g. Xenial) tinc nodes Status in Release Notes for Ubuntu: New Status in openssl package in Ubuntu: New Status in tinc package in Ubuntu: New Bug description: The tinc included in Jammy (1.0.36-2build1 linked with libssl3) cannot connect to tinc nodes running e.g. tinc from Xenial (1.0.26-1). (Tinc from Impish, which is also v1.0.36-2 but is linked to libssl1.1, can connect to these nodes without problems.) The symptom is a log message (on the system running Jammy) during the metadata channel negotiation (with debug level set to 5): Error during initialisation of cipher from tinc_xenial [...] error:0308010C:digital envelope routines::unsupported To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1972939/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1990216] [NEW] backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" to Jammy
Public bug reported: OpenSSL upstream implemented a fix for their issue #18359 "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" https://github.com/openssl/openssl/issues/18359 as of libssl3 3.0.4 (and thus it is included in recent libssl3 versions in Kinetic). Could this fix be backported to libssl3 in Jammy? ** Affects: openssl (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1990216 Title: backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" to Jammy Status in openssl package in Ubuntu: New Bug description: OpenSSL upstream implemented a fix for their issue #18359 "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" https://github.com/openssl/openssl/issues/18359 as of libssl3 3.0.4 (and thus it is included in recent libssl3 versions in Kinetic). Could this fix be backported to libssl3 in Jammy? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1990216/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
Re: [Touch-packages] [Bug 1972939] Re: Jammy tinc incompatibile with older (e.g. Xenial) tinc nodes
On Wed, May 18, 2022 at 15:36:30 -, Nathan Stratton Treadway wrote: > On Wed, May 18, 2022 at 13:37:46 -, Simon Chopin wrote: > > Could you give more details about what happens when using the legacy > > providers? > > The short version is that by enabling the legacy provider and setting > SECLEVEL to 1, I'm able to get past the "digital envelope (With the fixed version of OpenSSL's legacy.so, the SECLEVEL=1 configuration change is no longer needed -- tincd's openssl.cnf only needs to activate the "legacy" provider.) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1972939 Title: Jammy tinc incompatibile with older (e.g. Xenial) tinc nodes Status in Release Notes for Ubuntu: New Status in openssl package in Ubuntu: New Status in tinc package in Ubuntu: New Bug description: The tinc included in Jammy (1.0.36-2build1 linked with libssl3) cannot connect to tinc nodes running e.g. tinc from Xenial (1.0.26-1). (Tinc from Impish, which is also v1.0.36-2 but is linked to libssl1.1, can connect to these nodes without problems.) The symptom is a log message (on the system running Jammy) during the metadata channel negotiation (with debug level set to 5): Error during initialisation of cipher from tinc_xenial [...] error:0308010C:digital envelope routines::unsupported To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1972939/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1972939] Re: Jammy tinc incompatibile with older (e.g. Xenial) tinc nodes
On Fri, Aug 05, 2022 at 00:35:32 -, Don wrote: > It appears the issue is resolved in libssl3 3.0.4-1ubuntu1 from kinetic > (in addition to enabling the legacy providers) I installed a Kinetic test environment, and confirmed that I was able to connect to my Xenial tinc (1.0.26-1) instance successfully (with the legacy provider enabled). I noticed that Jammy and Kinetic actually have the same exact tinc package, so I figure the difference in functionality must be in libssl3: Jammy:pool/universe/t/tinc/tinc_1.0.36-2build1_amd64.deb Kinetic: pool/universe/t/tinc/tinc_1.0.36-2build1_amd64.deb I experimented with downgrading the libssl3 package: libssl3 3.0.5-2ubuntu1 (current latest version): worked 3.0.4-1ubuntu1: worked 3.0.3-5ubuntu3: got "Bogus data received from" error message again Further experimentation running tinc with the OPENSSL_MODULES environment variable set confirmed that the tinc connection succeeds if libssl3 3.0.3-5ubuntu3 is installed but the ossl-modules/legacy.so file from 3.0.4-1ubuntu1 is used by the tincd process. Cross-referencing the commit history for legacyprov.c with the the git commit logs for changes between 3.0.3 and .4: https://github.com/openssl/openssl/compare/openssl-3.0.3...openssl-3.0.4 , I found the commit "Fix regression in default key length for Blowfish CFB and OFB ciphers"... which would seem to be the change allows Tinc to work again (since Tinc 1.0.26 uses the Blowfish algorithm for the metadata connection). https://github.com/openssl/openssl/commit/1b8ef23e68b273bb5e59f60df62251153f24768d https://github.com/openssl/openssl/issues/18359 "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" Finally, going back to the original issue on Jammy: I copied the ossl-modules/legacy.so taken from libssl3 3.0.5-2ubuntu1 over to my Jammy instance and pointed OPENSSL_MODULES to that file (in /etc/default/tinc)... and sure enough that allowed my Jammy Tinc node to connect to the Xenial Tinc node successfully as well ** Bug watch added: github.com/openssl/openssl/issues #18359 https://github.com/openssl/openssl/issues/18359 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1972939 Title: Jammy tinc incompatibile with older (e.g. Xenial) tinc nodes Status in Release Notes for Ubuntu: New Status in openssl package in Ubuntu: New Status in tinc package in Ubuntu: New Bug description: The tinc included in Jammy (1.0.36-2build1 linked with libssl3) cannot connect to tinc nodes running e.g. tinc from Xenial (1.0.26-1). (Tinc from Impish, which is also v1.0.36-2 but is linked to libssl1.1, can connect to these nodes without problems.) The symptom is a log message (on the system running Jammy) during the metadata channel negotiation (with debug level set to 5): Error during initialisation of cipher from tinc_xenial [...] error:0308010C:digital envelope routines::unsupported To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1972939/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
Re: [Touch-packages] [Bug 1972939] Re: Jammy tinc incompatibile with older (e.g. Xenial) tinc nodes
On Fri, Aug 05, 2022 at 00:35:32 -, Don wrote: > It appears the issue is resolved in libssl3 3.0.4-1ubuntu1 from kinetic > (in addition to enabling the legacy providers) Thanks for that hint. Can you provide any additional details on your Tinc environment and what exactly allowed the connection to start working? For example, did you previously attempt to connect a Tinc node running Kinentic to a Xenial node and have it fail, but then see it start working once you upgraded libssl3 to the 3.0.4-1ubuntu1 release? Nathan -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1972939 Title: Jammy tinc incompatibile with older (e.g. Xenial) tinc nodes Status in Release Notes for Ubuntu: New Status in openssl package in Ubuntu: New Status in tinc package in Ubuntu: New Bug description: The tinc included in Jammy (1.0.36-2build1 linked with libssl3) cannot connect to tinc nodes running e.g. tinc from Xenial (1.0.26-1). (Tinc from Impish, which is also v1.0.36-2 but is linked to libssl1.1, can connect to these nodes without problems.) The symptom is a log message (on the system running Jammy) during the metadata channel negotiation (with debug level set to 5): Error during initialisation of cipher from tinc_xenial [...] error:0308010C:digital envelope routines::unsupported To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1972939/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
Re: [Touch-packages] [Bug 1972939] Re: Jammy tinc incompatibile with older (e.g. Xenial) tinc nodes
On Wed, May 18, 2022 at 13:41:06 -, Simon Chopin wrote: > Also, does tinc work in a purely Jammy context? :-) Sorry, I just realized that I had not mentioned here on this bug the results of my tests between various Ubuntu versions. I didn't test Jammy-to-Jammy, but (briefly): * Jammy (1.0.36/libssl3) to Xenial (1.0.26/libssl1.0.0) fails * Impish (1.0.36/libssl1.1) works to both Jammy and Xenial (no openssl.cnf changes needed on any node) * Focal (also 1.0.36/libssl1.1]) worked to Xenial. (I did not test that to Jammy.) * Jammy to Bionic (1.0.33/libssl1.1) works (no openssl.cnf changes needed) (I did not test point-releases between Xenial and Bionic.) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1972939 Title: Jammy tinc incompatibile with older (e.g. Xenial) tinc nodes Status in Release Notes for Ubuntu: New Status in openssl package in Ubuntu: New Status in tinc package in Ubuntu: New Bug description: The tinc included in Jammy (1.0.36-2build1 linked with libssl3) cannot connect to tinc nodes running e.g. tinc from Xenial (1.0.26-1). (Tinc from Impish, which is also v1.0.36-2 but is linked to libssl1.1, can connect to these nodes without problems.) The symptom is a log message (on the system running Jammy) during the metadata channel negotiation (with debug level set to 5): Error during initialisation of cipher from tinc_xenial [...] error:0308010C:digital envelope routines::unsupported To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1972939/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
Re: [Touch-packages] [Bug 1972939] Re: Jammy tinc incompatibile with older (e.g. Xenial) tinc nodes
On Wed, May 18, 2022 at 13:37:46 -, Simon Chopin wrote: > Could you give more details about what happens when using the legacy > providers? The short version is that by enabling the legacy provider and setting SECLEVEL to 1, I'm able to get past the "digital envelope routines::unsupported" error during the tinc metadata channel setup... but the Jammy node still (just a step or two later in the negotiation process) reports a "Bogus data received from" error and then aborts the connection. The "Bogus data received from" error is a tinc error message, but as far as I can tell the likely trigger for that message is some sort of failure to decrypt incoming data by the OpenSSL library -- and since Focal, Impish and Jammy all have exactly the same tinc version, it would seem the issue is libssl3-related... but I am not sure precisely how You can find additional details in this tinc-mailing-list thread: https://www.tinc-vpn.org/pipermail/tinc/2022-May/005598.html (but so far the discussion there hasn't managed to narrow down the exact interaction between tinc and libssl that's causing the problem). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1972939 Title: Jammy tinc incompatibile with older (e.g. Xenial) tinc nodes Status in Release Notes for Ubuntu: New Status in openssl package in Ubuntu: New Status in tinc package in Ubuntu: New Bug description: The tinc included in Jammy (1.0.36-2build1 linked with libssl3) cannot connect to tinc nodes running e.g. tinc from Xenial (1.0.26-1). (Tinc from Impish, which is also v1.0.36-2 but is linked to libssl1.1, can connect to these nodes without problems.) The symptom is a log message (on the system running Jammy) during the metadata channel negotiation (with debug level set to 5): Error during initialisation of cipher from tinc_xenial [...] error:0308010C:digital envelope routines::unsupported To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1972939/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
Re: [Touch-packages] [Bug 1972939] Re: Jammy tinc incompatibile with older (e.g. Xenial) tinc nodes
On Wed, May 18, 2022 at 13:41:06 -, Simon Chopin wrote: > Also, does tinc work in a purely Jammy context? :-) As far as I can determine the issue relates to compatibility between libssl3 and the algorithms used by the Xenial-era tinc, and thus I can't imagine Jammy-to-Jammy would be a problem -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1972939 Title: Jammy tinc incompatibile with older (e.g. Xenial) tinc nodes Status in Release Notes for Ubuntu: New Status in openssl package in Ubuntu: New Status in tinc package in Ubuntu: New Bug description: The tinc included in Jammy (1.0.36-2build1 linked with libssl3) cannot connect to tinc nodes running e.g. tinc from Xenial (1.0.26-1). (Tinc from Impish, which is also v1.0.36-2 but is linked to libssl1.1, can connect to these nodes without problems.) The symptom is a log message (on the system running Jammy) during the metadata channel negotiation (with debug level set to 5): Error during initialisation of cipher from tinc_xenial [...] error:0308010C:digital envelope routines::unsupported To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1972939/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
Re: [Touch-packages] [Bug 1972939] Re: Jammy tinc incompatibile with older (e.g. Xenial) tinc nodes
On Wed, May 18, 2022 at 07:42:04 -, Simon Chopin wrote: > I'm guessing there are some SSL certificates involved? If so, this issue Tinc uses openssl's implementations of specific alogorithms, but does not use either TLS or SSL certificates. (So I don't think the Tinc situation is covered by the existing OpenSSL 3.0 section of the Release Notes document.) The Xenial version of Tinc uses the Blowfish algorithm for the metadata connection, which openssl3 does move to the legacy provider -- but even though enabling the legacy provider on the Jammy node allows the connenction setup to get further along, it's not sufficient to get a working connection -- the libssl3 transition seems to have affected some other aspect of the connection as well... -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1972939 Title: Jammy tinc incompatibile with older (e.g. Xenial) tinc nodes Status in Release Notes for Ubuntu: New Status in openssl package in Ubuntu: New Status in tinc package in Ubuntu: New Bug description: The tinc included in Jammy (1.0.36-2build1 linked with libssl3) cannot connect to tinc nodes running e.g. tinc from Xenial (1.0.26-1). (Tinc from Impish, which is also v1.0.36-2 but is linked to libssl1.1, can connect to these nodes without problems.) The symptom is a log message (on the system running Jammy) during the metadata channel negotiation (with debug level set to 5): Error during initialisation of cipher from tinc_xenial [...] error:0308010C:digital envelope routines::unsupported To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1972939/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1972939] Re: Jammy tinc incompatibile with older (e.g. Xenial) tinc nodes
** Also affects: openssl (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1972939 Title: Jammy tinc incompatibile with older (e.g. Xenial) tinc nodes Status in Release Notes for Ubuntu: New Status in openssl package in Ubuntu: New Status in tinc package in Ubuntu: New Bug description: The tinc included in Jammy (1.0.36-2build1 linked with libssl3) cannot connect to tinc nodes running e.g. tinc from Xenial (1.0.26-1). (Tinc from Impish, which is also v1.0.36-2 but is linked to libssl1.1, can connect to these nodes without problems.) The symptom is a log message (on the system running Jammy) during the metadata channel negotiation (with debug level set to 5): Error during initialisation of cipher from tinc_xenial [...] error:0308010C:digital envelope routines::unsupported To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1972939/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1764172] Re: Unable to change hostname from the one specified during Bionic server installation
(In addition to the one mentioned by WirelessMoves, I found several other Ubuntu Forum threads as well as blog posts, etc. which recommend working around this problem by editing the /etc/cloud/cloud.cfg file to set the "preserve_hostname:" line's value to "true". However, that approach means there would be a conffile conflict whenever the cloud- init package is upgraded, so a better solution in the long run is probably to create a new file in /etc/cloud/cloud.cfg.d/ with that setting instead.) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to hostname in Ubuntu. https://bugs.launchpad.net/bugs/1764172 Title: Unable to change hostname from the one specified during Bionic server installation Status in Release Notes for Ubuntu: New Status in hostname package in Ubuntu: Confirmed Status in subiquity package in Ubuntu: New Bug description: In Bionic Beta 2 I am not able on a host or in a guest VM to change the hostname of a Bionic Beta 2 installation by changing /etc/hostname. The name in the file can be changed but it always reverts to the hostname configured during installation. In the following thread on the topic it is suggested to remove a number of cloud packages. When doing this in a VM install I could change the hostname again via /etc/hostname. https://ubuntuforums.org/showthread.php?t=2389098=2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1764172/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1764172] Re: Unable to change hostname from the one specified during Bionic server installation
Presumably the ideal solution would be for Subiquity to hand off to cloud-init in a manner that really only ran on that very first boot of the new system. However, assuming that a true fix to that situation is too invasive to be included into Bionic at this point, it seems like it might be a good idea to at least mention the issue (and recommended workaround) in the Bionic release notes. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to hostname in Ubuntu. https://bugs.launchpad.net/bugs/1764172 Title: Unable to change hostname from the one specified during Bionic server installation Status in Release Notes for Ubuntu: New Status in hostname package in Ubuntu: Confirmed Status in subiquity package in Ubuntu: New Bug description: In Bionic Beta 2 I am not able on a host or in a guest VM to change the hostname of a Bionic Beta 2 installation by changing /etc/hostname. The name in the file can be changed but it always reverts to the hostname configured during installation. In the following thread on the topic it is suggested to remove a number of cloud packages. When doing this in a VM install I could change the hostname again via /etc/hostname. https://ubuntuforums.org/showthread.php?t=2389098=2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1764172/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1764172] Re: Unable to change hostname from the one specified during Bionic server installation
When installing Ubuntu Server using Subiquity (i.e. using the
ubuntu-18.04-live-server-amd64.iso installer image), the user is
prompted to enter a hostname for the new installation (along with
username/password info, etc.)
At the very end of the Subquity run, it writes this info into
var/lib/cloud/seed/nocloud-net/user-data within the installation target
filesystem (e.g.
==
root@bionic:/var/lib/cloud# head -6 seed/nocloud-net/user-data
#cloud-config
growpart: {mode: 'off'}
hostname: bionic
locale: en_US.UTF-8
resize_rootfs: false
users:
==
)
When the newly-installed system is booted for the first time, this file
causes cloud-init finish up the configuration of the new instance --
include setting the new system's hostname to the specified value as part
of that initial boot.
However, cloud-init on Bionic (e.g. 19.2-36-g059d049c-0ubuntu2~18.04.1)
calls the cc_set_hostname module upon every boot (from within the
cmd/main.py:main_init() function, thus overriding the normal "per-
instance" frequency for the module)...
...and because the "hostname" cloud-config parameter is found to be set,
the cc_set_hostname module will always re-write /etc/hostname back to
the originally-entered hostname at that point -- unexpectedly undoing
the user's manual change to the file.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to hostname in Ubuntu.
https://bugs.launchpad.net/bugs/1764172
Title:
Unable to change hostname from the one specified during Bionic server
installation
Status in Release Notes for Ubuntu:
New
Status in hostname package in Ubuntu:
Confirmed
Status in subiquity package in Ubuntu:
New
Bug description:
In Bionic Beta 2 I am not able on a host or in a guest VM to change
the hostname of a Bionic Beta 2 installation by changing
/etc/hostname. The name in the file can be changed but it always
reverts to the hostname configured during installation.
In the following thread on the topic it is suggested to remove a
number of cloud packages. When doing this in a VM install I could
change the hostname again via /etc/hostname.
https://ubuntuforums.org/showthread.php?t=2389098=2
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-release-notes/+bug/1764172/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1764172] Re: Unable to change hostname from the one specified during Bionic server installation
** Also affects: ubuntu-release-notes Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to hostname in Ubuntu. https://bugs.launchpad.net/bugs/1764172 Title: Unable to change hostname from the one specified during Bionic server installation Status in Release Notes for Ubuntu: New Status in hostname package in Ubuntu: Confirmed Status in subiquity package in Ubuntu: New Bug description: In Bionic Beta 2 I am not able on a host or in a guest VM to change the hostname of a Bionic Beta 2 installation by changing /etc/hostname. The name in the file can be changed but it always reverts to the hostname configured during installation. In the following thread on the topic it is suggested to remove a number of cloud packages. When doing this in a VM install I could change the hostname again via /etc/hostname. https://ubuntuforums.org/showthread.php?t=2389098=2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1764172/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1764172] Re: Unable to change hostname specified during Bionic server installation
** Summary changed: - Unable to change hostname + Unable to change hostname specified during Bionic server installation ** Also affects: subiquity (Ubuntu) Importance: Undecided Status: New ** Summary changed: - Unable to change hostname specified during Bionic server installation + Unable to change hostname from the one specified during Bionic server installation -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to hostname in Ubuntu. https://bugs.launchpad.net/bugs/1764172 Title: Unable to change hostname from the one specified during Bionic server installation Status in hostname package in Ubuntu: Confirmed Status in subiquity package in Ubuntu: New Bug description: In Bionic Beta 2 I am not able on a host or in a guest VM to change the hostname of a Bionic Beta 2 installation by changing /etc/hostname. The name in the file can be changed but it always reverts to the hostname configured during installation. In the following thread on the topic it is suggested to remove a number of cloud packages. When doing this in a VM install I could change the hostname again via /etc/hostname. https://ubuntuforums.org/showthread.php?t=2389098=2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/hostname/+bug/1764172/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
Re: [Touch-packages] [Bug 1797872] Re: ntpd keeps Soliciting pool server
On Fri, Oct 19, 2018 at 14:36:35 -, Manuel López-Ibáñez wrote: > $ timedatectl status > Network time on: yes > NTP synchronized: yes > > So it seems it is synchronized, it just re-tries too frequently. (I am not sure what exactly timedatectl looks at when checking the status of ntpd, but the fact that in the ntpq output all your servers show a stratum of 16 and a reach of 0 means that ntpd is defintely not synchronized to anything When it's functioning properly, your pool server stratums should show up somewhere between 1 and 3 or 4, and the reach will be an octal flag showing progressively more bits turned on as responses are received from the server in question [e.g. 1, 3, 7, 17, 37... on until 377, assuming that there aren't any lost packets along the way].) Nathan -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ntp in Ubuntu. https://bugs.launchpad.net/bugs/1797872 Title: ntpd keeps Soliciting pool server Status in ntp package in Ubuntu: New Bug description: ntpd keeps printing "Soliciting pool server" in the syslog (once every 5 seconds). $ ntpq -c pe remote refid st t when poll reach delay offset jitter == 0.ubuntu.pool.n .POOL. 16 p- 6400.0000.000 0.000 1.ubuntu.pool.n .POOL. 16 p- 6400.0000.000 0.000 2.ubuntu.pool.n .POOL. 16 p- 6400.0000.000 0.000 3.ubuntu.pool.n .POOL. 16 p- 6400.0000.000 0.000 ntp.ubuntu.com .POOL. 16 p- 6400.0000.000 0.000 $ sudo ntpq -c rv associd=0 status=c016 leap_alarm, sync_unspec, 1 event, restart, version="ntpd 4.2.8p4@1.3265-o Fri Jul 6 20:10:51 UTC 2018 (1)", processor="x86_64", system="Linux/4.15.0-33-generic", leap=11, stratum=16, precision=-24, rootdelay=0.000, rootdisp=0.360, refid=INIT, reftime=. Thu, Feb 7 2036 6:28:16.000, clock=df6ee808.934d239d Mon, Oct 15 2018 11:18:48.575, peer=0, tc=3, mintc=3, offset=0.00, frequency=6.224, sys_jitter=0.00, clk_jitter=0.000, clk_wander=0.000 I have changed nothing in the default configuration of ntp or the firewall. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: ntp 1:4.2.8p4+dfsg-3ubuntu5.9 ProcVersionSignature: Ubuntu 4.15.0-33.36~16.04.1-generic 4.15.18 Uname: Linux 4.15.0-33-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.18 Architecture: amd64 CurrentDesktop: KDE Date: Mon Oct 15 11:17:45 2018 InstallationDate: Installed on 2018-04-20 (177 days ago) InstallationMedia: Ubuntu 16.04.3 LTS "Xenial Xerus" - Release amd64 (20170801) SourcePackage: ntp UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1797872/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
Re: [Touch-packages] [Bug 1797872] Re: ntpd keeps Soliciting pool server
On Fri, Oct 19, 2018 at 14:36:35 -, Manuel López-Ibáñez wrote: > Both of them work. I don't understand how the last command can work and > I may still be behind a firewall. "ntpdate -d" sends packets using an unprivileged source port, so a firewall could allow those packets but block outgoing packets from ntpd itself, which use a source port of 123 Nathan -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ntp in Ubuntu. https://bugs.launchpad.net/bugs/1797872 Title: ntpd keeps Soliciting pool server Status in ntp package in Ubuntu: New Bug description: ntpd keeps printing "Soliciting pool server" in the syslog (once every 5 seconds). $ ntpq -c pe remote refid st t when poll reach delay offset jitter == 0.ubuntu.pool.n .POOL. 16 p- 6400.0000.000 0.000 1.ubuntu.pool.n .POOL. 16 p- 6400.0000.000 0.000 2.ubuntu.pool.n .POOL. 16 p- 6400.0000.000 0.000 3.ubuntu.pool.n .POOL. 16 p- 6400.0000.000 0.000 ntp.ubuntu.com .POOL. 16 p- 6400.0000.000 0.000 $ sudo ntpq -c rv associd=0 status=c016 leap_alarm, sync_unspec, 1 event, restart, version="ntpd 4.2.8p4@1.3265-o Fri Jul 6 20:10:51 UTC 2018 (1)", processor="x86_64", system="Linux/4.15.0-33-generic", leap=11, stratum=16, precision=-24, rootdelay=0.000, rootdisp=0.360, refid=INIT, reftime=. Thu, Feb 7 2036 6:28:16.000, clock=df6ee808.934d239d Mon, Oct 15 2018 11:18:48.575, peer=0, tc=3, mintc=3, offset=0.00, frequency=6.224, sys_jitter=0.00, clk_jitter=0.000, clk_wander=0.000 I have changed nothing in the default configuration of ntp or the firewall. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: ntp 1:4.2.8p4+dfsg-3ubuntu5.9 ProcVersionSignature: Ubuntu 4.15.0-33.36~16.04.1-generic 4.15.18 Uname: Linux 4.15.0-33-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.18 Architecture: amd64 CurrentDesktop: KDE Date: Mon Oct 15 11:17:45 2018 InstallationDate: Installed on 2018-04-20 (177 days ago) InstallationMedia: Ubuntu 16.04.3 LTS "Xenial Xerus" - Release amd64 (20170801) SourcePackage: ntp UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1797872/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 962616] Re: mii-tool assumes NIC names of the form eth* when given no interface(s) as argument
I'm not at all familiar with the net-tools source, but here's a quick proof-of-concept patch to pull the list of interface names out of /proc/net/dev (silently skipping any that don't support the SIOCGMIIPHY ioctl [lo, lxcbr0, etc.]). = first example = ./mii-tool_lp962616 enp4s0: negotiated 100baseTx-FD, link ok enp9s0: no link enp8s0: negotiated 1000baseT-FD flow-control, link ok enp6s0: negotiated 1000baseT-FD flow-control, link ok = second example = ./mii-tool_lp962616 eno1: negotiated 1000baseT-FD flow-control, link ok SIOCGMIIPHY on 'eno2' failed: Resource temporarily unavailable (Obviously one downside of /proc/net/dev is that it isn't always in alphabetical order...) ** Patch added: "mii-tool interface-name searching" https://bugs.launchpad.net/ubuntu/+source/net-tools/+bug/962616/+attachment/4696078/+files/mii-tool.c_lp962616.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to net-tools in Ubuntu. https://bugs.launchpad.net/bugs/962616 Title: mii-tool assumes NIC names of the form eth* when given no interface(s) as argument Status in net-tools package in Ubuntu: Confirmed Bug description: On a system with biosdevname enabled, which names NICs in the forms em* and p*p*, mii-tool will return the message "no MII interfaces found" if mii-tool is called without specifying an interface. The correct behavior would be to iterate through em* and p*p*. (More information on biosdevname can be found at http://linux.dell.com/files/whitepapers/consistent_network_device_naming_in_linux.pdf.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/net-tools/+bug/962616/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 962616] Re: mii-tool assumes NIC names of the form eth* when given no interface(s) as argument
> Upstream fix http://net-tools.git.sourceforge.net/git/gitweb.cgi?p =net-tools/net- tools;a=commitdiff;h=9dc3a20511a409e1de1a41d715a10028d3bc1b56 This commit can be found at this updated URL: https://sourceforge.net/p/net-tools/code/ci/9dc3a20511a409e1de1a41d715a10028d3bc1b56/ Not that the approach taken by this commit is to change the mii-tools command to require interface names to be specified on the command line, rather than updating the program to do a more robust search for defined interfaces. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to net-tools in Ubuntu. https://bugs.launchpad.net/bugs/962616 Title: mii-tool assumes NIC names of the form eth* when given no interface(s) as argument Status in net-tools package in Ubuntu: Confirmed Bug description: On a system with biosdevname enabled, which names NICs in the forms em* and p*p*, mii-tool will return the message "no MII interfaces found" if mii-tool is called without specifying an interface. The correct behavior would be to iterate through em* and p*p*. (More information on biosdevname can be found at http://linux.dell.com/files/whitepapers/consistent_network_device_naming_in_linux.pdf.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/net-tools/+bug/962616/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 962616] Re: mii-tool assumes NIC names of the form eth* when given no interface(s) as argument
Since Xenial now uses "predictable" interface naming schemes, mii-tool's limit will affect most systems. = first example = # mii-tool no MII interfaces found # mii-tool $(cd /sys/class/net/; ls -d en*) enp4s0: negotiated 100baseTx-FD, link ok enp6s0: negotiated 1000baseT-FD flow-control, link ok enp8s0: negotiated 1000baseT-FD flow-control, link ok enp9s0: no link = second example = # mii-tool no MII interfaces found # mii-tool $(cd /sys/class/net/; ls -d en*) eno1: negotiated 1000baseT-FD flow-control, link ok SIOCGMIIPHY on 'eno2' failed: Resource temporarily unavailable ** Tags added: xenial -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to net-tools in Ubuntu. https://bugs.launchpad.net/bugs/962616 Title: mii-tool assumes NIC names of the form eth* when given no interface(s) as argument Status in net-tools package in Ubuntu: Confirmed Bug description: On a system with biosdevname enabled, which names NICs in the forms em* and p*p*, mii-tool will return the message "no MII interfaces found" if mii-tool is called without specifying an interface. The correct behavior would be to iterate through em* and p*p*. (More information on biosdevname can be found at http://linux.dell.com/files/whitepapers/consistent_network_device_naming_in_linux.pdf.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/net-tools/+bug/962616/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1597909] Re: systemd-timesyncd unit still running after installation of ntp package
Here are my current versions of the affected packages: # dpkg -l ntp systemd | cat Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==-===--= ii ntp1:4.2.8p4+dfsg-3ubuntu5 amd64Network Time Protocol daemon and utility programs ii systemd229-4ubuntu6amd64system and service manager -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ntp in Ubuntu. https://bugs.launchpad.net/bugs/1597909 Title: systemd-timesyncd unit still running after installation of ntp package Status in ntp package in Ubuntu: New Bug description: I recently installed the ntp package on a fairly vanilla installed- from-DVD Xenial system, and noticed that after the package installation both systemd-timesyncd and ntp were running: # systemctl status ntp systemd-timesyncd.service --no-pager ntp.service - LSB: Start NTP daemon Loaded: loaded (/etc/init.d/ntp; bad; vendor preset: enabled) Active: active (running) since Tue 2016-06-28 19:21:16 HDT; 6min ago Docs: man:systemd-sysv-generator(8) CGroup: /system.slice/ntp.service 3364 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 112:118 [...log lines...] systemd-timesyncd.service - Network Time Synchronization Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled) Drop-In: /lib/systemd/system/systemd-timesyncd.service.d `-disable-with-time-daemon.conf Active: active (running) since Sun 2016-06-26 06:53:05 HDT; 2 days ago Docs: man:systemd-timesyncd.service(8) Main PID: 821 (systemd-timesyn) Status: "Synchronized to time server 91.189.89.199:123 (ntp.ubuntu.com)." CGroup: /system.slice/systemd-timesyncd.service 821 /lib/systemd/systemd-timesyncd [...log lines...] I was able to do "systemctl stop systemd-timesyncd.service" manually without any trouble, but presumably if I hadn't noticed the situation I might have had problems with the two services both running simultaneously until my next reboot. (Once the systemd-timesyncd service is stopped, it is prevented from starting again by the constraint in the disable-with-time-daemon.conf file.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1597909/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1597909] [NEW] systemd-timesyncd unit still running after installation of ntp package
Public bug reported: I recently installed the ntp package on a fairly vanilla installed-from- DVD Xenial system, and noticed that after the package installation both systemd-timesyncd and ntp were running: # systemctl status ntp systemd-timesyncd.service --no-pager ntp.service - LSB: Start NTP daemon Loaded: loaded (/etc/init.d/ntp; bad; vendor preset: enabled) Active: active (running) since Tue 2016-06-28 19:21:16 HDT; 6min ago Docs: man:systemd-sysv-generator(8) CGroup: /system.slice/ntp.service 3364 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 112:118 [...log lines...] systemd-timesyncd.service - Network Time Synchronization Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled) Drop-In: /lib/systemd/system/systemd-timesyncd.service.d `-disable-with-time-daemon.conf Active: active (running) since Sun 2016-06-26 06:53:05 HDT; 2 days ago Docs: man:systemd-timesyncd.service(8) Main PID: 821 (systemd-timesyn) Status: "Synchronized to time server 91.189.89.199:123 (ntp.ubuntu.com)." CGroup: /system.slice/systemd-timesyncd.service 821 /lib/systemd/systemd-timesyncd [...log lines...] I was able to do "systemctl stop systemd-timesyncd.service" manually without any trouble, but presumably if I hadn't noticed the situation I might have had problems with the two services both running simultaneously until my next reboot. (Once the systemd-timesyncd service is stopped, it is prevented from starting again by the constraint in the disable-with-time-daemon.conf file.) ** Affects: ntp (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ntp in Ubuntu. https://bugs.launchpad.net/bugs/1597909 Title: systemd-timesyncd unit still running after installation of ntp package Status in ntp package in Ubuntu: New Bug description: I recently installed the ntp package on a fairly vanilla installed- from-DVD Xenial system, and noticed that after the package installation both systemd-timesyncd and ntp were running: # systemctl status ntp systemd-timesyncd.service --no-pager ntp.service - LSB: Start NTP daemon Loaded: loaded (/etc/init.d/ntp; bad; vendor preset: enabled) Active: active (running) since Tue 2016-06-28 19:21:16 HDT; 6min ago Docs: man:systemd-sysv-generator(8) CGroup: /system.slice/ntp.service 3364 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 112:118 [...log lines...] systemd-timesyncd.service - Network Time Synchronization Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled) Drop-In: /lib/systemd/system/systemd-timesyncd.service.d `-disable-with-time-daemon.conf Active: active (running) since Sun 2016-06-26 06:53:05 HDT; 2 days ago Docs: man:systemd-timesyncd.service(8) Main PID: 821 (systemd-timesyn) Status: "Synchronized to time server 91.189.89.199:123 (ntp.ubuntu.com)." CGroup: /system.slice/systemd-timesyncd.service 821 /lib/systemd/systemd-timesyncd [...log lines...] I was able to do "systemctl stop systemd-timesyncd.service" manually without any trouble, but presumably if I hadn't noticed the situation I might have had problems with the two services both running simultaneously until my next reboot. (Once the systemd-timesyncd service is stopped, it is prevented from starting again by the constraint in the disable-with-time-daemon.conf file.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1597909/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1362481] Re: openldap upgrade fails. chwon of olcDbDirectory, /var/lib/ldap not empty and missing backup of suffix
If you are working on cleaning up the slapd.postinst script, you may
find some of these related discussions to be interesting and/or
helpful...:
LP: #450645 error during slapd configuration: chown: cannot access
`olcDbDirectory\nolcDbDirectory'
LP: #632051 Improve slapd postinst error message in case database directory
can't be determined for a given LDAP suffix
LP: #571498 slapd.postinst should put all backed-up items together in one
place under /var/backups
LP: #571481 when slapd upgrade fails, later upgrade attempts overwrite saved
backups of pre-upgrade configuration files
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1362481
Title:
openldap upgrade fails. chwon of olcDbDirectory, /var/lib/ldap not
empty and missing backup of suffix
Status in “openldap” package in Ubuntu:
In Progress
Status in “openldap” package in Debian:
New
Bug description:
Upgrading from Ubuntu 12.04.5 LTS to 14.04.1 LTS
(slapd-2.4.28-1.1ubuntu4.4 to slapd-2.4.31-1+nmu2ubuntu8), it fails
horribly on my setup with one disk-backend and one ldap-backend (sync
to another server).
First, dump_databases in
/var/lib/dpkg/info/slapd.{config,preinst,postinst} fails due to
get_directory returning olcDbDirectory instead of /var/lib/ldap.
This is caused by a missing -h to grep, causing another : in the
returned line, thus causing the '| cut -d: -f 2' to get the wrong part
of the line. This causes both the backup of the suffix to fail, and
later the chown after restore to fail.
grep olcDbDirectory: `grep -l olcSuffix: ...
should have been
grep -h olcDbDirectory: `grep -l olcSuffix: ...
later, get_suffix causes the same suffix to be reported twice, thus
causing database load to fail on the second round of the while since
/var/lib/ldap is already loaded with the correct files, but is
expected to be empty. I fixed it with a '| sort -u' in get_suffix, but
i guess it would be better to maybe redo load_databases' while loop to
get both suffix and dbdir (since you can have the same suffix stored
in more than one location, as I have, and thus first getting the
suffix and then doing a grep for the olcDbDirectory in get_directory
will cause the same storage to be reported for both instances of the
suffix)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1362481/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1348343] [NEW] resolvconf 1.69ubuntu1.1 includes non-Upstart /etc/init.d/resolvconf script
Public bug reported: I noticed that when my Trusty systems upgrade from resolvconf 1.69ubuntu1 to 1.69ubuntu1.1 (from trusty-updates), /etc/init.d/resolvconf is changed from a symlink pointing to /lib/init/upstart into a normal file containing the Debian sysinit startup script. Is that change intentional? (It's not mentioned in the changelog entry.) Nathan ** Affects: resolvconf (Ubuntu) Importance: Undecided Status: New ** Tags: trusty ** Tags added: trusty -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1348343 Title: resolvconf 1.69ubuntu1.1 includes non-Upstart /etc/init.d/resolvconf script Status in “resolvconf” package in Ubuntu: New Bug description: I noticed that when my Trusty systems upgrade from resolvconf 1.69ubuntu1 to 1.69ubuntu1.1 (from trusty-updates), /etc/init.d/resolvconf is changed from a symlink pointing to /lib/init/upstart into a normal file containing the Debian sysinit startup script. Is that change intentional? (It's not mentioned in the changelog entry.) Nathan To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1348343/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
