Created attachment 237302 [details] Update security/teleport to version 4.4.12 The version of Teleport currently packaged by FreeBSD (4.3.9, from Dec. 2020!) contains multiple known vulnerabilities and most components silently broke since the port is getting compiled with Go 1.16 and higher. I tried to mail the maintainer last year but didn't get a response. There has been an attempt by someone else to get the software updated (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261459), but nothing happened since January. This could be due to said effort being incomplete and providing no update path (forcing existing clusters to be re-installed). I've chosen the more comprehensive path of step-by-step upgrades. This first step brings Teleport up to version 4.4.12, the final one in the 4.4 branch that was released in March this year. It can be used to upgrade existing 4.3 installations and unbreaks several components with newer versions of Go. If it is committed, I intend to follow up an update to version 5.2.5. The port description has been revised as Teleport evolved significantly since the port was introduced at version 2.5.6. This proposal passes "portlint -AC" and a test build with Synth. I set up a test cluster with 4.3.9 nodes (package built with old Go), updated the machines with this port and ensured that Teleport still works. If this patch requires further work to be committed, I'll be happy to do that.
Upstream release branches are a bit confusing, is there any reason not to go for 7.3 or newer after this one which seems to be the oldest supported version looking at https://goteleport.com/download/? I presume that 4.X is already EoL by upstream and that upgrade paths are broken at some point either way? Next step would preferably be to keep secure/teleport up to date and move older versions to a versioned port (if needed). While I'm at it, would either of you (CCed Daniel) be interested in adopting this port? Best regards, Daniel
(In reply to Daniel Engberg from comment #1) Teleport started out as a rather humble project that would help people to adopt SSH best practices. It grew more and more related functionality, though: Web application proxying (like dashboards, PHP Myadmin, etc.) in 5.x, DB access (Postgres, MySQL, ect.) in 6.x, Windows Server via RDP in 9.x and so on. This lead to rather quick releases of new major versions. Before 5.0, every new version was only compatible with the previous minor release. So FreeBSD's current 4.3 cannot be upgraded to 5.x or newer. This is why I propose an update to 4.4 first which then allows to be updated to 5.x, then 6.x and so on. Indeed 7.x is the oldest still supported branch as far as I know and getting that into the tree is my mid-term goal (or probably rather 8.x at that point). We could of course also decide to drop this port completely and introduce Daniel Ylitalo's port (updated to 8.3.18) as teleport8. However I think that it's actually worth to go through the latest releases of the next two obsolete branches (5.x and 6.x) first, ensuring both the upgrade path is valid and giving me time to test new major features one by one. If I test 8.x and find that something is broken, it would be very helpful to know if it worked in 7.x. I'm willing to spend the time getting teleport to a supported release including going the intermediary steps. When it comes to adopting the port: I actually thought about it and would like to but am not sure if I'm the right person at the moment. I had the opportunity to talk with Kirk at EuroBSDCon. When I told him that while I was using FreeBSD for years now I never managed to get more involved in the community besides writing blog posts and such, he suggested looking into docs or ports. I enjoy hacking on ports and am pretty motivated, but cannot judge if that will be enough. Perhaps I should try to find somebody mentoring me? So my answer is an honest "maybe!".
(In reply to Michael Reim from comment #2) Thanks for the explanation of how upstream handles releases and branching. While I don't think time itself will be an issue the migration process however kinda clashes with how we branch the tree (each quarter). That would essentially mean that we could switch to next major version each quarter and that would take years catching up with upstream unless we introduce parallel versioned ports to speed up migration. I apprecate your concern about POLA but I don't think it would be practical to go with only the quarterly approach, we're already quite behind so there's no stress in introducing new versions. We usually don't commit short-lived ports but it's not the end of the world on the other hand so as long as it's clearly stated I don't see an issue with that approach. We do need however to have a "supported" lastest version so users don't get stuck with an unusable configuration. For example: Commit latest 4.4 minor vesion to tree as security/teleport4 (included in 2023q1) Commit 5.x and 6.x as "migration only" ports as security/teleport5 and security/teleport6 (included in 2023q1 only) Commit 7.x as "to be used in production" version as security/teleport ..and go from there when time permits I can't help you much when it comes to Go language itself but I can point you in the right direction when it comes to porting and also direct people who are more knowledgeable in specific areas if needed (can't guarantee that people will be available but we can at least try). Best regards, Daniel
(In reply to Daniel Engberg from comment #3) Right, catching up without skipping any major version in quarterly probably won't work out. Since it's a security related thing, I thought that it might be ok to upgrade within the quarterly branch - but then again there's no guarantees that everybody got the previous version in time and it might break the upgrade path. Also it doesn't feel right. Long-term we'd be fine as according to the new model (no more LTS), upstream provides security fixes for a period of 9 months for every release branch, giving us enough time to move to new major versions. I like your proposal with the migration ports that start with a rather short expiry date and mention (via pkg-message) that it's only a transitional package not meant to be put into use for new installations (i.e. "strongly discouraged"). So here's a suggestion: The current port is updated to 4.4 (there's really no reason to keep 4.3 around as far as I can tell) and moved to security/teleport4 in preparation for temporarily having multiple versions in the tree. I'll start working on further updating the port to the latest 5.x version. If I succeed and it gets committed as security/teleport5, the previous one gets an expiry date of 3 months and a heads-up in UPDATING for 2023Q1. Same thing for 5.x when 6.x lands. BTW: Thanks for your efforts to help getting this going! Really appreciate it, especially since the current state of the port is extremely ugly and might in fact warrant a FORBIDDEN if it cannot be updated (which might look strange since officially it's not even an unmaintained port!).
While going over the proposed 4.4 port once again, I noticed something: GH_COMMIT_SHORT has been set to fabee242d and since it hadn't been touched for the previous update to 4.3.9, I disregarded it. Now searching through all the branches of Teleport's git repo I figured out that it's the short commit hash for the tag of version _4.3.6_, so something seems not to be right here. However when I change it to the correct string for the 4.4.12 tag (i.e. d48e196) and do a "make makesum" again, the resulting distinfo does not change from the one in my patch. So my question is: Is it needed at all or could it be a leftover from a time when fetching such distfiles from GH worked differently?
Sounds great, there's still more than a month before branching so no need to rush. GH_COMMIT_SHORT is only used in GH_TAG_COMMIT and is later used to patch ${WRKSRC}/version.mk (after applying files/patch-version.mk) and isn't related to any distfiles only for version reporting as far as I can tell. Best regards, Daniel
I should also point out that we need to wait for usual timeout period (2 weeks) before we touch the port unless maintainer finds some time to review changes. Best regards, Daniel
(In reply to Daniel Engberg from comment #6) Thanks for explaining! I think I'll fix it anyway, can't hurt to have it point to the correct commit. While there I'm going to add a warning to pkg-message discouraging new installations. Will follow up with a new patch proposal here and then get working on security/teleport5. I assume that for the latter a new PR which references this one is the preferred approach? Two more weeks for maintainer timeout is perfectly fine. I've been waiting for about a year, hoping that someone would do something with this port. Now that things are getting traction, maybe Steve finds time to comment or probably disown the port? We'll see.
Created attachment 237562 [details] Improved patch This new patch includes a strong warning in the pkg-message and a comment regarding Go version compatibility in the Makefile. Otherwise it's identical to the previous, now obsolete patch.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=19cac1122ceb74cb35863a01f17cc2ef0556d227 commit 19cac1122ceb74cb35863a01f17cc2ef0556d227 Author: Michael Reim <kraileth@elderlinux.org> AuthorDate: 2022-11-06 10:37:31 +0000 Commit: Daniel Engberg <diizzy@FreeBSD.org> CommitDate: 2022-11-06 10:46:53 +0000 security/teleport: Update to 4.4.12 Pass maintainership to submitter due to multiple timeouts from current. Changelog: https://github.com/gravitational/teleport/releases/tag/v4.4.12 PR: 267052 Approved by: portmgr (maintainer timeout, 3+ weeks) security/teleport/Makefile | 13 +++-- security/teleport/distinfo | 10 ++-- ...patch-build.assets_pkg_etc_teleport.yaml (gone) | 51 ---------------- .../patch-docs_pages_config-reference.mdx (new) | 68 ++++++++++++++++++++++ .../files/patch-lib_config_fileconf.go (gone) | 11 ---- .../teleport/files/patch-lib_defaults_defaults.go | 4 +- .../teleport/files/patch-lib_events_auditlog.go | 4 +- security/teleport/files/patch-lib_events_doc.go | 2 +- .../teleport/files/patch-lib_services_server.go | 4 +- .../patch-tool_teleport_common_teleport__test.go | 2 +- ...dor_github.com_kr_pty_ztypes__freebsd__arm64.go | 2 +- security/teleport/files/patch-version.mk | 2 +- security/teleport/files/pkg-message.in | 23 +++++--- security/teleport/pkg-descr | 23 ++++---- 14 files changed, 115 insertions(+), 104 deletions(-)
Committed, thanks for working on this!