Debian GNU/Linux packaging

[ghost]

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:

• I assume the license is GPLv3 because https://github.com/Turasa/libsignal-service-java/blob/master/LICENSE contains it. The README however claims it is AGPLv3 and this inconsistency was reported in 2017 upstream but not addressed. It is not a blocking problem: without more information the terms of the license prevail. I wonder if maybe you can shed some light on this specific issue ?

• The latest sources are packaged and downloadable from maven.com. It would be nice to have confirmation these are indeed the best source to download such sources. It looks like releases were made available via GitHub in the past but this is no longer the preferred way to publish them.

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

[paride]

@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]

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

[ghost]

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

[paride]

A couple of pointers:

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

LibreSignal/LibreSignal#37 (comment)

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

[ghost]

@paride thanks, much appreciated 💯 Reading more.

[ghost]

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]

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]

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]

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

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

[ghost]

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]

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

[ghost]

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]

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]

@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]

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,

• did you ask libsignal's dependencies' authors?
• are you sure you will not break other programs? What happens if a program depends on a different version of libsignal's dependencies, but the jre already contains libsignal's preferred version? Shared objects have sonames, has java anything similar? I thought java intends that each programm has its own classpath where it can maintain its own dependencies, and only the (backwards-compatible) standard library is supplied by the jre

If no,

• what will happen? Will the jars be deployed at a fixed location, and programs will have to adjust their java classpath accordingly?

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]

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]

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]

@dachary

• I don't have more information on the licensing, sorry.
• maven is indeed the preferred way, to get the versioned source code
  The github releases are created automatically from tags, that I haven't created for this repo
• I have no problem with this library being packaged for Debian

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]

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]

@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:

• curve25519-java-0.3.0.jar
• debug-1.1.1.jar but libmatthew-debug-java exists, not sure if they are API compatible ?
• hexdump-0.2.1.jar but libmatthew-debug-java claims to do something similar
• okhttp-3.6.0.jar
• signal-protocol-java-2.5.3.jar
• unix-0.5.1.jar

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]

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]

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]

@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]

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 [email protected] 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]

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.