Hi, When dealing with a password protected archive, ark will only password protect the files that are added from the "Archive->Add Files" menu item or the CTRL-A shortcut. If you add files by dragging and dropping from dolphin, the files will *not* be encrypted. Steps to reproduce: 1) Open Ark and click "Archive -> New" 2) Choose any filename and change Type to "Zip archive" (i've only tested with zip so far) 3) Click "password protection" and set a password and verify it. 4) Click OK 5) Drag and drop a file from dolpin into Ark. 6) Quit Ark, and open the newly created archive At this point, you will be able to open any of the files within the archive without entering the password. I marked this major because a user could think that his data is password protected when in reality there is no password.
I was not able to reproduce this issue with 7zip archives. I tested with index being password protected and non protected, and both of them worked as expected. I was also unable to reproduce this issue with Jar archives. On my system, the only other option is tar which does not support passwords. This problem seems exclusive to zip archives. I also tested on the git as of now (55613a057013) and the problem exists there as well.
Created attachment 113977 [details] Debug log of reproducing this issue I have attached the debug output when reproducing this issue. The first run of ark is creating the zip file. The second run of ark is testing that the zip file contents are not password protected
This issue appears to be related to each specific file involved - and not the entire archive. When creating a multiple file password protected zip file with some files added through the "Add Files..." menu item and some files through drag and drop, the dropped files will not require a password when extracting.
Git commit 20c6faa54cc80b5d525e0cddca052c0e5b2888c8 by Elvis Angelaccio. Committed on 17/07/2018 at 19:30. Pushed by elvisangelaccio into branch 'Applications/18.08'. Stop ignoring compression options when dropping files Compression options set by CreateDialog were only taken into account when adding files through the AddDialog, but not when adding files by dropping them from Dolphin. We fix this issue by moving the init of compression options in a new dedicated function, which we can call also when dropping files. While at it, this change allows us to simplify the `droppedFiles()` signal emitted by ArchiveModel. FIXED-IN: 18.07.80 M +1 -1 part/archivemodel.cpp M +1 -1 part/archivemodel.h M +31 -20 part/part.cpp M +2 -0 part/part.h https://commits.kde.org/ark/20c6faa54cc80b5d525e0cddca052c0e5b2888c8
Hi Elvis, Really pleased to see a patch for this already! However - I'm actually still able to reproduce this on Ark built against 20c6faa54cc80b5d525e0cddca052c0e5b2888c8. The diff does appear to be addressing the issue. There could be some user error going on in my test, but I wanted to pass back my findings when testing the change. FWIW, when I built I specifically did a "git checkout 20c6faa54" to ensure I had this diff
Hi Lukas, that commit should definitely fix the issue. Are you sure you are actually running your locally built version of ark? I suggest to temporarily uninstall your system-wide ark package and try again (as the fix is in the part plugin and I suspect you might be loading the old plugin rather than the one you built).
Elvis, Thanks - you are likely right. I did make sure that I was running the newly compiled Ark binary, but I'm not confident that the newly compiled ark binary was loading the newly compiled plugin. When I try to run Ark after uninstalling the distribution-provided Ark and reinstalling the Ark I compiled from git with "make install", I get an error message when running Ark "Unable to find Ark's KPart component". If someone is aware of what's going wrong here, let me know. Otherwise, I don't want to get this issue too off-topic. The patch seems to directly address the issue and I don't want to cause too much noise hand-holding me through the debugging process. Cheers!
(In reply to Lukas Sabota from comment #7) > Elvis, > > Thanks - you are likely right. I did make sure that I was running the newly > compiled Ark binary, but I'm not confident that the newly compiled ark > binary was loading the newly compiled plugin. > > When I try to run Ark after uninstalling the distribution-provided Ark and > reinstalling the Ark I compiled from git with "make install", I get an error > message when running Ark "Unable to find Ark's KPart component". If someone > is aware of what's going wrong here, let me know. Otherwise, I don't want > to get this issue too off-topic. The patch seems to directly address the > issue and I don't want to cause too much noise hand-holding me through the > debugging process. > > Cheers! Actually, you shouldn't need to do 'make install'. Running the ark executable built in the bin subfolder should be enough. Anyway, we are off-topic indeed. Feel free to join #kde-utils or #kde-devel on IRC, or drop a mail to kthe de-utils-devel or kde-devel mailing list to get more help.
Some information about needed environment variables if you are installing into a different prefix is available at https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source#Set_up_the_runtime_environment Newer versions of extra-cmake-modules allow you to create a script setting those, see http://www.proli.net/2018/06/29/easily-building-and-testing-kde-applications-into-a-separate-prefix/
Bingo Chris! Thanks for providing that information. After setting the proper environment variables, I was able to confirm that this patch solves this password zip issue. Thank you so much! Cheers everyone and great job!
*** Bug 397234 has been marked as a duplicate of this bug. ***