> Unfortunately, NWAM has always automatically generated 'secobj' names,
> and it's done so for quite a while -- excluding only ':' from the
> strings it generates, and relying on '-' and '.' pretty heavily ('-'
> as a separator, and '.' as a replacement for ':').
>
> I'm not sure why (technically) the names need to be restricted, but if
> we're going to that, then we'll have to cook up some way of "fixing"
> any keys that people already have so that they have acceptable names,
> and so that applications can still find them after upgrade.
The only reason to restrict the namespace is to keep things simpler for
applications and end-users, and thus reduce the incidence of bugs. For
instance, having a user wrestle with how to specify a key with a ":" in it
and also put that key into a particular WEP slot with the ":" connect-wifi
syntax seems like pain for the sake of pain. Likewise, as we've seen,
whitespace causes a lot of pain, and unprintable characters would be
similarly painful, especially for consumers of dladm's parsable output.
If NWAM is already using "-" and it's not causing any problems, then I
have no issues with allowing it.
> For SXCE, that means familiar class action and BFU updates (and a flag
> day, since you can't go back without misplacing your keys[1]), but
> most instances of the problem are likely with OpenSolaris (where NWAM
> is the default), and that has no clear mechanism for dealing with
> upgrade-related scripting.
Assuming we allow "-" and ".", do we think many users are going to have
problems with upgrade? I'd expect most are using alphanumerics, and
spaces already don't really work (hence the bug).
--
meem
_______________________________________________
networking-discuss mailing list
[email protected]
