Bug 32748

Version 3.66.4 solves the issue so only Mageia 9 is affected.

CVE: (none) => CVE-2023-48795
Source RPM: (none) => filezilla-3.64.0-1.mga9.src.rpm
Version: Cauldron => 9
Assignee: bugsquad => geiger.david68210

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

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.david68210
Keywords: advisory => feedback

(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...

(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_update
Whiteboard: (none) => MGA9-64-OK MGA9-32-OK
CC: (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) => FIXED
Status: 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

(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 => RESOLVED
Resolution: (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) => FIXED
CC: (none) => dan
Status: REOPENED => RESOLVED