On Tue, 25 May 2010, James Carlson wrote:

>Nicolas Williams wrote:
>> On Fri, May 21, 2010 at 03:40:54AM -0700, Darren J Moffat wrote:
>>> /* That's what getpassphrase(3c) supports. */
>>> #define PK11_MAX_TOKEN_PIN_LEN          256
>> ...
>>>     int pkcs11_parse_uri(const char *str, pkcs11_uri_t *uri);
>>>
>>> Return codes are defined:
>> ...
>>> #define PK11_MUTEX_ERROR        6
>>>     - getpassphrase() is not MT-safe. We use a global mutex to
>>>       protect the getpassphrase() call.
>> 
>> Hmmm, I think it'd have been better to have the function return an error
>> when a PIN is need and let the app call it again with the PIN -- let the
>> app prompt for a PIN.
>> 
>> There's no way to deal with the fact that getpassphrase() is not
>> MT-safe from within a library.  The mutex you use to synchronize access
>> to it will not be the same mutex that the application uses.
>
>Perhaps more important for a library function: there's no way to know
>exactly how one gets input from a user.  It might involve interactions
>with a GUI or through some other sort of protocol (such as EAP).

        there are two options in the original spec:

        passphrasedialog=builtin
        passphrasedialog=exec:program

        the 2nd one is quite generic, one can write a script that can do 
anything. Anyway, I agree now that libcryptoutil should not ask via 
getpassphrase(), I'm now working on a changed design.

        J.

-- 
Jan Pechanec
http://blogs.sun.com/janp
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org

Reply via email to