Could skip that and just have a device using AOSP test keys but it's too painful to keep switching due to having only 1 of each.
-
-
Replying to @CopperheadOS @RichFelker
Have devices set up for running the CTS and it's a PITA to do it over again. Switching keys pretty much requires wiping them.
1 reply 0 retweets 0 likes -
Replying to @CopperheadOS
Seems like for (all but final) testing you'd want all the lockdown disabled.
2 replies 0 retweets 0 likes -
Replying to @RichFelker
BTW been meaning to ask - could
@CopperheadOS be easily tweaked by installing user to add a uid-0 sshd?1 reply 0 retweets 0 likes -
Replying to @RichFelker
If you make a userdebug build, you get root access via adb. For root sshd, you could probably repurpose the su SELinux domain.
1 reply 0 retweets 0 likes -
Replying to @CopperheadOS @RichFelker
For simply debugging, adb shell access is already enough though. Especially in userdebug builds where it has adb root / su.
2 replies 0 retweets 0 likes -
Replying to @CopperheadOS
My interest is not for debug build but for permanent fail-safe access to device without adb, etc. weakening physical security.
1 reply 0 retweets 0 likes -
Replying to @RichFelker
Enabling adb isn't that bad since it does have key-based whitelisting, and it's not exposed to the network at all by default.
1 reply 0 retweets 0 likes -
Replying to @CopperheadOS @RichFelker
And a userdebug build only has su exposed to the shell user, which is only available via adb. It's a risk but not a huge one.
1 reply 0 retweets 0 likes -
Replying to @CopperheadOS @RichFelker
Main issue with adb == trusting another machine, especially permanently. Using sshd instead would involve a similar risk.
1 reply 0 retweets 0 likes
The difference is I trust the OpenSSH developers' competence a lot more than I trust the Android developers' competence.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.