Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 01:55
    cfm edited #6387
  • 01:55
    cfm edited #6387
  • 01:44
    cfm edited #6464
  • 01:41
    cfm review_requested #6466
  • 01:41
    cfm review_requested #6466
  • 01:41
    cfm ready_for_review #6466
  • 01:40
    cfm edited #6466
  • 01:39
    cfm labeled #6466
  • 01:39
    cfm milestoned #6466
  • 01:39
    cfm opened #6466
  • 01:37

    cfm on backport-6464

    Merge pull request #6464 from f… (compare)

  • 01:35

    cfm on backport-6464

    Merge pull request #6464 from f… (compare)

  • 01:28

    eaon on i18n-merge

    (compare)

  • 01:28

    eaon on develop

    l10n: updated Arabic (ar) cont… l10n: updated Catalan (ca) con… l10n: updated Czech (cs) contr… and 17 more (compare)

  • 01:28
    eaon closed #6464
  • 01:27
    eaon edited #6464
  • 01:13
    cfm commented #6380
  • 00:43
    eaon edited #6464
  • May 23 23:56
    cfm edited #6464
  • May 23 23:56
    cfm commented #6464
David Huerta
@huertanix
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?)
David Huerta
@huertanix
@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
rocodes
@rocodes
:eyes:
Kevin O'Gorman
@zenmonkeykstop:matrix.org
[m]
There was a gnome setting iirc that you had to set but it should not be required in tails 4
Kevin O'Gorman
@zenmonkeykstop
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
David Huerta
@huertanix
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.
Kevin O'Gorman
@zenmonkeykstop
the recco from the 0.12.1 docs was to run the following in a terminal on the SVS:
cd /live/persistence/TailsData_unlocked/dotfiles
echo "/usr/bin/dconf write /org/gnome/nautilus/preferences/automatic-decompression false" > .xsessionrc
David Huerta
@huertanix
kk, gonna peek at the dconf file and try running that once I'm in the SVS.
David Huerta
@huertanix
Confirming SVS is tails 4.26.
David Huerta
@huertanix
Confirming that double-click file -> file roller -> Extract -> file location selection flow does keep the file name and extension while Extract here/Extract to does not.
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.
David Huerta
@huertanix
(we meaning trainers)
David Huerta
@huertanix
Hrmmm... in Tails 5, double-clicking .gpg tries to open them in Text Editor by default, which of course fails as it tries to display ascii-armor encoded ciphertext.
legoktm
@legoktm:matrix.org
[m]
David Huerta
@huertanix
Tried choosing to open to Kleopatra via right click/context menu, but it opens it thinking it's a key, so it throws an info prompt saying it processed zero things.
legoktm
@legoktm:matrix.org
[m]
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)
David Huerta
@huertanix
Soooo, for training+docs, the workflow changes so you have to first open Kleopatra from the Applications menu -> Decrypt/Verify -> Save all. Then after that, navigate back to Nautilus, double-click -> highlight file -> Extract -> Extract.
Can't use context menu -> Extract here since that still borks Excel files.
Erik Moeller
@eloquence

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

David Huerta
@huertanix
:cool:
Yeah I think I may peruse the Tails bug tracker to see if there's an open issue for the Extract here flow.
Erik Moeller
@eloquence
@huertanix remember this fun issue :-) freedomofpress/securedrop#2289
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"
David Huerta
@huertanix
:upside_down_face:
Erik Moeller
@eloquence
The whole Kleopatra thing sounds like it may make the workflow significantly less efficient still :/
David Huerta
@huertanix
Yuuup.
Kevin O'Gorman
@zenmonkeykstop:matrix.org
[m]
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
David Huerta
@huertanix
Yeah, the decryption's happening in the SVSs though, but maybe this could be better addressed in Tails upstream.
Kevin O'Gorman
@zenmonkeykstop:matrix.org
[m]
Fair point. I wonder if it would be an idea to recommend holding off on svs upgrades until said workflow is sorted
David Huerta
@huertanix
Yeah, I'm thinking the same thing.
Kevin O'Gorman
@zenmonkeykstop
Hello all! We’ve just opened translations for the upcoming SecureDrop 2.4.0 release. If you have suggestions for source strings, please get them to us by 2022-05-12. Translation will end on 2022-05-18.
Kevin O'Gorman
@zenmonkeykstop
Hello once again all! SecureDrop 2.4.0-rc1 is now available for testing, check out freedomofpress/securedrop#6440 for details.
David Huerta
@huertanix
Submitted a bug report to Tails fam for the gz compression issue: https://gitlab.tails.boum.org/tails/tails/-/issues/18977
Kevin O'Gorman
@zenmonkeykstop
Hello yet again all! The next SecureDrop candidate, 2.4.0-rc2 is now available for testing. Check out freedomofpress/securedrop#6440 for details.
Kevin O'Gorman
@zenmonkeykstop
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
Allie Crevier
@creviera
Thanks @nahara7 for your SecureDrop Workstation contribution (your PR's been merged)! Much appreciated :)
Nahara
@nahara7
Thank youuu !!
deeplow
@deeplow
Hi all! Long time no see!
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
Cory Francis Myers
@cfm
I've replied in more detail in your forum thread, but here too: thanks so very much, @deeplow!
deeplow
@deeplow
happy to help :)