search

Turasa / libsignal-service-java

GNU General Public License v3.0
37 stars 21 forks source link

Debian GNU/Linux packaging #13

Open ghost opened 6 years ago

ghost commented 6 years ago

Hi @AsamK,

I would like to package libsignal-service-java for Debian GNU/Linux. My primary motivation is because it is a dependency of signal-cli.

A few simple things would greatly help moving forward:

Thanks in advance for your help and even more for your persistent work to maintain this library !

paride commented 6 years ago

@dachary Just for your information. I don't know if you intend to package signal-cli or perhaps Signal-Desktop, but keep in mind that @moxie0 opposed the third party distribution of software using the official Signal service and using the OWS/Signal trademarks. This is basically the reason why there is no Signal client on F-Droid.

ghost commented 6 years ago

@parid oh, thanks for the information ! Do you have a reference to a public statement about this trademark enforcement ?

ghost commented 6 years ago

For the record, here are the commits unique to Turasa (i.e. not in the upstream) : https://github.com/signalapp/libsignal-service-java/compare/master...Turasa:master

paride commented 6 years ago

A couple of pointers:

https://cloud.githubusercontent.com/assets/1433926/9705240/83886c9c-54be-11e5-867a-458f24bf9b6a.png

https://github.com/LibreSignal/LibreSignal/issues/37#issuecomment-217211165

but you'll find very long discussions about the issue here on GitHub. Dig into the closed issues.

ghost commented 6 years ago

@paride thanks, much appreciated :100: Reading more.

ghost commented 6 years ago

Is there a text version of https://cloud.githubusercontent.com/assets/1433926/9705240/83886c9c-54be-11e5-867a-458f24bf9b6a.png somewhere ? I'd like to quote it and assert the publication date.

So far my understanding is that:

a) moxie threatened in 2016 to enforce the "signal" trademark against some forks but did not actually do it. His motivation was to prevent forks connecting to the servers operated by Open Whisper Signal. b) there has been no threat since nor any legal action against the numerous forks of the Open Whisper Signal code that are distributed world wide and carry the name "signal"

How far am I from reality ? Thanks for your patience: I'm eager to learn but very new to this old controversy ;-)

ghost commented 6 years ago

For the record, the "intent to package" post in Debian GNU/Linux is at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890915 and some discussion about licenses and trademarks is also likely to happen there.

paride commented 6 years ago

I don't know if you can still get a text version, try digging in moxie's or @xmikos' Twitter accounts. I'm not familiar with Twitter.

I recall, at some point, moxie threatening legal action and xmikos consequently renaming his forked client. But I could be wrong.

What I suggest you is: try to get a statement from moxie. Is him happy with Debian distributing unofficial clients for his service? After all, this is what the Maintainer's Guide suggests:

You should contact the program's author(s) to check if they agree with packaging it and are amicable to Debian. It is important to be able to consult with the author(s) in case of any problems with the program, so don't try to package unmaintained software.

ghost commented 6 years ago

What I suggest you is: try to get a statement from moxie.

This is a wise advice, I'll do that now !

ghost commented 6 years ago

Dear Turasa/libsignal-service-java maintainer(s),

I intend to package libsignal-service-java for Debian GNU/Linux and it would be great if you could let me know how you feel about it. Quoting the maintainer guide:

You should contact the program's author(s) to check if they agree with packaging it and are amicable to Debian. It is important to be able to consult with the author(s) in case of any problems with the program, so don't try to package unmaintained software.

Note that I already asked the maintainer of the signalapp/libsignal-service-java repository the same question. They thanked me for the initiative but were not interested in having that kind of conversation, reason why I'm asking you. You distribute a well maintained fork and have done so consistently over the a long period, you are a good upstream from a packaging point of view. I do not expect to have many questions or request, don't worry :-)

Please kindly let me know what you think and thanks for a great service to the Free Software community

Trolldemorted commented 6 years ago

What are the benefits of distributing it as a debian package?

ghost commented 6 years ago

What are the benefits of distributing it as a debian package?

@Trolldemorted given your nick I feel obliged to ask, is this a troll question ? ;-)

Trolldemorted commented 6 years ago

No, this really is a genuine question.

I understand that compiled shared objects should be placed in the loader's path so that you can save disk and memory space, but does that apply to jars as well?

ghost commented 6 years ago

@Trolldemorted the benefit of distributing this library as a package is that it allows developers to rely on it when developing applications or other libraries. If a package is not available, the developer who wants to use libsignal-service-java needs to rely on other distributions channels to get it. It is the same rationale that drives people to package https://packages.debian.org/stretch/libbcprov-java for instance.

GNU/Linux distributions such as Debian or Ubuntu rely on a form of packaging that is different from gradle (for instance) or pip (for python). It is required when building a Debian package that it does not pull resources from the network, other than the official repositories. That ensures the distribution is self contained and is a stable and controlled environment, with security patches.

Another benefit is that some distributions such as Tails https://tails.boum.org/ welcome packages that are already available in Debian GNU/Linux. It would be much more difficult to propose new software if it was not packaged for Debian GNU/Linux.

Does that answer your question ?

Trolldemorted commented 6 years ago

Thanks for the elaborate response! I am not sure I understand you completely though, but I am far from what you would call an expert on linux' many package managers.

I don't think you can compare libsignal and libbcprov. If I understand libbcprov's rationale correctly, it modifies the installed java runtime environment (so for all processes on your system) to insert its own security provider.

Would you do the same with libsignal, and with all of libsignal's dependencies? If yes,

If no,

Will you release a deb package for every libsignal version, and deb packages for every version of every dependency of libsignal, and maintain all of them with security patches and bugfixes?

I hope you don't mind my nagging, but I have seen debian packages being completely broken for months, so I may have a tainted and overly pessimistic view on the ecosystem. But apart from debian otherwise declining signal-cli because of their "thou shalt have use other build tools" requirement I still see no benefit, most if not every developer is going to use maven or gradle.

ghost commented 6 years ago

did you ask libsignal's dependencies' authors?

It appears I've been fooled by the fact that build.gradle does not display any dependency. How can I figure out the list libsignal-service-java dependencies ?

I hope you don't mind my nagging,

On the contrary ! This is very welcome at this stage :-) While nothing is committed. It would be much more difficult to re-consider the risks after packaging is done. This needs to be sustainable.

Trolldemorted commented 6 years ago

You can find libsignal-service-java's dependencies here and signal-cli's dependencies here.

Since you want to distribute signal-cli in the long run, here is the content of signal-cli's lib folder:

argparse4j-0.7.0.jar
bcprov-jdk15on-1.55.jar
commons-codec-1.9.jar
commons-logging-1.2.jar
curve25519-java-0.3.0.jar
dbus-java-2.7.0.jar
debug-1.1.1.jar
hexdump-0.2.1.jar
httpclient-4.4.jar
httpcore-4.4.jar
jackson-annotations-2.5.0.jar
jackson-core-2.5.0.jar
jackson-databind-2.5.0.jar
libphonenumber-8.3.0.jar
okhttp-3.6.0.jar
okio-1.11.0.jar
protobuf-java-2.5.0.jar
signal-cli-0.5.6.jar
signal-protocol-java-2.5.3.jar
signal-service-java-2.5.11_unofficial_1.jar
unix-0.5.1.jar

Additionally, I fear that each of these jar files could contain classes from "hidden" dependencies which were added with obscure hacks in the building process.

Where and how would you deploy signal-cli and its dependency zoo? Would you alter signal-cli so that it loads the deps from the locations you specify? How are other java applications with dependencies dealing with this situation?

AsamK commented 6 years ago

@dachary

I'm not developing new features for this library, but I'll keep updating it to the latest upstream versions, for the foreseeable future. Packaging all dependencies could be a problem, but I don't have time to help with that.

ghost commented 6 years ago

I have no problem with this library being packaged for Debian I'll keep updating it to the latest upstream versions, for the foreseeable future.

That's good enough for me, thank you :-)

ghost commented 6 years ago

@Trolldemorted thanks, I missed the file in the java directory. The following are not packaged for Debian GNU/Linux as far as I can tell:

The versions of the existing packages must also be verified to match the requirements. I just checked their existence.

Additionally, I fear that each of these jar files could contain classes from "hidden" dependencies which were added with obscure hacks in the building process.

Right!

Where and how would you deploy signal-cli and its dependency zoo?

Once the zoo is complete (that's a total of 8 packages to deal with), installing signal-cli would be done via apt-get install signal-cli and it would pull all dependencies from the Debian GNU/Linux mirrors.

Trolldemorted commented 6 years ago

You are indeed correct, deps like argpars4j already have corresponding java packages - nice!

I meant where and how will be deployed on the target system. I have never seen java deps being installed by aptitude, so I am curious how it supports depending on different versions of the same dependency. Will every required version of dependency foo be deployed to /usr/lib/foo/X.Y.Z and you fix the consuming program's classpath to use the right one?

ghost commented 6 years ago

A typical example would be https://packages.debian.org/stretch/libphonenumber7 which should be packaged as libphonenumber8 since this version is presumably not API compatible. But I'm not sure about how the paths are set to not be mixed up.

ghost commented 6 years ago

@Trolldemorted @AsamK after thinking about it a little more I don't think I'm able to effectively support packaging libsignal-service-java in the long run and closed the intent to package with explanations.

I hope someone braver than me will take that challenge in the near future. To that end it may be a good thing to keep this issue open.

Thank you both for your insights and advices. And even more for your continuous support to the world of Free Software :-)

seandiggity commented 5 years ago

I'm actively recruiting volunteer devs for a native Signal / Signal-like client in Gtk, in the hopes that we can bring it to the Purism Librem 5 phone. Please contact sean.obrien@puri.sm if interested. PGP/GPG: FA9D 40F1 5FE1 D8AB 8312 4AAA 77E3 1447 CD1F C3F6

@ghost I'm especially interested in the dependencies situation for signal-cli... we do package our own apps for PureOS at Purism and it's possible we can package and support libsignal* packages. Though, of course, getting them in Debian is preferable.

wookey commented 2 years ago

I've just read this thread as I need a linux signal client on debian and upstream only provide binaries for amd64. I have an ARM machine. I also have a linux phone so the android and iOS binaries are not much use either. The resistance of upstream to 3rd-party suppliers seems to remove much of the advantages of it being free-software in the first place. It excludes anyone on a less-common platform and makes it almost impossible for them to help themselves. I am a debian developer and thus willing and able to help anyone who is attempting to package this stuff. I've packaged a fair amount of java stuff in the past.

The multi-architecture support is one of the the things you get from distro packaging which is not mentioned above. That particular consideration is more relevant to the signal-desktop software than this libsignal-service-java, but equally non-developers and admins don't want a pile of maven-generated software on their machines (which seems to be the only sanctioned way of getting the signal java stack installed/built?) - they want a set of packages which can be removed as well as installed cleanly. Can I please encourage someone to package this despite the unhelpful upstream? It is useful software. I would love to encourage people off WhatsApp onto signal but at least in my case it's not even installable.