No decompilers when using OBS version

[Tachi107]

Environment information

• Operating System: Debian Testing
• Cutter version: 2.2.0
• Obtained from:
  • Built from source
  • Downloaded release from Cutter website or GitHub
  • Distribution repository
  • Official OBS repository

Describe the bug

When installing Cutter via the official OBS apt repository, no decompilers are available.

To Reproduce

Steps to reproduce the behavior:

1. Add the Debian Testing OBS repository
2. Install the cutter-re package
3. Open any random binary

Expected behavior

When using the official OBS repos, the Ghidra and jsdec decompilers should be available out of the box, just like when using the AppImage.

Screenshots

Additional context

This is my first time using Cutter, so please keep in mind that I'm a complete newbie!

Thanks for your work :D

[ret2libc]

This is known :( I think I'd prefer to fix this by improving rz-pm so that you can install it that way instead of complicating the OBS builds.

@Tachi107 would it help if you could install the decompiler plugins through rz-pm?

[Tachi107]

Hi, thanks for the reply! I prefer to use my distro's package manager when possible, and anything else is the same for me; I can also use the AppImage without issues.

Is it possible to install the decompiler plugins separately?

Lastly, since I maintain a couple of packages in Debian I may be able to help here; if you can point me to your OBS' configuration files I could look into adding a new cutter-re-plugins package which contains the exactly what you'd expect. Does it make sense?

[ret2libc]

@Tachi107 that would be awesome!! Even more so, it would be great to have these packages directly in the official Debian/Ubuntu repos. OBS is a bit of a way around that TBH.

https://build.opensuse.org/project/show/home:RizinOrg

[XVilka]

@Tachi107 that would be awesome!! Even more so, it would be great to have these packages directly in the official Debian/Ubuntu repos.

Absolutely agree, maybe you could ping corresponding package maintainer as well - Cutter version and naming is outdated in Debian (and Ubuntu respectively): https://repology.org/project/cutter-re/versions

Instead of radare2-cutter it should be cutter-re like in many other distributions.

[Tachi107]

Yeah, Cutter is in Debian already, but as far as I can tell it is the old radare2-based version.

According to https://bugs.debian.org/950372 there has been a bit of drama around radare2 in Debian, and that's probably the main reason for its poor packaging state.

It already looks like it is the case, but would things be different for the new Cutter and Rizin?

[XVilka]

I made a new bug about the rename and update: https://bugs.debian.org/1036923

[Tachi107]

Hi @XVilka, I'd be willing to look into this, but I'd first like to be sure that you (upstream) really are ok with packaging Cutter in Debian.

If the package gets shipped in a stable release (e.g. Debian 12), the version will remain the same during the whole Debian 12 lifecycle (a couple of years), minus bug fixes and security updates. Would you be OK with this?

Some upstreams like MbedTLS are so kind to even ship LTS releases that we (distro developers) can trivially use in stable releases.

[XVilka]

There is one tricky thing about packaging Rizin/Cutter/rz-ghidra/etc - the dependency on capstone. Recenly we invested quite some effort in updating capstone for many architectures, to support all newest opcodes for ARM, PPC, MIPS, etc via the so-called "auto-sync" project, synchronizing the Capstone code with the LLVM via some automation. While the 5.0 version of the capstone library is almost out, with Tricore architecture added, the ARM, PPC, MIPS (and possibly some other architectures) will not make it into 5.0 and will be a part of the next release - 5.1 or 6.0, whichever they decide to do. Rizin, as a base for Cutter, will tie itself to this new Capstone, due to the many missing opcodes and errors in all previous versions, also with some new architectures supported. This whole effort will be a part of the Rizin 0.6.0 and Cutter 2.3.0 upcoming releases which will not happen in 3 months even though.

[Tachi107]

That doesn't look like an issue for me. If Debian ships e.g. libcapstone 5.0 then we'll just package the latest Rizin version targeting that capstone version.

Does it make sense? Or did I misinterpreted your comment?

[XVilka]

@Tachi107 No issue, you are right — just a thing to remember during the packaging since Rizin is sensitive to the capstone version. We, the RizinOrg team, discussed this today, and we are OK with Rizin and Cutter being packaged in Debian with not being updated during the release life, except for bugfix releases.

[XVilka]

Moreover, as we are working on the next release in the upcoming months, let us know if you meet some bug/issue/problem/patch during the packaging so that we can integrate it mainstream for the next release. We have documents for packagers:

• https://github.com/rizinorg/rizin/blob/dev/doc/PACKAGERS.md
• https://cutter.re/docs/building.html#making-linux-distribution-specific-packages

Let us know if you find this documentation missed something.

[XVilka]

To ping you both @Tachi107 and @ret2libc - Rizin 0.7.1 and Cutter 2.3.4 are out, it would be nice to update/package them.

[Tachi107]

Hi Anton, thanks for the ping! Unfortunately I've stopped using Cutter due to some unfortunate events regarding my rev journey, and I'm not directly interested in packaging it anymore. A friend of mine will start its RE journey in a bit though, so I might use that as an excuse to package the program - I make no promises though ;)