challenger

commit 1020675832109df580a24ce0403cd8a49f026c73
parent 6b05c88f754b428cb3d3c14aabcd71fa332fa8d8
Author: Christian Grothoff <christian@grothoff.org>
Date:   Fri, 14 Aug 2026 17:47:31 +0200

disambiguate return values

Diffstat:
M
src/challenger/cat-once.sh
 | 
6
+++---
M
src/challenger/challenger-httpd_challenge.c
 | 
41
+++++++++++++++++++++++++++++++++--------

2 files changed, 36 insertions(+), 11 deletions(-)
diff --git a/src/challenger/cat-once.sh b/src/challenger/cat-once.sh
@@ -6,9 +6,9 @@
 # that went down between two TAN transmissions.
 #
 # Exit 30 ("provider outage or internal error", see challenger-send-sms(1))
-# is what a real helper reports for that.  Note that exit 1 would NOT work:
-# under the helper exit-code scheme anything below 10 means the TAN was
-# transmitted, and 1 specifically means "accepted, delivery not confirmed".
+# is what a real helper reports for that.  Under the helper exit-code scheme
+# the successes are 0 (delivered) and 200-210 (accepted for delivery); every
+# other status, exit 1 included, is a failure.
 TARGET="$(echo $1 | jq -r ".filename")"
 if [ -e "${TARGET}.sent" ]
 then
diff --git a/src/challenger/challenger-httpd_challenge.c b/src/challenger/challenger-httpd_challenge.c
@@ -305,14 +305,37 @@ reply_error (struct ChallengeContext *bc,
 
 
 /**
+ * Did a TAN transmission helper report that the TAN was transmitted?
+ *
+ * Exit code 0 means the TAN was confirmed to have reached the address.  The
+ * 200-210 band means a service accepted it for delivery without confirming
+ * that it arrived: 201 accepted by the provider, 202 suppressed as a duplicate
+ * of a message already in flight.
+ *
+ * The band deliberately does not start at 1: libgnunetutil reports a helper it
+ * failed to exec() as exit code 1, and that must not be mistaken for a
+ * delivery.
+ *
+ * @param exit_code exit status of the helper, which must have exited normally
+ * @return true if the TAN was transmitted
+ */
+static bool
+helper_reported_success (unsigned long int exit_code)
+{
+  return (0 == exit_code) ||
+         ( (exit_code >= 200) &&
+           (exit_code <= 210) );
+}
+
+
+/**
  * Map the exit status of a TAN transmission helper onto an HTTP status and
  * error code.
  *
  * The helpers use a banded exit-code scheme documented in
- * challenger-send-sms(1): anything below 10 means the TAN was transmitted (0
- * confirmed on the handset, 1 accepted by the provider, 2 suppressed as a
- * duplicate of a message already in flight), 10-19 blames the address the user
- * gave us, 20-29 is a recipient that is temporarily unreachable, 30-39 is the
+ * challenger-send-sms(1): 0 and 200-210 mean the TAN was transmitted (see
+ * #helper_reported_success()), 10-19 blames the address the user gave us,
+ * 20-29 is a recipient that is temporarily unreachable, 30-39 is the
  * transmission provider and 40-49 is our own configuration.
  *
  * Codes we do not recognise are reported as an upstream failure rather than
@@ -327,17 +350,19 @@ static enum TALER_ErrorCode
 classify_helper_status (unsigned long int exit_code,
                         unsigned int *http_status)
 {
-  if (exit_code < 10)
+  if (helper_reported_success (exit_code))
   {
     *http_status = MHD_HTTP_OK;
     return TALER_EC_NONE;
   }
-  if (exit_code < 20)
+  if ( (exit_code >= 10) &&
+       (exit_code < 20) )
   {
     *http_status = MHD_HTTP_BAD_REQUEST;
     return TALER_EC_CHALLENGER_ADDRESS_UNUSABLE;
   }
-  if (exit_code < 30)
+  if ( (exit_code >= 20) &&
+       (exit_code < 30) )
   {
     *http_status = MHD_HTTP_SERVICE_UNAVAILABLE;
     return TALER_EC_CHALLENGER_ADDRESS_UNREACHABLE;
@@ -883,7 +908,7 @@ CH_handler_challenge (struct CH_HandlerContext *hc,
   if ( (GNUNET_OS_PROCESS_UNKNOWN != bc->pst) &&
        (NULL == bc->child) &&
        ( (GNUNET_OS_PROCESS_EXITED != bc->pst) ||
-         (bc->exit_code >= 10) ) )
+         (! helper_reported_success (bc->exit_code)) ) )
   {
     char es[32];
     unsigned int http_status;