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
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
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
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
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
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.)
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
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
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
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
ated 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
smi
(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 —
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:
>
>
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:
>
>
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
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
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
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
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
'
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
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
' 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
.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
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
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
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
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
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
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
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
*/
free(body);
+ openconnect_close_https(vpninfo, 0);
return i;
} else {
/* Connection closed. Reduce allocation to just
what we need */
--
David Woodhouse
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
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.
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
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
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
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/)
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
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
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
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
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
(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
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¹
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:
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
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
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
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
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
(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
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 Woodhouse
-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
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
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
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
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
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
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
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
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
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
62 matches
Mail list logo
