+++ This bug was initially created as a clone of Bug #32641 +++ Ubuntu has issued an advisory on January 18: https://ubuntu.com/security/notices/USN-6589-1
Version 3.66.4 solves the issue so only Mageia 9 is affected.
CVE: (none) => CVE-2023-48795Source RPM: (none) => filezilla-3.64.0-1.mga9.src.rpmVersion: Cauldron => 9Assignee: bugsquad => geiger.david68210
Keywords: TRACKER => (none)
Depends on: 32641, 32670, 32673, 32674, 32675, 32676, 32682, 32644, 32656, 32660, 32662, 32671, 32672 => (none)Blocks: (none) => 32641
Assigning to QA, Packages in 9/Core/Updates_testing: ====================== filezilla-3.66.4-1.mga9 lib64filezilla-devel-0.45.0-1.mga9 lib64filezilla41-0.45.0-1.mga9 libfilezilla-devel-0.45.0-1.mga9 libfilezilla41-0.45.0-1.mga9 libfilezilla-i18n-0.45.0-1.mga9.noarch.rpm From SRPMS: filezilla-3.66.4-1.mga9.src.rpm libfilezilla-0.45.0-1.mga9.src.rpm
Assignee: geiger.david68210 => qa-bugs
Tested on real hardware mageia 8 x86_64 lxqt Updated without issues Run filezilla - Connect to external sftp server works - Connect to external ftp server works
URL: (none) => https://ubuntu.com/security/notices/USN-6589-1
Keywords: (none) => advisory
mga9-64 quick test: Clean update Localisation Swedish OK Remembered a server I had used Browsed server content Upload not tested, I currently have no ftp server with write access. I have not used filezilla for long - Maybe not ever in mga9. System was fresh install with mga9, kept most of /home. $ rpm -qa|grep filezilla|sort filezilla-3.66.4-1.mga9 lib64filezilla36-0.42.2-1.mga9 lib64filezilla41-0.45.0-1.mga9 libfilezilla-i18n-0.45.0-1.mga9 ----------------------------- Problem 1: At launch, a popup complain: An error occurred loading the transfer queue from "/home/morgan/.config/filezilla/queue.sqlite3". Some queue items might not have been restored. And similarly at shutdown it say it got an error saving that file. $ ll /home/morgan/.config/filezilla/ totalt 64 -rw-r--r-- 1 morgan kamo 8946 feb 3 21:40 filezilla.xml -rw-r--r-- 1 morgan kamo 930 feb 3 21:44 layout.xml -rw-r--r-- 1 morgan kamo 0 aug 20 2016 lockfile -rw-r--r-- 1 morgan kamo 32768 aug 29 2022 queue.sqlite3 -rw-r--r-- 1 morgan kamo 1072 dec 12 2022 recentservers.xml -rw-r--r-- 1 morgan kamo 367 dec 12 2022 search.xml -rw-r--r-- 1 morgan kamo 678 feb 16 2020 sitemanager.xml -rw-r--r-- 1 morgan kamo 3591 feb 3 21:33 trustedcerts.xml ----------------------------- Problem 2: To get that popup in English, I launched it with: $ LC_ALL=C filezilla There then is an additional popup after the one described above, that warns: Character encoding issue A local filename could not be decoded. Please make sure the LC_CTYPE(or LC_ALL) environment variable is set correctly. Unless you fix this problem, files might be missing in the file listings. No further warning will be displayed for this session.
CC: (none) => fri, geiger.david68210Keywords: advisory => feedback
CC: (none) => mageia
(In reply to Morgan Leijström from comment #4) > Problem 2: > > To get that popup in English, I launched it with: > > $ LC_ALL=C filezilla > > There then is an additional popup after the one described above, that warns: > > Character encoding issue > A local filename could not be decoded. > Please make sure the LC_CTYPE(or LC_ALL) environment variable is set > correctly. > Unless you fix this problem, files might be missing in the file listings. > No further warning will be displayed for this session. Confirm that message with LC_ALL=C filezilla , the best way to start filezilla in english is menu Edit -> Settings -> Interface -> Language and change to english, the application will show a dialog about need to restart I think the problem 1 is a rotten/legacy configuration from an old version of filezilla
(In reply to Morgan Leijström from comment #4) > mga9-64 quick test: > > Clean update > Localisation Swedish OK > Remembered a server I had used > Browsed server content > > Upload not tested, I currently have no ftp server with write access. > > I have not used filezilla for long - Maybe not ever in mga9. > System was fresh install with mga9, kept most of /home. > > > $ rpm -qa|grep filezilla|sort > filezilla-3.66.4-1.mga9 > lib64filezilla36-0.42.2-1.mga9 > lib64filezilla41-0.45.0-1.mga9 > libfilezilla-i18n-0.45.0-1.mga9 > > ----------------------------- > > Problem 1: > At launch, a popup complain: > > An error occurred loading the transfer queue from > "/home/morgan/.config/filezilla/queue.sqlite3". > Some queue items might not have been restored. > I get this on my i586 test, with filezilla closed I delete .config/filezilla/queue.sqlite3 and the message disappear
Tested on real hardware mageia 9 i586 Update without issues, I get the issue reported by Morgan, but the application works and disappear once I delete .config/filezilla/queue.sqlite3 Upload and download files with sftp and ftp
Installed and tested without issues. Tested ftp, ftps, and sftp. Listing and transferring files worked. Did NOT see the issue described in comment 4. $ uname -a Linux jupiter 6.6.14-desktop-1.mga9 #1 SMP PREEMPT_DYNAMIC Sat Jan 27 01:13:53 UTC 2024 x86_64 GNU/Linux $ rpm -qa | grep filezilla lib64filezilla36-0.42.2-1.mga9 libfilezilla-i18n-0.45.0-1.mga9 lib64filezilla41-0.45.0-1.mga9 filezilla-3.66.4-1.mga9
Searching the web for the issue described in Comment 4, it seem rather common. It is safe to just delete that file, it just holds the file queue. Some say it may have become damaged but it is so commonly asked, also for the MSWindows version of filezilla BTW, and most of us see it, that i think it may rather be a version bug. So i suggest to either make the upgrade suggest user this file can be deleted if they see this problem, or we put it in errata. Or should we just let people hit into it and search web? Non of us QA even did until now...
CC: (none) => davidwhodgins
(In reply to Morgan Leijström from comment #9) > Searching the web for the issue described in Comment 4, it seem rather > common. > It is safe to just delete that file, it just holds the file queue. > Some say it may have become damaged but it is so commonly asked, also for > the MSWindows version of filezilla BTW, and most of us see it, that i think > it may rather be a version bug. > > So i suggest to either make the upgrade suggest user this file can be > deleted if they see this problem, or we put it in errata. > > Or should we just let people hit into it and search web? > Non of us QA even did until now... I think a Errata is enough, in my x86_64 test I don't get this, but I get on i586 test
Problem with Errata is we should not extend/pollute it with odd hickups of every hundreds of applications...
(In reply to Morgan Leijström from comment #11) > Problem with Errata is we should not extend/pollute it with odd hickups of > every hundreds of applications... And the problem with return to packager is the usual lack of time they have @Thomas the decision is yours
This upstream issue being so easily found on web, I actually think we can ship it as-is and without errata entry. People doing FTP etc are usually no newbies. Thomas, WDYT?
CC: (none) => andrewsfarm
Another problem with ERRATA is that many if not most users fail to RTFM. But there's nothing we can do about that. Lets go for it. We have tests in both arches, so giving both OKs. Validating.
Keywords: feedback => validated_updateWhiteboard: (none) => MGA9-64-OK MGA9-32-OKCC: (none) => sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2024-0034.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED
filezilla-3.66.4-1.mga9 rpms have been moved from /core/updates_testing to /core/updates but no libfilezilla rpm has been moved As a consequence, updating filezilla is not possible
CC: (none) => philippedidier
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
(In reply to Philippe Didier from comment #16) > filezilla-3.66.4-1.mga9 rpms have been moved from /core/updates_testing to > /core/updates > > but > no libfilezilla rpm has been moved > > As a consequence, updating filezilla is not possible This will require manual intervention from the sysadmins. They have been alerted about the issue.
They showed up as an update on my production machine a few minutes ago. If they aren't on your mirror-of-choice now, they should be there before long.
Status: REOPENED => RESOLVEDResolution: (none) => FIXED
(In reply to Thomas Andrews from comment #18) > They showed up as an update on my production machine a few minutes ago. If > they aren't on your mirror-of-choice now, they should be there before long. Thanks Thomas I was surprised since the mirror I use is distrib-coffee which is usually up-to-date
My mistake. They have NOT been moved yet. I didn't realize it until you mentioned distrib-coffee, and that is the mirror I use, as well. I looked, and found I had checked for the missing rpms in the testing repos with qarepo, but neglected to disable the local repo that it had created. So when my machine checked for updates, it found them. Sigh. I really hate it when I do dumb stuff like that.
Resolution: FIXED => (none)Status: RESOLVED => REOPENED
libfilezilla-0.45.0-1.mga9 has now been moved and MGASA-2024-0034 updated to match.
Resolution: (none) => FIXEDCC: (none) => danStatus: REOPENED => RESOLVED