Policy for outdated packages

[ShalokShalom]

Issue description

Currently, it seems that outdated packages with known security issues are the default choice for some people.

Mono, as an example:

The repo is full of versions and exactly the oldest from 2015 is the default.

Packages like FSharp build on it.

Someone in the IRC said it is the common policy, that the attribute without any version number added to its name is that one "which we are the least scared to use"

I really hope that you are scared by an unmaintained software from 2015.
Otherwise, I am.

[matthewbauer]

In general, I would say the policy should be to always use the latest version (even if things break). Some people disagree, but with release channels every 6 months, hopefully they will get more comfortable with breaking things.

Usually things like this get out of date when we don't have an active maintainer for it. Things like Haskell and Python have extremely active maintainers but Mono does not (but we're always looking for new maintainers).

As a side note, if you do know of any confirmed vulnerabilities in Mono or really anything else, please make a PR adding "meta.knownVulnerabilities" array with an identifier and a description of the vulnerability. I will gladly merge any PR doing this very quickly! We definitely want to be as secure as possible.

[ShalokShalom]

Well, if you want to be secure as possible, you have to find a way to automatically flag unmaintained software.

My proposal: Send a mail to x, when the CI breaks and after one month no change?

[matthewbauer]

For reference, you are referring to this Mono bug:
http://www.mono-project.com/docs/about-mono/vulnerabilities/#string-to-double-parser-bug
correct? I will look into switching us from defaulting to mono40 to mono58 (with some overrides for legacy software).

Hydra used to email when packages broke but I think this has been disabled for some reason. For something like Mono, it will rarely break on Hydra - but that doesn't mean it's not insecure. Vulnix is what we use to identify vulnerabilities and it catches most things.

[ShalokShalom]

To be honest, when a software is unmaintained since years, it is very likely that there are security issues with it.

One guy in the IRC said Hydra broke on Mono one month ago, this is what I was referring to.

I suggest an outdated repo, where those packages get transferred automatically once broken on Hydra and untouched afterwards for a specific period of time.

I suggest one up to two months

Then one mail again to the maintainer and one notification into the IRC, that the package is moved now.

What is your opinion?

[7c6f434c]

I think the packages that I do expect to work correctly often do not have upstream releases every two months.

If outdated repo is implemented I will use only it and that's where I will update LibreOffice.

Of course, your point about having a much fresher upstream release packaged but not default for a long time is a very good point…

[ShalokShalom]

I talk about packages which are broken and edited my text to reflect that

[7c6f434c]

Yes, but your definition of broken includes:

Once a package is unmaintained, it could be considered as broken after a while.

[ShalokShalom]

Yeah, I mean once its unmaintained and broken, I changed the text now, thanks for your eye, my mistake :)

[7c6f434c]

Ah, that does sound nice.

The problem with Hydra notifications was that creating a new jobset (like release-18.03) results in notifications to basically everyone (commits since last build = the entire history of repository).

[ShalokShalom]

Does this mean everyone gets a new notification in that process, anyway how you configure Hydra?

The notification could be send via another software. One that is coupled on the service which moves the packages?

[xeji]

I suggest an outdated repo, where those packages get transferred automatically once broken on Hydra and untouched afterwards for a specific period of time.

I would prefer to mark defective packages as broken by setting meta.broken = true; instead of a separate repo. But I don't think this should be an automated process.

[ShalokShalom]

Yeah, does that remove them from the online package viewer and the command line query?

~~

I am in a distribution that is always up to date and always very stable, I never experienced a single broken package within a few years and that feeling of 'it just works' is very valuable, imho.

So I think that a time frame of one up to two months is already very long.
If something blocks the temporary removal any longer, I dont see much sense in this, really.

The packages in the repository are supposed to be stable and useful, what is the exact reason to keep packages in it, which are known to be defective?

[xeji]

Yes. And you can still override this in you user environment to try and install broken packages.

[ShalokShalom]

Thats awesome.

[matthewbauer]

Closing because there’s nothing really actionable. Documentation PRs are always welcome though.

[ShalokShalom]

Ähm, you missed this point:

I would prefer to mark defective packages as broken by setting meta.broken = true; instead of a separate repo.

Do this automatically.

[Ekleog]

@ShalokShalom What exactly do you mean by “broken”? I don't see how we could automatically set meta.broken = true for not-updated-for-a-long-time packages -- for instance, the last release of perl (which I guess we can agree should not be marked as broken) is ~a year old.

[7c6f434c]

@Ekleog as far as I understand, the automatic part is about packages that have 100% failure rate on Hydra for, say, a month (and maybe at least 10 last builds) and do not receive any commits in this time.

[stale]

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.