⏳ Document Release Policy

[adriens]

The problem

We are using privatebin and are realy hapy with it. I would like to applu governance on maintenance process, hence I would need to get the lifecycle policy about for example support strategy, end of life,...

The solution

Provide some guidelines , for example by providing a SECURITY.md like on the repo explaining clearly how users should maintain their instance.

For exammple, saying that each major version reaches its end of life as soon as a new major version is released.

Alternatives

Give the web page where it is documented.

Additional context

The main idea would to add it to https://endoflife.date/ (see the dedicated DEV.to series):

• ⌛ Manage EoLs like a boss with endoflife.date 🛑
• 🔁 Browse Neo4J EoL versions inside Neo4J AuraDB 🤓
• Kaggle dataset : ⏳ endoflife.date database (duckdb)

[elrido]

At the moment our policy in that regard is very simple: We only support the latest release as we have no capacity (in terms of maintainers) to handle multiple releases such as a long term supported one. This is indeed documented in our SECURITY.md file here in the repo:

PrivateBin/SECURITY.md

Lines 1 to 8 in eb59f3a

	# Security Policy
	## Supported Versions
	| Version | Supported |
	| ------- | ------------------ |
	| 1.7.1 | :heavy_check_mark: |
	| < 1.7.1 | :x: |

For vulnerabilities, there is one precedent where we provided a backport of the fix to the prior minor version. In other such incidents we did either provide a workaround that could get applied via configuration change to several prior releases or did try and identify and contact the affected instances' administrators.

We have and would still use the information visible publicly in the directory to assess how widespread a problem is. Should many instances affected by a problem still be on an older minor release, a code change to mitigate to problem necessary and not too difficult to backport, I would consider doing so. At the time of writing this, shortly after the 1.7 releases, there are for example still many instances with 1.6 and 1.5 out there, but only a handful of 1.4 ones left.

The part that is less clear to me is updates in our libraries. So far we had only one report of a vulnerability in one weakening pastes security. We do update as many of them as possible to the latest versions prior each of our releases, but so far have not considered any of them a reason for a backport. We really need someone looking into upgrading bootstrap, for example. Luckily that is mostly CSS, so while it makes the UI look dated, it's unlikely to affect us in terms of security.

[rugk]

An addendum:

The main idea would to add it to https://endoflife.date/ (see the dedicated DEV.to series):

Yeah sure, feel free to add it there/propose a PR there. If anything more than what we have (SECURITY.md) is needed for that, please let us know.

[adriens]

Awesome, thanks a lot for the kind and cool feedback @rugk 🙏

[adriens]

WIP

• [new product] privatebin endoflife-date/endoflife.date#4657

[adriens]

• Request : privatebin simple-icons/simple-icons#10500

[adriens]

I'll let you know if I need some more resources, probably the releasePolicyLink 🤔