Status Update
Comments
ow...@google.com <ow...@google.com> #2
DeviceCredentialHandlerActivity
has been removed in the latest version of biometric, to be released June 24 2020, as part of a refactor.
There is a mismatch between TabHostBindingAdapter.setCurrentTabTag
using !=
and TabHost.setCurrentTabByTag
using .equals()
.
ra...@gmail.com <ra...@gmail.com> #3
There is a mismatch between TabHostBindingAdapter.setCurrentTabTag using != and TabHost.setCurrentTabByTag using .equals().
not getting! clear
mo...@google.com <mo...@google.com> #4
It found a bug in the binding adapter. I plan on making a change to fix it.
ra...@gmail.com <ra...@gmail.com> #5
mo...@google.com <mo...@google.com> #6
I don't have an answer for when you'll see the fix. But you can implement a fix for yourself by defining the binding adapter in your own code and it will take precedence over the default binding adapter pulled from the data binding library.
mo...@google.com <mo...@google.com> #7
I've completed the TabHostBindingAdapter.java work. Reassigning to Curtis to handle the DeviceCredentialHandlerActivity work.
cu...@google.com <cu...@google.com> #8
Per DeviceCredentialHandlerActivity
is removed as of
Description
Version used:
Theme used:
Devices/Android versions reproduced on:
Following two flaws(with line number)/complaining by veracode
Attack Vector: span.neq
Number of Modules Affected: 1
Description: Using '!=' to compare two strings for inequality actually compares the object references rather than their values. It is unlikely that this reflects the intended application logic.
Remediation: Use the equals() method to compare strings, not the '!=' operator.
Attack Vector: DeviceCredentialHandlerActivity
Number of Modules Affected: 1
Description: The component DeviceCredentialHandlerActivity as configured in AndroidManifest.xml is exported with no permission(s) set which increases the application's attack surface and possibly allows for injection or stealing of app data.
Remediation: The component's exported attribute in AndroidManifest.xml should be set explicitly to false, if possible. If it must be exported, then permissions should be used to ensure the app is used in the intended manner. This permission may be specific to the attribute or applied globally to the manifest's application element.