Behaviour of security/lastpass-cli changed on current (OpenBSD 6.8-beta (GENERIC.MP) #69: Tue Sep 15 12:34:41 MDT 2020). Attempting to login to a lastpass account results in a SSL connect error. Expected behaviour is that lpass asks for a password.
$ lpass login user Error: SSL connect error. A bit more info: $ LPASS_LOG_LEVEL=8 lpass login user; cat ~/.lpass/lpass.log Error: SSL connect error. <7> [1600697212.073792] Making request to https://lastpass.com/iterations.php Trying 104.98.132.96:443... * Connected to lastpass.com (104.98.132.96) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/ssl/cert.pem CApath: none * error:1404B418:SSL routines:ST_CONNECT:tlsv1 alert unknown ca * Closing connection 0 After a bit of bisecting I found that the change in behaviour is caused by a recent change in lib/libcrypto/x509/x509_vpm.c (r1.22). Log message: "re-enable new x509 chain verifier as the default". Reverting this commit fixes the above, thus enabling me to login to lastpass again. Is the change in behaviour of the new x509 chain verifier intended? Instead of reverting lib/libcrypto/x509/x509_vpm.c to r1.21 there is a workaround: Addition of the certificate pin of lastpass.com to lastpass-cli's pins list (https://github.com/lastpass/lastpass-cli/blob/master/pins.h). I have a diff but I'm not sure if this is a sane solution. Does it make sense to patch lastpass-cli?
