Status Update
Comments
ra...@google.com <ra...@google.com>
bo...@google.com <bo...@google.com> #2
Since this is happening in Tink, rather than in the AndroidX library, it would be best to open an
lb...@gmail.com <lb...@gmail.com> #3
bo...@google.com <bo...@google.com> #4
Tink is the library that does the heavy lifting in Jetpack Security.
And yes, potentially raising that issue with the Tink team directly could help.
lb...@gmail.com <lb...@gmail.com> #5
Here, created it there too:
an...@gmail.com <an...@gmail.com> #6
jm...@google.com <jm...@google.com>
dr...@gmail.com <dr...@gmail.com> #7
na...@cybercom.com <na...@cybercom.com> #8
sa...@gmail.com <sa...@gmail.com> #9
da...@gmail.com <da...@gmail.com> #10
il...@gmail.com <il...@gmail.com> #11
na...@docusign.com <na...@docusign.com> #12
m....@gmail.com <m....@gmail.com> #13
+1
fe...@gmail.com <fe...@gmail.com> #14
sa...@clearquote.io <sa...@clearquote.io> #15
da...@google.com <da...@google.com>
ap...@google.com <ap...@google.com> #16
Branch: androidx-main
commit a505a060ec741478e4096e8d160e136de18e8f39
Author: Daniel Angell <danielangell@google.com>
Date: Thu Oct 13 12:14:15 2022
Upgrade tink to 1.7.0 in security-crypto
Changed some calls into Tink to avoid deprecation warnings.
Bug: 185219606 (and likely others)
Test: Ran the security-crypto test suite
Change-Id: I7b1dcb3bf3f5d018a93ac3b06280724559f63ded
M security/security-crypto/build.gradle
M security/security-crypto/src/main/java/androidx/security/crypto/EncryptedFile.java
M security/security-crypto/src/main/java/androidx/security/crypto/EncryptedSharedPreferences.java
da...@google.com <da...@google.com>
lb...@gmail.com <lb...@gmail.com> #17
i wonder what about the rare crashes though.
da...@google.com <da...@google.com> #18
I'm pretty new on this project and I haven't dug deep into all of the strange behavior reported. But having read many of the bug reports my initial guess is crashes on initialization are related to encrypted files that got restored from a backup. If you back up all of an app's files - including EncryptedSharedPreferences - and then restore after moving to a new device, factory restoring a device, or perhaps even uninstalling and reinstalling an app, you will crash and it might not be clear why. The recommended way to use the security jetpack library lends to these kinds of errors. The files get encrypted with a key that won't be available inside of a backup copy. So decryption will always fail if that key isn't there when restoring from a backup.
lb...@gmail.com <lb...@gmail.com> #19
But even if it did, it should have been automatically handled by the library , and as long as it's not, be mentioned on the docs with an explanation of what should be done about it.
da...@google.com <da...@google.com> #20
and as long as it's not, be mentioned on the docs with an explanation of what should be done about it.
I have at least added a warning to the docs for now.
I'll look into the bug you linked.
lb...@gmail.com <lb...@gmail.com> #21
Maybe some way to exclude these files in backup rules?
da...@google.com <da...@google.com> #22
You can see the warning I added in your editor as a documentation comment on the EncryptedFile
and EncryptedSharedPreferences
classes. Those comments get copied into the reference info on the jetpack website:
But I think it would be much better for us to provide an Android backup agent implementation that does the filtering for you.
lb...@gmail.com <lb...@gmail.com> #23
Is it possible using setting it in XML , or only during runtime?
I wonder how to do each. BackupAgent doesn't have many samples at all, not even on Github and StackOverflow...
da...@google.com <da...@google.com> #24
You can definitely accomplish this with XML configuration:
But you can also write a custom backup agent class to do the work at runtime. I will update the documentation later to include a reference XML configuration.
Thanks for your feedback!
lb...@gmail.com <lb...@gmail.com> #25
Does it offer a functionality to tell "for the rest, backup as many files as of these from the list" ? This is useful for semi-cache files, which are important, but not very important.
lb...@gmail.com <lb...@gmail.com> #26
bu...@gmail.com <bu...@gmail.com> #27
pa...@gmail.com <pa...@gmail.com> #28
The issue still persists.
Description
AndroidKeysetManager: keyset not found, will generate a new one
java.io.FileNotFoundException: can't read keyset; the pref value __androidx_security_crypto_encrypted_prefs_value_keyset__ does not exist
at com.google.crypto.tink.integration.android.SharedPrefKeysetReader.readPref(SharedPrefKeysetReader.java:71)
at com.google.crypto.tink.integration.android.SharedPrefKeysetReader.readEncrypted(SharedPrefKeysetReader.java:89)
at com.google.crypto.tink.KeysetHandle.read(KeysetHandle.java:105)
at com.google.crypto.tink.integration.android.AndroidKeysetManager$Builder.read(AndroidKeysetManager.java:311)
at com.google.crypto.tink.integration.android.AndroidKeysetManager$Builder.readOrGenerateNewKeyset(AndroidKeysetManager.java:287)
at com.google.crypto.tink.integration.android.AndroidKeysetManager$Builder.build(AndroidKeysetManager.java:238)
at androidx.security.crypto.EncryptedSharedPreferences.create(EncryptedSharedPreferences.java:160)
at androidx.security.crypto.EncryptedSharedPreferences.create(EncryptedSharedPreferences.java:120)
Please avoid this.
It has no way for us to handle it. It isn't something we can do about it.
See attached file to understand how I get the instance. Basically it's:
@RequiresApi(Build.VERSION_CODES.LOLLIPOP)
@WorkerThread
private fun getSecuredSharedPreferences(context: Context, fileName: String): SharedPreferences {
val masterKey = MasterKey.Builder(context, MasterKey.DEFAULT_MASTER_KEY_ALIAS).setKeyScheme(MasterKey.KeyScheme.AES256_GCM).build()
return EncryptedSharedPreferences.create(context, fileName, masterKey,
EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
)
}