Removal of insecure "steghide" package

Development Security
1

Hi,

I’d like to get some clarifying hints on what to do with the “steghide” package. See Vulnerability roundup 100: steghide-0.5.1: 1 advisory [7.5] · Issue #116923 · NixOS/nixpkgs · GitHub for details.

The package got an CVE advisory which basically states that it does not hide stuff as effective as it promises to do. Since the package has not seen upstream activity for 8 years, I suspect that there will be no bug fix. It does not have an nixpkgs maintainer either. I’d suggest to remove it altogether.

How to proceed? Please comment on:

  • Add knownVulnerabilites meta attribute to 20.09? unstable?
  • Remove it completely from unstable?
  • Remove it from unstable after the next branch-off so that it will remain in the next release?
  • If so: How do we make sure that we don’t forget it as there is no maintainer?

Cheers, Christian

2 Likes
2

My vote is to remove it from unstable right away.

4 Likes
3

I agree, should be removed from unstable as soon as possible.

4

To be fair, I only encountered people using steghide to make challenges in cybersecurity events.

I vote for the first option and/or to mark the package as broken?

2 Likes
5

are we hackers yet?

https://jjjollyjim.github.io/arewehackersyet/index.html

having lots of broken packages in nixpackages not only looks bad from a PR point of view, but even if it doesn’t get built by hydra, the nix evaluations get bigger.

If it’s not in nixpkgs, there probably more scope to to add it.

retiring libraries and things that depend on just one top level application might be a different case.

so it’s either play the package numbers vanity game, or have have as many high quality working packages as possible?

i’m not sure what it is best.

and what is broken anyway? it doesn’t actually compile? it’s a securtiy risk? the code is dead, unmaintained and is useless :-(… maybe ‘broken’ needs more definition?

6

There we go:

3 Likes
7

We removed it. If someone wants to pick up maintainership and stick it back in with appropriate vulnerability notices, go for it.

8

This is definitely an old issue, and ignoring the necrobump, I’m wondering what the appropriate way to deal with this kind of thing is: maintaining copies of old/broken packages. I agree that these shouldn’t be in nixpkgs, especially if we’re trying to have a good repository of vetted packages.

Looking back at the list of packages on the aforementioned “are we hackers yet?” list, if most of these are broken or vulnerable, and even just maintained by Debian with minor bugfixes, I’m not sure the goal should be to get all of those packages added to nixpkgs.

Is this something better provided by a separate overlay, with warnings and vulnerability notices? I ask because having done those kind of security challenges, having the toolkit of Kali has been invaluable, even if the tools are themselves insecure.

9

One of the reasons flakes are so interesting to me right now, if it can’t go into to the mono-repo nixpkgs, then someone can make a flake for it and have that as an option.

Flakes really make a for a ‘policy free’ way of getting packages onto your system.

interesting times!

1 Like