It's error-prone, and our specific usage of it here upsets ubsan.
Bug: https://issuetracker.google.com/158428513
Test: treehugger
Change-Id: I3a6b68865e6b4c37ac005f5f24c3d6e1de7c5bac
Also, print key id in padd/add like keyctl(1). This makes local
debugging and integration test easier.
Test: run all commands manually in shell, see expected output
Bug: None
Change-Id: I6be6ea9e273e80e7d5848da5cf348da8308a62c1
This gives us two benefits:
- Better compatibility to keyctl(1), which doesn't have "dadd"
- Pave the way to specify key's security labels, since keyctl(1)
doesn't support, and we want to avoid adding incompatible option.
Test: See keys loaded in /proc/keys
Bug: 128607724
Change-Id: Ia45f6e9dea80d037c0820cf1fd2bc9d7c8bb6302
- Valid ID format examples: 0x90a, 123
- ID like 90a will not work now.
Bug: None
Test: mini-keyctl unlink 0x11d25c86 0x2873c96d
Change-Id: I057bce0a49a60f475d54b23e28dc18db25124466
This CL change the mini-keyctl tool to make it compitable with libkeyctl
tool to make it more useful.
Bug: 112038861
Test: mini-keyctl padd asymmetric 'desc' .fs-verity < /path/to/cert.der
Test: mini-keyctl unlink <key_id> <keyring_id>
Test: mini-keyctl restrict_keyring <keyring_id>
Change-Id: I950f07c7718f173823ce5a5cd08e0d1a0e23a007
This CL adds a binary to load keys to a keyring.
Bug: 112038861
Test: mini-keyctl -k .fsverity -c PATH_CONTAINER_CERTS
Test: cat /proc/keys and find the newly added keys
Change-Id: Iead68618ea194e9412616c5c6cff885e3cf78520
adbd (and its dependencies) are marked as recovery_available:true so
that recovery version of the binary is built separately from the one for
system partition. This allows us to stop copying the system version to
the recovery partition and also opens up the way to enable shared
libraries in the recovery partition. Then we can also build adbd as a
dynamic executable.
Bug: 79146551
Test: m -j adbd.recovery
Change-Id: Ib95614c7435f9d0afc02a0c7d5ae1a94e439e32a
