Skip to content
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

limesurvey: mark as insecure #111218

Merged
merged 1 commit into from Jan 30, 2021
Merged

Conversation

dotlambda
Copy link
Member

@dotlambda dotlambda commented Jan 29, 2021

Motivation for this change

closes #101163

https://github.com/LimeSurvey/LimeSurvey/blob/3.x-LTS/docs/release_notes.txt lists many security fixes that our version is lacking.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.

cc @offlinehacker @davidak @aanderse

@aanderse
Copy link
Member

@dotlambda I'm under the impression this software hasn't really been maintained in nixpkgs for many years now... we might simply consider removing this package and the module 🤷‍♂️

I'm good either way.

@dotlambda
Copy link
Member Author

@dotlambda I'm under the impression this software hasn't really been maintained in nixpkgs for many years now... we might simply consider removing this package and the module

I'm good either way.

You're right, that's the cleaner solution. Let's wait for @davidak to chime in and tell us whether he plans to finish his work on upgraded limesurvey.

@davidak
Copy link
Member

davidak commented Jan 30, 2021

I don't have time to upgrade or maintain it.

It is the best free software for the task, so it would be valuable to keep it.

In general, i don't like when we remove packages. Someone has put work into it. We should always try to find a new maintainer first. I think there aren't formal rules for that yet.

I will try do find a new maintainer.

Copy link
Member

@davidak davidak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment on lines 41 to 42
"CVE-2020-11455"
"CVE-2020-11456"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not against marking this package as insecure, but I am not clear on whether:

  • These particlar CVEs are not fixed in the version that we currently have; our current version seems to be from the LTS branch after these CVEs;
  • or whether the CVE bounds of Repology are too greedy (since they mark every version <= 4.1.11 vulnerable).

We should not put CVEs in this attribute that the current version is not vulnerable to.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it was a topic in the last update issue that it is not really visible if it is vulnerable and we would have to ask the projects maintainers.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could write

knownVulnerabilities = [
  "Unauthorized access to statistics of a survey with certain permission configurations"
  "Persistent XSS in browse response"
];

I got this info from https://github.com/LimeSurvey/LimeSurvey/blob/3.x-LTS/docs/release_notes.txt.

Copy link
Contributor

@danieldk danieldk Jan 30, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dotlambda: Sounds good.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it was a topic in the last update issue that it is not really visible if it is vulnerable and we would have to ask the projects maintainers.

Indeed, I tried to go through the commit history, but it's very hard to what is addressed both in the commit logs and in the release notes.

@danieldk
Copy link
Contributor

In general, i don't like when we remove packages. Someone has put work into it. We should always try to find a new maintainer first. I think there aren't formal rules for that yet.

By keeping around packages that are unmaintained, we set the the wrong expectations and expose unknowing users to known vulnerabilities (which is at least solved by marking the package insecure).

@dotlambda
Copy link
Member Author

I think we have two sensible options:

  • update to 3.25.10 (shouldn't be too hard) or
  • remove the package because it is not maintained.

@davidak
Copy link
Member

davidak commented Jan 30, 2021

We should not keep around unmaintained, insecure or broken packages, but we should have a formal workflow to TRY to find a new maintainer.

@danieldk
Copy link
Contributor

We should not keep around unmaintained, insecure or broken packages, but we should have a formal workflow to TRY to find a new maintainer.

Let's mark it insecure until a new maintainer is found. I agree on needing a workflow.

@dotlambda
Copy link
Member Author

We should not keep around unmaintained, insecure or broken packages, but we should have a formal workflow to TRY to find a new maintainer.

I guess asking on discourse whether anyone is using this could be a first step.

@dotlambda
Copy link
Member Author

Let's mark it insecure until a new maintainer is found. I agree on needing a workflow.

If anyone needs the software, marking it as insecure will automatically make them step up and update it.

@danieldk danieldk merged commit 256eb05 into NixOS:master Jan 30, 2021
@dotlambda dotlambda deleted the limesurvey-insecure branch January 30, 2021 11:14
@dotlambda
Copy link
Member Author

backport: #111291

@nixos-discourse
Copy link

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/packages-looking-for-a-maintainer/5442/6

@TredwellGit TredwellGit added 8.has: port to stable A PR already has a backport to the stable release. and removed 9.needs: port to stable A PR needs a backport to the stable release. labels Aug 20, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Vulnerability roundup 95: limesurvey-3.23.7+201006: 2 advisories [6.1]
6 participants