search

signalapp / libsignal

Home to the Signal Protocol as well as other cryptographic primitives which make Signal possible.
GNU Affero General Public License v3.0
3.06k stars 362 forks source link

[Feature request] Release on crates.io #490

Open werdahias opened 1 year ago

werdahias commented 1 year ago

I intend to package libsignal for debian. This would require this crate being on crates.io. I'd appreciate it if you could publish it.

Cheers

jrose-signal commented 1 year ago

We can certainly consider releasing on crates.io, but I don't think the project is well-suited for a Debian package. As noted in the readme, we don't promise any support for use outside Signal; in particular, "all APIs and implementations are subject to change without notice". We maintain protocol compatibility across our range of currently supported clients, but that's all we guarantee. Combined with Debian's stringent update requirements that leads to packages falling behind their source projects, and you could pretty quickly have something that's no longer consistent with what Signal itself uses. Of course, libsignal can be used as a building block for other programs and protocols, but without compatibility promises updating from version to version has to be understood as a manual step, and making libsignal a standard Debian package dilutes that message somewhat. (It's also a little weird that that package wouldn't come from us, the Signal Foundation.)

Let's take a step back: what are you actually hoping to accomplish?

werdahias commented 1 year ago

I intend to package Flare in the long run ( a unofficial GTK Signal client). As it uses libsignal as dependency I'd need to package that first (debian policy calls for no vendored dependencies) . I agree that by the time libsignal would make it into debian stable it might be out of date/incompatible. But because Ubuntu pulls ~70% of the new debian packages in testing, it would be made available for a lot of endusers/developers.

gferon commented 1 year ago

I would really love to see libsignal on crates.io as it would allow us to publish crates that make use of it, and it's pretty easy to update and make sure everything stays compatible with the official Signal ecosystem.

However, I feel like @jrose-signal really has a point with Debian packages, and I don't see it very fitting either.

werdahias commented 1 year ago

The release on crates.io is somewhat separate from the package. A debian/ubuntu rust package provides the same files as in the repo, e.g. src/lib.rs. As in regards to possible API breaks: Since most of the users/possible developers in the debian ecosystem run some version of ubuntu because of the newer packages (or debian testing/unstable) I don't see this as a big issue.

werdahias commented 1 year ago

Any update? Or are you not going to release it?

jrose-signal commented 1 year ago

We're still considering, and it's only one priority amidst many. There are a number of things working against putting this on crates.io, such as the usual complexity around multiple crates and the dependence on forks of other crates (curve25519-dalek and boring).

libsignal-protocol on its own would be fairly suitable to crates.io as is, but that isn't necessarily what's being asked for here. The other crates are a little harder.

gferon commented 1 year ago

Thanks for your insight. I believe if you decide to make it happen, publishing libsignal-protocol and zkgroup only would already be really useful.

werdahias commented 1 year ago

If some crate depends on some fork, that will indeed pose an obstacle. From a quick glance some crates aren't depending on specific crates. Releasing just those would also help.