4 ms·

F-Droid is cool but will lack lots of applications, even open source ones. I recently checked what it would require to publish my app there -- alas, can't do th

F-Droid is cool but will lack lots of applications, even open source ones. I recently checked what it would require to publish my app there -- alas, can't do that since my app includes an API key that can't be published (according to the rules of the service in question), and F-Droid would need that[1]. [1] https://f-droid.org/forums/topic/what-to-do-with-private-api-keys https://f-droid.org/forums/topic/what-to-do-with-private-api...

captn3m0 10y ago
If the key is published as part of the APK, it is already public. Not committing it on github doesn't really reduce exposure.
- pmtarantino 10y ago
  I never developed an app so I dont know, but if you cant include in the APK because people can decode it, how do you distribute keys and secret strings?
  - iokanuon 10y ago
    You do it like that and just hope people won't abuse it.
  - PeterisP 10y ago
    What secret strings? You distribute user-specific secrets after a user has logged in over a secure channel. You don't get to have app-specific secrets - since anybody can get and run the app (and modify it!), nothing in it has a reason to be secret. This means that you don't get to have an API that's available only through that app and with limitations set by that app. If you use a third-party API that requires you to enforce limits on its use (e.g. that end users can't redistribute access to that API), this means that you can't meet the requirements of that API licencing.
- deleted 10y ago
  [deleted]
- distances 10y ago
  That's a very technical viewpoint. The API agreement tells not to share the key, which obviously does not mean you can't include it in the app binary. I interpret that as not being allowed to publish the key with the source code though.
  - krick 10y ago
    That's pretty weird and questionable interpretation, since if I have a binary — I have the key, even if in some obfuscated form (even that isn't usually true with APKs though), but whatever, if it works for you — fine, then I have a solution to your problem. Don't include API_KEY in the published source, include rot13(API_KEY).
    - distances 10y ago
      You have to consider the intention of the service provider, which in this case is more geared towards mobile clients than web services. It's perfectly clear that binaries will include the API key, no interpretation needed on that part. It's the source code part that is open to interpretation. I could of course just ask for explicit permission for that.
      - krick 10y ago
        So rot13 should work as fine as that, I'd assume. You wouldn't publish API_KEY this way, would you?
        distances 10y ago
        In a sense, perhaps. But I feel that's just technical trickery on a reasonable request, so I don't see myself bothering with such workarounds.
pawadu 10y ago
I think the response krt gave was fair enough: --- I dont get all that API key nonsense, you can search this board for our opinions on API keys. I’ll keep this short: If your app requires an API key and you withhold it (because you entered an agreement with the service provider), this basically makes it not buildable for 3rd parties in a useful manner. F-droid will not sign an agreement with whatever service provider you use nor will we withhold build information. There are actually only two solutions: 1) Provide a way for the user (!) to enter API key or account information at runtime. 2) Provide a way for us to get the key at buildtime, e.g. there was one app where I had to download a pre-compile APK file, extract the key from it and re-use that key in our builds.. which sucked. Anyway, I dont see what’s the difference to just providing the API key. If you distribute an APK, you distribute the API key (in one form or another) — since without it the app would not work… sigh.
- pawadu 10y ago
  Should also add the f-droid tries to build software that are truly open, i.e. can function without 3rd part closed services. I think many times you can limit the FOSS version to not include functions such as leader boards to avoid such issues and no one will complain.
- distances 10y ago
  Yes, I think that's a fair stance. Just means I can't publish my app. Maybe that's even desirable, considering the service is providing non-free data.
- s73ver 10y ago
  I think part 1 is fair, but part 2 is not. That's just silly.
jhasse 10y ago
Many people don't consider something "open source" if they can't build it themselves. Other alternative app stores are the Yandex Store (https://store.yandex.com/ https://store.yandex.com/) or the Amazon App Store, those include non-free software too.
- distances 10y ago
  You can build the app, and to make it functional you could request your own API key, so I think it satisfies the label. Requesting API keys as a regular end user isn't anywhere near being realistic though, so that's not an option for distribution.
  - Sean1708 10y ago
    From pawadu's response above it sounds like your app would satisfy the requirements if you have a build parameter or similar that lets them specify the key.
    - distances 10y ago
      There's another discussion thread [1] which takes a strict stance more explicitly: "I don’t see how something that contains a ‘secret’ key [...] can be Free Software. So we just don’t publish such applications." [1] https://f-droid.org/forums/topic/api-keys-and-free-software-apps-on-f-droid-and-in-general https://f-droid.org/forums/topic/api-keys-and-free-software-...
- floatboth 10y ago
  Yeah, BTW the good thing about these stores is that they install apps normally, by launching the system APK install dialog, instead of the rootkit-style thing Google Play does.
  - jhasse 10y ago
    Rootkit-style installing is also possible with F-Droid :)
kuschku 10y ago
But you can! F-Droid has several apps where they download a built APK, decompile it automatically, extract the API key, and build the open source app with that key. You can do exactly that already.

captn3m0 10y ago

If the key is published as part of the APK, it is already public. Not committing it on github doesn't really reduce exposure.

pmtarantino 10y ago
I never developed an app so I dont know, but if you cant include in the APK because people can decode it, how do you distribute keys and secret strings?
- iokanuon 10y ago
  You do it like that and just hope people won't abuse it.
- PeterisP 10y ago
  What secret strings? You distribute user-specific secrets after a user has logged in over a secure channel. You don't get to have app-specific secrets - since anybody can get and run the app (and modify it!), nothing in it has a reason to be secret. This means that you don't get to have an API that's available only through that app and with limitations set by that app. If you use a third-party API that requires you to enforce limits on its use (e.g. that end users can't redistribute access to that API), this means that you can't meet the requirements of that API licencing.
deleted 10y ago
[deleted]
distances 10y ago
That's a very technical viewpoint. The API agreement tells not to share the key, which obviously does not mean you can't include it in the app binary. I interpret that as not being allowed to publish the key with the source code though.
- krick 10y ago
  That's pretty weird and questionable interpretation, since if I have a binary — I have the key, even if in some obfuscated form (even that isn't usually true with APKs though), but whatever, if it works for you — fine, then I have a solution to your problem. Don't include API_KEY in the published source, include rot13(API_KEY).
  - distances 10y ago
    You have to consider the intention of the service provider, which in this case is more geared towards mobile clients than web services. It's perfectly clear that binaries will include the API key, no interpretation needed on that part. It's the source code part that is open to interpretation. I could of course just ask for explicit permission for that.
    - krick 10y ago
      So rot13 should work as fine as that, I'd assume. You wouldn't publish API_KEY this way, would you?
      - distances 10y ago
        In a sense, perhaps. But I feel that's just technical trickery on a reasonable request, so I don't see myself bothering with such workarounds.

pawadu 10y ago

I think the response krt gave was fair enough: --- I dont get all that API key nonsense, you can search this board for our opinions on API keys. I’ll keep this short: If your app requires an API key and you withhold it (because you entered an agreement with the service provider), this basically makes it not buildable for 3rd parties in a useful manner. F-droid will not sign an agreement with whatever service provider you use nor will we withhold build information. There are actually only two solutions: 1) Provide a way for the user (!) to enter API key or account information at runtime. 2) Provide a way for us to get the key at buildtime, e.g. there was one app where I had to download a pre-compile APK file, extract the key from it and re-use that key in our builds.. which sucked. Anyway, I dont see what’s the difference to just providing the API key. If you distribute an APK, you distribute the API key (in one form or another) — since without it the app would not work… sigh.

pawadu 10y ago
Should also add the f-droid tries to build software that are truly open, i.e. can function without 3rd part closed services. I think many times you can limit the FOSS version to not include functions such as leader boards to avoid such issues and no one will complain.
distances 10y ago
Yes, I think that's a fair stance. Just means I can't publish my app. Maybe that's even desirable, considering the service is providing non-free data.
s73ver 10y ago
I think part 1 is fair, but part 2 is not. That's just silly.

jhasse 10y ago

Many people don't consider something "open source" if they can't build it themselves. Other alternative app stores are the Yandex Store (https://store.yandex.com/ https://store.yandex.com/) or the Amazon App Store, those include non-free software too.

distances 10y ago
You can build the app, and to make it functional you could request your own API key, so I think it satisfies the label. Requesting API keys as a regular end user isn't anywhere near being realistic though, so that's not an option for distribution.
- Sean1708 10y ago
  From pawadu's response above it sounds like your app would satisfy the requirements if you have a build parameter or similar that lets them specify the key.
  - distances 10y ago
    There's another discussion thread [1] which takes a strict stance more explicitly: "I don’t see how something that contains a ‘secret’ key [...] can be Free Software. So we just don’t publish such applications." [1] https://f-droid.org/forums/topic/api-keys-and-free-software-apps-on-f-droid-and-in-general https://f-droid.org/forums/topic/api-keys-and-free-software-...
floatboth 10y ago
Yeah, BTW the good thing about these stores is that they install apps normally, by launching the system APK install dialog, instead of the rootkit-style thing Google Play does.
- jhasse 10y ago
  Rootkit-style installing is also possible with F-Droid :)

kuschku 10y ago

But you can! F-Droid has several apps where they download a built APK, decompile it automatically, extract the API key, and build the open source app with that key. You can do exactly that already.