I noticed the commits regarding the certificate updates. Certificate pinning is an outdated technique and should be avoided. With proper CAA records in combination with Certificate transparency logs pinning can be avoided.
lastpass.com does have CAA records. It looks like you could further lock it down by adding CAA records to sub-domains, which would only allow globalsign to be used for lastpass.com
$ doggo CAA lastpass.com @9.9.9.9
NAME TYPE CLASS TTL ADDRESS NAMESERVER
lastpass.com. CAA IN 300s 0 issue "amazon.com" 9.9.9.9:53
lastpass.com. CAA IN 300s 0 issue "globalsign.com" 9.9.9.9:53
lastpass.com. CAA IN 300s 0 iodef 9.9.9.9:53
"mailto:domain@lastpass.com"
lastpass.com. CAA IN 300s 0 issue "digicert.com" 9.9.9.9:53
Please consider removing the certificate pinning code to avoid downstream users having to compile things from source every time the certificates are rotated and their package manangers have not caught up.
I noticed the commits regarding the certificate updates. Certificate pinning is an outdated technique and should be avoided. With proper CAA records in combination with Certificate transparency logs pinning can be avoided.
lastpass.com does have CAA records. It looks like you could further lock it down by adding CAA records to sub-domains, which would only allow globalsign to be used for lastpass.com
The ct logs are visible here https://crt.sh/?q=lastpass.com
Please consider removing the certificate pinning code to avoid downstream users having to compile things from source every time the certificates are rotated and their package manangers have not caught up.