Why can't Google Play Store update F-Droid apps
(and what about GitHub/SourceForge)?
<https://i.postimg.cc/15XPh8nc/k9mail01.jpg> K-9 Mail with OAuth2 6.200

Recently I wanted to update K-9 mail and the Google Play Store had a
slightly newer version but it wouldn't update the F-Droid K-9 Mail.
<https://i.postimg.cc/rpWC5zxw/k9mail02.jpg> GPS vs F-Droid K-9 update

Why?

This isn't related to K-9, per se, as it seems to happen a lot.
Can someone explain better why than that cryptic message above?
"Conflicting package exists"
"INSTALL_FAILED_UPDATE_INCOMPATIBLE: Package com.fsck.k9
signatures do not match previously installed version, ignoring!"

I never did understand encryption, signatures and certificates.
--
And then what about other repositories for the exact same apps?

On 23/07/2022 22:25, Andy Burnelli wrote:
> Why can't Google Play Store update F-Droid apps
> (and what about GitHub/SourceForge)?
> <https://i.postimg.cc/15XPh8nc/k9mail01.jpg> K-9 Mail with OAuth2 6.200
>
> Recently I wanted to update K-9 mail and the Google Play Store had a
> slightly newer version but it wouldn't update the F-Droid K-9 Mail.
> <https://i.postimg.cc/rpWC5zxw/k9mail02.jpg> GPS vs F-Droid K-9 update
>
> Why?
>
> This isn't related to K-9, per se, as it seems to happen a lot.
> Can someone explain better why than that cryptic message above?
> "Conflicting package exists"
> "INSTALL_FAILED_UPDATE_INCOMPATIBLE: Package com.fsck.k9
> signatures do not match previously installed version, ignoring!"
>
> I never did understand encryption, signatures and certificates.

Is the Google update a partial replacement of K-9, rather than a full
replacement? If the former, I can understand Google's reluctance to
update by including a part of the app related to security, and leaving
the rest untouched. It doesn't know what the rest of the app does, or
what malware it might contain, and by allowing something new relating to
OAuth2 it /might/ be allowing the "new" K-9 to access things Google
believes it shouldn't.

If it's a "full" app update, I don't understand why it wouldn't allow
that as I assume it would just erase the old app anyway.

Do you know what the original install size was, and what the update size is?

--

Jeff

Jeff Layman wrote:

> It doesn't know what the rest of the app does, or what malware it might contain,
> and by allowing something new relating to OAuth2 it /might/ be allowing the
> "new" K-9 to access things Google believes it shouldn't.

If google don't want clients to access something on their servers, the correct
way to enforce that is on the servers, not on the client.

Andy Burns wrote:

> Jeff Layman wrote:
>
>> It doesn't know what the rest of the app does, or what malware it might contain,
>> and by allowing something new relating to OAuth2 it /might/ be allowing the
>> "new" K-9 to access things Google believes it shouldn't.
>
> If google don't want clients to access something on their servers, the correct
> way to enforce that is on the servers, not on the client.

I'm confused by _both_ responses, which I know were well meant and kind
hearted, but where I suspect Andy & Jeff know far more than I do about this
stuff, so unfortunately, their responses didn't help me (yet) understand
why.

I do not think the answer to the question is directly related to any client
but to "something" Google enforces for apps that are stored on its
repository.

Let me try to summarize what I am asking about here:
1. Just as you can access an FTP server using a variety of FTP-protocol
clients, and just as you can access an Apache web server using a
variety of HTTP-protocol clients, and just as you can access the
YouTube video server using a variety of (what I'll call) YT-protocol
clients, you can access the Google Play Store using a variety of
(what I'll call) GPS-protocol clients.

2. In each case, you get the exact same APK file no matter which client
you use to access the protocol server because it's downloading the
same APK file on (what I'll call) the Google Play Repo repository.

3. That means the APK I get from using either the Google Play Store
client or the Aurora Store client will be exactly the same APK;
so the client is NOT the issue.

4. However... the APK I get from any other repository than
(what I'll call) the Google Play Repo repository can be _different_
in terms of the signature (whatever that means) done _by_ Google.

5. Notice this signature, as I understand it, is done _by_ Google!

6. Hence, it has _rules_ that the app developer has to abide by.

7. This may be wrong, but I've gleaned that information from seeing
app developers tell us that the app on other repositories is NOT
exactly the same as the app on the Google Play Repo repository
_because_ of that Google-enforced signature _by_ Google.

8. Of course, as in the case of NetGuard, the non-Google Play Repo APK
is also a different set of functionality, but that's not what
I'm asking about here. I'm only asking about the _signatures_ here.

9. What I'm _guessing_ is what is happening, but I don't know this
for a fact, is that Google is enforcing a _signature_ on each
APK on the Google Play Store repo, which, confusingly, can be
put on _other_ repos (e.g., maybe GitHub perhaps?) but not on others.

10. If that's true, clearly one of those "others" is F-Droid's repo.

But I do Not know this for a fact.
Hence that's just a mere guess.

Anyone know more?
--
Posted out of the goodness of my heart to disseminate useful information,
which, in this case, is why can an Aurora Store downloaded app update only
another Google Play Repo app and and F-Droid downloaded app can not.

On 24/07/2022 11:27, Andy Burns wrote:
> Jeff Layman wrote:
>
>> It doesn't know what the rest of the app does, or what malware it might contain,
>> and by allowing something new relating to OAuth2 it /might/ be allowing the
>> "new" K-9 to access things Google believes it shouldn't.
>
> If google don't want clients to access something on their servers, the correct
> way to enforce that is on the servers, not on the client.

Has Google allowed updating of the F-Droid K-9 app prior to the OAuth2
update? If not, it's probably a policy thing related to what Google
generally allows for an update. If it has, then it's specific to the
OAuth2 update (and maybe further updates? A permanent change of policy,
perhaps?).

--

Jeff

On 24/07/2022 23.14, Andy Burnelli wrote:
> Andy Burns wrote:
>
>> Jeff Layman wrote:

....

> 7. This may be wrong, but I've gleaned that information from seeing
> app developers tell us that the app on other repositories is NOT
> exactly the same  as the app on the Google Play Repo repository
> _because_ of that Google-enforced signature _by_ Google.
>
> 8. Of course, as in the case of NetGuard, the non-Google Play Repo APK
>   is also a different set of functionality, but that's not what   I'm
> asking about here. I'm only asking about the _signatures_ here.
>
> 9. What I'm _guessing_ is what is happening, but I don't know this   for
> a fact, is that Google is enforcing a _signature_ on each   APK on the
> Google Play Store repo, which, confusingly, can be   put on _other_
> repos (e.g., maybe GitHub perhaps?) but not on others.
>
> 10. If that's true, clearly one of those "others" is F-Droid's repo.
>
> But I do Not know this for a fact. Hence that's just a mere guess.
>
> Anyone know more?

I don't know about Google, but I know about signatures in Linux
packages, or being precise, on openSUSE.

Each package is cryptographically signed using PGP keys, so that the
user (and the application that does the update or install) can know that
the package is authentic and has not being modified, no matter how or
where from you download it. Packages generated and published by openSUSE
use the an openSUSE signature, while applications done by other
contributors have the signature key of those contributors.

I don't know how Google does things, but I suppose there are similarities.

The package you are going to update with, and the one already installed,
are signed by different people, so they don't come from the same source
or repository, so the installer stops. It doesn't really know if they
are in fact the same or compatible package, it just stops.

--
Cheers,
Carlos E.R.

Carlos E. R. wrote:

> The package you are going to update with, and the one already installed,
> are signed by different people, so they don't come from the same source
> or repository, so the installer stops. It doesn't really know if they
> are in fact the same or compatible package, it just stops.

Thanks Carlos for offering those suggestions based on your Linux
experience, which, I suspect, is likely also what's going on here.

It makes sense for Google to only want to update packages that it knows
came from its own repositories (no matter which client installed them).

It's clear Google won't update APKs installed from F-Droid, where I'm not
yet sure if Google will update APKs from Github or Sourceforge either.

Probably not; but I'd have to test it as I only started noticing this
recently, and I've never dealt with package signing in any serious way.

On 25/07/2022 15.17, Andy Burnelli wrote:
> Carlos E. R. wrote:
>
>> The package you are going to update with, and the one already
>> installed, are signed by different people, so they don't come from the
>> same source or repository, so the installer stops. It doesn't really
>> know if they are in fact the same or compatible package, it just stops.
>
> Thanks Carlos for offering those suggestions based on your Linux
> experience, which, I suspect, is likely also what's going on here.
>
> It makes sense for Google to only want to update packages that it knows
> came from its own repositories (no matter which client installed them).
>
> It's clear Google won't update APKs installed from F-Droid, where I'm not
> yet sure if Google will update APKs from Github or Sourceforge either.
>
> Probably not; but I'd have to test it as I only started noticing this
> recently, and I've never dealt with package signing in any serious way.

From what I know on my Linux, an application from one repository will
never be updated with the same one from another repository. This policy
can be overridden.

--
Cheers,
Carlos E.R.