David Woodhouse [Thu, 9 Aug 2018 10:27:08 +0000 (11:27 +0100)]
Don't treat Juniper 'realm' field as authgroup
The only point in the authgroup thing for the UI is to allow OpenConnect
to re-request the set of query fields for the new group. But the Juniper
protocol doesn't do that, and it's causing problems.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
David Woodhouse [Thu, 9 Aug 2018 09:56:21 +0000 (10:56 +0100)]
Provide unique hostname to CSD script
We see failures when DNS gives us a different IP address and the CSD
trojan ends up talking to a different host to the one we're actually
trying to authenticate to. Since we use pinned certificate hashes, it
shouldn't matter that we lose the hostname and can't validate the cert
against it.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Sun, 5 Aug 2018 23:05:06 +0000 (16:05 -0700)]
fix segfault in Java library test application
calling the Java method setCSDWrapper(String wrapper, String TMPDIR, String
PATH) with null TMPDIR and PATH would cause a segfault because
openconnect_set_csd_wrapper(vpninfo, name, value) requires a non-NULL value
Daniel Lenski [Sat, 4 Aug 2018 03:01:26 +0000 (20:01 -0700)]
include computer name in the GP cookie
The GlobalProtect "cookie" is an overstuffed monstrosity, due to the
requirement to retain a few random, non-secret values in order to logout
successfully (see gpst_bye):
Until now, I've avoided including the computer field in this cookie, on the assumption that it
can reproduced at any time using vpninfo->localname. However, it appears that this value can't always
be reproduced correctly when running under NetworkManager:
Daniel Lenski [Thu, 2 Aug 2018 19:10:45 +0000 (12:10 -0700)]
Remove first oNCP negotiation request (only second is necessary)
The current oNCP (Juniper) protocol support issues two separate
oNCP negotiation requests.
1) POST /dana/js?prot=1&svc=1 HTTP/1.1
<ignore response body>
<teardown and restart TLS connection>
2) POST /dana/js?prot=1&svc=4 HTTP/1.1
<continue using open TLS connection for oNCP tunnel>
The first of these two requests appears to be totally unnecessary, based on
testing with two different Juniper gateways, one of which returns
"NCP-Version: 2" and one which returns "NCP-Version: 3" in response to the
oNCP negotiation requests.
Removing the first request saves an additional TLS negotiation (2-3
roundtrips with TLS 1.0) and allows the connection to start faster.
Daniel Lenski [Thu, 2 Aug 2018 19:10:45 +0000 (12:10 -0700)]
Reduce unnecessary connection-rebuilding for Juniper
The current oNCP (Juniper) protocol support sets "Connection: close" in all
HTTP requests. This is not ideal because it requires many TLS handshakes
and round-trips, making the connection very slow to start when the latency
of the connection to the gateway is high, especially if the number of
authentication forms and redirects is large.
Simply removing the "Connection: close" header causes the oNCP connection
to fail; the server doesn't interpret the first packet sent over the oNCP
tunnel correctly (the vestigial authentication packet).
However, it appears that the "Connection: close" header *only* needs to be
specified for this final HTTP request, and not for any of the prior ones.
The presence of this header seems to signal to the gateway that it should
stop treating this as an HTTP connection, and start treating it as an
oNCP tunnel.
Tested on two different Juniper gateways, one which returns
"NCP-Version: 2" and one which returns "NCP-Version: 3" in response to
the oNCP negotiation requests.
Daniel Lenski [Thu, 2 Aug 2018 01:13:59 +0000 (18:13 -0700)]
Clarify protocol description in connection message
- Include both the TCP- and UDP-based protocols' compression details
- The UDP-based protocol really can't be connected by the time this
prints, since the mainloop hasn't had enough time to receive the
connection confirmation packets; show it as "in progress"
Before (with default verbosity):
Connected as 10.0.0.3 + dead::be:ef, using SSL + deflate
Established DTLS connection (using GnuTLS). Ciphersuite (DTLS1.2)-(RSA)-(AES-128-GCM).
After:
Connected as 10.0.0.3 + dead::be:ef, using SSL + Deflate, with DTLS + LZS in progress
Established DTLS connection (using GnuTLS). Ciphersuite (DTLS1.2)-(RSA)-(AES-128-GCM).
Daniel Lenski [Wed, 1 Aug 2018 02:35:59 +0000 (19:35 -0700)]
Align naming and commenting of mechanism for receiving oversize packets across protocols
We've now implemented mechanisms to tolerate larger-than-expected packets for:
- Uncompressed CSTP packets ("Fixed regression with CSTP MTU handling"
patch in July 2016)
- Uncompressed oNCP packets ("Do not drop vpn connection if packet arrived
is larger than MTU" patch in May 2017)
- Uncompressed GPST packets (in original merge from March 2018; this is a
virtual necessity for GlobalProtect because it has no functional
mechanism for negotiating the MTU)
- Uncompressed ESP packets ("check for oversize ESP packets, with 256
bytes of headroom above calculated" in March 2018; GlobalProtect requires
this for the aforementioned reason)
- Compressed CSTP packets (preceding patch in this series)
Since this is a requiring issue across protocols, it's useful to align the
naming, commenting, and packet sizing-tolerance across the source files.
1) Use receive_mtu everywhere as the name for the maximum tolerated size of an
incoming packet.
2) Insert similar comments explaining its purpose everywhere it's used.
3) Use receive_mtu = MAX(16384, vpninfo->ip_info.mtu) for all TLS-based
tunnels, because 16384 is the maximum TLS record size.
4) Use receive_mtu = MAX(2048, vpninfo->vpninfo->ip_info.mtu + 256) for
all UDP-based tunnels, because the MTU of IP datagrams on the public
internet is effectively ~1500.
Daniel Lenski [Wed, 1 Aug 2018 02:32:26 +0000 (19:32 -0700)]
Tolerate packets that are larger than negotiated MTU after decompression
In July 2016, the "Fixed regression with CSTP MTU handling" patch
(http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/90e1555494dbc1cf462552679f9aa3d30451d123)
allowed openconnect to gracefully handle uncompressed CSTP packets larger
than the negotiated MTU.
This patch extends that approach to tolerate compressed packets which are
larger than the negotiated MTU after decompression.
Daniel Lenski [Tue, 27 Mar 2018 15:39:58 +0000 (08:39 -0700)]
check for oversize ESP packets, with 256 bytes of headroom above calculated MTU
Because GlobalProtect VPNs have no practical mechanism for negotiating the
MTU whatsoever, it is entirely based on a client-side guess. Therefore,
extra headroom is needed to reliably receive packets via both the HTTPS and
the ESP tunnels.
A similar patch by Nikolay Martynov <mar.kolya@gmail.com> was originally
applied for the Juniper HTTPS tunnel:
http://lists.infradead.org/pipermail/openconnect-devel/2017-May/004320.html
And similar functionality was incorporated into the GlobalProtect HTTPS
tunnel as well (gpst.c).
This patch adds the extra headroom for the ESP tunnel (used by both Juniper
and GlobalProtect VPNs) as well, after unexpectedly-large ESP packets were
observed "in the wild":
https://github.com/dlenski/openconnect/issues/96
Signed-off-by: Dan Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Thu, 31 May 2018 15:25:15 +0000 (18:25 +0300)]
fix typo in Juniper TOTP form name
There's a thread from November 2017 in which Kevin Cernekee and Andy
Wang discuss a Juniper VPN where TOTP fails to work:
http://lists.infradead.org/pipermail/openconnect-devel/2017-November/004569.html
… and in that thread both "ftmTotpToken" and "frmTotpToken" are
mentioned. It appears that the reason for the misbehavior discussed in
the November 2017 is because of the (overlooked) typo in the code.
I'm not sure how the "ftm" version got committed in the first
place. ¯\_(ツ)_/¯. I did a bit of archeological digging, and I can't
find the original patch (from November 29, 2016) anywhere on the
mailing list, but it's obviously in the Git history:
http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/1ff34cb9689fbaf57decac537df1e32e799bb9c7
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
David Woodhouse [Tue, 29 May 2018 13:40:18 +0000 (14:40 +0100)]
Gitlab CI updates
Install 'make' and disable DSA tests on Fedora.
Remove vestiges of CentOS locale stuff which never worked.
Drop libp11 since it doesn't exist in Fedora any more.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Tue, 22 May 2018 15:57:10 +0000 (18:57 +0300)]
GlobalProtect can apparently deliver the challenge 2FA forms as XML in addition to JavaScript
This patch also prevents openconnect from reusing the last portal login form
wholesale on the gateway *if* it's a challenge form, since the same auth_id
and 2FA token won't work twice.
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Sun, 4 Mar 2018 09:32:00 +0000 (11:32 +0200)]
Add support for checking and submitting HIP reports
Unlike CSD, the HIP security checker runs during the connection phase, not
during the authentication phase.
Therefore we need to build the CSD token (an MD5 digest identifying the
client) without relying on the authentication phase having run in the same
process.
We build it from the cookie containing authentication information,
but exclude the volatile field (which changes from session to session)
and the preferred-ip field (which may not be present in all cases, or may
change from session to session).
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Sun, 4 Mar 2018 09:31:59 +0000 (11:31 +0200)]
Add support for GlobalProtect ESP tunnel
Most of the existing ESP support code (written for Juniper/nc) can be reused
for GlobalProtect ESP. The ESP algorithms, SPIs, and keys are sent as part of the
getconfig XML response.
GlobalProtect requires a fairly awkward "tap dance" between the TCP mainloop and
the UDP mainloop in order to support ESP:
* Prior to the getconfig XML request, the HTTPS tunnel will not work (even though
the authcookie is already known from the login response) and the ESP tunnel
also will not work (because the ESP keys are not known).
* After the getconfig XML request, either the ESP tunnel or the HTTPS tunnel can
be connected, but not both. As soon as the HTTPS tunnel is disconnected,
the ESP keys are invalidated. On the other hand, if the ESP tunnel stops
responding due to some firewall that interferes with UDP, the HTTPS tunnel
can still be connected.
* Therefore, in order to allow the ESP tunnel to start, the TCP mainloop must
refrain from actually connecting to the HTTPS tunnel unless the ESP tunnel
is disabled or has failed to connect... but it can't wait *too* long
because then the HTTPS keepalive connection may be dropped, and the user
will wonder why no traffic is flowing even though the VPN has allegedly
started. The wait time is currently hard-coded at 5 seconds (half the DPD
interval used by the official clients).
Another quirk of the GlobalProtect ESP support: it uses specially
constructed ICMP request/reply ("ping") packets as the probes for ESP
initiation and DPD.
* These packets must contain a "magic payload" in order to work.
* In most GlobalProtect VPNs, the packets are addressed to the public, external IPv4
address of the VPN gateway server even though they are sent over the ESP
tunnel (???), but in some cases they must be addressed to a different address
which is misleading described as <gw-address> in the getconfig XML response.
Don't blame me. I didn't design this.
GlobalProtect also has the strange quirk that incoming (server → client) ESP
sequence numbers start at 1, not 0, but this just causes a one-time offset
for the replay protection checker.
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Sun, 4 Mar 2018 09:31:58 +0000 (11:31 +0200)]
add PAN GlobalProtect protocol support (HTTPS tunnel only)
This includes support for generating an xmlconfig so that NetworkManager can
list all the gateway servers, when connecting to a GlobalProtect portal (not
gateway):
GlobalProtect distinguishes "portal" and "gateway" servers. Often the same
server supports both (/global-protect URLs are for the portal, /ssl-vpn URLs
are for the gateway). The official clients always connect through the
portal. Mostly, the portal configuration is not useful for OpenConnect; it
restricts the behavior of the official clients.
However, the portal configuration does contain a list of allowed gateways
(just as AnyConnect VPNs can list other servers). We therefore generate an
xmlconfig in the same format as AnyConnect VPNs, so that the NetworkManager
plugins can list all the supported gateways.
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Sun, 4 Mar 2018 09:31:57 +0000 (11:31 +0200)]
detect user[name], pass[word] form fields using only the first 4 characters
The current process_auth_form_cb hard-codes the interpretation of these form
fields based on their names. GlobalProtect has identical fields but with
slightly different names.
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Sun, 15 Apr 2018 23:40:35 +0000 (16:40 -0700)]
move sending of ONCP control packets for enabling/disabling ESP into oncp.c
This is another small case of Juniper-specific handling in the ESP code.
The ONCP protocol needs to tell the server to explicitly enable or disable
the ESP tunnel, and uses the same oncp_control_queue for ESP rekeying.
Simplified and refactor by David Woodhouse.
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
David Woodhouse [Tue, 29 May 2018 11:55:31 +0000 (12:55 +0100)]
Cope with gnutls_pkcs11_obj_get_info() ABI change in 3.6.0
Since 3.6.0, gnutls_pkcs11_obj_get_info() no longer includes the NUL
terminator in the output_size it returns. This was causing fields to
be truncated by one character.
David Woodhouse [Tue, 13 Mar 2018 15:32:19 +0000 (15:32 +0000)]
Fix translation of ESP warning messages
In commit 4daac3fa2e2 ("Save latest ESP sequence number even if replay
protection isn't in use") the messages for discarded packets were mangled
in a horribly untranslatable way. I should know better than that. Stupid
dwmw2; no biscuit.
Thanks to Marek Černocký for pointing it out.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Tue, 27 Feb 2018 10:11:16 +0000 (12:11 +0200)]
fix a bug leading to incorrect split-include netmasks
This bug was my fault. Introduced in 881eb286499baf78afbaeff4dbc5f055d23f1e4f on 15 Oct 2016 ("Correctly handle IPv4 route specified as either 10.1.2.0/255.255.255.0 or 10.1.2.0/24")
Left shift of >=32 bits is undefined on x86 (https://stackoverflow.com/a/7471843/20789), and it was causing split-includes of 0.0.0.0/0 to output inconsistent values to
the vpnc-script variables for split-includes:
CISCO_SPLIT_INC_12_MASKLEN=0
CISCO_SPLIT_INC_12_ADDR=0.0.0.0
CISCO_SPLIT_INC_12_MASK=255.255.255.255 # generated by netmaskbits() in script.c -- WRONG!
Caught due to an assertion failing in vpn-slice: https://github.com/dlenski/vpn-slice/issues/9
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Mon, 8 Jan 2018 01:54:38 +0000 (17:54 -0800)]
Save latest ESP sequence number even if replay protection isn't in use
In the current source, incoming ESP sequence numbers
(vpninfo->esp_in[vpinfo->current_esp_in].seq) are not actually tracked at
all unless replay protection is in use.
At the time of a rekey, old_esp_maxseq is *set based on the current value of
the incoming seq* at the time of the switchover:
if (new_keys) {
vpninfo->old_esp_maxseq = vpninfo->esp_in[vpninfo->current_esp_in].seq + 32;
And then esp.c rejects packets with the old incoming SPI, unless seqp < old_esp_maxseq:
This code is supposed to allow a smooth handover from the old incoming SPI
to the new one after a rekey, so that in-flight packets from the old SPI
aren't totally dropped, but also aren't allowed to continue forever.
This patch tracks the latest sequence number even if ESP replay protection
isn't in use -- however inadvisable that may be -- allowing the handover to
work correctly.
This patch also improves the confusing trace message shown when a packet
from the old SPI is received.
[dwmw2: Just call verify_packet_seqno() every time, and let it return an
artificial 'success' when replay protection is turned off. Also
add changelog entry.]
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Ľubomír Carik [Wed, 21 Feb 2018 20:29:31 +0000 (21:29 +0100)]
Windows application icon
This tool is console application only, but many terminals re-use
the icon if exists. In addition window tab-switching with that
terminal window is decorated by this icon as well.
Signed-off-by: Ľubomír Carik <Lubomir.Carik@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Kevin Cernekee [Mon, 12 Feb 2018 01:02:04 +0000 (17:02 -0800)]
android: Re-enable optimization
The introduction of $(EXTRA_CFLAGS) in commit 00f0b80e4befe4
("android: Build ARM with -march=armv7-a") inadvertently overrode the
default "-O2 -g" CFLAGS. Fixing this + enabling Thumb reduces the ARM
libopenconnect.so from ~3.5MB to ~1.9MB.
Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
Kevin Cernekee [Fri, 2 Feb 2018 04:47:15 +0000 (20:47 -0800)]
java: Bump to Java 8
This fixes the following warnings:
[javac] warning: [options] bootstrap class path not set in conjunction with -source 1.5
[javac] warning: [options] source value 1.5 is obsolete and will be removed in a future release
[javac] warning: [options] target value 1.5 is obsolete and will be removed in a future release
Java 8 was released in 2014 so it should be widely available now.
Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
Kevin Cernekee [Mon, 29 Jan 2018 00:56:18 +0000 (16:56 -0800)]
android: Build libraries --with-pic
Recent Android OS releases have become stricter about TEXTRELs in
native code. When built without -DPIC, a few of the libgmp assembly
files generate problematic code sequences:
In this case, adjusting the address at 23f320 would require making .text
writable, which Android does not want to do.
The solution is to specify --with-pic which causes the LEA macro
($GMP/mpn/arm/arm-defs.m4) to embed a PC-relative address into the code,
avoiding the issue.
Tested on ARM + x86.
Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
Kevin Cernekee [Mon, 29 Jan 2018 06:33:58 +0000 (22:33 -0800)]
android: Upgrade liboath
liboath requires minor hacks to build with the latest NDK releases:
1) __freading() cannot be implemented, because older versions of
Bionic[0] do not keep track of the last operation on the stream.
2) Some of the autoconf checks need to be overridden from "cross" to
"yes".
3) Most of the stdio replacement code in gnulib doesn't compile,
because it requires access to internal libc structs. The internals
are no longer exposed through NDK headers, and they vary from one
Android version to the next.
Fortunately, while these hacks would not pass muster upstream, they
are good enough for the special case of compiling liboath.
Kevin Cernekee [Mon, 12 Feb 2018 03:34:22 +0000 (19:34 -0800)]
Fix crash on DTLS resumption
If the mainloop is paused and then resumed, DTLS will attempt to
reconnect at the same time as CSTP. When DTLS-PSK is in use,
gnutls_prf() will be called on a NULL vpninfo->https_sess pointer.
Avoid this by deferring DTLS resumption until CSTP has reconnected, if
DTLS-PSK is in use.
Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
Daniel Lenski [Wed, 21 Jun 2017 18:23:52 +0000 (11:23 -0700)]
try alternate vpnc-script location (used by Debian-based distros)
This patch checks for the vpnc-script in the location used by
the standard vpnc-script package on Debian- and Ubuntu-based
Linux systems, /usr/share/vpnc-scripts/vpnc-script, in addition
to the standard /etc/vpnc/vpnc-script.
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Sat, 20 May 2017 22:43:27 +0000 (15:43 -0700)]
add new_keys argument to esp_setup_keys() in preparation for supporting GlobalProtect ESP
The existing ESP key setup code can be almost entirely reused for
GlobalProtect ESP, except for the fact that esp_setup_keys() always
overwrites the secret keys with new random keys.
Since GlobalProtect ESP always uses keys provided by the server, a new
argument is added to esp_setup_keys() to make this behavior optional.
The Juniper-specific code in oncp.c calls it with new_keys=1 in order
to explicitly request it.
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Sat, 20 May 2017 22:43:26 +0000 (15:43 -0700)]
add vpn_proto member functions .udp_send_probes and .udp_catch_probe in preparation for supporting GlobalProtect ESP
The existing Juniper ESP code can be almost entirely reused for
GlobalProtect ESP, except for the Juniper-specific code for sending and
recognizing the probe packets used for ESP initiation and DPD.
The Juniper-specific code is moved into functions names esp_send_probes
(sends Juniper probe packets) and esp_catch_probe (recognizes Juniper probe
packet responses), which are called via vpn_proto member functions.
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Sat, 20 May 2017 22:43:25 +0000 (15:43 -0700)]
tweak the dtls_state handling in preparation for supporting GlobalProtect ESP
If a protocol wishes to have dtls_state set to DTLS_SLEEPING after closing
UDP, then it must now do so explicitly, because the mainloop will no longer
set it. This patch make both existing protocols set dtls_state explicitly
after closing the UDP connection. (The nc protocol already did so
explicitly, but the anyconnect protocol didn't.)
The previous behavior, wherein dtls_state was *always* set to DTLS_SLEEPING
after closing UDP, was incompatible with the GlobalProtect VPN.
Disconnecting and reconnecting GlobalProtect VPN doesn't just require
require reconnecting the UDP socket and resending probes; it actually
invalidates any previously-obtained ESP secret.
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Wed, 14 Jun 2017 22:54:56 +0000 (15:54 -0700)]
relax requirements for Juniper hostname packet response
This fixes the "Unexpected response of size 3 after hostname packet" or "Invalid packet waiting for KMP 301" errors
which I get intermittently when connecting to an old Juniper NC server:
Here's what is going on: this server is (sometimes) concatenating the 3-byte
response packet together with the longer IP-configuration packet that
follows. When they are concatenated together, the server sends only a
single 2-byte length prefix for both (0x01d2 = 466).
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Sat, 20 May 2017 22:43:22 +0000 (15:43 -0700)]
factor out common dump_buf_hex() and free_optlist() utility functions
These will be used in GlobalProtect protocol support, so it makes sense
to factor them out into shared utility functions rather than use slight
variants for each protocol.
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
David Woodhouse [Mon, 14 Aug 2017 10:33:16 +0000 (11:33 +0100)]
Require GnuTLS 3.2.10+ for GnuTLS builds
It's not worth the effort to keep it building for <3.2 any more; nobody
cares... or noticess when we accidentally break it. So kill it; we've
been threatening to for ages.
Use 3.2.10 as the base because 3.2.x before that was broken on Windows.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
David Woodhouse [Mon, 14 Aug 2017 09:42:41 +0000 (10:42 +0100)]
Allow reading stdin on Windows instead of forcibly opening console
This was filed against Ľubomír Carik's github project for openconnect-gui;
https://github.com/openconnect/openconnect-gui/issues/101
It isn't perfect, as the ANSI code page on Windows can be different
from the OEM code page used for the console, so fgetws() is likely
to do the wrong thing — which is why we force-opened the console and
used ReadConsoleW() in the first place. But perfect is the enemy of
good in this case, as reading from something other than stdin is
*definitely* wrong. We still use ReadConsoleW() when stdin does happen
to be the console, so that part shouldn't regress.
I hate Windows...
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
projects / users / dwmw2 / openconnect.git / log