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 b
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
>https://security-tracker.debian.org/tracker/
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
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 w
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 i
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-trus
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 de
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'
.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 — becau
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-ar
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-ar
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
ind
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 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 work
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:
>
> $
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 n
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
li
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,
#x27;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 th
.
--
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 lib
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 s
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
e.
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 So
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 su
uct openconnect_info
*vpninfo, int *result,
} else if (i < 0) {
/* Error */
free(body);
+ openconnect_close_https(vpninfo, 0);
return i;
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-d
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 pro
On Tue, 2012-06-12 at 15:18 +0200, Ralf Jung wrote:
> [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
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.
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 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
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 t
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
http://git.infradead.org
On Sun, 2011-11-27 at 11:26 +0800, Antonio Borneo wrote:
> On Sat, Nov 26, 2011 at 5:14 PM, David Woodhouse 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.
> >
>
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 wan
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 - ho
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
repositor
(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" a
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/us
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/s
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 includi
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
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 deb
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
> (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
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.
-
ons 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 i
o 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-30&id=1ca0f0d2db265fcded9c74954d3651e1ba2b40b1
--
David WoodhouseOpen Source Technology Centre
david.woodh
-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
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
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.
ting, 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 Woodhouse
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 no
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 n
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 up
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,
62 matches
Mail list logo