Hi, thanks for responding. I had a look, and yes, the bytes were the same as the 979 character string (hex) - they contained the certificate itself. I should post it here anyways, since it is the debug certificate in this case. Well, here it is:
-------------------------- 308201e53082014ea00302010202044baf98bc300d06092a864886f70d01010505003037310b30090603550406130255533110300e060355040a1307416e64726f6964311630140603550403130d416e64726f6964204465627567301e170d3130303332383137353832305a170d3131303332383137353832305a3037310b30090603550406130255533110300e060355040a1307416e64726f6964311630140603550403130d416e64726f696420446562756730819f300d06092a864886f70d010101050003818d0030818902818100c571d5da04aacec883134f20a27b9fe73a7fab49a31443885d4ddd979fa61084bb54110d597857cd1c80429ccb3d8dacef702e5c006856399ddd5b61630b59c6632dc5af8698a5fe4dd5795b93bc41814adf92bb81867bbf69f9f051325862651dae28f9483fdded978e5d4497da365f8cf9cbeb50dd67ab114be08587347fad0203010001300d06092a864886f70d010105050003818100af92d2bf20aaebe83761bb73d4e3cd240b2e96f23d43d4cbc33db5d8e1090dbd5fbb43ae45924dbda6f961b2f06b00304c39ed68c382134a507101a9eaa23f480cac7563aa54fb507bdf9433a2f5e015a9a23dbb6de1a0a7c8f2f8f6a2ee522faaff4c73767b22581572e55c40726f2c41b21b31cd309d5bed9b4a568cdf2665 -------------------------- If you run it through a tool like this: http://home2.paulschou.net/tools/xlate/ You'll see gibberish interspersed with words like Android and Debug. That definitely looks like the certificate to me, not that I'm a certificate expert. I'm still wondering how the maps API does it. If it's something that they're keeping secret, fair enough I guess, would've been nice. But still an interesting problem. On Apr 6, 12:10 am, Bob Kerns <[email protected]> wrote: > Actually, the package manager would be able to check using the API. > The only thing that was at question was whether the byte sequence > included anything beyond the certificate or not. We know the API > doesn't. Actually, what I'd like to know is whether it includes the > certificate, or just the public key from the certificate! > > You've effectively answered the first question, at least for now. But > since the API doesn't say -- you can't really depend on the bytes > anyway. All you can really do with them is the comparison. > > The issues around being able to keep secrets within an application are > pretty deep. Let's just say it's never been made practical and > robust. > > On Apr 5, 11:20 am, ko5tik <[email protected]> wrote: > > > On Apr 5, 6:09 pm, Bob Kerns <[email protected]> wrote: > > > > 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 problem is, that every other application can also read this > > signature > > and produce hash out of it... > > > > 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 checked - it was the same. Otherwise market app/installer would be > > unable to > > check whether you are upgrading existing application. > > > > or user, yes, but application, no. Nothing in a .apk can be regarded > > > as secret. > > > ... It would be cool feature request for android. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] 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.
