Update keepassxc to 2.7.9. I will attach a patch after obtaining the PR number.
Created attachment 251590 [details] The patch Upload the patch.
Hi! This is related to existing bug #277652 This release also includes the last patch posted there.
Thanks for the patch! I am testing it and it's really unfortunately that like 2.7.8 in bug 277652, it is still stuck in all my systems while opening the .kdbx file. I did some ktrace and found that it's in a loop of trying to open /dev/ugen*, but no matter the operation is successful or not, it's endless. I don't see such behavior on 2.7.6, it doesn't try to open /dev/ugen* However I am really curious why this seems only happen on my systems, but at least 3 with 14.0, 14.1 and CURRENT.
(In reply to Li-Wen Hsu from comment #3) It is happening here too. Usually I have keepassxc compiled with the YUBIKEY option off, so no USB support, so no lockup, and I can use the latest version. But if I test with YUBIKEY on I can easily trigger lockups. The code in keepassxc does not open usb devices itself, I think it goes. Problem could be there. New keepassxc versions added polling for USB devices so that looks like the issue, with some bug in our libusb maybe.
I might be skewed here, because I'd like to use software Passkeys (which need upgrade to at least 2.7.7) and don't care about usi Yubi as a backend for KeePassXC (if I had one, which I don't, I'd probably use it directly from Firefox, non via KeePassXC anyways) but if this is a show-stopper I'd rather remove Yubikey support temporarily from this port. Passkeys are of more widespread usage. (IMvHO of course)
Created attachment 257690 [details] patch including moving to botan 3 Hi, I am uploading a slightly revised patch moving to botan3, already supported upstream. Botan2, on which port depends at present has been marked deprecated and will be removed. BTW, at this point I think we need to really evaluate updating the port even if this causes incompatibilities with USB support, since fixing that is outside of the port control. Keeping the port back indefinitely does not look like a good solution long term.
(In reply to Guido Falsi from comment #6) Indeed, I also don't want to block this. Sorry for no progress for quite a while since I was busy and ill. I think if we cannot get all available features in the older version working with the new version. Perhaps keeping an old version temporarily is acceptable?
(In reply to Li-Wen Hsu from comment #7) Hi, Maybe we can preserve the old version in a separate port (keepassxc-legacy?), and move on with the main one?
(In reply to Guido Falsi from comment #8) That would be a good idea. Or, versioning the ports. Either works for me. I totally get keeping the old version. I use the old version (screen49) of screen because initially they broke status lines. Though upstream says they fixed them, I can't seem to get status lines to work with the new syntax. sysutils/screen49 and sysutils/screen50 are in the tree. sysutils/screen is a metaport pointing to sysutils/screen49. I'll do the flip over to screen 5.0 when either upstream or I fix hardstatus statements. I've been using 2.7.9 in my "prod" tree since submitting this PR. 2.7.10 is out. I will update the patch and commit it as keepassxc-latest instead. I will withdraw this PR then.
Created attachment 258253 [details] Add keepassxc27 Before I commit this to add keepassxc27.
Created attachment 258254 [details] And add dependency on botan3. Adding keepassxc27 to track upstream updates for now until regressions requiring keepassxc be maintained can be resolved.
Reopening as add a new port instead and assigning to myself.
(In reply to Guido Falsi from comment #8) I just uploaded a new patch adding keepassxc27. We can do this using the old port to support yubikey and other dongles.
(In reply to Cy Schubert from comment #13) Thanks for the patch. IMHO that it's fine to have security/keepassxc use the latest version (2.7.10) and we can add a pkg-message mention that if you need yubikey or other usb support please temporarily use the older version (2.7.6). BTW, I think we might want to call the port security/keepassxc276 as both of them are all 2.7.x. Cy, I saw you listed as MAINTAINER in the port, I'm good with that, just wanted to check, do you want to maintain keepassxc276 or the latest keepassxc? (or both?)
(In reply to Li-Wen Hsu from comment #14) I simply felt I should take the new port but if we're updating the existing port, I could take it or leave it with you. Whatever works. 2.7.10 is not available through the upstream github site he uses to distribute keepassxc. To update to 2.7.10 we'd need to use USE_GITHUB=YES. That may introduce some build time changes like autotools dependencies. I haven't looked though so I'm not sure. I'll update the original patch to 2.7.10 while keeping the existing port as keepass-legacy for those who need yubikey support. Does that sound ok?
(In reply to Guido Falsi from comment #8) Yes, the existing port will be called keepassxc-legacy.
Created attachment 258267 [details] Four commits to implement keepassxc-legacy and update keepassxc This file contains four commits: * 06831734208c 5e562ccf43ed 2025-03-03 - (HEAD -> keepassxc) security/keepassxc: Update to 2.7.10 * 52f2440c1ddd 6fbc9f74eb58 2024-06-20 - security/keepassxc: Update to 2.7.9 * 2cb415fb5a9f b028d2cf538e 2025-03-03 - security/keepassxc-legacy: Differentiate from security/keepassxc * ad4937e6f6a7 efc500aeb8bd 2025-03-03 - security/keepassxc-legacy: Repocopy from security/keepassxc
(In reply to Guido Falsi from comment #6) This is exactly what I was suggesting to you in private email @ Sun, Jun 23, 2024. (In reply to Guido Falsi from comment #8) I don't think '-legacy' is a good name -- 2.7.x is not legacy, 2.7.6 is just old patch release from supported branch. security/keepassxc276 is a best fit IMO. (In reply to Cy Schubert from comment #15) > 2.7.10 is not available through the upstream github site he uses to distribute keepassxc. > To update to 2.7.10 we'd need to use USE_GITHUB=YES. No, we don't need -- there's a release page [0] and corresponding release asset [1]. I've changed DISTVERSION and 'make makesum' went fine without USE_GITHUB. [0]: https://github.com/keepassxreboot/keepassxc/releases/tag/2.7.10 [1]: https://github.com/keepassxreboot/keepassxc/releases/download/2.7.10/keepassxc-2.7.10-src.tar.xz
(In reply to Anton Saietskii from comment #18) He must have updated his distribution site then. Probably best to leave it with USE_GITHUB. IMO this is preferred anyway. Before we abandon 2.7.6 we need to find a solution for the loss of yubikey support. If we abandon it, patches are always welcome. ;)
(In reply to Cy Schubert from comment #19) > He must have updated his distribution site then. Yeah, 2.7.10 may have been tagged with release assets generated with some delay... > Probably best to leave it with USE_GITHUB. IMO this is preferred anyway. In fact, the opposite according to section 5.4.3. of Porter's Handbook [0]: > Please switch to release assets and if not available ask upstream to generate ones. > Before we abandon 2.7.6 we need to find a solution for the loss of yubikey support. If we > abandon it, patches are always welcome. ;) For me, it's pretty easy and obvious -- move keepassxc to keepassxc276 and update former to 2.7.10. Or maybe we don't even need to keep 2.7.6, see bug #277652, comment #38. Though I can't verify that due to no-use of hw keys. [0]: https://docs.freebsd.org/en/books/porters-handbook/book/#makefile-master_sites-github
(In reply to Anton Saietskii from comment #20) That would work too. IMO the name is unimportant. Whatever name people want, as long as everyone's needs are met. I'd like to hear from lwhsu@ first before proceeding.
Created attachment 258315 [details] Updated patch with keepassxc276 recommendation Attached is the updated patch with the keepassxc276 recommendation.
I'm using the proposed patch locally, with the latest port installed (2.7.10) and everything works fine here.
(In reply to Guido Falsi from comment #23) But we still need to switch back to using release assets for 2.7.10.
Created attachment 259774 [details] Update to 2.7.10 and preserving 2.7.6, migrating to botan3 Hi, Since keepassxc has just been deprecated due to depending on old botan, I'm attaching an updated patch. This patch uses upstream assets instead of leveraging USE_GUTHUB, removes the deprecation by updating to depend on botan3 The 2.7.6 version failed to build with botan 3 so I imported the patch from upstream at [1] to fix it. I think this should be committed ASAP at this point, to avoid port removal. [1] https://github.com/keepassxreboot/keepassxc/commit/cc0530ba4671a7e2b6ac4a6c00cd097f4114fd22
Created attachment 259863 [details] Two updates to keepassxc, Hi LI-Wen, Considering keepassxc is deprecated due to its dependency on botan2, I don't think preserving 2.7.6 --> keepassxc-legacy is viable anymore. Please approve this patch and approve my assuming maintainership of this port.
(In reply to Cy Schubert from comment #26) What's the point of having 2 commits, of which one is for not latest version? Anyway, can we PLEASE get this committed ASAP?
(In reply to Anton Saietskii from comment #27) Two commits preserve tree history and it's already in my tree, and in use here, locally, for months. I see Li-Wen has approved the patch on March 3. But that was in the context of a -legacy port. The legacy port is no longer viable because of its dependency on botan2. Let's wait for Li-Wen. He uses a plugin that is only supported by 2.7.6. Though, I don't know how we can salvage 2.7.6 (as -legacy) given it's deprecated now. We have plenty of time before we absolutely have to push these commits. Let's wait two weeks.
(In reply to Cy Schubert from comment #26) @cy My patch from comment #25 also includes a fix to allow the old version to compile and work with botan3, please include that in your patch!
Created attachment 260177 [details] YUBIKEY fixes Hello, this may fix the problem of Yubikey.
I think SHENG-YI fixes the issue, if that also works for others, we can go with this directly. (if it still has problems, I'm fine for keeping legacy version -- I prefer the "276" version suffix if possible.)
I dig into the code of libusb and thought it is the correct patch to solve it. https://reviews.freebsd.org/D50170
So https://reviews.freebsd.org/D50170 has been merged as base d2852659180307475a8376ce86aa587cccbb10bf , and we're aiming to MFC this to stable/14 and releng/14.3 soon. It think after 14.3 release, we can safely upgrade to 2.7.10, and which is before the current removing date. For desktop users, I think encouraging them upgrading to 14.3 for using keepassxc is acceptable.
(In reply to Li-Wen Hsu from comment #33) Previous minor release is still being supported 3 months after new one. Forcing users to upgrade from something not dead smells microsoft way very much.