On Mon 2 Sep 2013 at 09:17:29AM +0200, Oswald Buddenhagen wrote: > On Mon, Sep 02, 2013 at 12:49:51AM -0500, guns wrote: > > mbsync currently assumes that all password inputs are double quote > > escaped¹. This is true for "Pass" config entries, the output of > > "PassCmd", and also for passwords entered at the terminal. [...] > > ¹ The following lines in src/compat/config.c illustrate this > > assumption: [...] > > > this analysis is incomplete. > for one, the compat/ folder is irrelevant for mbsync - it's the isync > compatibility wrapper. it needs to be dealt with separately. it would be > probably easiest to leave the quotes in the strings and write them out > again without adding new quotes.
I chose a bad example then. How about this one in src/drv_imap.c:
imap_exec( ctx, 0, imap_open_store_authenticate2_p2,
"LOGIN \"%s\" \"%s\"", srvc->user, srvc->pass );
If my PassCmd returns (or I enter at stdin):
a\b
then the pass field is set to the 3-character string a\b. This is then
sent verbatim to the IMAP server, but wrapped in quotes:
LOGIN "user" "a\b"
However, this is incorrect and results in an error since the password
must be sent as "a\\b" or as a\b (unquoted).
As it stands, it is up to the user to escape their own backslashes and
double quotes before passing to mbsync. This is surprising behaviour,
and no other IMAP client I have worked with has this requirement.
This kind of quoting issue is pervasive in the shell, in Lisp, and in
XML/HTML. The proper solution in each of these domains is to store the
raw value and quote on emission.
> second, it is correct that the main config parser does not deal with
> escaped qoutes. to not change the semantics of the backslash, i suggest
> to employ this trick: two adjacent quotes in a quoted string expand to
> one literal quote.
>
> lastly, the PassCmd output is *not* treated in any way. the problem is
> at the IMAP level: the spec does not define a means to escape quotes in
> a quoted string, so every server is likely to do something else. the
> solution would be sending (problematic) passwords as literals.
I defer to your experience, but there is this entry in RFC 2683:
http://www.ietf.org/rfc/rfc2683.txt
3.4.2. Special Characters
Certain characters, currently the double-quote and the backslash, may
not be sent as-is inside a quoted string. These characters must be
preceded by the escape character if they are in a quoted string, or
else the string must be sent as a literal. Both clients and servers
must handle this, both on output (they must send these characters
properly) and on input (they must be able to receive escaped
characters in quoted strings). Example:
C: 001 LIST "" %
S: * LIST () "" INBOX
S: * LIST () "\\" TEST
S: * LIST () "\\" {12}
S: "My" mailbox
S: 001 OK done
C: 002 LIST "" "\"My\" mailbox\\%"
S: * LIST () "\\" {17}
S: "My" mailbox\Junk
The title of this RFC is "IMAP4 Implementation Recommendations", so I
suppose this is not mandatory for compliance, but the IMAP servers I
interact with accept \\ and \" within in double-quoted strings.¹
> patches welcome.
The patch is trivial, but agreement is harder won.
Respectfully,
Sung Pae
¹ I often find myself submitting patches for password quoting problems
since I generate my passwords from /dev/random mapped over ASCII 0x20
to 0x7e
(I apologize if this was sent twice)
pgplORsoBr5zj.pgp
Description: PGP signature
------------------------------------------------------------------------------ Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
_______________________________________________ isync-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/isync-devel
