Delete references to long-removed SecurID code

Commit d707fc524 (Clean up auth form handling) removed securid.c and
the tokencode+PIN prompts, but the docs and headers still refer to these
features.

Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>

diff --git a/README.SecurID b/README.SecurID
deleted file mode 100644 (file)
index 3f5d115..0000000
--- a/README.SecurID
+++ /dev/null
@@ -1,38 +0,0 @@
-
-When it detects that the server is asking for a SecurID token, the
-OpenConnect client will now ask for both tokencode _and_ PIN.
-
-You can still just enter your tokencode with the PIN already
-incorporated as before, and leave the PIN entry box blank.
-
-
-Adding the PIN to a generated tokencode is a simple operation -- we
-just add each digit modulo 10. So a code of 12345678 + PIN 246801
-would give a result of 12581479, for example.
-
-By entering your PIN into the 'Token View' in the Windows SoftID
-client, you are giving your PIN away to anyone who can see the nice
-big readout of digits both before and after. As so-called "two-factor"
-authentication, it's a complete fig leaf. That's why we now give you
-the option of entering your PIN into the OpenConnect client instead.
-
-It would be even better if we could script the SecurID token somehow
-so that you don't need to copy and paste that part at all. The Windows
-tool should be scriptable, or the Java one might be a better option.
-
-The generate_securid_tokencodes() function in securid.c is waiting for
-someone to implement something along those lines.
-
-Even better would be to just implement SecurID natively -- it
-shouldn't be particularly hard. We already know how the 64-bit tokens
-work: http://seclists.org/bugtraq/2000/Dec/0459.html
-
-For the 128-bit tokens, they just use a standard AES algorithm instead
-of their own 'speshul' hash. A basic description of it can be found at
-http://www.velocityreviews.com/forums/t367596-aes-securid-token.html
-
-If we just work out how the input bits are fed into the hash, and work
-out how the token is stored in the file system, then we should be able
-to do that part transparently within the OpenConnect client (or, more
-usefully, in a generic library).
-

diff --git a/openconnect-internal.h b/openconnect-internal.h
index be958281974f435504a8bdd2ed165468928dcd85..eaf05a760bb27024bdb5fdfa3cbdfeea9bd9c9ff 100644 (file)
--- a/openconnect-internal.h
+++ b/openconnect-internal.h
@@ -398,10 +398,6 @@ int internal_parse_url(char *url, char **res_proto, char **res_host,
 /* ssl_ui.c */
 int set_openssl_ui(void);
 
-/* securid.c */
-int generate_securid_tokencodes(struct openconnect_info *vpninfo);
-int add_securid_pin(char *token, char *pin);
-
 /* version.c */
 extern const char *openconnect_version_str;