<div dir="ltr"><div>> 
Surely if the password is say "!@#"!@*&" then all 10 characters are part of the password.  It is not for NUT to guess. <br></div><div><br></div><div>So I've run some experiments... and it seems to work as I OTOH-described earlier.<br></div><div><br></div><div>In the new NIT tests, there are methods for `upsmon` configuration to be created but it is not tested yet. Passwords for upsmon roles are used from API clients however (Python, C++) and they succeed whether it is enclosed in double-quotes or not in the `upsd.users` file.</div><div><br></div><div>In a live setup, identical password strings with or without doublequotes worked for `upsmon.conf` and `upsd.conf`, also if only one is quoted.</div><div><br></div><div>Escaped doublequotes inside a password also worked, e.g. pass\"word or "pass\"word"; however spaces (escaped or hidden in doublequotes) did not work since the NUT protocol did not allow for that extra token on assumed request line => ERR INVALID-ARGUMENT.</div><div><br></div><div>Then it gets a bit complicated for "invalid" spellings:</div><div>* upsd.users may define a pass"word (one unescaped quote in the middle) but upsmon.conf must have it properly quoted and escaped as "pass\"word" (otherwise it is a very long token I guess, and the MONITOR role is defaulted as a secondary since the requested primary role is not parsed as such).</div><div>
* upsd.users may define a "pass"word" (three unescaped quotes) but effectively the token is cut at the second quote, rest being ignored for this line - so upsmon.conf must use it as "pass".

</div><div><br></div><div>Similar effects are in place for `upsd.users` entries without an upsmon role - quotes around work, unescaped quotes in the middle like pass"word do not, escaped quotes in the middle do work, spaces cause ERR PASSWORD-REQUIRED.<br></div><div><br></div><div>So passwords with spaces may be a problem, but otherwise everything seems correct and predictable ;)</div><div><br></div><div>Hope this helps,<br></div>Jim Klimov<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Dec 29, 2022 at 9:11 PM Roger Price <<a href="mailto:roger@rogerprice.org">roger@rogerprice.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, 29 Dec 2022, Jim Klimov via Nut-upsuser wrote:<br>
<br>
> > Ah, dropping the ""s seems to have resolved it.<br>
> <br>
> I think parser should ignore quotes (not take them as content -<br>
> just treat the insides as one token) unless escaped, in both config file contexts.<br>
<br>
Surely if the password is say "!@#"!@*&" then all 10 characters are part of the <br>
password.  It is not for NUT to guess.   Roger_______________________________________________<br>
Nut-upsuser mailing list<br>
<a href="mailto:Nut-upsuser@alioth-lists.debian.net" target="_blank">Nut-upsuser@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser" rel="noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser</a><br>
</blockquote></div>