[Touch-packages] [Bug 1892798] Re: systemd package missing resolvconf(8) compatibility symlink, and a Provides: resolvconf
I think he meant to post this on https://bugs.launchpad.net/ubuntu/+source/wireguard/+bug/1950317 -- 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/1892798 Title: systemd package missing resolvconf(8) compatibility symlink, and a Provides: resolvconf Status in systemd package in Ubuntu: Won't Fix Status in wireguard package in Ubuntu: Confirmed Status in systemd package in Debian: Incomplete Bug description: By default Ubuntu now uses systemd to manage the nameservers in resolv.conf, so resolvconf and openresolv seem to be redundant. However, it appears that systemd's resolvectl is compatable with resolvconf style commands if symlinked as resolvconf. I'm not really sure how deb packaging works, but if it possible to check for the resolvconf command, and if not found just symlink /usr/bin/resolvectl to /usr/sbin/resolvconf then wg-quick will work without additional packages. See https://manpages.ubuntu.com/manpages/focal/man1/resolvectl.1#compatibility%20with%20resolvconf(8) for more info. Apologies if there is a better place to direct this info. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1892798/+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 1892798] Re: systemd package missing resolvconf(8) compatibility symlink, and a Provides: resolvconf
Your four appended comments are super full of just plain wrong information. I'll try to unpack these all piecemeal: > Ubuntu/Debian has never used openresolv This is not the case. Ubuntu and Debian have provided openresolv for a very long time, and resolvconf has mostly been an unmaintained mess. Most users who do DNS stuff wind up switching from resolvconf to openresolv if their OS comes preinstalled with resolvconf, and you'll find a lot of blogs advocating that too. Openresolv has definitely been part of the Debian/Ubuntu verse for a long time. > and yes systemd-resolved had a contribution to have openresolv compatible input interface. "had a contribution" what? Lennart wrote that code. It wasn't just some random third party contribution that got accidentally merged or something. The maintainer of the project wrote it and merged it. Why did he do that? Because resolvconf(8) is the standard stack-agnostic CLI interface for managing DNS on Linux. It's not some "legacy" thing or a "compatibility" thing, but a standard thing. Ensuring that systemd provides that was important for systemd to be able to become a drop in replacement for standard uniform resolver infra. > I am not asking for wireguard to implement any legacy/compat interfaces, but use directly systemd-resolved standard interface which has abi guarantees. Wha?! You've got it all backwards here. WireGuard uses resolvconf(8), because that's the standard Linux mechanism for managing DNS resolution. It will *not* use some specific backend, or write support for 20 different backends, because the resolvconf(8) is a successful abstraction over these so that application writers need not include a massive list of various things to try. So no, sorry, asking an upstream to implement some random newfangled thing isn't going to fly: Linux has a standard interface already for this kind of thing, which systemd implements because systemd is a caring citizen in the Linux-verse, and you're just crippling your users by *not* providing this standard interface. Please quit trying to introduce more fragmentation and shoving the burden of that upstream to application writers, in order to support your OS. Rather, play nicely with others, and provide the standard interfaces. Two of your upstreams are working together for this -- systemd provides a resolvconf(8), and wireguard uses a resolvconf(8). But for some bad reason you want to take away the standard link between the two and instead impose vendor-specific things on upstreams. This is a waste of everybody's time and makes code harder to maintain. > There is a lot more things and options one can provide to systemd-resolved > via native API that is impossible to specify via openresolv or > compat-openresolv. So what? resolvconf(8) provides a good acceptable abstraction for most use cases, which is why application writers use it. If somebody needs to dip down below the abstraction, so be it, but that's mostly not the case, and it certainly isn't the case here. > I do not wish to ship any openresolv/resolvconf/compat symlinks at all going > forward. Please, stop adding fragmentation. You're doing a disservice to both your users and your upstreams. The result is that things will stop working on Ubuntu, or you'll convince a few upstreams to incorporate brain damaged Ubuntu-specific hacks, as is commonly the case. Don't do this. > Integration with resolvconf _without_ using .$suffix of where the DNS > information is originating is incorrect integration on Debian/Ubuntu, because > of how resolvconf is shipped and configured on Debian/Ubuntu and used by > other packages. > > Arch used to use openresolv, openresolv compat was added to systemd-resolved, > and yes hence they were able to switch to systemd-resolved providing > openresolv symlink / compat / integration. Either by default, or as an option. > > That is not possible for Debian/Ubuntu because of more than three dozen of > packaging & hooks, calling resolvconf with .$suffix notation. Your reasoning here doesn't make sense. If you're removing resolvconf(8), all packages and hooks will stop working. If you're replacing broken Debian resolvconf(8) with compliant openresolv or systemd-resolvconf, it's either the same exact situation, or it's a situation that's slightly less bad. And, fixing the .$suffix notation seems a lot easier than refactoring everything anyway. Either way, you might have to do work. But, seeing as openresolv is *already* something available to users and *already* something that users use frequently, why not ship systemd-resolvconf too? Stop trying to gimp your users. > Please see previous bugs about this, trying to identify, enumerate and fix all of those usecases. The bugs that I've seen always seem like the crumby Debian resolvconf has big issues, since that's basically unmaintained and poorly specified. Usually people switch to openresolv and everything works fine. Instead, here, you could switch to sys
[Touch-packages] [Bug 1892798] Re: systemd package missing resolvconf(8) compatibility symlink, and a Provides: resolvconf
** Changed in: wireguard (Ubuntu) Status: Incomplete => Confirmed -- 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/1892798 Title: systemd package missing resolvconf(8) compatibility symlink, and a Provides: resolvconf Status in systemd package in Ubuntu: Won't Fix Status in wireguard package in Ubuntu: Confirmed Bug description: By default Ubuntu now uses systemd to manage the nameservers in resolv.conf, so resolvconf and openresolv seem to be redundant. However, it appears that systemd's resolvectl is compatable with resolvconf style commands if symlinked as resolvconf. I'm not really sure how deb packaging works, but if it possible to check for the resolvconf command, and if not found just symlink /usr/bin/resolvectl to /usr/sbin/resolvconf then wg-quick will work without additional packages. See https://manpages.ubuntu.com/manpages/focal/man1/resolvectl.1#compatibility%20with%20resolvconf(8) for more info. Apologies if there is a better place to direct this info. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1892798/+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 1892798] Re: systemd package missing resolvconf(8) compatibility symlink, and a Provides: resolvconf
By the way, Arch manages the possibility of openresolv colliding with systemd's resolvconf by providing a package called "systemd-resolvconf": https://www.archlinux.org/packages/core/x86_64/systemd-resolvconf/ https://github.com/archlinux/svntogit- packages/blob/packages/systemd/trunk/PKGBUILD#L239-L251 This seems like a perfectly reasonable way to accomplish this. Simply package the symlink in a separate package, and then the "Recommends:" for wireguard just includes systemd-resolvconf in the list alongside openresolv and resolvconf. That seems like an exceedingly reasonable way of going about things. Why not just do the same thing here? -- 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/1892798 Title: systemd package missing resolvconf(8) compatibility symlink, and a Provides: resolvconf Status in systemd package in Ubuntu: Won't Fix Status in wireguard package in Ubuntu: Confirmed Bug description: By default Ubuntu now uses systemd to manage the nameservers in resolv.conf, so resolvconf and openresolv seem to be redundant. However, it appears that systemd's resolvectl is compatable with resolvconf style commands if symlinked as resolvconf. I'm not really sure how deb packaging works, but if it possible to check for the resolvconf command, and if not found just symlink /usr/bin/resolvectl to /usr/sbin/resolvconf then wg-quick will work without additional packages. See https://manpages.ubuntu.com/manpages/focal/man1/resolvectl.1#compatibility%20with%20resolvconf(8) for more info. Apologies if there is a better place to direct this info. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1892798/+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 1892798] Re: eliminating resolvconf/openresolv dependencies
> wireguard package => please feed DNS data direct to systemd-resolved using either dbus or the cli. Absolutely not. We're not going to add vendor-specific hacks for broken distros that are unable to include the standard interface for this kind of thing, resolvconf(8). This is a pretty clear case of downstream being broken. > Unfortunately systemd's resolved's resolvctl is not compatible with Debian's/Ubuntu's historical resolvconf. First of all, we're not talking about systemd's resolvectl. We're talking about systemd's resolvconf compatibility symlink which provides the same interface as openresolv or the debian resolvconf monster. With that clarified, if you still think there's a problem due to Debian's resolvconf using an interface prefix list, I think you're incorrect there too. Firstly, openresolv doesn't act that way, and things work fine. Secondly, systems that have moved to systemd-resolved (that is, Ubuntu itself) have in the process _broken_ resolvconf anyway. Replacing broken resolvconf with one that is less broken -- even if it doesn't do priority interface prefixes -- is still a marked improvement. And thirdly, every script I've seen that uses resolvconf actually continues to work fine with systemd's compatibility symlink of resolvconf; if any you see don't, why not fix them? So, in other words, I don't think you've presented a very compelling argument at all. I can't see any correct technical reasoning in what you wrote. It seems like adding the resolvconf compatibility symlink is a marked improvement over the current broken status quo. ** Summary changed: - eliminating resolvconf/openresolv dependencies + systemd package missing resolvconf(8) compatibility symlink, and a Provides: resolvconf -- 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/1892798 Title: systemd package missing resolvconf(8) compatibility symlink, and a Provides: resolvconf Status in systemd package in Ubuntu: Won't Fix Status in wireguard package in Ubuntu: Confirmed Bug description: By default Ubuntu now uses systemd to manage the nameservers in resolv.conf, so resolvconf and openresolv seem to be redundant. However, it appears that systemd's resolvectl is compatable with resolvconf style commands if symlinked as resolvconf. I'm not really sure how deb packaging works, but if it possible to check for the resolvconf command, and if not found just symlink /usr/bin/resolvectl to /usr/sbin/resolvconf then wg-quick will work without additional packages. See https://manpages.ubuntu.com/manpages/focal/man1/resolvectl.1#compatibility%20with%20resolvconf(8) for more info. Apologies if there is a better place to direct this info. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1892798/+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 1892798] Re: eliminating resolvconf/openresolv dependencies
Thanks for bringing this to my attention. I believe your assessment is correct. Do you know which Ubuntu first started using resolved? How far back do we need to make changes? There are two facets of this: 1) The Ubuntu systemd package should install the resolvconf compatibility symlink. I have no idea why this isn't already the case, and that seems like a bug that should be remedied ASAP. resolvconf(8) is the standard interface for programs to interact with DNS, which is why systemd provides it. Not providing it is super confusing. 2) The Recommends in the wireguard package should be adjusted. I believe apw@ can handle (2). Somebody on the systemd team should handle (1). ** Changed in: wireguard (Ubuntu) Status: New => Confirmed ** Also affects: systemd (Ubuntu) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu) Status: New => Confirmed -- 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/1892798 Title: eliminating resolvconf/openresolv dependencies Status in systemd package in Ubuntu: Confirmed Status in wireguard package in Ubuntu: Confirmed Bug description: By default Ubuntu now uses systemd to manage the nameservers in resolv.conf, so resolvconf and openresolv seem to be redundant. However, it appears that systemd's resolvectl is compatable with resolvconf style commands if symlinked as resolvconf. I'm not really sure how deb packaging works, but if it possible to check for the resolvconf command, and if not found just symlink /usr/bin/resolvectl to /usr/sbin/resolvconf then wg-quick will work without additional packages. See https://manpages.ubuntu.com/manpages/focal/man1/resolvectl.1#compatibility%20with%20resolvconf(8) for more info. Apologies if there is a better place to direct this info. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1892798/+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 1890286] Re: ansi escape sequence injection in add-apt-repository
You might be right that the remaining ones that slip through your regex are mere "nuisance"s. But you know how those things go - one man's nuisance is another man's vuln. Some of those, anyhow, are implemented by the Linux console driver. Why not just take the tried and true "safe" route, as implemented by vis(3)'s VIS_SAFE or similar? Otherwise it sounds like you're playing with a bit of fire. Put differently, is there some legitimate use case of the ANSI escape characters that make you want to preserve some of their usage while disallowing other parts? If so, that would really surprise me. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to software-properties in Ubuntu. https://bugs.launchpad.net/bugs/1890286 Title: ansi escape sequence injection in add-apt-repository Status in software-properties package in Ubuntu: Fix Released Bug description: This was reported to oss-security and to secur...@ubuntu.com, but I figure I should make a real bug report, as otherwise it'll probably be missed. Original post from https://www.openwall.com/lists/oss- security/2020/08/03/1 follows below. -- Hi, I've found a rather low grade concern: I'm able to inject ANSI escape sequences into PPA descriptions on Launchpad, and then have them rendered by add-apt-repository *before* the user consents to actually adding that repository. There might be some sort of trust barrier issue with that. This could be used to clear the screen and imitate a fresh bash prompt, upload files, dump the current screen to a file, or other classic shenanigans, well chronicled in the archives of oss-sec. PoC time -- I'm using this "feature" for good at the moment to announce the deprecation in bold text of a PPA that I maintain: https://data.zx2c4.com/add-apt-repository-ansi-injection.png The proper fix to this is likely to do sanitization on the add-apt-repository side. Regards, Jason To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1890286/+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 1890286] Re: ansi escape sequence injection in add-apt-repository
I'm not convinced that really cuts it. Namely, from the diff:
-print(" %s" % (info["description"] or ""))
+# strip ANSI escape sequences
+description = re.sub(r"(\x9B|\x1B\[)[0-?]*[ -/]*[@-~]",
+ "", info["description"] or "")
+
+print(" %s" % description)
There are sequences that don't get filtered by that. Aside from the
usual things like \r or \b, it looks like https://man7.org/linux/man-
pages/man4/console_codes.4.html lists a few codes that defy it too.
While that diff above might be the "stackoverflow answer", it doesn't
seem complete.
Instead, why not just adopt a whitelist policy? Only allow visible and
space characters, or something like that.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to software-properties in
Ubuntu.
https://bugs.launchpad.net/bugs/1890286
Title:
ansi escape sequence injection in add-apt-repository
Status in software-properties package in Ubuntu:
Fix Released
Bug description:
This was reported to oss-security and to secur...@ubuntu.com, but I
figure I should make a real bug report, as otherwise it'll probably be
missed. Original post from https://www.openwall.com/lists/oss-
security/2020/08/03/1 follows below.
--
Hi,
I've found a rather low grade concern: I'm able to inject ANSI escape
sequences into PPA descriptions on Launchpad, and then have them
rendered by add-apt-repository *before* the user consents to actually
adding that repository. There might be some sort of trust barrier
issue with that. This could be used to clear the screen and imitate a
fresh bash prompt, upload files, dump the current screen to a file, or
other classic shenanigans, well chronicled in the archives of oss-sec.
PoC time -- I'm using this "feature" for good at the moment to
announce the deprecation in bold text of a PPA that I maintain:
https://data.zx2c4.com/add-apt-repository-ansi-injection.png
The proper fix to this is likely to do sanitization on the
add-apt-repository side.
Regards,
Jason
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1890286/+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 1890286] Re: ansi escape sequence injection into add-apt-repository
Looks like this has come up before in other utilities and was fixed, such as https://bugs.launchpad.net/ubuntu/+source/base- files/+bug/1649352 . ** Summary changed: - ansi escape sequence injection into add-apt-repository + ansi escape sequence injection in add-apt-repository -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to software-properties in Ubuntu. https://bugs.launchpad.net/bugs/1890286 Title: ansi escape sequence injection in add-apt-repository Status in software-properties package in Ubuntu: New Bug description: This was reported to oss-security and to secur...@ubuntu.com, but I figure I should make a real bug report, as otherwise it'll probably be missed. Original post from https://www.openwall.com/lists/oss- security/2020/08/03/1 follows below. -- Hi, I've found a rather low grade concern: I'm able to inject ANSI escape sequences into PPA descriptions on Launchpad, and then have them rendered by add-apt-repository *before* the user consents to actually adding that repository. There might be some sort of trust barrier issue with that. This could be used to clear the screen and imitate a fresh bash prompt, upload files, dump the current screen to a file, or other classic shenanigans, well chronicled in the archives of oss-sec. PoC time -- I'm using this "feature" for good at the moment to announce the deprecation in bold text of a PPA that I maintain: https://data.zx2c4.com/add-apt-repository-ansi-injection.png The proper fix to this is likely to do sanitization on the add-apt-repository side. Regards, Jason To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1890286/+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 1890286] [NEW] ansi escape sequence injection in add-apt-repository
*** This bug is a security vulnerability *** Public security bug reported: This was reported to oss-security and to secur...@ubuntu.com, but I figure I should make a real bug report, as otherwise it'll probably be missed. Original post from https://www.openwall.com/lists/oss- security/2020/08/03/1 follows below. -- Hi, I've found a rather low grade concern: I'm able to inject ANSI escape sequences into PPA descriptions on Launchpad, and then have them rendered by add-apt-repository *before* the user consents to actually adding that repository. There might be some sort of trust barrier issue with that. This could be used to clear the screen and imitate a fresh bash prompt, upload files, dump the current screen to a file, or other classic shenanigans, well chronicled in the archives of oss-sec. PoC time -- I'm using this "feature" for good at the moment to announce the deprecation in bold text of a PPA that I maintain: https://data.zx2c4.com/add-apt-repository-ansi-injection.png The proper fix to this is likely to do sanitization on the add-apt-repository side. Regards, Jason ** Affects: software-properties (Ubuntu) Importance: Undecided Status: New ** Information type changed from Private Security to Public ** Information type changed from Public to Public Security -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to software-properties in Ubuntu. https://bugs.launchpad.net/bugs/1890286 Title: ansi escape sequence injection in add-apt-repository Status in software-properties package in Ubuntu: New Bug description: This was reported to oss-security and to secur...@ubuntu.com, but I figure I should make a real bug report, as otherwise it'll probably be missed. Original post from https://www.openwall.com/lists/oss- security/2020/08/03/1 follows below. -- Hi, I've found a rather low grade concern: I'm able to inject ANSI escape sequences into PPA descriptions on Launchpad, and then have them rendered by add-apt-repository *before* the user consents to actually adding that repository. There might be some sort of trust barrier issue with that. This could be used to clear the screen and imitate a fresh bash prompt, upload files, dump the current screen to a file, or other classic shenanigans, well chronicled in the archives of oss-sec. PoC time -- I'm using this "feature" for good at the moment to announce the deprecation in bold text of a PPA that I maintain: https://data.zx2c4.com/add-apt-repository-ansi-injection.png The proper fix to this is likely to do sanitization on the add-apt-repository side. Regards, Jason To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1890286/+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 725126]
Tracking the new bug here now: https://sourceware.org/bugzilla/show_bug.cgi?id=26141 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/725126 Title: gas may assemble b to locally-defined, preemptible global symbol as "b.n" Status in binutils: Fix Released Status in Linaro Binutils: Won't Fix Status in Cortex String Routines: Invalid Status in armel-cross-toolchain-base package in Ubuntu: Fix Released Status in binutils package in Ubuntu: Fix Released Bug description: There's no guarantee that R_ARM_THM_JUMP11 relocation can be resolved correctly if the symbol gets preempted. Observed in binutils-arm-linux-gnueabi 2.20.51.20100908-0ubuntu2cross1.52. Observed on binutils trunk on 2011-02-25. The problem seems to strike when the compiler optimises a sibling call to "b ", for which the assembler generates a b.n. As a side-effect of the presence of this relocation, Thumb-2 kernel modules may fail to load, since the kernel doesn't support fixing up this relocation. I believe the kernel doesn't do any symbol preemption processing when loading modules -- if so, the relocation is actually redundant. But there's no way for the kernel to detect at module load time that the relocation can safely be ignored. In kernel builds, about 1 out every 6 modules suffers from this problem. It's not clear to me whether the method used by the kernel to link .ko objects is wrong or not. It seems that either the tools should support symbol preemption in this scenario (implying that a short branch is not adequate to guarantee that preemption will work -- i.e., a gas bug) or not (in this case the fixup should be done locally and there should presumably be no relocation -- i.e., a different gas bug). It appears that passing -fno-optimize-sibling-calls to GCC can work around the problem by avoiding the generation of local branches to global symbols, but this is clearly not the correct fix. To manage notifications about this bug go to: https://bugs.launchpad.net/binutils/+bug/725126/+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 725126]
This problem still exists on binutils 2.33 when -fvisibility=hidden is passed to cflags. I imagine this is so due to some conflicting code where the forced B.W is only generated for static functions, since non- static ones will be relocated differently, but then because of -fvisibility=hidden, they get treated like statics, only B is used instead of the forced B.W, causing this issue to crop up again. OpenWRT experienced this when including WireGuard on a new board. I fixed it like this: https://git.zx2c4.com/wireguard-linux- compat/commit/?id=178cdfffb99f2fd6fb4a5bfd2f9319461d93f53b -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/725126 Title: gas may assemble b to locally-defined, preemptible global symbol as "b.n" Status in binutils: Fix Released Status in Linaro Binutils: Won't Fix Status in Cortex String Routines: Invalid Status in armel-cross-toolchain-base package in Ubuntu: Fix Released Status in binutils package in Ubuntu: Fix Released Bug description: There's no guarantee that R_ARM_THM_JUMP11 relocation can be resolved correctly if the symbol gets preempted. Observed in binutils-arm-linux-gnueabi 2.20.51.20100908-0ubuntu2cross1.52. Observed on binutils trunk on 2011-02-25. The problem seems to strike when the compiler optimises a sibling call to "b ", for which the assembler generates a b.n. As a side-effect of the presence of this relocation, Thumb-2 kernel modules may fail to load, since the kernel doesn't support fixing up this relocation. I believe the kernel doesn't do any symbol preemption processing when loading modules -- if so, the relocation is actually redundant. But there's no way for the kernel to detect at module load time that the relocation can safely be ignored. In kernel builds, about 1 out every 6 modules suffers from this problem. It's not clear to me whether the method used by the kernel to link .ko objects is wrong or not. It seems that either the tools should support symbol preemption in this scenario (implying that a short branch is not adequate to guarantee that preemption will work -- i.e., a gas bug) or not (in this case the fixup should be done locally and there should presumably be no relocation -- i.e., a different gas bug). It appears that passing -fno-optimize-sibling-calls to GCC can work around the problem by avoiding the generation of local branches to global symbols, but this is clearly not the correct fix. To manage notifications about this bug go to: https://bugs.launchpad.net/binutils/+bug/725126/+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 1683884] [NEW] openresolv is less crippled than debian-resolvconf for security-focused configurations
Public bug reported: Ubuntu relies on Debian's own "resolvconf" which is vastly inferior to Openresolv and makes it impossible to securely set up DNS servers for ephemeral secure tunnel interfaces. Specifically, Debian's "resolvconf" relies on a hard coded list of interface templates. For virtual interfaces or renamed interfaces -- such as those used for creating secure tunnels -- the DNS entries will be lowest priority. This means it's not possible to override the current DNS with a DNS bound to particular arbitrarily-named interface. In other words, Debian's "resolvconf" explicitly ties interface naming templates to interface metrics. Openresolv has the `-m` option for this. Using `-m 0` will give an interface's DNS servers top priority. Secondly, and importantly, Debian's "resolvconf" does not support the `-x` option, which specifies that a DNS servers of an interface should be the _exclusive_ servers in use. This option is necessary to prevent leaking DNS queries over another interface. Even with the aforementioned `-m 0` option, an attacker could DoS the top priority DNS server in order to leak queries to the second priority DNS server. Openresolv's `-x` option fixes this, by allowing marking an interface as having "exclusive" control over DNS. Therefore, I'd suggest that either: a) Ubuntu switch to using Openresolv by default instead of its own "resolvconf". The openresolv package already "Provides: resolvconf",so it should be a drop-in replacement; or b) Debian's "resolvconf" backport these useful and necessary features from Openresolv. For my specific usage, the recommendation in https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1680811 might work as a fix for the `-m 0` issue, but it is less than ideal and does accomplish `-x`. Therefore, I recommend doing either (a) or (b), preferably (a). ** Affects: resolvconf (Ubuntu) Importance: Undecided Status: New ** Description changed: Ubuntu relies on Debian's own "resolvconf" which is vastly inferior to Openresolv and makes it impossible to securely set up DNS servers for ephemeral secure tunnel interfaces. Specifically, Debian's "resolvconf" relies on a hard coded list of interface templates. For virtual interfaces or renamed interfaces -- such as those used for creating secure tunnels -- the DNS entries will be lowest priority. This means it's not possible to override the current DNS with a DNS bound to particular arbitrarily-named interface. In other words, Debian's "resolvconf" explicitly ties interface naming templates to interface metrics. Openresolv has the `-m` option for this. Using `-m 0` will give an interface's DNS servers top priority. Secondly, and importantly, Debian's "resolvconf" does not support the `-x` option, which specifies that a DNS servers of an interface should be the _exclusive_ servers in use. This option is necessary to prevent leaking DNS queries over another interface. Even with the aforementioned `-m 0` option, an attacker could DoS the top priority DNS server in order to leak queries to the second priority DNS server. Openresolv's `-x` option fixes this, by allowing marking an interface as having "exclusive" control over DNS. Therefore, I'd suggest that either: - a) Ubuntu switch to using Openresolv by default instead of its own "resolvconf". The openresolv package already "Provides: openresolv",so it should be a drop-in replacement; or + a) Ubuntu switch to using Openresolv by default instead of its own "resolvconf". The openresolv package already "Provides: resolvconf",so it should be a drop-in replacement; or b) Debian's "resolvconf" backport these useful and necessary features from Openresolv. For my specific usage, the recommendation in https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1680811 might work as a fix for the `-m 0` issue, but it is less than ideal and does accomplish `-x`. Therefore, I recommend doing either (a) or (b), preferably (a). -- 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/1683884 Title: openresolv is less crippled than debian-resolvconf for security- focused configurations Status in resolvconf package in Ubuntu: New Bug description: Ubuntu relies on Debian's own "resolvconf" which is vastly inferior to Openresolv and makes it impossible to securely set up DNS servers for ephemeral secure tunnel interfaces. Specifically, Debian's "resolvconf" relies on a hard coded list of interface templates. For virtual interfaces or renamed interfaces -- such as those used for creating secure tunnels -- the DNS entries will be lowest priority. This means it's not possible to override the current DNS with a DNS bound to particular arbitrarily-named interface. In other words, Debian's "resolvconf" explicitly ties interface naming templates to int
[Touch-packages] [Bug 1680811] Re: Request to add wireguard interface to interface-order
It might make more sense to simply switch to using openresolv, which is a proper resolvconf implementation, which doesn't rely on this silly hard-coded list. Alternatively, you could just backport features one by one from openresolv, such as '-m 0 and '-x'. But really, since openresolv has no downsides and only upsides, and Debian's homebaked resolvconf is rotting and has issues, you'd really be better off just removing Debian's resolvconf from Ubuntu and relying instead on openresolv. -- 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/1680811 Title: Request to add wireguard interface to interface-order Status in resolvconf package in Ubuntu: Triaged Bug description: This started from https://github.com/jlund/streisand/issues/557. Basically wg* namespace is not in interface-order and acts last in * scope, and this makes resolv.conf to stay in the same state. I suggest the following change: :/etc/resolvconf/interface-order # interface-order(5) lo.inet6 lo.inet lo.@(dnsmasq|pdnsd) lo.!(pdns|pdns-recursor) lo +wg* tun* tap* hso* em+([0-9])?(_+([0-9]))* p+([0-9])p+([0-9])?(_+([0-9]))* @(br|eth)*([^.]).inet6 @(br|eth)*([^.]).ip6.@(dhclient|dhcpcd|pump|udhcpc) @(br|eth)*([^.]).inet @(br|eth)*([^.]).@(dhclient|dhcpcd|pump|udhcpc) @(br|eth)* @(ath|wifi|wlan)*([^.]).inet6 @(ath|wifi|wlan)*([^.]).ip6.@(dhclient|dhcpcd|pump|udhcpc) @(ath|wifi|wlan)*([^.]).inet @(ath|wifi|wlan)*([^.]).@(dhclient|dhcpcd|pump|udhcpc) @(ath|wifi|wlan)* ppp* * To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1680811/+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
