1.7.2 / valid to / paste lifetime / lease time / always 23 hours

[un99known99]

the valid to is not kept, despite set lifetime to 5mins it will always say "vaild to 23hours", checked with 1.7.1 - here it is working

[elrido]

This affects the bootstrap (3) template - I had a similar issue while working on the bootstrap5 one and in fixing that must have introduced this regression. I'll have a public holiday coming up, so hope to have something ready for the weekend.

[rugk]

Hmm could we somehow push back the release/stop it from deployment for now?

[rugk]

Added a note on github for now. (Edit: and pinned this issue, so people see it)

[rugk]

Hmm tried a quick look through the code to maybe spot an issue but the diff is huge and the only change related to paste self-deletion/expiration/lifetime that comes to my mind is #1295 – maybe the creation date (postdate) somehow was used to calculate the expiration date and this is somehow broken now? (Because it is removed too early?)
Note AFAIK that the expiration time was validated in the backend to be a valid one, so this could come into play here.

Of course if curious people wanted to contribute a git bisect finding/telling the bad commit would be very much appreciated. We know good=1.7.1 and bad=1.7.2 for sure. Anyway, needs manual testing and probably even with git bisect some steps hmm…

[elrido]

I'm pretty sure that this is due to the bootstrap5 template, because I had this exact issue in the new template, then "fixed" the drop-down update mechanism and it now works for bootstrap5 and page, but no longer for bootstrap (3). I'll work on it today and would like to release a hotfix by the weekend. If I can find the time I'd also like to apply a first round of improvements that got suggested for the bootstrap 5 template (OT, sorry).

[Ozwel]

Shouldn't 1.7.2 release be removed? It's currently spreading. Admins may not notice the bug and may not check updates for a while.

[elrido]

Shouldn't 1.7.2 release be removed?

We have never considered the process of removal of a release. In the past, under such circumstances, we simply released a fix-release (if necessary even with backports) but stuff is always already out there.

It is unfortunate that we only got this reviewed too late for me to do the release yesterday afternoon. Our spare time to work on these passion projects is, unfortunately, limited. I now have a busy work week in front of me and don't know if I can find the time to release some evening, I'll try but can't promise - worst case, the release occurs next Saturday.

I'm also not quite clear what counts as sufficient for "removing": Just put the release page back to draft? Also untag? Hide the master branch? Also delete the container images that already got downloaded and are on peoples machines? What about the next release number: 1.7.2 (again) or 1.7.3? In the first case, how to distinguish between buggy and fixed release? In the second case, how to account for the "missing" release?

In light of such questions and their complex answers, and especially in light of all the maintainers' very limited time to spend on this project, I'd prefer focusing on fixing issues than coming up with more processes.

[Ozwel]

I do completely understand. That was a bad suggestion.
And thanks for your time.

[rugk]

It's not inherently a bad suggestion, but as @elrido said, it's just a process we never thought/discussed about and had no procedure. As such, I have opened https://github.com/orgs/PrivateBin/discussions/1334 for a lessons learned. I tried to describe the whole history of that bug, from how it got introduced until how it got fixed…

[un99known99]

test with version 1.7.3 was fine, working as expected, many thanks for the quick fix!

[Ozwel]

1.7.3 works fine for me, also tried with custom retention times.
Thanks for the responsiveness.