Update cloudflared to 2024.11.0

[IngmarStein]

Changelog: https://raw.githubusercontent.com/cloudflare/cloudflared/master/RELEASE_NOTES

2024.11.0

• 2024-11-05 VULN-66059: remove ssh server tests
• 2024-11-04 TUN-8700: Add datagram v3 muxer
• 2024-11-04 TUN-8646: Allow experimental feature support for datagram v3
• 2024-11-04 TUN-8641: Expose methods to simplify V3 Datagram parsing on the edge
• 2024-10-31 TUN-8708: Bump python min version to 3.10
• 2024-10-31 TUN-8667: Add datagram v3 session manager
• 2024-10-25 TUN-8692: remove dashes from session id
• 2024-10-24 TUN-8694: Rework release script
• 2024-10-24 TUN-8661: Refactor connection methods to support future different datagram muxing methods
• 2024-07-22 TUN-8553: Bump go to 1.22.5 and go-boring 1.22.5-1

Description

Fixes #

Checklist

• Build rule all-supported completed successfully
• New installation of package completed successfully
• Package upgrade completed successfully (Manually install the package again)
• Package functionality was tested
• Any needed documentation is updated/created

Type of change

• Bug fix
• New Package
• Package update
• Includes small framework changes
• This change requires a documentation update (e.g. Wiki)

[hgy59]

please do not update packages just for every new version.
especially for packages that have often more than one update per month.

except for vulnerabilities we should not create more than one package per six months or so...

our resources are very limitted...

[IngmarStein]

This update closes "VULN-66059".

But I got it, I won't send more version bumps in the future.

[mreid-tt]

Hey @IngmarStein, I can't speak for all SynoCommunity devs, but I have a nuanced perspective on some of our resource constraints:

1. Server Capacity: Due to limited storage, we often retain only the most recent versions of larger packages. This makes it crucial to focus on updates for major releases or those addressing significant vulnerabilities.

2. Human Capacity: Our developers are all volunteers, so we handle many responsibilities beyond just submitting code. This includes testing releases across DSM versions and platforms, identifying and triaging bugs, cross-referencing related issues, updating documentation, and conducting code reviews. Major efforts like updating packages for new DSM versions or restructuring the spksrc library also require significant time and coordination.

Since our availability to contribute can vary, I started by diagnosing bugs, then testing package updates, and eventually writing some of my own. Code reviews have been a learning curve for me, but I pitch in when I can.

We’re always glad to welcome anyone willing to help. Getting involved might mean expanding the kinds of support you provide—like tackling specific issues—or taking ownership of a package you know well. Some devs focus on particular packages they use regularly, which allows for a more consistent maintenance effort.

I hope this perspective encourages you to contribute in a way that aligns with your interests. We're grateful for any support you can offer!

[IngmarStein]

@mreid-tt thanks for the nuance! I understand how difficult and thankless maintaining an open source project can be and I emphasize with y'all.

As for this particular package: I've already reverted to a pure container setup (although I prefer running bare metal, wherever possible) which seems to be the better fit here because the image is provided by Cloudflare. With containers, the frequent upgrades don't require any work from you or contributors.
Hence, I will no longer be able to build and test SPKs locally which would be a requirement for a contribution.

More generally, I'd encourage you to find an organizational model which scales better given the constrains you mentioned (there are currently 80 open PRs going back to 2015, indicating that it's hard to keep up). Maybe find a way where package owners could act more independently, without creating work for the core team. Of course, it's a fine balance with how much control you want/need to have over the overall quality of the repo (e.g. in terms of security and functionality).

Maybe setting expectations also helps. https://synocommunity.com states: "Bleeding Edge. We provide frequent updates to our packages so you can enjoy new features of your favorite softwares.". With that in mind, I naively started sending you version bumps and inadvertently generated load for the core team. If that had read "Stable releases. We focus on major releases and those addressing significant vulnerabilities.", I wouldn't have bothered you.