Bug#1062838: openconnect: NMU diff for 64-bit time_t transition
This looks like overkill to me, for openconnect. There's precisely one function exported from libopenconnect which uses time_t, and I suspect there aren't any *users* of that function in the distribution anyway (neither openconnect(8) nor NetworkManager- openconnect use it). So although it's not best practice, we could actually get away with just *dropping* that function, and adding a new function which returns either an explicit 64-bit value or a timespec or something. Alternatively... on how many of our 64-bit architectures can we just return the high 32 bits of the 64-bit time_t in a register that we call-clobbered anyway — so callers who expect a 64-bit time_t get to see it all, and callers who expect a 32-bit time_t just don't notice? The contents of the *low* 32 bits are the same either way, right? It definitely doesn't seem like we need to switch to a new soname ... except *are* you switching the soname? Or just the package name? It looks like the symbol versions are remaining the *same*...? How does that work? On Sat, 2024-02-03 at 16:13 -0300, Lucas Kanashiro wrote: > Source: openconnect > Version: 9.12-1 > Severity: serious > Tags: patch pending sid trixie > Justification: library ABI skew on upgrade > User: debian-...@lists.debian.org > Usertags: time-t > > NOTICE: these changes must not be uploaded to unstable yet! > > Dear maintainer, > > As part of the 64-bit time_t transition required to support 32-bit > architectures in 2038 and beyond > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > openconnect as a source package shipping runtime libraries whose ABI > either is affected by the change in size of time_t, or could not be > analyzed via abi-compliance-checker (and therefore to be on the safe > side we assume is affected). > > To ensure that inconsistent combinations of libraries with their > reverse-dependencies are never installed together, it is necessary to > have a library transition, which is most easily done by renaming the > runtime library package. > > Since turning on 64-bit time_t is being handled centrally through a > change > to the default dpkg-buildflags (https://bugs.debian.org/1037136), it > is > important that libraries affected by this ABI change all be uploaded > close > together in time. Therefore I have prepared a 0-day NMU for > openconnect > which will initially be uploaded to experimental if possible, then to > unstable after packages have cleared binary NEW. > > Please find the patch for this NMU attached. > > If you have any concerns about this patch, please reach out ASAP. > Although > this package will be uploaded to experimental immediately, there will > be a > period of several days before we begin uploads to unstable; so if > information > becomes available that your package should not be included in the > transition, > there is time for us to amend the planned uploads. > > > > -- System Information: > Debian Release: trixie/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 6.2.0-39-generic (SMP w/32 CPU threads; PREEMPT) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, > TAINT_UNSIGNED_MODULE > Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) smime.p7s Description: S/MIME cryptographic signature
Bug#839278: oathtool: has no secure way to provide a key
If you're going to load keys from files, surely you want to use PSKC files? And we need to be able to write back to them in the case of HOTP keys too, to increase the counter. smime.p7s Description: S/MIME cryptographic signature
Bug#959428: openconnect: CVE-2020-12105
Which means since 7.07 in July 2016. On 2 May 2020 11:29:34 BST, Luca Boccassi wrote: >Package: openconnect >Version: 6.00-2 > >Tracking https://security-tracker.debian.org/tracker/CVE-2020-12105 >Not sure what's the oldest version affected, asked on >https://security-tracker.debian.org/tracker/CVE-2020-12105 > >-- >Kind regards, >Luca Boccassi -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#959428: openconnect: CVE-2020-12105
Since that code (for OpenSSL 1.0.2+) was first added in https://gitlab.com/openconnect/openconnect/-/commit/674881cbb078937d84c9b16219b52d7b56623ba7 On 2 May 2020 11:29:34 BST, Luca Boccassi wrote: >Package: openconnect >Version: 6.00-2 > >Tracking https://security-tracker.debian.org/tracker/CVE-2020-12105 >Not sure what's the oldest version affected, asked on >https://security-tracker.debian.org/tracker/CVE-2020-12105 > >-- >Kind regards, >Luca Boccassi -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#704180: Use p11-kit to replace nssckbi
On Mon, 2019-01-14 at 10:33 -0500, Daniel Kahn Gillmor wrote: > On Sun 2019-01-13 19:07:42 +0100, Andreas Metzler wrote: > > The coding would be straightforward afaict. > > > > https://salsa.debian.org/gnutls-team/p11-kit/commits/tmp-704180-divertnss > > I like the looks of this, though perhaps we want to name the new package > p11-kit-trust to be more in line with the name given by other distros. In Fedora it's called p11-kit-trust and it's pulled in by default as a dependency of various other packages including NSS and GnuTLS. In fact I think GnuTLS is built to use it as its default trust store, so not installing it isn't really a possibility. It also provides the standard update-ca-certificates mechanism which manages the CAs used by OpenSSL. They use alternatives so that if the user really wants to disable it for NSS and use the standard libnssckbi.so for NSS, they can. smime.p7s Description: S/MIME cryptographic signature
Bug#704180: Use p11-kit to replace nssckbi
On Thu, 2019-01-10 at 19:14 +0100, Laurent Bigonville wrote:
> > However, am I right in thinking that we have multiple packages all
> > shipping their *own* special version of the NSS libraries, instead of
> > using the system one? Each instance of libnssckbi.so (in firefox,
> > thunderbird, etc.) would need to be replaced, wouldn't it?
>
> If I'm searching for a file called libnssckbi.so in the archive, the
> only other occurrence is in package libapache2-mod-nss.
Looking back, I see this bug was opened with the comment "With the
recent switch of wheezy-security's iceweasel to using the
embedded copy of nss..."
That was 2014 though. Is it no longer the case?
FWIW my Ubuntu 18.04 box does have separate instances of libnssckbi.so
in /usr/lib/{thunderbird,firefox}/ (along with all the other NSS
libraries, I believe).
Perhaps the answer is that any separate instances of NSS should *not*
ship their own libnssckbi.so and should use the system one. The
interface there is entirely stable as it's PKCS#11, so there won't be
compatibility problems (else p11-kit-trust couldn't work either).
smime.p7s
Description: S/MIME cryptographic signature
Bug#704180: Use p11-kit to replace nssckbi
On Thu, 2019-01-10 at 15:53 -0500, Daniel Kahn Gillmor wrote: > what's the advantage of using alternatives instead of a package- > specific displacement? None really, as long as you put it in a separate p11-kit-trust package as Fedora/RHEL do. You don't want installation of the p11-kit package itself to trigger the replacement, necessarily. Lots of other things use p11-kit. smime.p7s Description: S/MIME cryptographic signature
Bug#704180: Use p11-kit to replace nssckbi
On Wed, 2019-01-09 at 14:04 -0500, Daniel Kahn Gillmor wrote: > On Wed 2019-01-09 16:39:36 +0100, Laurent Bigonville wrote: > > So what is the status of this? > > > > In RHEL 7 they made the switch to p11-kit and libnssckbi.so is an > > alternative between the file shipped by nss and p11-kit-trust.so shipped > > by p11-kit (with p11-kit version being the default). > > > > Should we switch debian by default to p11-kit as well? > > seems like the maintainers of p11-kit could unilaterally decide to > implement the diversion approach mentioned in > https://bugs.debian.org/704180 with a new binary package, if the nss > folks are reluctant to do it. > > I'm cc'ing Andreas here to try to get some feedback -- is this something > that there's interest in for the p11-kit maintainers? That would seem like an excellent way to do it. However, am I right in thinking that we have multiple packages all shipping their *own* special version of the NSS libraries, instead of using the system one? Each instance of libnssckbi.so (in firefox, thunderbird, etc.) would need to be replaced, wouldn't it? smime.p7s Description: S/MIME cryptographic signature
Bug#847135: openconnect: vpn connection mtu too big
On Tue, 2016-12-06 at 07:53 +, Martin wrote: > including the bug tacker this time (and extra notes at the end): > > From the command line on 7.08 I get: > > Established DTLS connection (using GnuTLS). Ciphersuite > (DTLS0.9)-(DHE-RSA-4294967237)-(AES-128-CBC)-(SHA1). > Too long time in MTU detect loop; MTU set to 1401. > Detected MTU of 1401 bytes (was 1406) > > However the newer version works fine after this and the old version doesn't > > Though obviously the MTU is wrong but the new version does somehow cope. > > I'll try and find time to investigate why it's timing out detecting the MTU The MTU detection is not perfect yet. You can add '-v -v' and see more information about what it's doing. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Bug#847135: openconnect: vpn connection mtu too big
Hm, if you use OpenConnect on the command line do you see the same problem? What MTU does OpenConnect actually ask for? And if you update to the latest version from git (which I really ought to release as 7.08 some time soon) does that fix it? The Arch bug you link is ancient; that sounds like it's from the days when NetworkManager didn't actually honour the MTU that OpenConnect requested. That shouldn't be the case nowadays. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Bug#835587: openconnect: Connection dies frequently, is restored after dead peer detection
On Tue, 2016-08-30 at 22:26 +0200, Marco Marzetti wrote: > I can confirm that i have same problem (debian testing here). > As far as i can see it started after i have updated libgnutls30 and > libgnutls-openssl27 from 3.5.2-2 to 3.5.3-2 . > > A few minutes ago i have updated to 3.5.3-3, but the problem is > still there. Yes, the problem was introduced in 3.5.3. See https://bugzilla.redhat.com/show_bug.cgi?id=1370881 -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature
Bug#829272: Missing accessors
(Dropping the Debian bug from Cc) On Wed, 2016-07-20 at 15:11 +, Richard Levitte via RT wrote: > On Mon Jul 11 14:04:22 2016, dw...@infradead.org wrote: > > I was using store.get_issuer() in OpenConnect too, because I need to > > manually build the trust chain to include it on the wire — because > > even today the server might *still* suffer RT#1942 and fail to trust > > our client cert unless we help it by providing the *right* chain. > > Is this still true with OpenSSL 1.1? If so, please file a report. No, I fixed it years ago in OpenSSL. But it took many years for Cisco to actually start *using* a fixed version of OpenSSL. So we still try really hard, on the client side, to put the *right* intermediate CAs on the wire if we can find them. Because that way it doesn't matter so much if the server can't. > > I've worked around the lack of access to get_issuer() by doing a dummy > > call to X509_verify_cert(), throwing away its result and then hoping > > that we have something useful in store.chain (which we *can* still > > access). That seems to work but I'm not stunningly happy with it; if > > we > > can have an accessor I'd much rather go back to doing it the old way. > > > > http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/0d635a0 > > (in workaround_openssl_certchain_bug() in the hunk around line 1306) > > https://github.com/openssl/openssl/pull/1294 currently provides a setter for > get_issuer in X509_STORE. OK, thanks. Once it lands, I may go back to using that. -- dwmw2 -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602 Please log in as guest with password guest if prompted smime.p7s Description: S/MIME cryptographic signature
Bug#829272: [openssl-dev] [openssl.org #4602] Missing accessors
On Mon, 2016-07-11 at 13:08 +, Mattias Ellert via RT wrote: > > > Looking at the various places in the code where get_issuer > and check_issued are accessed, they mostly use the context rather than > the store. Here are the places I have found: > > https://sources.debian.net/src/nordugrid-arc/5.1.2-1/src/hed/libs/credential/CertUtil.cpp/#L71 > > https://sources.debian.net/src/canl-c/2.1.6-2/src/proxy/sslutils.c/#L1581 > > https://sources.debian.net/src/voms/2.0.13-1/src/sslutils/sslutils.c/#L1588 > > https://sources.debian.net/src/globus-gsi-callback/5.8-2/library/globus_gsi_callback.c/#L367 > > https://sources.debian.net/src/globus-gsi-callback/5.8-2/library/globus_gsi_callback.c/#L1059 > > https://sources.debian.net/src/globus-gsi-credential/7.9-2/library/globus_gsi_cred_handle.c/#L1997 > > And the following one actually uses the store and not the context: > > https://sources.debian.net/src/globus-gssapi-gsi/12.1-1/library/globus_i_gsi_gss_utils.c/#L448 I was using store.get_issuer() in OpenConnect too, because I need to manually build the trust chain to include it on the wire — because even today the server might *still* suffer RT#1942 and fail to trust our client cert unless we help it by providing the *right* chain. I've worked around the lack of access to get_issuer() by doing a dummy call to X509_verify_cert(), throwing away its result and then hoping that we have something useful in store.chain (which we *can* still access). That seems to work but I'm not stunningly happy with it; if we can have an accessor I'd much rather go back to doing it the old way. http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/0d635a0 (in workaround_openssl_certchain_bug() in the hunk around line 1306) -- dwmw2
Bug#829272: Missing accessors
On Mon, 2016-07-11 at 13:08 +, Mattias Ellert via RT wrote: > > > Looking at the various places in the code where get_issuer > and check_issued are accessed, they mostly use the context rather than > the store. Here are the places I have found: > > https://sources.debian.net/src/nordugrid-arc/5.1.2-1/src/hed/libs/credential/CertUtil.cpp/#L71 > > https://sources.debian.net/src/canl-c/2.1.6-2/src/proxy/sslutils.c/#L1581 > > https://sources.debian.net/src/voms/2.0.13-1/src/sslutils/sslutils.c/#L1588 > > https://sources.debian.net/src/globus-gsi-callback/5.8-2/library/globus_gsi_callback.c/#L367 > > https://sources.debian.net/src/globus-gsi-callback/5.8-2/library/globus_gsi_callback.c/#L1059 > > https://sources.debian.net/src/globus-gsi-credential/7.9-2/library/globus_gsi_cred_handle.c/#L1997 > > And the following one actually uses the store and not the context: > > https://sources.debian.net/src/globus-gssapi-gsi/12.1-1/library/globus_i_gsi_gss_utils.c/#L448 I was using store.get_issuer() in OpenConnect too, because I need to manually build the trust chain to include it on the wire — because even today the server might *still* suffer RT#1942 and fail to trust our client cert unless we help it by providing the *right* chain. I've worked around the lack of access to get_issuer() by doing a dummy call to X509_verify_cert(), throwing away its result and then hoping that we have something useful in store.chain (which we *can* still access). That seems to work but I'm not stunningly happy with it; if we can have an accessor I'd much rather go back to doing it the old way. http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/0d635a0 (in workaround_openssl_certchain_bug() in the hunk around line 1306) -- dwmw2 -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602 Please log in as guest with password guest if prompted
Bug#798179: openconnect: Link to Juniper VPN will not be established without reconnect
On Tue, 2015-09-08 at 18:58 -0400, Mike Miller wrote: > But this is only to eliminate or implicate NM. If we already think NM > is implicated, then nevermind. And if the only thing that NM is accused of is not working well when you try to set network devices up behind its back, then nevermind indeed. It would be nice to have Juniper support which *does* work properly with NetworkManager. It's possible for now just by building libopenconnect with Juniper as the default, instead of AnyConnect. Before I support it for real, I really want to sort out the HTML authentication forms (letting the UI render real HTML instead of the hack I currently have to parse the known forms and fail on anything non -standard). -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Bug#794237: openconnect: Does not work with network-manager 1.0.4
On Fri, 2015-08-07 at 09:10 +0300, Matti Koskimies wrote: The MTU value of the tun0 device created when using openconnect on the command line was 1200. It was 1500 for the vpn0 device created using network-manager-openconnect. So I reduced the mtu value to 1200 and voilà, everything works fine! Can I somehow make this setting permanent? That's a NetworkManager or NM-openconnect bug. We *do* pass that MTU value back to NM and expect it to act on it. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Bug#794237: openconnect: Does not work with network-manager 1.0.4
On Fri, 2015-08-07 at 08:27 -0400, Mike Miller wrote: Thanks for the debugging guys, reassigned to NM-openconnect for now. Nah, that makes it my fault too! Pass the buck a bit further! Seriously, NM-openconnect doesn't really do much with the IP configuration at all. You can use dbus-monitor to watch what nm-openconnect-service-openconnect-helper hands back to NM, and I bet it *will* include the MTU. We haven't really touched that part for ages. I blame NM. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Bug#794237: openconnect: Does not work with network-manager 1.0.4
On Thu, 2015-08-06 at 14:18 +0300, Matti Koskimies wrote: Pinging doesn't work, but I don't expect it to in our network. Oh? Your network is infested by idiot admins who like to block ICMP? That's almost certainly relevant. Instead, I used netcat for port pinging the ssh port: $ nc -znvw1 172.24.38.144 22 Connection to 172.24.38.144 22 port [tcp/*] succeeded! $ Despite this, the ssh command just hangs. This is a typical symptom of the above-mentioned 'idiot admin' problem. If you do a packet capture, do you find that the connection hangs the moment the SSH server wants to send you a full-sized packet? Which presumably doesn't fit through the VPN, so the VPN server sends back an ICMP packet to the server telling it to send a smaller one... and the VPN server never receives it because of the aforementioned idiot admins. So the SSH server just keeps sending the too-large packets. which never get through. You normally get away with this when you are connecting directly from the VPN client host (as opposed to a virtual machine running thereon). Because the TCP connection setup will indicate an MSS value which *will* fit in the MTU for the immediately local connection. Can you show that packet capture? And try *reducing* your MTU on the VPN interface (tun0) and see if that works? And go and punch one of the idiots for me. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Bug#794237: openconnect: Does not work with network-manager 1.0.4
On Wed, 2015-08-05 at 16:19 +0300, Matti Koskimies wrote: Connecting using the GUI still doesn't work, although I get a lot further now. Connecting and authentication works, and everything looks OK in NM. The routing table looks similar to the one I get using my workaround. But there's no networking unless I set the setting Use this connection only for resources on its network under Routes in IPv4 Settings, but then I can connect only to the same networks as without the VPN. OK, so connecting *does* work but your routes are still not right. The oddly named 'Use this connection only for resources on its network' option basically means Do not set the default route. But you *want* the default route, so you shouldn't be setting that. Let's take a look at what's happening without that option set. You say that the routing table looks similar to the one you get using your workaround — which is promising. But you have no networking. Which is ambiguous. Can you reach hosts on the VPN if you ping them by their IP address? Is it only DNS that isn't working? Can you show the full output of connecting manually with openconnect with '-v' added to the command line so we can see the routes and DNS it's supposed to be setting up? What do you have in /etc/resolv.conf when you've connected with NetworkManager? -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Bug#794237: openconnect: Does not work with network-manager 1.0.4
On Tue, 2015-08-04 at 08:45 +0300, Matti Koskimies wrote: I'm using only command line for both openconnect and network-manager. So don't even have network-manager-openconnect installed. I'm using self written systemd files to connect and disconnect the VPN. The command I use for starting is: /usr/sbin/openconnect --quiet --background --pid -file=/var/run/openconnect.pid --usergroup=$USERGROUP --user=$VPNUSER - -passwd-on-stdin $SERVER $PASSWORD That's all the configuration I have. So presumably what's happening is that OpenConnect sets a default route to the VPN, and then NetworkManager renews its DHCP lease and 'fixes' the default route to go the way that NetworkManager expects it to. This (doing stuff behind NetworkManager's back) isn't really a supported configuration. But as you've observed, adding an *additional* default route does make it work because NetworkManager's own route isn't being removed; it's still there with a lower metric? Connecting from the GUI never worked for me, because the GUI is missing some settings that are required by my VPN provider (username, usergroup). It should ask you for the username if it needs one, and the 'usergroup' is merely the first path element of the login URL. So you can set a gateway of https://vpn.example.com/usergroup or something along those lines. Please let me know if that doesn't work. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature
Bug#792073: openconnect: certificate dialog is unusable in es_US.UTF-8
On Fri, 2015-07-10 at 23:22 +, brian m. carlson wrote: On Fri, Jul 10, 2015 at 11:31:44PM +0100, David Woodhouse wrote: On Fri, 2015-07-10 at 22:01 +, brian m. carlson wrote: Note that the certificate is in fact valid and verifies correctly, as Firefox accepts it. What CA is used to verify it? Go Daddy Secure Certificate Authority - G2 The certificate is in the system store: Go_Daddy_Root_Certificate_Authority_-_G2.crt That's not the same one. The Root CA is the *issuer* of the Secure CA which signed your server's certificate. Your server should be including the intermediate Secure CA in the exchange on the wire, and then we'd be able to make the chain all the way to the 'Root' CA which is actually trusted. I found the same thing as you when I tested — it worked in firefox but not with anything else. That was because the 'Secure' CA was already present in my Firefox certificate database, so we *could* complete the missing part of the chain. A simple 'fix' might be just to change the translation to use the canonical form U+00ED for the í instead of U+0069 + U+0301. Is there a reason *not* to do that? That's probably the easiest solution, and I suspect the one most likely to work. http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/59e5f95 Thanks for identifying the problem, btw. That was extremely non -obvious. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Bug#792073: openconnect: certificate dialog is unusable in es_US.UTF-8
On Fri, 2015-07-10 at 22:01 +, brian m. carlson wrote: Note that the certificate is in fact valid and verifies correctly, as Firefox accepts it. What CA is used to verify it? Debian unfortunately doesn't have a system-wide configuration for trusted CAs — the update-ca-certificates tool only works for OpenSSL and GnuTLS, and not for NSS. You really ought to be using p11-kit-trust and replacing the NSS libnssckbi.so library with it, to actually get consistency across all applications. However, openconnect does not, and prompts. Entering si displays the certificate, as does entering sí or yes. In fact, there's nothing I can enter that makes it accept the certificate. I believe this is because the prompt uses U+0073 + U+0069 + U+0301, whereas using the compose key I enter U+0073 + U+00ED. Since either encoding is valid, you must use Unicode normalization to accept either choice. As it is, the program is unusable in this locale. That seems... suboptimal :) I do seem to be able to work around it by cutting and pasting the sí from the prompt. Or by typing 's' 'i' then Ctrl-Shift-u-3-0-1. But I certainly accept that you shouldn't have to do so! A simple 'fix' might be just to change the translation to use the canonical form U+00ED for the í instead of U+0069 + U+0301. Is there a reason *not* to do that? -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature
Bug#776484: openconnect: Config file not read properly due to optarg misuse
Thanks for the patch. As it happens, this memory corruption was fixed in http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/57a1577c in early June 2012, and the fix was present in the 4.00 release a couple of weeks later. I strongly recommend updating to the current version 7.04. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature
Bug#744214: openconnect: PKCS#11 support broken with GnuTLS 2.12.x
On Sat, 2014-04-12 at 18:49 +0200, Thomas Uhle wrote: Eventually, the bug was found in the function assign_privkey() (line 510), please see the attached patch. Thank you for the excellent debugging. The patch looks correct; please could I trouble you for a Signed-off-by: line as described at http://www.infradead.org/openconnect/contribute.html ? -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Bug#744214: openconnect: PKCS#11 support broken with GnuTLS 2.12.x
On Fri, 2014-04-11 at 15:05 +0200, Thomas Uhle wrote: The changes in gnutls.c from v5.01 to v5.02 concerning support of CA certificates from PKCS#11 tokens (with GnuTLS 3.2.7+) break functionality in openconnect at least if compiled with GnuTLS 2.12.x. Therefore, it also affects libopenconnect2 (= 5.02-1) in Ubuntu 14.04LTS. Thanks for the bug report. Please could you describe the exact failure mode? Can you provide output with '-v' both before and after the offending change? Is it that the old code would correctly find supporting certificates and include them on the wire, leading to a successful authentication... and the new code doesn't manage to find them? I'd be looking for the 'Adding supporting CA...' messages in the working code, and they'd be absent in the failing code, in that case. I have tried to investigate on this issue with GDB and have come as far as to gnutls.c:1517 where err is not the return value of any call to gnutls_pkcs11_get_raw_issuer() or gnutls_x509_crt_import() within the code guarded by #if defined(HAVE_P11KIT) defined(HAVE_GNUTLS_PKCS11_GET_RAW_ISSUER) Right. In your case, the value of 'err' is still the one from the gnutls_certificate_get_issuer() call. You seem to have identified this as the culprit: http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/b06b862f5 Please could you confirm that building that version from git is failing, and building the previous version from before that patch is working? I'd like to be sure it isn't one of the other changes in gnutls.c between v5.01 and v5.02. Before the patch in question, the logic was: - Call gnutls_certificate_get_issuer(). - If it failed, bail out. - Check if it returned nonsense, and bail out if so. After the patch, the logic should be: - Call gnutls_certificate_get_issuer(). - If it succeeded but returned nonsense, bail out. - If it failed but we can use get_raw_issuer(), try that. - If the last thing we tried failed, bail out. I can't see anything obviously wrong. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Bug#742755: openconnect: avoid OpenSSL in openconnect, just use libgnutls28
On Wed, 2014-03-26 at 21:34 -0400, Mike Miller wrote: Nope, all the more reason to move to GnuTLS 3.x now that we have a GPLv2-compatible GMP. Is that something you can do on all platforms where you wanted to ship OpenConnect 6.00? -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Bug#742755: openconnect: avoid OpenSSL in openconnect, just use libgnutls28
On Wed, 2014-03-26 at 19:12 -0400, Mike Miller wrote: The portions that are built into the openconnect library are LGPL and link with GnuTLS while the openconnect program links with OpenSSL (or a new enough GnuTLS), which should allow GPL rdeps to link. But regardless... Hm, since we moved the mainloop into libopenconnect itself (which is what allows it to be used easily from Java in the Android client, etc.), that is no longer true. Sorry, I had forgotten the implications of that — even when we recently discussed the possibility of dropping older versions of GnuTLS. If you want to continue to build with GnuTLS 2.12, and want to retain DTLS support (which must therefore come from OpenSSL), I think you probably need to revert most of commit 30320884589e and the subsequent related changes. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Bug#630690: libical0: messes with timezone, affecting other threads
This is more broken than the bug report would suggest. It's not just that bogus values of $TZ may be visible to other threads (who have no clue that a library being used in a different thread is even using libical; the suggestion that they should obey libical's locking rules is insane). The very use of getenv() and putenv() is clearly documented to be unsafe in a threaded environment. See http://sourceware.org/bugzilla/show_bug.cgi?id=5069#c10 If one thread uses libical and ends up calling putenv(), then *any* other thread using getenv() is liable to crash with a use-after-free. See #c9 in the above-referenced bugs for a list of functions in glibc alone which will be calling getenv() behind the scenes and are likely to so fail. I've filed a patch (at least for those whose libc contains timegm()) in the SF bug. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature
Bug#708928: regression from 3.20-4: cannot connect to some gateways
On Tue, 2013-05-21 at 08:55 +0300, Modestas Vainius wrote: Yeah, for example, openconnect still complains with error messages after XML POST even in non-verbose mode. Yeah, I suppose we could make that quieter. And I'd accept a patch adding a --no-xmlpost command line if someone were to submit such. However, the whole thing works and IMHO is releasable. Feel free to ask me to test another version of the patch whenever you have it ready. Thanks. Please could you test the second patch I just committed to git, on its own (i.e. without the previous patch, which I also committed). I'd like to check that the notice the connection broke, and make a new one code is working. http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/fe85faaeecdd3da -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Bug#708928: regression from 3.20-4: cannot connect to some gateways
On Mon, 2013-05-20 at 11:40 +0300, Modestas Vainius wrote: It appears VPN is behind firewall which does IP filtering of some sort hence it is not publically accessible. Is there anything else I can do? Would capturing the whole gateway- openconnect conversation at protocol level (SSL-decryted obviously) help? That's basically what I'd be trying to do, and then trying to work out what we're doing wrong. In http.c, in do_https_request() can you print the contents of 'buf-data' immediately before the call to openconnect_SSL_write() at about line 880, and also print the contents of 'form_buf' immediately after the call to process_http_response() a few lines down? I don't think there should be any sensitive information in there (it's all before any authentication, of course), but do give it a quick look before sending it. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Bug#708928: regression from 3.20-4: cannot connect to some gateways
On Mon, 2013-05-20 at 22:56 +0300, Modestas Vainius wrote:
It appears that the gateway does not like a POST request it gets to its / and
then invalidates SSL connection. But openconnect does not detect this
condition and tries to fallback to GET / on the same connection which has no
chance of succeeding since connection is no longer valid.
Aha, thanks for the excellent debugging. So does this fix it? It should
now close the connection correctly, in the situation you describe.
It's not ideal; we really ought to handle the write failure in
do_https_request() and attempt to re-open the socket *if* we were
re-using an existing one. But that'll take a little more work...
diff --git a/http.c b/http.c
index 9869354..ad9bfbd 100644
--- a/http.c
+++ b/http.c
@@ -197,6 +197,7 @@ static int process_http_response(struct openconnect_info
*vpninfo, int *result,
if (openconnect_SSL_gets(vpninfo, buf, sizeof(buf)) 0) {
vpn_progress(vpninfo, PRG_ERR,
_(Error fetching HTTPS response\n));
+ openconnect_close_https(vpninfo, 0);
return -EINVAL;
}
@@ -206,6 +207,7 @@ static int process_http_response(struct openconnect_info
*vpninfo, int *result,
if ((!closeconn strncmp(buf, HTTP/1.1 , 9)) || !(*result =
atoi(buf+9))) {
vpn_progress(vpninfo, PRG_ERR,
_(Failed to parse HTTP response '%s'\n), buf);
+ openconnect_close_https(vpninfo, 0);
return -EINVAL;
}
@@ -219,6 +221,7 @@ static int process_http_response(struct openconnect_info
*vpninfo, int *result,
if (i 0) {
vpn_progress(vpninfo, PRG_ERR,
_(Error processing HTTP response\n));
+ openconnect_close_https(vpninfo, 0);
return -EINVAL;
}
colon = strchr(buf, ':');
@@ -296,6 +299,7 @@ static int process_http_response(struct openconnect_info
*vpninfo, int *result,
vpn_progress(vpninfo, PRG_ERR,
_(Response body has negative size
(%d)\n),
bodylen);
+ openconnect_close_https(vpninfo, 0);
return -EINVAL;
}
}
@@ -306,6 +310,7 @@ static int process_http_response(struct openconnect_info
*vpninfo, int *result,
vpn_progress(vpninfo, PRG_ERR,
_(Unknown Transfer-Encoding:
%s\n),
colon);
+ openconnect_close_https(vpninfo, 0);
return -EINVAL;
}
}
@@ -333,6 +338,7 @@ static int process_http_response(struct openconnect_info
*vpninfo, int *result,
if (i 0) {
vpn_progress(vpninfo, PRG_ERR,
_(Error reading HTTP response
body\n));
+ openconnect_close_https(vpninfo, 0);
free(body);
return -EINVAL;
}
@@ -404,6 +410,7 @@ static int process_http_response(struct openconnect_info
*vpninfo, int *result,
} else if (i 0) {
/* Error */
free(body);
+ openconnect_close_https(vpninfo, 0);
return i;
} else {
/* Connection closed. Reduce allocation to just
what we need */
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
signature.asc
Description: This is a digitally signed message part
smime.p7s
Description: S/MIME cryptographic signature
Bug#708928: regression from 3.20-4: cannot connect to some gateways
On Sun, 2013-05-19 at 20:08 +0300, Modestas Vainius wrote: Hello, the error message as it is now I started getting with: 1725ee9 http: Rewrite openconnect_obtain_cookie() loop However, since 4beeace http: Split GET/POST logic into a helper function openconnect stopped prompting me for USERNAME/PASSWORD: Please provide the address of this server, and I'll look into it. Note that there's no harm in giving out the address of the server (it's a publicly-accessible web server on the Internet, after all). I'm *not* asking for your username and password. But do feel free to provide it in private email if you really prefer. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Bug#669702: OpenSSL and Openconnect VPN in plasma networkmanagement
On Tue, 2012-06-12 at 15:18 +0200, Ralf Jung wrote: error [1339506419.612035] [nm-vpn-connection.c:934] get_secrets_cb(): Failed to request VPN secrets #3: (6) No agents were available for this request. I'm not entirely sure when plasma-widget-networkmanagement registers its NM VPN agent. This is almost certainly a problem with that, rather than the openconnect-specific parts. Can you restart kded perhaps? I've made a 3.99 release of OpenConnect, which is essentially a beta for 4.00. Matthew, you might want the subsequent patch from the git tree if you're using OpenSSL for DTLS still. The auth-dialog patches for GNOME are already upstream, although you need *not* to include the IPv6 bits from NetworkManager-openconnect unless you've also got an up-to-date NetworkManager. And the final auth-dialog patch for KDE is https://git.reviewboard.kde.org/r/105185/ The packages in Fedora rawhide should be working, using GnuTLS for authentication and falling back to OpenSSL (only in /usr/sbin/openconnect) for DTLS. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Bug#669702: OpenSSL and Openconnect VPN in plasma networkmanagement
On Thu, 2012-06-07 at 12:16 +0200, Ralf Jung wrote: So the next step would be to change the KDE openconnect NM plugin to use the GnuTLS backend of openconnect instead of the OpenSSL one? Currently the backend also uses some stuff directly from OpenSSL, I do not know why that is needed. I fixed that already: http://git.infradead.org/users/dwmw2/networkmanagement.git/commitdiff/dde75baa -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Bug#669702: OpenSSL and Openconnect VPN in plasma networkmanagement
On Mon, 2012-05-28 at 13:14 +0200, Ralf Jung wrote: That said, I'm working on porting to GnuTLS anyway. That's good news. Let me know if I can help testing :) http://lists.infradead.org/pipermail/openconnect-devel/2012-May/000572.html -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Bug#669702: OpenSSL and Openconnect VPN in plasma networkmanagement
On Mon, 2012-05-28 at 12:21 +0200, Ralf Jung wrote: According to the copyright headers and the git log, you are the main and actually almost the only author of that plugin. Is that correct, and if yes, would you be willing to add a license extension as stated in [1] to the files, so they can be linked with OpenSSL? Like libopenconnect itself, Ilia's code is already licensed under the LGPL, not the GPL. There is no need for an exception for OpenSSL, in the openconnect-specific plugin. Whether that's sufficient or not is not entirely clear to me though. It is still being loaded into the GPL'd kded as a plugin, after all. [1] http://people.gnome.org/~markmc/openssl-and-the-gpl.html That highlights §2 and §6 of the OpenSSL licence: * 3. All advertising materials mentioning features or use of this *software must display the following acknowledgment: *This product includes software developed by the OpenSSL Project *for use in the OpenSSL Toolkit. (http://www.openssl.org/) * 6. Redistributions of any form whatsoever must retain the following *acknowledgment: *This product includes software developed by the OpenSSL Project *for use in the OpenSSL Toolkit (http://www.openssl.org/) I don't see the relevance of §6. You're linking to a copy of OpenSSL in shared library form which already exists on the system; you aren't redistributing it in any form. So that should be a non-issue, surely? So that leaves §2, and I have difficulty understanding precisely what restriction that places on kded. We don't *have* any advertising materials that mention features or use of OpenSSL, but I suppose the concern is that any downstream user must have the right to *create* such, without the wording that OpenSSL requires? But surely they *can* anyway? Doing so doesn't restrict their ability to use libopenconnect or anything higher up in the stack; only their ability to distribute OpenSSL itself, which as already observed we aren't doing. That said, I'm working on porting to GnuTLS anyway. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Bug#669702: OpenSSL and Openconnect VPN in plasma networkmanagement
On Mon, 2012-05-28 at 13:14 +0200, Ralf Jung wrote: * 6. Redistributions of any form whatsoever must retain the following *acknowledgment: *This product includes software developed by the OpenSSL Project *for use in the OpenSSL Toolkit (http://www.openssl.org/) I don't see the relevance of §6. You're linking to a copy of OpenSSL in shared library form which already exists on the system; you aren't redistributing it in any form. So that should be a non-issue, surely? From what I understood - but that's not very much - the problem is simply that this is a restriction, while the GPL forbids all kinds of restrictions. It's not a restriction unless you are redistributing OpenSSL, which nobody here is doing. That said, I'm working on porting to GnuTLS anyway. That's good news. Let me know if I can help testing :) It'll be a while; there's a lot to be done and I don't have a lot of free time for it at the moment. If anyone else is interested in working on it, I'd be happy to hand off my work-in-progress and my vague notes on what else needs doing (past the basics of actually making it compile). -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Bug#669702: Patch to enable openconnect VPN plugin
On Fri, 2012-05-25 at 22:45 +0200, Michael Biebl wrote: If only openconnect would have used gnutls... If only gnutls would have given a sane way to use a certificate from a TPM, and supported DTLS. Hey, maybe I wouldn't have had to write HTTP client support for myself at all; I could have used one of the multitude of existing libraries! Looking to the future though: gnutls does have DTLS support now, and it shouldn't be that hard to make it support the slightly nonstandard version of DTLS that Cisco use in AnyConnect. And I'd settle for generic PKCS#11 module support (even though there's still no sane PKCS#11 module for TPM access). Patches to openconnect to make it optionally use gnutls instead of openssl would be most welcome... and it could be done incrementally; using gnutls just for the TCP connection first and still using OpenSSL for DTLS (which happens in openconnect(8) not in libopenconnect). That would be enough to solve this issue, and adding PKCS#11 support and DTLS support could come later. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Bug#668282: openconnect: Fix FTBFS on kfreebsd and hurd
On Tue, 2012-04-10 at 17:29 +0200, Svante Signell wrote: The inlined patch below solves the build problems for GNU/Hurd and GNU/kFreeBSD by defining the _GNU_SOURCE macro also for these architectures. This should already be fixed in the 3.16 release by the patch at http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/21289460 Thanks! -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Bug#640978: [vpnc-devel] Bug#640978: vpnc-script requires an update for recent iproute
On Sun, 2011-11-27 at 11:26 +0800, Antonio Borneo wrote: On Sat, Nov 26, 2011 at 5:14 PM, David Woodhouse dw...@infradead.org wrote: On Fri, 2011-11-25 at 08:24 +0800, Antonio Borneo wrote: no reason, should be applied. I'll commit it in the weekend. If you don't want to just delete vpnc-script from the vpnc repo, then it would be best to pull in *all* the fixes from the git tree rather than diverging. Hi David, for openvpn the script vpnc-script is one of the possible options. It is acceptable to have it on a separate repository. For vpnc, the script is a mandatory component. I prefer keeping it inside the same repository. ... unless you're using NetworkManager or ConnMan, of course. Those each have their own alternative version that just passes the information back to NM/CM via DBus. The situation is exactly the same for openconnect which was designed to use a vpnc-script identical to vpnc's. When used from the command line, the vpnc-script is mandatory. To start with, distributions made the openconnect package depend on the vpnc package — but now they tend to have a separate 'vpnc-script' package which both vpnc and openconnect packages can depend on, so that you don't *have* to have vpnc installed. I would like to pull all the fixes from your repository and I'm checking all of them. I have some concern about IPv6 patches. So far vpnc doesn't have real support for IPv6. Just few macro definition and a check in the script. Should we consider these patches as a early IPv6 support in the script, waiting for contribution in the core code? Are they required by systems configured for IPv6 and running current vpnc? No, not using vpnc. Only openconnect. But it shouldn't be particularly hard to make it work for vpnc too, if someone can set up a test server with IPv6. It doesn't even need to be *real* globally-routable IPv6; just site-local addresses where you can only reach the server and no further would be sufficient to test basic connectivity and setup. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Bug#640978: [vpnc-devel] Bug#640978: vpnc-script requires an update for recent iproute
On Fri, 2011-11-25 at 08:24 +0800, Antonio Borneo wrote: no reason, should be applied. I'll commit it in the weekend. If you don't want to just delete vpnc-script from the vpnc repo, then it would be best to pull in *all* the fixes from the git tree rather than diverging. In fact, if you want to convert the vpnc repo from Subversion to git, it would then be easy to automatically pull in the changes from vpnc-scripts.git. I can help you with that (and give you somewhere to host it) if it helps. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Bug#640978: [vpnc-devel] Bug#640978: vpnc-script requires an update for recent iproute
On Wed, 2011-11-23 at 23:29 +0100, Florian Schlichting wrote: I was just thinking that I should submit a patch which removes the out-of-date script from vpnc altogether. There have been a number of other fixes in the git tree too. What do you mean remove the script from vpnc - how would routes pushed from the concentrator be configured on the client without this script? They wouldn't be configured *without* the script. They'd be configured by an up-to-date version of the script, from its own git repository. Preferably shipped in its own package, which both vpnc and openconnect packages can depend on. Note: That fuzz you speak of when applying the patch... that's due to the rest of the fixes to vpnc-script since it was imported into its own git repo, surely? -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Bug#640978: [vpnc-devel] Bug#640978: vpnc-script requires an update for recent iproute
(Resending to Debian bug since I just got a bizarre complaint that my reply didn't have a Package: line at the start. Perhaps it didn't like the original mail being S/MIME signed?) On Sat, 2011-09-10 at 15:52 +0800, Antonio Borneo wrote: In the fix you provide, 1) you add ;s/ipid 0x//g at the end of string. This does not impact backward compatibility. I'm in favour to commit it. It's not sufficient. We originally had this in the vpnc-scripts.git repository¹ since about May, but then the iproute command grew *more* unrecognised output options so we have since changed it to be 'opt-in' instead of 'opt-out'². I was just thinking that I should submit a patch which removes the out-of-date script from vpnc altogether. There have been a number of other fixes in the git tree too. -- dwmw2 ¹ http://git.infradead.org/users/dwmw2/vpnc-scripts.git/shortlog ² http://git.infradead.org/users/dwmw2/vpnc-scripts.git/commitdiff/4deaaf9a32 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#640978: [vpnc-devel] Bug#640978: vpnc-script requires an update for recent iproute
On Sat, 2011-09-10 at 15:52 +0800, Antonio Borneo wrote: In the fix you provide, 1) you add ;s/ipid 0x//g at the end of string. This does not impact backward compatibility. I'm in favour to commit it. It's not sufficient. We originally had this in the vpnc-scripts.git repository¹ since about May, but then the iproute command grew *more* unrecognised output options so we have since changed it to be 'opt-in' instead of 'opt-out'². I was just thinking that I should submit a patch which removes the out-of-date script from vpnc altogether. There have been a number of other fixes in the git tree too. -- dwmw2 ¹ http://git.infradead.org/users/dwmw2/vpnc-scripts.git/shortlog ² http://git.infradead.org/users/dwmw2/vpnc-scripts.git/commitdiff/4deaaf9a32 smime.p7s Description: S/MIME cryptographic signature
Bug#637362: openconnect: Fix FTBFS on hurd-i386
On Tue, 2011-08-16 at 12:24 +0200, Svante Signell wrote: Signed-off-by: svante.sign...@telia.com Or do you need a DM to do the signing. I'm not a DM myself, but can find one if needed. From yourself is what I needed, as the author of the patch. Applied; thanks: http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/1f8e4849 -- dwmw2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#637362: openconnect: Fix FTBFS on hurd-i386
On Wed, 2011-08-10 at 18:22 +0200, Svante Signell wrote: Source: openconnect Version: 3.02-1 Severity: important Tags: patch User: debian-h...@lists.debian.org Usertags: hurd Hi, currently openconnect does not compile on hurd-i386. The problem is a missing inclusion of sys/statfs.h in ssl.c. The inlined patch fixes this issue. Thanks. Can I have that patch again with a Signed-off-by: please? -- dwmw2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628676: firmware-nonfree: add ti-connectivity firmware
On Sun, 5 Jun 2011, Ben Hutchings wrote: This firmware has a very problematic licence. It actually forbids anyone to download the firmware without agreeing to the licence. We have no way to ask users whether they agree to this before even downloading the package. Do not download this unless you intend to comply with its licence is fairly much implicit in *anything* we distribute, isn't it? You only have permission to copy GPL software *if* you comply with its licence. David, I'm rather surprised you accepted firmware into linux-firmware with these terms, as it seems to mean that anyone cloning the repository is expected to accept them. I *do* expect anyone cloning the repository to comply with the indivual licences for the components therein. -- dwmw2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628676: firmware-nonfree: add ti-connectivity firmware
On Sun, 5 Jun 2011, Ben Hutchings wrote: In reality every transfer over a network involves many transient copies being made. However, I think that legally only the sender tends to be held responsible for distributing or copying. It was sent to me by TI with the express intention of including it in the git tree in that form. I *do* expect anyone cloning the repository to comply with the indivual licences for the components therein. But you also allow anyone to clone it before seeing the licence terms that may disallow that. So far as I know, none of the other licence texts claim to restrict recipients that don't use or redistribute the firmware. If you do nothing with the firmware, but it merely exists in your clone of the git tree (by virtue of TI's having deliberately put it there), what exactly are you restricted from doing? Why is this different to GPL'd firmware on which you violate the licence, and lose your rights? -- dwmw2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566191: #566191 — openconnect depends on a lot of libraries
As of OpenConnect v3.02 and NetworkManager v0.8.4, the auth-dialog has moved back to the NetworkManager-openconnect package where it belongs. OpenConnect provides a library, libopenconnect.a, which is used by the auth-dialog. Obviously that should be a *shared* library, but I'd rather not set an soname and commit to an ABI until I have at least one user of the 'library' that wasn't developed incestuously in conjunction with it. Hopefully we'll get that soon as a result of https://bugs.kde.org/show_bug.cgi?id=226028 or maybe in MeeGo (which is currently abusing the NetworkManager auth-dialog, but shouldn't be). -- dwmw2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566193: #566193 — Package upstream vpnc-scripts
Note that the vpnc-scripts there are designed to be compatible with both vpnc and openconnect. In Fedora we have dropped the old vpnc-script from the vpnc package, and we ship a separate vpnc-script package which *both* vpnc and openconnect depend on. -- dwmw2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606527: root upgrade vulnerability in exim4
(although sadly I can't see how to get it to render in a fixed-width font). http://bugs.exim.org/show_bug.cgi?id=1044 -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587849: [Evolution] Bug#587849: Bug#587849: Handle NSS init errors better
On Sat, 2010-07-03 at 15:00 +0200, Yves-Alexis Perez wrote: Then run evolution with the “old” .pki in place and report back. Please keep a 'pristine' copy of the old files too -- and in fact if they don't have any special keys or anything in them, please let me have a copy. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587849: SQL DB init
Hm, I don't know why the initialisation is failing. This patch adds some more information about the failure, which should help us understand. It also makes the code fall back to the old DBM database, so that Evolution will actually manage to start up. http://git.gnome.org/browse/evolution-data-server/commit/?h=gnome-2-30 -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587849: Handle NSS init errors better
This code isn't handling errors very well. First it ought to report the error more coherently so that we know what went wrong, and then it should fall back to using the old DBM database instead of just failing completely. This should fix those complaints, and I'd be very interested to know the output, which should explain _why_ the SQL database is failing to initialise. http://git.gnome.org/browse/evolution-data-server/commit/?h=gnome-2-30id=1ca0f0d2db265fcded9c74954d3651e1ba2b40b1 -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587849: [Evolution] Bug#587849: Handle NSS init errors better
On Fri, 2010-07-02 at 16:27 +0200, Yves-Alexis Perez wrote: David: would it make sense to try fixing permissions in case they're considered wrong by NSS and thus it won't open the db? I would be _very_ reluctant to do that kind of thing. I don't want to mess with permissions that someone else has set on the directory. Although if the problem was that the directory was _too_ permissive, and we're talking about tightening it up, then perhaps I could be persuaded. It would be interesting to know what the original problem was -- and more to the point, how it got that way. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#577004: openconnect: FTBFs on kfreebsd: error: storage size of 'buf' isn't known
http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/fe00b0e5 I've just done a v2.23 release with that, since I had some other things queued up anyway. -- dwmw2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#553024: [PATCH 1/2] phylib: Support phy module autoloading
On Thu, 2010-04-01 at 19:38 -0700, David Miller wrote: Whatever you submit next I'd like to toss into net-next-2.6 so it can cook for a while and maybe we'll backport it so that this bug can be fixed for good upstream and then perhaps even in -stable. When backporting, note that you'll need s/PHY_ID_BCMAC131/0x0143bc70/ in the patch to broadcom.c, because 2.6.32 didn't have a definition for that. There's also trivial change in phy_device_create() which will make the patch fail to apply, but git-cherry-pick copes. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#553024: [PATCH 1/2] phylib: Support phy module autoloading
On Thu, 2010-04-01 at 05:34 +0100, Ben Hutchings wrote:
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -188,7 +188,7 @@ struct phy_device* phy_device_create(struct mii_bus *bus,
int addr, int phy_id)
around for long enough for the driver to get loaded. With
MDIO, the NIC driver will get bored and give up as soon
as it finds that there's no driver _already_ loaded. */
- sprintf(modid, phy: PHYID_FMT, PHYID_ARGS(phy_id));
+ sprintf(modid, MDIO_MODULE_PREFIX MDIO_ID_FMT, MDIO_ID_ARGS(phy_id));
request_module(modid);
You forgot to increase the size of the 'modid' storage there, and it
needed to grow by one character. But that's OK. I forgot that
request_module() takes printf-style arguments. So now I've killed the
temporary 'modid' buffer altogether, and I just call
request_module(MDIO_MODULE_PREFIX ...). I dropped the ifdef, too.
-#define PHY_MODULE_PREFIXphy:
+#define MDIO_MODULE_PREFIX mdio:
-#define PHYID_FMT
%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d
-#define PHYID_ARGS(_id) \
+#define MDIO_ID_FMT
%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d
+#define MDIO_ID_ARGS(_id) \
(_id)31, ((_id)30) 1, ((_id)29) 1, ((_id)28) 1, \
((_id)27) 1, ((_id)26) 1, ((_id)25) 1, ((_id)24) 1, \
((_id)23) 1, ((_id)22) 1, ((_id)21) 1, ((_id)20) 1, \
@@ -487,11 +487,17 @@ struct platform_device_id {
((_id)7) 1, ((_id)6) 1, ((_id)5) 1, ((_id)4) 1, \
((_id)3) 1, ((_id)2) 1, ((_id)1) 1, (_id) 1
Still tempted to add a %b format to the kernel's printf... some runtimes
have it.
-
-
-struct phy_device_id {
- uint32_t phy_id;
- uint32_t phy_id_mask;
+/**
+ * struct mdio_device_id - identifies PHY devices on an MDIO/MII bus
+ * @phy_id: The result of
+ * (mdio_read(MII_PHYSID1) 16 | mdio_read(PHYSID2)) @phy_id_mask
+ * for this PHY type
+ * @phy_id_mask: Defines the significant bits of @phy_id. A value of 0
+ * is used to terminate an array of struct mdio_device_id.
That last sentence is a lie; I removed it. file2alias.c just ignores the
last entry in the array regardless of what it contains. I have no idea
why we use a 'terminator' in these arrays. Legacy, perhaps?
static int do_phy_entry(const char *filename,
- struct phy_device_id *id, char *alias)
+ struct mdio_device_id *id, char *alias)
I made that 'do_mdio_entry()' for cosmetic reasons.
- sizeof(struct phy_device_id), phy,
+ sizeof(struct mdio_device_id), phy,
And that mdio, not phy, so that it works.
--
dwmw2
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#553024: [PATCH 1/2] phylib: Support phy module autoloading
On Thu, 2010-04-01 at 05:34 +0100, Ben Hutchings wrote: On Wed, 2010-03-31 at 02:18 +0100, David Woodhouse wrote: We don't use the normal hotplug mechanism because it doesn't work. It will load the module some time after the device appears, but that's not good enough for us -- we need the driver loaded _immediately_ because otherwise the NIC driver may just abort and then the phy 'device' goes away. Instead, we just issue a request_module() directly in phy_device_create(). [...] Thanks for doing this, David. I had a stab at it earlier when this problem was reported in Debian http://bugs.debian.org/553024. I didn't complete this because (a) I didn't understand all the details of adding new device table type, and (b) I tried to avoid duplicating information, which turns out to be rather difficult in modules with multiple drivers. It shouldn't be _that_ hard. You could contrive a macro which you use inside the driver definition and which takes the phy_id and phy_id_mask as arguments, and has the side-effect of setting up the MODULE_DEVICE_TABLE data. Since you've dealt with (a), and (b) is not really as important, I would just like to suggest some minor changes to your patch 1 (see below). Feel free to fold them in. Your patch 2 would then need the substitutions s/phy_device_id/mdio_device_id/; s/TABLE(phy/TABLE(mdio/. I'll tolerate the silly __u32 crap if I must for consistency, but normally I prefer to write in C. I did think about 'mdio:' for the module alias, but I decided that 'phy:' probably made more sense since these are PHY driver modules and the number is the phy_id. Kernel-doc is good though. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524982: [Pkg-openssl-devel] Bug#524982: Integrate compatibility patches for Cisco VPN client DTLS
On Mon, 2009-04-27 at 23:24 +0200, Kurt Roeckx wrote: If my memory is any good, that last patch has been around for some time without respons from upstream, but now finally seems to have made it. Yeah, they ignored it for a long time (and ignored a lot of plain DTLS bug-fixes too). But now it all seems to be getting merged. I'll see about uploading a new version. Thanks. -- dwmw2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524982: DTLS
Patchsets 17500 and 17505 are simple bug fixes which are necessary to make normal DTLS work too, and which have already been included in two releases on the 0.9.8-stable branch. It's only 18307 which is specifically for compatibility with Cisco's speshul implementation. That patch is merged upstream now, and will be included in the _next_ release from the 0.9.8 branch. -- dwmw2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#296492: [exim] [Debian normal bug #296492] exim4: remote_smtp transport should fallback to ipv4 with fallback_hosts too
On Sun, 2005-02-27 at 00:06 +0100, Marc Haber wrote: this is Debian Bug #296492, which I consider a bug with normal severity from a Debian point of view. - Forwarded message from Laurent Fousse [EMAIL PROTECTED] - When sending to a remote host that has both an ipv6 and ipv4 RR, exim falls back immediately to ipv4 when ipv6 connectivity is not present. I noticed however that exim is stuck to ipv6 when it's trying to send to a fallback_host. Pleae define 'stuck to' in this context. Surely Exim should attempt to use all addresses in the RR set for the named fallback_host? Does it try only the first and then give up? If the first address returned from getaddrinfo() is the IPv6 address and you don't have a global IPv6 address of your own, then your resolver isn't conforming to RFC3484. Nevertheless, the failure to connect to the IPv6 address(es) should be fairly much instant, and we should fall back to the other address(es). Please could you describe the problem in more detail? -- dwmw2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
