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
> up
** 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
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
>
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
** 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.
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
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 in
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-enc
*** 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
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
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://b
(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, whi
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 i
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
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 succe
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 connect
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.
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" err
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.
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 t
** 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
(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
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
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
** 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
** 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
+ U
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
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
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: negotiat
> 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 appr
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, l
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
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 d
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
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 int
35 matches
Mail list logo
