I'm unsure about
- is it ok to apply this patch globally, or should it be overridden for tigervnc only?
- how many rebuilds it triggers
- whether it was neccessary to update to latest dev version (seems to work)
The bug report indicates that others distros just includes this patch (?)
Cf. #1498. vcunat: the patch should be usable globally, as e.g. Arch does it.
Using autoreconfHook doesn't work for me, maybe --force is bad for it.
- asn1-encoding: add version 0.8.1.2
- asn1-parse: add version 0.8.1
- x509-store: add version 1.4.3
- x509-system: add version 1.4.2
- x509-validation: add version 1.5.0
- x509: add version 1.4.7
Qt and CUPS are not supported on Darwin and are dependencies.
Note: this makes ipython the same as ipythonLight on Darwin, but
ipython is used as an input for other packages (ipdb and ipdplugin)
and it is reasonable to assume that users on other platforms may
choose ipythonLight.
Note that it doesn't actually work unless you run it as root, because
the Darwin kernel disallows unsigned debuggers (you'll get an error
message "please check gdb is codesigned").
'YubiKey Integration for Full Disk Encryption Pre-Boot Authentication (Copyright) Yubico, 2011 Version: 1.1'.
Used binaries:
* uuidgen - for generation of random sequence numbers
* ykchalresp - for challenging a Yubikey
* ykinfo - to check if a Yubikey is plugged in at boot (fallback to passphrase authentication otherwise)
* openssl - for calculation of SHA-1, HMAC-SHA-1, as well as AES-256-CTR (de/en)cryption
Main differences to the specification mentioned above:
* No user management (yet), only one password+yubikey per LUKS device
* SHA-512 instead of CRC-16 for checksum
Main differences to the previous implementation:
* Instead of changing the key slot of the LUKS device each boot,
the actual key for the LUKS device will be encrypted itself
* Since the response for the new challenge is now calculated
locally with openssl, the MITM-USB-attack with which previously
an attacker could obtain the new response (that was used as the new
encryption key for the LUKS device) by listening to the
Yubikey has ideally become useless (as long as uuidgen can
successfuly generate new random sequence numbers).
Remarks:
* This is not downwards compatible to the previous implementation
