Feature request: show Alpine package versions -rN in logs

[the-hotmann]

What's the feature 🧐

Regular Updates when dependencies, or base gets updated.

Currently (2024.07.27) this is the setup:

Name	Current Version	Version available	Where to be found
Alpine	3.19.1	3.19.3 (Update)	LINK
Alpine	3.19.1	3.20.2 (Upgrade)	LINK
OpenVPN v2.5	2.5.8	2.5.10-r1	LINK
OpenVPN v2.6	2.6.8	2.6.11-r0	LINK
Unbound	1.20.0	1.20.0-r0	LINK
IPtables	1.8.10	1.8.10-r3	LINK

Please also show the -r* addition, as this would make the versions more transparent, if there are security issues with specific version we can contact you and initiate a rebuild with the fixed version.

Thanks for your nice tool! :)

Extra information and references

No response

[github-actions]

@qdm12 is more or less the only maintainer of this project and works on it in his free time.
Please:

• do not ask for updates, be patient
• 👍 the issue to show your support instead of commenting
  @qdm12 usually checks issues at least once a week, if this is a new urgent bug,
  revert to an older tagged container image

[the-hotmann]

@qdm12 thanks very much for updating the base+dependencies.

Is there a possibility, you also show the Subsequent package versions of each dependency for transparency reasons?

Currently everything is up-to-date - which is nice to see:

2024-07-27T00:55:52Z INFO Alpine version: 3.19.3
2024-07-27T00:55:52Z INFO OpenVPN 2.5 version: 2.5.10
2024-07-27T00:55:52Z INFO OpenVPN 2.6 version: 2.6.11
2024-07-27T00:55:52Z INFO Unbound version: 1.20.0
2024-07-27T00:55:52Z INFO IPtables version: v1.8.10

Thank you very much!

[qdm12]

Regular Updates when dependencies, or base gets updated.

It's not that simple, especially when it comes to Alpine/Openvpn/iptables since upgrading these often break the setups for a good chunk of users. I need to do Gluetun releases between each upgrade and make sure it's stable before moving forward upgrading those dependencies.

For example I really want to upgrade Alpine to 3.20 to get the newer (fixed) iptables, but I'm trying to first have workarounds for the (borked) iptables with Alpine 3.19 (upgrade from 3.18 to 3.19 is still after the last release v3.38.0). Baby steps 🦶 👶 😄

Please also show the -r* addition, as this would make the versions more transparent
Is there a possibility, you also show the Subsequent package versions of each dependency for transparency reasons?

Well this is specific to Alpine, and the long-term goal is to NOT depend on an OS, so I would rather just get the version from the actual subprograms (iptables --version etc.) instead of using Alpine's apk.

if there are security issues with specific version we can contact you and initiate a rebuild with the fixed version.

I'm unaware to be honest, what's the difference in versioning between v1.8.1-r0 and v1.8.1-r1? Isn't the bug fix the last 1 in v1.8.1? The rN part is really just the package version, and I doubt it would add a security fix in there? Thoughts?

Currently everything is up-to-date - which is nice to see:

Eh not that much. Alpine is still on 3.19. All programs are not pinned on the the bugfix version, only on the feature version (or not pinned at all). Also Unbound is about to be thrown out after next v3.39.0 release 😄

[qdm12]

In the end I did upgrade to Alpine 3.20, because that iptables issue is affecting some machines not supporting iptables-legacy (see #2304 (comment)). So now everything should be up to date. There is still a discussion to have about showing Alpine package versions -rN though 🤔

[the-hotmann]

since upgrading these often break the setups for a good chunk of users.

Yes, indeed, many Synology users (myself included) are experiencing problems with the new 3.20.x upgrade. However, I hope this can be fixed. Otherwise, older Synology devices will need to remain on 3.19.x.

Well this is specific to Alpine, and the long-term goal is to NOT depend on an OS

That would be fantastic! I can imagine this application being solely based on Golang and compiled with CGO_ENABLED=0 into a single static binary, which would not require any other OS. It could potentially be shipped in a Docker-Scratch Docker image.

I'm unaware to be honest, what's the difference in versioning between v1.8.1-r0 and v1.8.1-r1? Isn't the bug fix the last 1 in v1.8.1?

Yes and no. Once 1.8.1 is released by the software maintainer, a package maintainer will compile it from scratch (source build) and release it as the Alpine package 1.8.1-r0 (first release). If a security issue is found in 1.8.1 and a fix is released on GitHub, there isn't always an immediate new release. However, the package maintainer can rebuild it and release it as 1.8.1-r1, allowing everyone on Alpine to apply the fix immediately.
Alpine's package manager also allows insecure or outdated releases to be flagged, notifying the package maintainer who will then release a fixed version (if a fix is available). You can identify these flagged releases by checking the release color (green = up-to-date, red = flagged). Red Example

In short: the official version (semver) is defined by the software maintainer, while the -rN version is defined by the package maintainer. As long as it is based on Alpine, I appreciate the transparency of the -rN info.

[the-hotmann]

About the Synology Problem: I guess on the long run this will not be solvable, since Synology does not provide Kernel Upgrades.
And since Golang (as many other vendors, OSs etc..) do cut support for old kernels this anyway will be a problem on the long run.
#ref
So my old Syno (DS1817+) anyway soon will very likely not run anything that is based on Golang >1.24.x. But that is my problem. Will move the dockers to my NUC, which anyway would not have had this issue to begin with.

Anyway on all my other machines (Debian SID | Kernel v6.9.12-1) the new version works flawlessly. But keep in mind, that I have not checked if it really is secure. I assume you make such tests for all releases as some type of A/B-Testing?

Thanks again for your hard work and the chat :)

[qdm12]

Yes, indeed, many Synology users (myself included) are experiencing problems with the new 3.20.x upgrade.

What problems are you experiencing?? Feel free to comment here or create other issues per problem.

Alpine's package manager also allows insecure or outdated releases to be flagged, notifying the package maintainer who will then release a fixed version (if a fix is available). You can identify these flagged releases by checking the release color (green = up-to-date, red = flagged).

I did... not know that!! Thanks! 👍

#ref
So my old Syno (DS1817+) anyway soon will very likely not run anything that is based on Golang >1.24.x. But that is my problem.

Did not know that either, interesting! 🎖️ As in, I can maintain 2 versions in that case, there would be a oldkernel tag or something, especially since Go is relatively compatible even from a higher version to a lower one. Anyway, we'll see later!

the official version (semver) is defined by the software maintainer, while the -rN version is defined by the package maintainer. As long as it is based on Alpine, I appreciate the transparency of the -rN info.

Ok I guess then this information could be useful. Even better would be a check against Alpine database to check if it's 'green' or 'red', but that's when the tunnel is up later. Could be nice to report 'red' packages 👍 I'll look into that instead, so just printing the versions as it does now, but after the tunnel is up, report any "red" packages. Thoughts on that?

But keep in mind, that I have not checked if it really is secure. I assume you make such tests for all releases as some type of A/B-Testing?

Define "secure" 😄
As in Gluetun is a big-big wrapper around OpenVPN or Wireguard; security depends on those protocols and especially on the VPN servers configuration (especially for OpenVPN). Some providers are quite bad at having a decent configuration, so that's that. Well there is the firewall in Gluetun (and soon, I gotta do #1697), so these are security risks indeed, but they don't change much (I hate fiddling with those now that it works 😄).
I don't really do any testing to compare releases (ain't no time for that); but I do have my little release process, more or less described at the bottom of https://github.com/qdm12/gluetun-wiki/blob/main/setup/docker-image-tags.md#why-is-latest-pointing-to-the-edge-of-development if that is relevant.

[the-hotmann]

What problems are you experiencing?? Feel free to comment here or create other issues per problem.

Sorry should have updated the post. #2375 (comment) fixed the issue.

Did not know that either, interesting! 🎖️ As in, I can maintain 2 versions in that case, there would be a oldkernel tag or something, especially since Go is relatively compatible even from a higher version to a lower one. Anyway, we'll see later!

That probably would be neat in the future. For me: I will switch the container to the Intel NUC and have it run on the newest kernel, but since I read some other issues, I noticed a lot of people using Synologys - if they use old ones (just like me) that would adress that issue :)

Thoughts on that?

Will test it and report back :)
Also: flagging AFAIK is just allowed/possible in the edge-branch, since all other branches, are expected to be "outdated". So maybe this does not work as initially intended..

Thanks again!

[qdm12]

I migrated your questions to #2370 and see my answer on #2370 (comment) 😉

[github-actions]

Closed issues are NOT monitored, so commenting here is likely to be not seen.
If you think this is still unresolved and have more information to bring, please create another issue.

This is an automated comment setup because @qdm12 is the sole maintainer of this project
which became too popular to monitor issues closed.