I agree with Darren here. A tool to obscure SMF stored passwords (or CHAP secrets in the case of iSCSI) needs to be a separate project that these other cases can depend on. Let's do it once, correctly.
Let's let this case go, or vote. -- mark Darren J Moffat wrote: > Bill Sommerfeld wrote: > >> No, it's not closed. See my message dated 15 Aug 2007 10:51:39 -0400; >> the current password-in-files policy says that if you're storing a >> password you need at the very least some sort of reversible obfuscation >> to protect against shoulder-surfing-the-admin attacks. >> > > ... > > Also if the password is obscured in the SMF repository then a tool to > generate that obscured format will be needed (either a new tool or > documentation on how to use an existing one). Also this means that > practically every user of this SMF functionality is going to need a > similar tool. > > In my opinion we have much much bigger "sins" in Solaris already, for > example the ssh host keys are in the clear, IPsec private keys are > usually in the clear. Those are in separate files but I don't see how > that really helps much, it is basically cat vs svcprop. > > Personally I think this case has done enough and it is either time to > let it complete or for it to be derailed and have a vote called (I'm not > willing to derail it). > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20070823/91ccd293/attachment.html>
