Nixpkgs: angr

Created on 24 Aug 2019  路  20Comments  路  Source: NixOS/nixpkgs

Project description
angr is a python framework for analyzing binaries. It combines both static and dynamic symbolic ("concolic") analysis, making it applicable to a variety of tasks.

Metadata

packaging request

Most helpful comment

@jonringer angr dropped its support for Python2 on their latest major release: https://angr.io/blog/moving_to_angr_8/ .

Hence, it only works on Python3!

All 20 comments

I started looking into this, but it's taking some time. There are a lot of dependencies that need to be added in addition to angr.

Edit: It looks like @Pamplemousse already started packaging some dependencies.

I am currently working on angr, and I use NixOS, so I naturally started to write nix expressions for its components.

I have only submitted a PR for "external packages" (packages not developed by the angr developpers), but I already have the expressions working for the rest of the components (claripy, cle, pyvex, ailment, archinfo, and angr itself):聽see the branch angr of my nixpkgs fork.

This still needs a bit of work, especially around running the tests, but I am getting there!

I have been writing PRs, for packaging missing angr requirements into pythonPackages.
Some are being accepted, some are still pending; But unfortunately, some may not have their place in this repo: as per @jonringer's comment on #68428 .

I started wondering couple of weeks ago if I should not even put all my work for angr in a repo separated from nixpkgs (something like mozilla/nixpkgs-mozilla).
This would be much less troublesome to maintain (less load on nixpkgs, lower standards for custom packages), especially considering the poor state of their engineering practices (although they are deploying efforts to improve it).

However, I do not have time, nor the knowledge, to make such a repository; And it is very unlikely that the core angr team will do, as they have a very small user base using NixOS, and other engineering priorities.

And I still saw some value PRing things here, as a couple of more "general use" packages were missing.

In the end, I learned about NUR very recently, so that might be a path to explore to get the package available quickly, and leave time to make a solution the angr team can have more control on.

although angr looks like an active repo/community, unfortunately cooldict didn't really hit a standard bar with me. Another committer might disagree and feel fine with it, I just didn't :/

it should be easy enough to get a pipenv or virtualenv going, and use pip to install it though

@jonringer, I am not sure how to interpret your last statement:
You mean pip install it as part of the building of the angr package?

$ nix-shell -p python3Packages.virtualenv
$ virtualenv venv
$ source venv/bin/activate
$ pip install angr

FYI, angr updated its code not to be dependent on cooldict anymore: https://github.com/angr/angr/commit/aace252da92c78dcb9eb70e9bda9ceb2fe4aa17e .

I have started angr/nixpkgs!

As per the discussion above, it seems more pertinent to isolate the "home-developed" angr related packages into a dedicated repository, made available on NUR.

Packages for which I had a PR waiting in NixOS/nixpkgs, are already migrated.
Expressions for other angr components will follow.

As my development environment is a bit messy right now (using my fork, the normal nixpkgs, plus the new NUR repo in local), I will wait to have tidied a bit before sharing my nix expressions as examples in angr/nixpkgs.

Feel free to reach out if you have questions :)
Or to contribute by opening issues and submitting PRs!

Keep persevering @Pamplemousse, this looks really neat. (feel free to cc me on any new PRs you have for this)

@risicle Thanks for the support!

As discussed earlier, angr has found its place in NUR: https://github.com/angr/nixpkgs.
I will happily take feedback over there: I am still quite a beginner at Nix/Nixpkgs, so reviews would be extra helpful.
You are welcome to open issues or submit PRs for comments and proposals :)

And I have finally added angr to it! :tada:

@jonringer, @armijnhemel
Should this issue be closed as angr is available via NUR?

I'm not familiar with the package, but if it there's broad appeal, then i would say continue the good fight.

Most of my hesitation was around some of the dependencies which were unmaintained for over a year (such as cooldict, which was later removed as a dependency).

I would certainly appreciate having pyvex available to me in nixpkgs...

(same goes for archinfo)

@Pamplemousse I would try to upstream it to nixpkgs, my major concern is if it only works on python2, which according to pypi, it does not.

@jonringer angr dropped its support for Python2 on their latest major release: https://angr.io/blog/moving_to_angr_8/ .

Hence, it only works on Python3!

Thank you for your contributions.

This has been automatically marked as stale because it has had no activity for 180 days.

If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.

Here are suggestions that might help resolve this more quickly:

  1. Search for maintainers and people that previously touched the related code and @ mention them in a comment.
  2. Ask on the NixOS Discourse.
  3. Ask on the #nixos channel on irc.freenode.net.

I think if the PR was updated to the latest version, this is still applicable to be added to nixpkgs

TL;DR: I am going to stick with contributing to angr/nixpkgs, and won't spend time or energy trying to package angr (and its dependencies) here.


Because it's being "cutting-edge" by nature (developed in a academic research environment), I don't think it is worth trying to put angr (nor the dependencies the angr team develops - archinfo, claripy, cle, pyvex, etc.) in nixpkgs.

  • They have now a "fast" release cycle: they started doing a "stable" release every week, but slowed down lately (unsure why, but might be related to the fact that the process is not completely automated - so dependent on the workload of the core contributors);
  • Their definition of "stable" is... disconcerting: they often rely on non-stable features of their dependencies, or custom forks. See angr/cle#255, angr/cle#257 for recent examples of that;
  • They sometimes introduce dependencies that might not be up to nixpkgs expectations: a recent example is pyxbe (one maintainer, created recently, so hard to tell if it won't become stale).

Which means that updating the angr package would often requires repackaging dependencies, sometimes creating expression for custom forks.
Plus, if one wanted to keep up with their "fast" release cycle, it would imply a decent amount of maintenance here.

Quoting myself from a comment above, I believe NUR is more adapted.:

This would be much less troublesome to maintain (less load on nixpkgs, lower standards for custom packages), especially considering the poor state of their engineering practices (although they are deploying efforts to improve it).

This makes sense :-)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

copumpkin picture copumpkin  路  3Comments

teto picture teto  路  3Comments

rzetterberg picture rzetterberg  路  3Comments

edolstra picture edolstra  路  3Comments

lverns picture lverns  路  3Comments