Alok,
Responses below.

Alok Aggarwal wrote:
> On Tue, 27 Jan 2009, William Schumann wrote:
>
>> Passwords should be encrypted in manifests, not by the installer code.
>>
>> The basic fix was simple - remove encryption calls from the code - but
>> it was noted that there could be XML entities encoded in the password,
>> so XML entities will now be decoded. The XML decoding is basic and has
>> some shortcuts, such as decoding only 1-byte numeric values. It is
>> expected that the AI manifests will soon be restructured and then should
>> be parsed with established parsers, such as in libxml2.
>>
>> Bugs fixed along the way:
>> - values with spaces were being truncated at the first space
>> - apostrophes used as value delimiters were not working
>> - some typos with keyword name not matching intended storage variable 
>> name
>>
>> http://defect.opensolaris.org/bz/show_bug.cgi?id=4246
>> http://cr.opensolaris.org/~wmsch/bug-4246/
>
> auto_parse.c: lines 581-583: What happens if there
> are multiple blank spaces either one after the other
> or separated by tokens?
Spaces are compressed to a single space - fixed.
>
> auto_parse.c: decode_xml_entities(): This code looks
> complicated. Given that the SC manifest is going to eventually move 
> out to SMF enhanced profiles, I do
> wonder whether it's worth the effort to write this code
> that's going to be thrown away once we move over to SMF
> enhanced profiles.
90 lines of code here. The effort would be in reviewing it and dealing 
with possible bugs.

Another XML parsing problem is that it is assumed that the SC value is 
on the same line as the "propval" keyword and AI will fail if it isn't.

Do you know a time frame for moving to SMF enhanced profiles?
>
> I don't have a strong preference but what do others think about this?
>
> auto_install.c: line 925, 934, 941: The user account should
> be changed to being "jack" and the om_encrypt() needs to still
> be there on line 934.
Restored these. Also removed some strdups, since this is done by 
nvlist_add_string().
>
> Lastly, which cases did you test while testing out these
> changes?
Tried values:
- single, multiple spaces
- empty
- all possible (5) XML entities; XML decimal, octal encodings
- invalid XML entities, missing terminator
- XML entities adjacent, at beginning of line, at end of line
- value longer than VALUE_SIZE (added warning on overflow)

What is still needed for a better user experience is specific validation 
of the different input types (username, password, description, etc.) up 
front.
William

Reply via email to