On Sat, 2019-04-06 at 03:20 +1100, Damien Miller wrote:
> On Fri, 5 Apr 2019, Jakub Jelen wrote:
>
> > There is also changed semantics of the ssh-keygen when listing keys
> > from PKCS#11 modules. In the past, it was not needed to enter a PIN
> > for
> > this, but now.
> >
> > At least, it is not consistent with a comment in the function
> > pkcs11_open_session(), which says
> >
> > 727 * if pin == NULL we delay login until key use
> >
> > Being logged in before listing keys prevents bug #2430, but as a
> > side
> > effect, even the ssh can not list keys before login and if the
> > configuration contains a PKCS#11 module, the user is always
> > prompted
> > for a PIN, which is not very user friendly.
> >
> > I see this is a regression and the bug #2430 should get solved as
> > proposed in the patches (will need some tweaks after the big
> > refactoring).
>
> We'll take a look at this (and the other things you just reported)
> after the release is done.
Release is out with this regression. Is there any progress on this? The
simplest thing how to reproduce is by extending the agent-pkcs11
regress testsuite with the following line, which previously worked
fine, but now asks for a pin:
${SSHKEYGEN} -D ${TEST_SSH_PKCS11}
Is this on a radar or should I create a new bug? I am using keys from
PKCS#11 all the time and this prevents me from updating to the newer
version.
Regards,
--
Jakub Jelen
Senior Software Engineer
Security Technologies
Red Hat, Inc.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
