On Thursday, January 19, 2012 6:09:25 PM UTC-5, Oleg Gryb wrote:
You're absolutely right, there is no any reason to discuss that. It
just some opinions were rather unusual in my view and I wanted to
understand why. I should admit that still don't have an answer for
that why question.
It also says the key may be self signed, so after all it's not that
bad if I use a company's CA to issue signing certs.
On Jan 17, 11:43 am, Jeff six.jeff...@gmail.com wrote:
So...the certificate *kinda* needs to be self-signed, at least if
you're going to include your app in the Market. From
On Thu, 19 Jan 2012 15:32:49 -0800
Subbu Srinivasan wrote:
No-This cannot be manual. We need a reputation mechanism built into
android mkt place, the android installer would check against this and
suggest any course of action.
social web of trust. brilliant idea, actually.
That's the best
On Thu, 19 Jan 2012 09:16:31 -0800
Subbu Srinivasan wrote:
PKI has both strengths and weaknesses, the weakness being that end users
sometime do not understand how the mechanism works and end up blindly
accepting SSL connections.
But they will think before entering they're credit card info and
On Thu, 19 Jan 2012 14:54:01 -0800 (PST)
Oleg Gryb wrote:
self-signed cert is not a hard
requirement, but rather a questionable practice and in this regard,
The whole idea of CA is that everybody knows and trusts them and
relies on them when something needs to be verified about a less known
3-rd
What is that ultimate goal?
1) We are trying to protect the end user from apps that do naughty things?
2) So how can the app be trusted?
- People associate implicit trust with a brand - I trust angry bird app
(for whatever reasons the brand increased in value)
- People trust an app where
On Fri, 20 Jan 2012 11:54:08 -0800
Subbu Srinivasan wrote:
- Maybe google does not want to be in the business of code review, but it
is an opportunity to outsource this to certified vendors(of course I have
not given thought on how the vendors can monetize this)
I struggle to see how it can
social web of trust. brilliant idea, actually.
On Thursday, 19 January 2012 18:16:31 UTC+1, subbu wrote:
Perhaps a app validating mechanism coupled by a community driven
reputation score would help,.
--
You received this message because you are subscribed to the Google Groups
Android
You're absolutely right, there is no any reason to discuss that. It
just some opinions were rather unusual in my view and I wanted to
understand why. I should admit that still don't have an answer for
that why question.
Anyway, what I really want to know is the answer for a) on David's
list:
1.
No-This cannot be manual. We need a reputation mechanism built into
android mkt place, the android installer would check against this and
suggest any course of action.
On Thu, Jan 19, 2012 at 3:09 PM, Oleg Gryb oleg.g...@gmail.com wrote:
You're absolutely right, there is no any reason to
On Thu, Jan 19, 2012 at 3:09 PM, Oleg Gryb oleg.g...@gmail.com wrote:
Brian, if you're still around, please take a look.
I really don't know, I happen to work on the lower level X509, SSL, and
some https stuff on Android, but not on market or package manager.
-bri
--
You received this
If what you're saying is correct, self-signed cert is not a hard
requirement, but rather a questionable practice and in this regard,
I'm curious if I'll have any problems with publishing apps on Android
market when use non self-signed certs, but the ones signed by an
approved CA?
On a separate
self-signed cert is not a hard
requirement, but rather a questionable practice and in this regard,
I'm curious if I'll have any problems with publishing apps on Android
market when use non self-signed certs, but the ones signed by an
approved CA?
These are two separate problems:
a)
Does anyone know if a) on the David's list below would be problematic
for non self-signed certs?
On Jan 18, 11:57 am, David Herges david.her...@uni-ulm.de wrote:
self-signed cert is not a hard
requirement, but rather a questionable practice and in this regard,
I'm curious if I'll have any
I was writing about self-signed X.509 cert, not about signature, sorry
if it was not clear.
On Jan 18, 11:57 am, David Herges david.her...@uni-ulm.de wrote:
reduces it to a primitive binary blob.
That's why it's a code signature.
--
You received this message because you are subscribed to
Is self-signed cert a hard requirement? It's kind of unusual. In my
mindset, self-signed certs should be used in pre-prod environments
only. The whole idea of CA is that everybody knows and trusts them and
relies on them when something needs to be verified about a less known
3-rd party. It makes
If a cert must be self-signed as Brian has mentioned, then I don't
think that I can do much except storing all public keys for all
trusted parties. If the same party uses more than one key then I would
need to store all of them and this is what I was trying to avoid,
apparently with no luck so
confusing. Could you call that 'ceritificates' instead and return
Certificate[] array instead of Signature[] array?
Can somebody please answer this qs as well? Probably I'm missing
something here.
--
You received this message because you are subscribed to the Google Groups
Android Security
If this is part of the public API, then no, it probably not going to be
able to change.
-bri
On Tue, Jan 17, 2012 at 10:11 AM, Oleg Gryb oleg.g...@gmail.com wrote:
confusing. Could you call that 'ceritificates' instead and return
Certificate[] array instead of Signature[] array?
Can
I've just checked FF 9.0.1 and it has about 70 trusted root CA, while IE7 -
only 25, but even it's 600 in other browsers, this is really a very small
portion of what it could be if self-signed certs were used.
I agree that trusting to all of them, even if it's only 25 is probably not
a good idea.
I think there is a reason why commercial CA wouldn't do that and this
reason is even more valid if you think about the number of small
companies that write apps for Android and don't use HSM's or other
serious controls to protect their private keys. A probability of
private key compromise is very
More specifically: Java's jarsigner is used to sign Android's apk
files. It creates two files: signature (*.sf) and signature block
(*.dsa). The information that I'm looking for is stored in (*.dsa)
file. Is there any way of getting it from PackageManager's Signature
collection returned by:
After looking to Package.java, I found the answer and think that it's
somewhat funny. The collection that is called 'signatures' and is
returned by
pm.getPackageInfo(info.packageName,PackageManager.GET_SIGNATURES).signatures
is actually an array of public X.509 certificates encoded to DER, I've
23 matches
Mail list logo
