Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bring the app to f-droid #233

Open
bootofood opened this issue Oct 12, 2016 · 78 comments
Open

Bring the app to f-droid #233

bootofood opened this issue Oct 12, 2016 · 78 comments
Assignees

Comments

@bootofood
Copy link

@bootofood bootofood commented Oct 12, 2016

Please make it possible to compile the app without the non-free dependencies.
In this way it could be included in f-droid, finally beating Signal!

@someoneEsle
Copy link
Contributor

@someoneEsle someoneEsle commented Oct 12, 2016

Answer here: #5
You may as well close ^^

@bootofood
Copy link
Author

@bootofood bootofood commented Oct 13, 2016

Thanks. That issue is closed, that's why I didn't find it. Good to read that they're interested in publishing the app in f-droid, certainly a more friendly and reasonable approach than what we got for Signal.

Shouldn't a "f-droid issue" stay open until we've got it in there, complying with the inclusion policy?

@someoneEsle
Copy link
Contributor

@someoneEsle someoneEsle commented Oct 13, 2016

I don't know what the policy as for keeping issues open is, but it looks like something they're aware of, therefore there's no need to let the ticket open (which may be why they closed the other one). I'm pretty sure they'll remember even if this issue gets closed.
(I understand your point about leaving an issue open though, maybe they could leave the original one open as it has the official reply too)

@bjoernherbig
Copy link

@bjoernherbig bjoernherbig commented Oct 14, 2016

Thanks guys for bringing this up again and yes, we will remember it for sure. As for closing it, we will leave this one open since there are likely to come in more requests for f-droid.

@h-2
Copy link

@h-2 h-2 commented Oct 14, 2016

Out of curiosity: what are the proprietary dependencies blocking f-droid acceptance? Seems like if you already have a fallback for GCM you are almost there or not? Maybe other people could help in this process?

@paride
Copy link

@paride paride commented Oct 16, 2016

@h-2 take a look here:

#5 (comment)

and compiling without GCM is probably non trivial, even if there is already a fallback mechanism.

@h-2
Copy link

@h-2 h-2 commented Nov 4, 2016

I am posting a 50€ bounty for someone who creates a version of the Android Wire client that fully meets F-Droid’s criteria, i.e. no proprietary dependencies. Preferably the changes would also meet upstream’s criteria for integration into the official repository, e.g. via a Flavor or build flag or something like that.

I can send the money via Paypal or WireTransfer/SEPA.

edit: timeframe: for this bounty there should be some alpha/beta version until 2017-02-01

@lipis
Copy link
Contributor

@lipis lipis commented Nov 4, 2016

💶 💵 💶 💵 💶

@grote
Copy link

@grote grote commented Nov 6, 2016

The first step, before anybody can take this on would be to get rid of the custom maven repository and get those dependencies submitted to jcenter.

Currently, these libraries are affected:

  • gradle-android-scala-plugin - non-upstreamed fork?
  • icu4j-shrunk - non-upstreamed fork?
  • robotest_2.11 - non-upstreamed fork?
  • spotify-auth - non-free software?
  • spotify-player - non-free software?

Having some information on these libraries would make it easier to assess the actual effort needed for a 3rd-party to take on this work.

@h-2
Copy link

@h-2 h-2 commented Nov 8, 2016

Users of Signal have three months until the last version "expires" that works without PlayServices. If wire published a preliminary free software version until then, it could motivate quite a few people to switch and would definitely get some attention...
https://twitter.com/VenemaSander/status/794937272697294852
https://twitter.com/shiromarieke/status/793947755840413696

(Note that Free Software server source and federation #237 would be really cool, but totally unrelated to this issue as Signal didn't provide these either)

@darkbluelight
Copy link

@darkbluelight darkbluelight commented Nov 11, 2016

Referencing #233 (comment)
@bjoernherbig count one more request for f-droid from a Signal user (with quite some friends using Signal...) willing to change to Wire! I'm really looking forward to it. Especially as the GCM free WebSocket Signal for f-droid is very likely to be discontinued :(

@bgermann
Copy link
Contributor

@bgermann bgermann commented Nov 16, 2016

The bintray maven repository wire-android/third-party that @grote mentioned is not the only one that is in use and not allowed by f-droid. There are some more by wire (wire-android/releases, wire-android/snapshots), which can be built from the github sources, and a Localytics repo.

The Localytics library seems to be BSD licensed, but I cannot find the corresponding source. I guess this tracking library would have to be removed for f-droid anyway.

I have not checked all build scripts. Maybe there are some other Maven repositories not allowed by f-droid.

For the mentioned third-party libraries I have found the following:

  • gradle-android-scala-plugin - non-upstreamed fork, can be imported via jitpack.
  • icu4j-shrunk - can be replaced by standard icu4j.
  • robotest_2.11 - There is a newer incompatible version available on standard repos. But you can use a jitpack build on v0.7.

@h-2
Copy link

@h-2 h-2 commented Nov 23, 2016

So it seems it is mostly about making the spotify stuff and localytics optional, the rest is just infrastructural cleanup?

@bgermann
Copy link
Contributor

@bgermann bgermann commented Dec 15, 2016

@wireswiss in app/opensource.txt you list Spotify Authentication Library and Spotify Player Library as Apache 2.0 licensed. While this is true for a newer Authentication Library than the Beta version you link with, the Spotify Player Library is subject to Spotify Developer Terms of Use rather than any open source license.

You also list Localytics SDK in that file, but it is not open sourced as well. I guess it is redistributable under the Localytics Terms of Service.

I suggest you remove the lines from app/opensource.txt and mention the proprietary dependencies at README

@grote
Copy link

@grote grote commented Dec 15, 2016

I would also be nice if you could clarify whether you would accept a PR that introduces a new gradle flavor that builds the app without these non-free dependencies.

@hakonbo
Copy link

@hakonbo hakonbo commented Dec 16, 2016

Hi all,

We are looking into creating an F-Droid flavour, but it's a side project and will take a bit of time. Would be great if you want to contribute.
Spotify/Localytics libs are included in the sync engine project as well, so we need a new flavour of that one as well.
@bgermann Thanks for checking the licences, I think that file might be a bit outdated, I'll see if we can get it updated.

@ghost
Copy link

@ghost ghost commented Dec 29, 2016

Why was it closed? I think it's still not published in F-Droid.

So what's next on the agenda to make it publishable on F-Droid?

Edit: sorry! @someoneEsle is right. I saw the closed badge of #411 and thought it was for this issue.
When I asked for the status, sure I did read the message from @hakonbo but didn't got it, why it seemed like the work on this issue stopped.

@grote
Copy link

@grote grote commented Dec 31, 2016

@bastoGrande the issue is still open and the current status has been posted right above your message.

@someoneEsle
Copy link
Contributor

@someoneEsle someoneEsle commented Dec 31, 2016

@grote when @bastoGrande asked "why was it closed" I think he was talking about the PR introducing free build types: #411

@varac
Copy link

@varac varac commented Jan 5, 2017

Looking forward to an fdroid package! Please continue with your efforts!

@TomSea
Copy link

@TomSea TomSea commented Jan 21, 2017

Yes. Please make wire as an fdroid package. Thanks!!!

@h-2
Copy link

@h-2 h-2 commented Mar 27, 2017

I am posting a 50€ bounty for someone who creates a version of the Android Wire client that fully meets F-Droid’s criteria, i.e. no proprietary dependencies. Preferably the changes would also meet upstream’s criteria for integration into the official repository, e.g. via a Flavor or build flag or something like that.

I can send the money via Paypal or WireTransfer/SEPA.

edit: timeframe: for this bounty there should be some alpha/beta version until 2017-02-01

Signal now works well with Websockets and is available as APK, but not in F-Droid so I am renewing this pledge until 2017-07-01!

@fungs
Copy link

@fungs fungs commented May 3, 2017

Yes, I'm also waiting for Wire to get fully open (FDroid build support) before I can convince my contacts to switch from Signal/LibreSignal to Wire. It would be nice for all of us who do not use Google apps on our phones.

@mxmehl
Copy link

@mxmehl mxmehl commented May 11, 2017

I am posting a 50€ bounty for someone who creates a version of the Android Wire client that fully meets F-Droid’s criteria, i.e. no proprietary dependencies. Preferably the changes would also meet upstream’s criteria for integration into the official repository, e.g. via a Flavor or build flag or something like that.

Signal now works well with Websockets and is available as APK, but not in F-Droid so I am renewing this pledge until 2017-07-01!

I add another 50€ to @h-2's pledge, same timeframe and same conditions.

It would be awesome to have Wire in F-Droid!

@Gardosen
Copy link
Contributor

@Gardosen Gardosen commented Mar 2, 2020

Update Week 10(2nd of March): I closed two tickets, related to this topic, so we have one ticket as the source of truth about it.

OpenPush will be discussed internally this week.

Kind regards
Marco from the Android team

@genodeftest
Copy link

@genodeftest genodeftest commented Apr 18, 2020

In theory, the rfc2822 F-Droid repo should contain the Wire APKs. However, the download link broke because Wire's version numbering changed (bug report). It would be nice if you could fix that.

@12people
Copy link

@12people 12people commented Apr 20, 2020

@Gardosen How did the internal discussion go? Any plans on incorporating OpenPush?

@android10
Copy link
Contributor

@android10 android10 commented May 7, 2020

@12people and the rest, sorry for the late reply. At the time being there are no plans to address this. Unfortunately we are suffering from other issues that are higher priority. In any case, we will keep you posted if anything changes in the mid term.

Thanks for the patience.

@genodeftest
Copy link

@genodeftest genodeftest commented May 7, 2020

You may just add the rfc2822 F-Droid repo to F-Droid, it also ships the Wire app. The issues I mentioned a few weeks back have been fixed.

@zabbal
Copy link

@zabbal zabbal commented May 7, 2020

You may just add the rfc2822 F-Droid repo to F-Droid

No you can't:

The APKs are unaltered and hence still signed by the app developers.

So the Wire installed from that repo will still rely on proprietary FCM and won't work for lots of phones. The point of this ticket is not to automate manual .apk download step, it's to uplift Wire to the same code quality standards which are used by other secure chat apps in f-droid.org repos, like Telegram for example.

@zabbal
Copy link

@zabbal zabbal commented May 7, 2020

On a positive side, with the introduction of E2E to Riot and other Matrix clients this issue might become obsolete in a foreseeable future :)

@stephenjudge
Copy link

@stephenjudge stephenjudge commented May 7, 2020

I understand @zabbal point, however it doesn't look like Wire will ever buy in a position to replace the FCM dependcy and to be fair to Wire, they have pivoted aware from being a consumer client and are now focused on corportate solutions, so bring Wire to the F-Droid Repository is not going to be a very high priority for them.

If they cannot replace their FCM dependecy, then I would suggest that the best middle ground solution would be for them to host their own F-Droid Repository using the F-Droid Repomaker https://f-droid.org/en/repomaker/. This allows them to be in control of how their app is distrubted using the F-Droid app, rather than relying on third-party repositories like rfc2822 or Izzy's Repo.

@colans
Copy link

@colans colans commented May 7, 2020

On a positive side, with the introduction of E2E to Riot and other Matrix clients this issue might become obsolete in a foreseeable future :)

Just to add more perspective to that thought, I've been using Riot.im/Matrix.org for a couple of years now, having dumped Wire a while ago (mostly due to wireapp/wire#160). E2EE was in the Matrix protocol before, but the UX recently got better (yesterday, in fact).

@strypey
Copy link

@strypey strypey commented May 8, 2020

@stephenjudge

Wire ... have pivoted aware from being a consumer client and are now focused on corportate solutions

This is a red herring. If a corporate user chooses Wire over a proprietary chat app (eg WhatsApp or whatever Goggle calls their "enterprise" chat apps these days), it's because they care about security. Therefore they are just as likely as anyone to want a client that meets the requirements for inclusion in the F-Droid repo. With E2EE now being on by default in Riot, If Wire don't prioritize F-Droid inclusion, and rolling out support for server<>server federation (see wireapp/wire#160 (comment) ), they might find the corporate users they want as customers starting to use Matrix via Modular.im instead.

@2011
Copy link

@2011 2011 commented Jul 20, 2020

Just to add a comment to this thread so I can find it again...

The about page on the web site states "We put security and privacy first..." I don't see how Wire can make that claim (regarding privacy, not security) when Google gets a timeline of all received messages (via FCM) for the Android app, and would likely have no problem determining the identities of two or more people (all using Android) communicating with each other (in a real-time text chat, for example).

@tuxayo
Copy link

@tuxayo tuxayo commented Jul 22, 2020

have no problem determining the identities of two or more people (all using Android) communicating with each other (in a real-time text chat, for example).

I'm not sure how much users&messages traffic are needed to make such an attack impractical. That would be interesting to explore. IMHO, not much. I don't know how much of the 1.000.000+ install have daily activity but seeing only the GCM traffic should be terrible mess to match to user.
Responding quickly to the other is also important to help the attack.
And it's only for the receiver that gets a GCM push which makes matching harder.

@strypey
Copy link

@strypey strypey commented Jul 22, 2020

@tuxayo

I'm not sure how much users&messages traffic are needed to make such an attack impractical.

Doesn't that rather depend on the nature of the attack? What @2011 is saying is that GCM is leaking metadata. Let's not forget that fomer government spooks have made public comments about killing people based on metadata. While that's unlikely to be part of the threat model for a corporate client, it seems wise for Wire engineers to do everything they possibly can to reduce the amount of metadata that Wire leaks.

@codedust
Copy link

@codedust codedust commented Aug 18, 2020

More importantly, the closed-source libraries to use GCM need to be included in the Wire apk. This ruins the high mark of confidence of the Wire app not being able to bypass e2ee that is introduced by releasing the source code of the app. Only if the app can be build without any proprietary Google library, full trust in the app can be established.

@zabbal
Copy link

@zabbal zabbal commented Dec 21, 2020

https://github.com/threema-ch/threema-android - given the recent news on Threema going Free (as in Freedom) way I think this issue can be closed once threema appears on f-droid.org

@grote
Copy link

@grote grote commented Dec 21, 2020

Does not look like Threema is (fully) Free Software though: https://github.com/threema-ch/threema-android/blob/main/app/build.gradle#L384-L392

So it won't appear in F-Droid anytime soon.

@zabbal
Copy link

@zabbal zabbal commented Dec 21, 2020

Given that this issue will soon meet half-decade jubilaum, I'm prepared to use more relaxed definition of "soon" in this case.

@SailReal
Copy link

@SailReal SailReal commented Jan 30, 2021

Related to Threema: With this ugly hack I dropped all proprietary libs and code related to it SailReal/FOSS-threema-android@ade0176 ... feel free to use it :) . On my phone with GrapheneOS this works perfectly.

I will re-implement it using a build flavor to push it to the upstream repo and Threema said that they will accept this contribution but it will take time so feel free use the fork for time being.

@est31
Copy link

@est31 est31 commented Jan 31, 2021

@SailReal this is a thread about the Wire app. There is a dedicated thread for Threema's inclusion on the f-droid RFP tracker: https://gitlab.com/fdroid/rfp/-/issues/1596

Edit: also, much appreciated that you work on this :).

@nidico
Copy link

@nidico nidico commented Aug 11, 2021

FYI: Wire is looking to hire someone to bring the app on F-Droid: https://forum.f-droid.org/t/wire-on-f-droid/14374

@obfusk
Copy link

@obfusk obfusk commented Sep 1, 2021

FYI: Wire is looking to hire someone to bring the app on F-Droid: https://forum.f-droid.org/t/wire-on-f-droid/14374

I started working on that today :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet