Well, first, there's likely to be no MD5 hash involved at all. DSA
with SHA-1 would be the default signature type now, I believe.
Hashcode would not be secure. That is, you can construct an alternate
app+signature that would produce the same hash code. That may be good
enough for you, but I would discourage such a technique. However, you
could construct a secure SHA-1 hash of the value!
The documentation for android.content.pm.Signature states that it is
opaque. That means -- you're not supposed to know or try to figure out
what's in it.
I imagine the 979 characters include the hex or base 64 encoding of
the signing certificate. I am not sure if it actually contains the
signature! The purpose appears to be to compare WHO signed it, not the
actual individual signature. Everywhere the PackageManager
documentation refers to a signature, it is talking about seeing if two
packages have the "same" signature. That would imply it is ignoring
the hash, if it is even present in the datastructure. (It could ignore
the hash after verifying the application).
We could find out by comparing the Signature for two apps that have
been signed with the same key.
Unfortunately, the contract given for PackageManager does not even
guarantee that you'd get the same 979-character string consistently,
even for the same version of the same application. I'd be quite
surprised if you didn't. A more relevant question is if you get the
same value for two different versions of your app. If they include the
hash portion of the signature, and its encrypted counterpart, then the
answer is no.
I wish the semantics were better documented here.
However, you can include whatever you want in your manifest in
metadata. Why not just put your key there? Even if you are seeking to
tie it to your specific app, there's nothing that would prevent an
intruder from computing the same values with your app and then using
them from his app. There IS no secure way to guarantee that a request
comes from a specific application. A particular uncompromised device
or user, yes, but application, no. Nothing in a .apk can be regarded
as secret.
On Apr 5, 5:33 am, mendhak <mend...@gmail.com> wrote:
> Still struggling with this. Based on what you said, I tried playing
> with this:
>
> Signature[] sigs =
> getBaseContext().getPackageManager().getPackageInfo("com.whatever.blahpacka
> ge",
> 64).signatures;
>
> (64 = GET_SIGNATURE)
>
> I then had a look at
>
> sigs[0].toCharsString()
>
> which produced a 979 character long string!
>
> Is hashCode() of any use here? I ignored it for now.
>
> I also had a look at toByteArray(), by converting it to a String. The
> result was a string that contained some readable ASCII characters and
> some gobbledygook characters like 0 0 N
>
> I'm wondering if toCharsString is what we're actually looking for, but
> that's a huge amount of text to be sending along with the request!
> Would hashCode do?
>
> On Mar 31, 2:46 pm, ko5tik <kpriblo...@yahoo.com> wrote:
>
>
>
> > I'm also gnawing on the same problem. At the moment
> > I'm investigating following path:
>
> > Context -> Package Manager -> Package info (for name, with
> > signatures ) -> Signatures
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
To unsubscribe, reply using "remove me" as the subject.
