From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <b07c2ff1dcb618953620ac173286d274@hamnavoe.com>
To: 9fans@cse.psu.edu
From: Richard Miller <miller@hamnavoe.demon.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: [9fans] factotum apop protocol is incorrect
Date: Fri, 12 Dec 2003 19:47:35 +0000
Topicbox-Message-UUID: a0be6e4e-eacc-11e9-9e20-41e7f4b1d025

RFC1939 introduces the 'APOP name digest' command for
challenge-response authentication to a POP3 mail server, and says:
"The digest parameter ...  is sent in hexadecimal format, using
lower-case ASCII characters."

Factotum's proto=apop implementation encodes the digest as
upper-case hexadecimal.

Probably most POP3 servers can handle both, but I've just hit
an unforgiving one.

Possible fixes:

In /sys/src/cmd/auth/factotum/apop.c, replace
		sprint(s->resp, "%.*H", MD5dlen, digest);
with something like
		for(i=0; i<MD5dlen; i++)
			sprint(&s->resp[2*i], "%.2x", digest[i]);

or in /sys/src/libc/port/u16.c, replace
	static char t16e[] = "0123456789ABCDEF";
with
	static char t16e[] = "0123456789abcdef";

The latter has a more widespread effect, but it arguably makes the %H
format conform to its documentation.  The man page for print(2) makes
a distinction between "hexadecimal" and "upper case hexadecimal" for
%x and %X respectively.  enc16(2) just says %H means "base 16 (i.e.
hexadecimal)", so one might expect it to be lower case.

-- Richard Miller