Welcome to the SecureDrop chatroom. Code of Conduct: https://github.com/freedomofpress/securedrop/blob/develop/CODE_OF_CONDUCT.md
I have an SD setup that seems to remove the original file extensions of submissions so that a .xlsx can't be opened in LibreOffice because it's a container format and double-clicking it just extracts it. I recall there's some manual step in the install process that is required to preserve file extensions but I've been searching the SD docs for about 40 mins and haven't found it yet, searching for "file extensions" anyway. Anyone know where to find documentation for that?
(is that the issue?)
@rocodes Yeah but iirc this used to be an issue that was addresses with some SVS configuration, alas the last reference I had to it seemed to point to a much older version of the docs that isn't online: https://docs.securedrop.org/en/release-0.12.1/set_up_svs.html#ensure-filenames-are-preserved
There was a gnome setting iirc that you had to set but it should not be required in tails 4
so mayybe try that dconf command on the tails workstation and see if it helps? this change would be tails-only, the server doesn't know/care about submission file types
As far as "Extract here" being an issue, that's the first time I'm hearing this is the case; Using the default double-click behavior / File Roller causes other issues since journos in training don't understand the need to actually extract to a specific location, they just start trying to play with the files in limbo before putting them in a specific folder.
I'll double check the SVS Tails version but iirc it should be a recent Tails 4 release.
Wondering if something was rolled back in Tails land.
Yeah running the command from the 0.12.1 docs does not seem to fix the Extract here/to workflow. Still just decompresses without original name and extension.
So for now we'll just have to hammer home the use of file roller in training, and try to mitigate the confusion that generally happens when they see a file both in Nautilus and the File Roller window, which doesn't close itself after extraction.
There's also a kleopatra bug tracker on the gpg bugtracker :| https://dev.gnupg.org/tag/kleopatra/ (but couldn't find anything related to this there, but it seems much more active)
Can't use context menu -> Extract here since that still borks Excel files.
@huertanix I added a recco a while ago to never use "Extract here" because of the filename issue, in https://docs.securedrop.org/en/stable/journalist.html
Always extract gzip archives with the Archive Manager application, which is the default when double-clicking the archive. Other methods may not preserve the filename contained in the archive.
For example, an archive called 1-artful_elevation-doc.gz might contain a file secrets.docx, but if you extract the contents by right-clicking the archive and selecting Extract here, the extracted file will be called 1-artful_elevation-doc instead of secrets.docx. This may result in problems when attempting to open the file due to the loss of its file extension.
Yeah I think I may peruse the Tails bug tracker to see if there's an open issue for the Extract here flow.
We can abstract all of that away in Qubes-land, fortunately.
I love that
gzip's default behavior is to ignore the filename of the compressed file entirely. You have to explicitly tell it "I care about filenames, actually"
We are running a playbook against the tails workstations, could we maybe fix up mimetypes for .gpgs?
I guess we'd have to distinguish the key vs file case somehow tho
Fair point. I wonder if it would be an idea to recommend holding off on svs upgrades until said workflow is sorted
Hello once again all! SecureDrop 2.4.0-rc1 is now available for testing, check out freedomofpress/securedrop#6440 for details.
Submitted a bug report to Tails fam for the gz compression issue: https://gitlab.tails.boum.org/tails/tails/-/issues/18977
Hello yet again all! The next SecureDrop candidate, 2.4.0-rc2 is now available for testing. Check out freedomofpress/securedrop#6440 for details.
Hey all, we've pushed the release date for 2.4.0 to 2022-05-24. As a result, the translation window for the SecureDrop 2.4.0 release has been extended to 2022-05-23 00:00Z. We are especially in need of translation and review for the following languages:
- Hindi (hi): at risk of losing support in SecureDrop 2.5.0
- Romanian (ro): at risk of losing support in SecureDrop 2.5.0
- Slovak (sk)
- Portuguese (Portugal; pt_PT) was added as a new language in this cycle but will not be able to be included in SecureDrop 2.4.0 unless it reaches 100% translation coverage.
Assistance with any of the above in Weblate would be greatly appreciated
Just dropping by to say the pt_PT is now at 100% completion both for the SecureDrop web server as well as the workstation client. Hopefully it can now be shipped in the next release :) https://weblate.securedrop.org/languages/pt_PT/securedrop/#overview
