On Mon, Apr 2, 2012 at 5:53 PM, Erik Faye-Lund <kusmabite@xxxxxxxxx> wrote: > On Fri, Mar 23, 2012 at 10:10 PM, Jeff King <peff@xxxxxxxx> wrote: >> On Tue, Mar 20, 2012 at 12:06:54AM +0100, Erik Faye-Lund wrote: >> >>> This one pretty much sucks. Mem-leaks and a sketchy deletion-filter. >> >> Thanks for moving forward on this. I'm sorry I can't be much help on the >> Windows-specific knowledge, but I'll answer what I can. >> > > Thanks for following up :) > >>> Currently uses "::" as an attribute-separator, but this is not robust >>> without encoding if the attribute values themselves contains "::". >> >> Yeah. Can you store arbitrary bytes? If so, NUL would be a good >> terminator. > > No. TargetName is an LPWSTR, which is supposed to be zero-terminated. > There's no way of specifying it's length directly. > >> Otherwise, newline is a reasonable choice, as the protocol >> already can't communicate usernames/passwords with newlines (a >> limitation that I accepted to make the protocol much simpler for >> scripting use). >> > > This works, but it causes Windows 7's credential manager to glitch in > rendering the credential (adding all the newlines to the end of the > line, and stretching an icon - yuck), which is also a bit unfortunate. > > So I'm thinking that escaping the string needs to be done. It can't be > that big of a deal ;) > Hmm, but I must have been a complete moron; the credential structure in windows has a general purpose credential-attribute system, where I can store the meta-data I want. So I can probably use that and get away without any sort of encoding. Yay. I'll look deeper into it when I find the time. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html