-
-
Notifications
You must be signed in to change notification settings - Fork 420
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
[Feature request] Release on crates.io #490
Comments
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? |
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. |
I would really love to see However, I feel like @jrose-signal really has a point with Debian packages, and I don't see it very fitting either. |
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. |
Any update? Or are you not going to release it? |
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. |
Thanks for your insight. I believe if you decide to make it happen, publishing |
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. |
I'm also interested in a crates.io release, but maybe at the same level as the APIs for the other languages. Essentially, I have an idea for an application that I'd like to build for mobiles, and would like to have Signal's E2EE encryption. Since it's just little old me working on this, I'd love to be able to feed two birds with one scone and build it using Tauri which says it has cross-platform support for mobile devices. That means I could likely build nearly everything in Rust, which is currently my wheelhouse 😁 If not, maybe I could use the TypeScript API, but it would be great to keep as much of it in Rust as possible. |
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
The text was updated successfully, but these errors were encountered: