6 ms·

VLC can't update on Android without giving Google private signing keys

116 points by buro9 3y ago

oefrha 3y ago
> You can sign those with your own key, but then you need to share your private upload key to keep compatibility. Or you don't share it and Google signs it with a new key, leaving old devices behind. I don’t get it: app can’t be updated if signed with a new key? Given that apps are sold all the time, and developers sometimes lose private keys themselves, this makes no sense.
- phh 3y ago
  > I don’t get it: app can’t be updated if signed with a new key? That's correct. > Given that apps are sold all the time, I'm pretty confident that in 90%+ of those cases, developers just sell the signing keys with it. FWIW, Android does have a mechanism to upgrade keys (app signed with the old key contains in its metadata the new key saying that this key is okay) since like 4-5 years ago. But I expect very few people use that. (I don't even know whether Google Play Store allows using this) > and developers sometimes lose private keys themselves, this makes no sense. I guess they don't when their revenue relies on it?
  - rvnx 3y ago
    In fact most of the developers do not manage the key themselves but instead use the default option: let Google generate and store one signed distribution key for you. This is the key that is used by the devices to verify that the APK can be installed on top of another. If an APK was signed by "Key A", only "Key A" can do updates. One advantage of that, is that malicious users cannot be served a malicious update of an app that didn't go through Play Store. Let's imagine it's the opposite, that France for example wants to spy on some users ? Other advantage, is that if you lose your developer private key, then you do not lose the capacity of doing updates. The minus of that, is that you have to count on Google to sign every single of your APKs. If they do not trust Google, VLC can add a checksum or integrity checks to the binaries loaded by the app during runtime.
    - oefrha 3y ago
      > This is the key that is used by the devices to verify that the APK can be installed on top of another. Given that one option here is to let Google sign with a new key and keep things updated (dropping support for old devices in the process), this seems like a policy limitation, not an Android technical limitation?
      - phh 3y ago
        Oh yeah it's completely a Google Play policy issue. The original VLC thread on X is titled "App stores were a mistake"
    - mschuster91 3y ago
      > One advantage of that, is that malicious users cannot be served a malicious update of an app that didn't go through Play Store. And the disadvantage of that is that it is almost impossible to patch APKs on your own without running into serious issues, even as root - particularly when the app you're trying to patch has shared permissions with other apps of the same developer.
LinuxBender 3y ago
Archive [1] Just a snapshot in time of a growing mastodon thread [1] - https://archive.is/pzanE https://archive.is/pzanE
swozey 3y ago
Is the Android and iPhone VLC app similar? The MacOS and Windows versions are completely different, I didn't know that and wanted to export my settings to match and MacOS has way fewer features.
- danaris 3y ago
  ...Have you checked the settings after pressing the Show All button on Mac?
  - swozey 3y ago
    Yes I have. The apps are completely different. They don't even look remotely the same, the tool bars and media library etc are all different. I have to look for a ton of stuff that I know exactly where it is in Windows. There is specifically no zoom with the rectangle box that Windows has and many other things. There IS a "Zoom" but it's not the same at all and just modified window sizes. And I can't import my Windows VLC settings like I thought I would. I have tons of shortcuts, etc already assigned on my Windows end. This pissed me off because I spent a lot of time getting my VLC settings how I want them thinking I would just import them into my macbook. There's not even a way to import or export MacOS VLC's own settings. https://imgur.com/a/7G7REfv https://imgur.com/a/7G7REfv I would be more than happy to be wrong about this and corrected..
LinuxBender 3y ago
The only scenario that comes to mind would be Google repackaging a build after some subtle changes, signing it and sending to a lawful intercept target. Are there other cases where the developer does not sign the package aside from selling the package to Google?
- can16358p 3y ago
  Apple does something similar to create optimized versions of the app for different devices/OS versions (presumably).
  - LinuxBender 3y ago
    Interesting. Do Apple then submit their optimized diffs to the developer and have them uptake the changes so the source is optimized? Or would the developer have to de-compile the artifacts and reverse engineer the optimizations to see what was changed, added or removed? It seems like this would make attestation and audits challenging for apps used by b2b financial customers.
    - nerdjon 3y ago
      I would imagine that this is similar to the same shared security model that you would use within AWS and other Cloud Providers. At some point you have to point to their documentation and how they do things as being out of your control but possibly audited on its own. But if you are really worried for iOS it is optional. I don't see any capabilities regarding your first question outside of testing specific devices through TestFlight, but I would think it is fairly safe to assume that Apple has put a lot of work into making sure this works consistently between devices. It is also entirely possible that, like working with Cloud Providers, that there is a difference between what normal users can do and what can be done with NDA's and other contracts signed.
  - tempay 3y ago
    For some details: https://help.apple.com/xcode/mac/current/#/devbbdc5ce4f https://help.apple.com/xcode/mac/current/#/devbbdc5ce4f
denysvitali 3y ago
I faced a similar issue: it seems like it has now become close to impossible to use your own signing / release key. My understanding is that Google really wants to manage your keys so that you can't really mess up. If your app has a lot of users and you lose the signing key, IIRC you'll cause an outage due to the fact that existing users will not be able to update the app without uninstalling it and re-installing it, causing data loss. I'd love to be corrected, as there might be some key rotation procedure in place that I'm unaware of. In any case, even if you owned the signing key, no one could theoretically stop Google from providing an APK signed with another key to the PlayStore users, since at first install the apps trust whatever key you provide (and the only cross-check I'm aware of is, well, Play Protect, also owned by Google)
- danpalmer 3y ago
  > My understanding is that Google really wants to manage your keys so that you can't really mess up. It's not just this, apps are now delivered as many separate parts so that a device only gets what it needs. In the age of ARM/ARM64/x86, varying DPIs, different graphics abilities, etc, it can be easy for most users to not need most of an app. Google generates all these pieces from the "bundle", and picks optimal sets for each user/device. This could be potentially managed by users (it's all based on bundletool, an open source project), but there's a lot more on top of this, dynamic pieces that Google can generate on-demand for apps for various app health/security/product features. This only works if Google can sign the pieces.
  - ndriscoll 3y ago
    If the distributor (Google) has the signing keys, why not just... not sign it? What does signing give you that TLS doesn't? Why can't Google sign the app with its own keys without the author having a say? The entire point of signatures is that users can trust their download is what the author published because they're the only one who could produce that signature.
    - Hizonner 3y ago
      > What does signing give you that TLS doesn't? A huge number of replicated servers have to have access to TLS keys, and a huge number of people have to be involved in the administration of those servers. And, to rely on TLS, you have to assure the integrity of the data within the whole store infrastructure, not just at the point that a file gets injected into it. The practical exposure is vastly worse than with end to end signing.
sp332 3y ago
Some discussion from a few days ago, but on a less useful link. https://news.ycombinator.com/item?id=39798565 https://news.ycombinator.com/item?id=39798565
can16358p 3y ago
Not to be the devil's advocate but how is just a signing key for an Android app/developer that is used for signing APKs and bundles comparable to "keys to your bank account"?
- danpalmer 3y ago
  It is not. Google signs the parts of the app because apps are no longer one single APK, they're a complex set of many parts that can be updated independently and in complex ways. The mobile ecosystem has moved on a lot since monolithic APKs and user expectations are too high for them to be sufficient.
  - RHSeeger 3y ago
    That being said, the signing key is supposed to be "we certify this". Handing your key over to a 3rd party defeats that. If both <software producer> and google need to be able to sign it in some way, then the signing process should be enhanced to represent that. Maybe the software producer signs their individual components, and google signs the bundle, or something like that.
    - danpalmer 3y ago
      I believe this is captured already – it's possible to verify that the binary was created by Google, but that it originated from the original developer.
    - rvnx 3y ago
      The key your describe, is the developer key, Google checks it. The key that VLC is talking about, is the distribution key. Google manages the distribution key for you, one of the many reasons is because they create optimized APKs for each platform.
    - wongarsu 3y ago
      Similar to how on Windows you sign both the installer and each binary that will be installed. In that setup it's trivial to have the binaries signed by one party, and the installer by another party.
ChrisArchitect 3y ago
[dupe] More discussion over here last week: https://news.ycombinator.com/item?id=39789300 https://news.ycombinator.com/item?id=39789300
fsflover 3y ago
So Android is not as free as many commenters here used to say while arguing that there is an alternative to Apple.
- pbhjpbhj 3y ago
  You don't have to use the Google Play store, other app stores and side-loading are available, so there is still freedom in Android, but not so much in Google Play. In other words, Android gives access to multiple curated app stores, and side-loading. Whilst I understand that Apple only allowed use of apps from their own store until the EU stepped in, and now they have an EU-available update that allows side-loading.
- II2II 3y ago
  Android is not the same thing as the Play Store. As far as I can tell, every Android user has the option to enable the installation of 3rd party software (though I could be wrong here, since my experience is with phones/tablets and not other Android based devices). When you deal with the Play Store, you are dealing with the store's policies rather than a limitation of the Android platform.
- sanitycheck 3y ago
  The freedom, such as it is, comes from alternative app stores. I trust F-Droid (https://f-droid.org/ https://f-droid.org/) somewhat more than I trust apps on the Play Store so that's my first stop when I'm looking for something.
  - MikusR 3y ago
    Google Play has started to hijack apps installed from Fdroid. As the keys don't match the upade fails and is stuck in the updates available notification. In essence breaking manual check for updates, because the button to check for update is the same as show updates.
- anta40 3y ago
  Well, you can use 3rd party app stores like F-Droid, which is open source...
aaomidi 3y ago
People are bad at key management. Like, this has been proven time and time again. I do think a hybrid approach would be best here though.
littlestymaar 3y ago
What's the point of Google asking for other people's private keys? That's not how asymetric encryption scheme are supposed to be used! Google could sign packages with their own keys, I don't see what they gain from having videolans' keys, except to impersonate them (which is fishy).
Aza- 3y ago
[dead]
deleted 3y ago
[deleted]
m-p-3 3y ago
It's also tangentially related to the app archiving feature of Android 15, which in order to retain backward-compatibility, replaces the full APK by a shim that you can simply open to initiate the app redownload. This allows to keep the existing local app storage in place. You cannot replace the original APK by another one unless the signatures of both matches. https://www.androidauthority.com/android-15-app-archiving-demo-3425621/ https://www.androidauthority.com/android-15-app-archiving-de...

116 points by buro9 3y ago

> You can sign those with your own key, but then you need to share your private upload key to keep compatibility. Or you don't share it and Google signs it with a new key, leaving old devices behind. I don’t get it: app can’t be updated if signed with a new key? Given that apps are sold all the time, and developers sometimes lose private keys themselves, this makes no sense.

phh 3y ago
> I don’t get it: app can’t be updated if signed with a new key? That's correct. > Given that apps are sold all the time, I'm pretty confident that in 90%+ of those cases, developers just sell the signing keys with it. FWIW, Android does have a mechanism to upgrade keys (app signed with the old key contains in its metadata the new key saying that this key is okay) since like 4-5 years ago. But I expect very few people use that. (I don't even know whether Google Play Store allows using this) > and developers sometimes lose private keys themselves, this makes no sense. I guess they don't when their revenue relies on it?
- rvnx 3y ago
  In fact most of the developers do not manage the key themselves but instead use the default option: let Google generate and store one signed distribution key for you. This is the key that is used by the devices to verify that the APK can be installed on top of another. If an APK was signed by "Key A", only "Key A" can do updates. One advantage of that, is that malicious users cannot be served a malicious update of an app that didn't go through Play Store. Let's imagine it's the opposite, that France for example wants to spy on some users ? Other advantage, is that if you lose your developer private key, then you do not lose the capacity of doing updates. The minus of that, is that you have to count on Google to sign every single of your APKs. If they do not trust Google, VLC can add a checksum or integrity checks to the binaries loaded by the app during runtime.
  - oefrha 3y ago
    > This is the key that is used by the devices to verify that the APK can be installed on top of another. Given that one option here is to let Google sign with a new key and keep things updated (dropping support for old devices in the process), this seems like a policy limitation, not an Android technical limitation?
    - phh 3y ago
      Oh yeah it's completely a Google Play policy issue. The original VLC thread on X is titled "App stores were a mistake"
  - mschuster91 3y ago
    > One advantage of that, is that malicious users cannot be served a malicious update of an app that didn't go through Play Store. And the disadvantage of that is that it is almost impossible to patch APKs on your own without running into serious issues, even as root - particularly when the app you're trying to patch has shared permissions with other apps of the same developer.

LinuxBender 3y ago

Archive [1] Just a snapshot in time of a growing mastodon thread [1] - https://archive.is/pzanE https://archive.is/pzanE

swozey 3y ago

Is the Android and iPhone VLC app similar? The MacOS and Windows versions are completely different, I didn't know that and wanted to export my settings to match and MacOS has way fewer features.

danaris 3y ago
...Have you checked the settings after pressing the Show All button on Mac?
- swozey 3y ago
  Yes I have. The apps are completely different. They don't even look remotely the same, the tool bars and media library etc are all different. I have to look for a ton of stuff that I know exactly where it is in Windows. There is specifically no zoom with the rectangle box that Windows has and many other things. There IS a "Zoom" but it's not the same at all and just modified window sizes. And I can't import my Windows VLC settings like I thought I would. I have tons of shortcuts, etc already assigned on my Windows end. This pissed me off because I spent a lot of time getting my VLC settings how I want them thinking I would just import them into my macbook. There's not even a way to import or export MacOS VLC's own settings. https://imgur.com/a/7G7REfv https://imgur.com/a/7G7REfv I would be more than happy to be wrong about this and corrected..

LinuxBender 3y ago

The only scenario that comes to mind would be Google repackaging a build after some subtle changes, signing it and sending to a lawful intercept target. Are there other cases where the developer does not sign the package aside from selling the package to Google?

can16358p 3y ago
Apple does something similar to create optimized versions of the app for different devices/OS versions (presumably).
- LinuxBender 3y ago
  Interesting. Do Apple then submit their optimized diffs to the developer and have them uptake the changes so the source is optimized? Or would the developer have to de-compile the artifacts and reverse engineer the optimizations to see what was changed, added or removed? It seems like this would make attestation and audits challenging for apps used by b2b financial customers.
  - nerdjon 3y ago
    I would imagine that this is similar to the same shared security model that you would use within AWS and other Cloud Providers. At some point you have to point to their documentation and how they do things as being out of your control but possibly audited on its own. But if you are really worried for iOS it is optional. I don't see any capabilities regarding your first question outside of testing specific devices through TestFlight, but I would think it is fairly safe to assume that Apple has put a lot of work into making sure this works consistently between devices. It is also entirely possible that, like working with Cloud Providers, that there is a difference between what normal users can do and what can be done with NDA's and other contracts signed.
- tempay 3y ago
  For some details: https://help.apple.com/xcode/mac/current/#/devbbdc5ce4f https://help.apple.com/xcode/mac/current/#/devbbdc5ce4f

denysvitali 3y ago

I faced a similar issue: it seems like it has now become close to impossible to use your own signing / release key. My understanding is that Google really wants to manage your keys so that you can't really mess up. If your app has a lot of users and you lose the signing key, IIRC you'll cause an outage due to the fact that existing users will not be able to update the app without uninstalling it and re-installing it, causing data loss. I'd love to be corrected, as there might be some key rotation procedure in place that I'm unaware of. In any case, even if you owned the signing key, no one could theoretically stop Google from providing an APK signed with another key to the PlayStore users, since at first install the apps trust whatever key you provide (and the only cross-check I'm aware of is, well, Play Protect, also owned by Google)

danpalmer 3y ago
> My understanding is that Google really wants to manage your keys so that you can't really mess up. It's not just this, apps are now delivered as many separate parts so that a device only gets what it needs. In the age of ARM/ARM64/x86, varying DPIs, different graphics abilities, etc, it can be easy for most users to not need most of an app. Google generates all these pieces from the "bundle", and picks optimal sets for each user/device. This could be potentially managed by users (it's all based on bundletool, an open source project), but there's a lot more on top of this, dynamic pieces that Google can generate on-demand for apps for various app health/security/product features. This only works if Google can sign the pieces.
- ndriscoll 3y ago
  If the distributor (Google) has the signing keys, why not just... not sign it? What does signing give you that TLS doesn't? Why can't Google sign the app with its own keys without the author having a say? The entire point of signatures is that users can trust their download is what the author published because they're the only one who could produce that signature.
  - Hizonner 3y ago
    > What does signing give you that TLS doesn't? A huge number of replicated servers have to have access to TLS keys, and a huge number of people have to be involved in the administration of those servers. And, to rely on TLS, you have to assure the integrity of the data within the whole store infrastructure, not just at the point that a file gets injected into it. The practical exposure is vastly worse than with end to end signing.

sp332 3y ago

Some discussion from a few days ago, but on a less useful link. https://news.ycombinator.com/item?id=39798565 https://news.ycombinator.com/item?id=39798565

can16358p 3y ago

Not to be the devil's advocate but how is just a signing key for an Android app/developer that is used for signing APKs and bundles comparable to "keys to your bank account"?

danpalmer 3y ago
It is not. Google signs the parts of the app because apps are no longer one single APK, they're a complex set of many parts that can be updated independently and in complex ways. The mobile ecosystem has moved on a lot since monolithic APKs and user expectations are too high for them to be sufficient.
- RHSeeger 3y ago
  That being said, the signing key is supposed to be "we certify this". Handing your key over to a 3rd party defeats that. If both <software producer> and google need to be able to sign it in some way, then the signing process should be enhanced to represent that. Maybe the software producer signs their individual components, and google signs the bundle, or something like that.
  - danpalmer 3y ago
    I believe this is captured already – it's possible to verify that the binary was created by Google, but that it originated from the original developer.
  - rvnx 3y ago
    The key your describe, is the developer key, Google checks it. The key that VLC is talking about, is the distribution key. Google manages the distribution key for you, one of the many reasons is because they create optimized APKs for each platform.
  - wongarsu 3y ago
    Similar to how on Windows you sign both the installer and each binary that will be installed. In that setup it's trivial to have the binaries signed by one party, and the installer by another party.

ChrisArchitect 3y ago

[dupe] More discussion over here last week: https://news.ycombinator.com/item?id=39789300 https://news.ycombinator.com/item?id=39789300

fsflover 3y ago

So Android is not as free as many commenters here used to say while arguing that there is an alternative to Apple.

pbhjpbhj 3y ago
You don't have to use the Google Play store, other app stores and side-loading are available, so there is still freedom in Android, but not so much in Google Play. In other words, Android gives access to multiple curated app stores, and side-loading. Whilst I understand that Apple only allowed use of apps from their own store until the EU stepped in, and now they have an EU-available update that allows side-loading.
II2II 3y ago
Android is not the same thing as the Play Store. As far as I can tell, every Android user has the option to enable the installation of 3rd party software (though I could be wrong here, since my experience is with phones/tablets and not other Android based devices). When you deal with the Play Store, you are dealing with the store's policies rather than a limitation of the Android platform.
sanitycheck 3y ago
The freedom, such as it is, comes from alternative app stores. I trust F-Droid (https://f-droid.org/ https://f-droid.org/) somewhat more than I trust apps on the Play Store so that's my first stop when I'm looking for something.
- MikusR 3y ago
  Google Play has started to hijack apps installed from Fdroid. As the keys don't match the upade fails and is stuck in the updates available notification. In essence breaking manual check for updates, because the button to check for update is the same as show updates.
anta40 3y ago
Well, you can use 3rd party app stores like F-Droid, which is open source...

aaomidi 3y ago

People are bad at key management. Like, this has been proven time and time again. I do think a hybrid approach would be best here though.

littlestymaar 3y ago

What's the point of Google asking for other people's private keys? That's not how asymetric encryption scheme are supposed to be used! Google could sign packages with their own keys, I don't see what they gain from having videolans' keys, except to impersonate them (which is fishy).

Aza- 3y ago

[dead]

deleted 3y ago

[deleted]

m-p-3 3y ago

It's also tangentially related to the app archiving feature of Android 15, which in order to retain backward-compatibility, replaces the full APK by a shim that you can simply open to initiate the app redownload. This allows to keep the existing local app storage in place. You cannot replace the original APK by another one unless the signatures of both matches. https://www.androidauthority.com/android-15-app-archiving-demo-3425621/ https://www.androidauthority.com/android-15-app-archiving-de...