GitHub repository for the SecureDrop whistleblower platform. Do not submit tips here!

Overview

CircleCI branch codecov Translation status Gitter

SecureDrop is an open-source whistleblower submission system that media organizations can use to securely accept documents from, and communicate with anonymous sources. It was originally created by the late Aaron Swartz and is currently managed by the Freedom of the Press Foundation.

Documentation

SecureDrop's documentation is built and hosted by Read the Docs at https://docs.securedrop.org. It is maintained in a standalone repository: https://github.com/freedomofpress/securedrop-docs

By default, the documentation describes the most recent SecureDrop release. This is known as the stable version and is recommended for end users (Sources, Journalists, or Administrators). The latest documentation is automatically built from the most recent commit to the SecureDrop documentation repository. It is most useful for developers and contributors to the project. You can switch between versions of the documentation by using the toolbar in the bottom left corner of the Read the Docs screen.

Found an issue?

If you're here because you want to report an issue in SecureDrop, please observe the following protocol to do so responsibly:

How to Install SecureDrop

See the Installation Guide.

How to Use SecureDrop

How to Contribute to SecureDrop

See our contribution page.

Developer Quickstart

Ensure you have Docker installed and:

make dev

This will start the source interface on 127.0.0.1:8080 and the journalist interface on 127.0.0.1:8081. The credentials to login are printed in the Terminal.

License

SecureDrop is open source and released under the GNU Affero General Public License v3.

Wordlists

The wordlist we use to generate source passphrases come from various sources:

Acknowledgments

A huge thank you to all SecureDrop contributors! You can see just code and documentation contributors in the "Contributors" tab on GitHub, and you can see code, documentation and translation contributors together here.

Comments
  • daily email alert to journalists about submissions received in the past 24h

    daily email alert to journalists about submissions received in the past 24h

    Status

    Ready for Review

    Description of Changes

    Fixes #1195

    A cron job runs daily on the app server and updates the

    /var/lib/securedrop/submissions_today.txt
    

    file which contains the number of submissions sent in the past 24h, as created by the manage.py how_many_submissions_today command.

    The OSSEC agent on the app server runs a command daily, displaying the content of /var/lib/securedrop/submissions_today.txt. The output of the command is sent to the OSSEC server.

    A new rule is defined on the OSSEC server to send a mail to when the output is received from the OSSEC agent running on the app server.

    A new procmail rule is definied on the OSSEC server to catch mails encrypt mails containing the /var/lib/securedrop/submissions_today.txt string and send them to the email defined by the journalist_alert_email ansible variable.

    A new set of (optional) ansible variables, similar to ossec_alert_gpg_public_key, ossec_gpg_fpr, ossec_alert_email are defined: journalist_alert_gpg_public_key, journalist_gpg_fpr, journalist_alert_email. They are used to upload a journalist public key to the OSSEC server and inserted into the send_encrypted_alarm.sh script which handles mails received by procmail.

    The modified send_encrypted_alarm.sh script takes one argument (journalist or ossec) and dispatches the mail read from stdin to the corresponding recipient.

    Integration tests are implemented to verify the following:

    • manage.py how_many_submissions_today
    • the app OSSEC agent sends a mail to the journalist address
    • cover all branches of send_encrypted_alarm.sh

    Testing

    • make build-debs
    • vagrant up /staging/
    • ./testinfra/test.py staging
    Running Testinfra suite against 'staging'...
    Target roles:
        - testinfra/ossec
    ==================================================================== test session starts =====================================================================
    platform linux2 -- Python 2.7.13, pytest-3.3.1, py-1.5.2, pluggy-0.6.0 -- /home/loic/software/securedrop/virtualenv/bin/python2
    cachedir: .cache
    rootdir: /home/loic/software/securedrop/securedrop, inifile: setup.cfg
    plugins: testinfra-1.7.1, xdist-1.21.0, forked-0.2
    collected 10 items                                                                                                                                           
    
    testinfra/ossec/test_journalist_mail.py::TestJournalistMail::test_procmail[ansible://app-staging] SKIPPED                                              [ 10%]
    testinfra/ossec/test_journalist_mail.py::TestJournalistMail::test_send_encrypted_alert[ansible://app-staging] SKIPPED                                  [ 20%]
    testinfra/ossec/test_journalist_mail.py::TestJournalistMail::test_missing_journalist_alert[ansible://app-staging] SKIPPED                              [ 30%]
    testinfra/ossec/test_journalist_mail.py::TestJournalistMail::test_ossec_rule_journalist[ansible://app-staging] SKIPPED                                 [ 40%]
    testinfra/ossec/test_journalist_mail.py::TestJournalistMail::test_journalist_mail_notification[ansible://app-staging] SKIPPED                          [ 50%]
    testinfra/ossec/test_journalist_mail.py::TestJournalistMail::test_procmail[ansible://mon-staging] PASSED                                               [ 60%]
    testinfra/ossec/test_journalist_mail.py::TestJournalistMail::test_send_encrypted_alert[ansible://mon-staging] PASSED                                   [ 70%]
    testinfra/ossec/test_journalist_mail.py::TestJournalistMail::test_missing_journalist_alert[ansible://mon-staging] PASSED                               [ 80%]
    testinfra/ossec/test_journalist_mail.py::TestJournalistMail::test_ossec_rule_journalist[ansible://mon-staging] PASSED                                  [ 90%]
    testinfra/ossec/test_journalist_mail.py::TestJournalistMail::test_journalist_mail_notification[ansible://mon-staging] PASSED                           [100%]
    
    ====================================================================== warnings summary ======================================================================
    None
      Module already imported so cannot be rewritten: testinfra
    
    -- Docs: http://doc.pytest.org/en/latest/warnings.html
    ===================================================== 5 passed, 5 skipped, 1 warnings in 106.35 seconds ======================================================
    

    Comments

    See the forum discussion for the rationale behind the testinfra: remove some XXX tests duplicating Ansible commits.

    Deployment

    • The journalist emails is not set for existing installations, nothing will happen
    • During sdconfig the admin will be prompted for the email of the journalist and the encryption key. If set, the daily notification mails will be sent.

    Checklist

    If you made changes to the app code:

    • [x] Unit and functional tests pass on the development VM

    If you made changes to the system configuration:

    If you made changes to documentation:

    • [x] Doc linting passed locally
    feature goals: journalist experience OSSEC 
    opened by ghost 51
  • Add basic message filtering in the SI

    Add basic message filtering in the SI

    Status

    Work in progress (tests required)

    Description of Changes

    Fixes #6297. Fixes #6298.

    adds options in the JI instance config, and in the SI, to:

    • set a minimum message length for source's initial messages, as per #6297
    • reject initial messages that consist of the source's codename, as per #6298

    Testing

    • check out this branch and run make dev

    minimum message length

    • in the JI, navigate to the Instance Config page via the Admin page
      • [x] verify that the Submission Preferences section includes a "Prevent sources from sending initial messages shorter than the minimum required length" option, currently unchecked and with the length field set to 0.
    • check the "Prevent sources from sending initial messages shorter than..." checkbox but do not set a length. Click Update Submission Preferences
      • [x] verify that the checkbox is unchecked and an error message is displayed asking you to set a length.
    • check the "Prevent sources from sending initial messages shorter than..." checkbox and set a length of between 5 and 20 chars. Click Update Submission Preferences
      • [x] verify that the checkbox is checked, the length you chose is set, and a success message is displayed.
    • Create a new source account on the SI, navigating through to the /lookup page
      • [x] verify that a notice is displayed under the message textfield like "If you are only sending a message, it must be at least N characters long" where N is the length you chose above
      • [x] Verify that if you try to submit too short a message, the submission fails with a flashed error like "Your first message must be at least N characters long"
      • [x] Verify that a message N characters long can be submitted successfully
      • [x] after a successful first submission, verify that the notice under the text field is no longer displayed and you can submit message shorter than N chars
      • [x] in the JI, uncheck the "Prevent sources from sending initial messages shorter than..." checkbox,, click Update Submission Prefs and verify that the length is set to zero and a success message is displayed
      • [x] Create a new source account in the SI and verify that no message length limit is mentioned or set

    codename messages

    • in the JI, navigate to the Instance Config page via the Admin page
      • [x] verify that the Submission Preferences section includes a "Prevent sources from submitting their codename as an initial message." option, currently unchecked.
    • check the "Prevent sources from submitting their codename as an initial message" checkbox. Click Update Submission Preferences
      • [x] verify that the checkbox is checked and a success message is displayed.
    • Create a new source account on the SI, navigating through to the /lookup page
      • [x] Enter the codename as a message and click Submit - verify that the message is not submitted and an error is flashed like "Please do not submit your codename.."
      • [x] Enter anything else as a message and click Submit - verify that the message was submitted correctly
      • [x] Enter your codename again and click Submit - verify that the message was submitted correctly.

    Deployment

    DB migration script required, but new functionality is disabled by default.

    Checklist

    If you made changes to the server application code:

    • [ ] Linting (make lint) and tests (make test) pass in the development container

    If you made non-trivial code changes:

    • [ ] I have written a test plan and validated it for this PR

    Choose one of the following:

    • [ ] I have opened a PR in the docs repo for these changes, or will do so later
    • [x] I would appreciate help with the documentation
    • [ ] These changes do not require documentation
    opened by zenmonkeykstop 39
  • Include various client related strings in test data

    Include various client related strings in test data

    Status

    Ready for review

    Description of Changes

    Fixes https://github.com/freedomofpress/securedrop-client/issues/1080

    Adds many different test strings to test securedrop-client text formatting.

    Testing

    • [ ] make dev should have 2 sources
    • [ ] NUM_SOURCES=10 make dev should create 10 sources
    • [ ] NUM_SOURCES=ALL make dev shoudl create 43 sources
    • [ ] Use the securedrop-client against the local server and look many strange looking texts :)

    Deployment

    Any special considerations for deployment? Consider both:

    1. Upgrading existing production instances.
    2. New installs.

    Checklist

    If you made changes to the server application code:

    • [ ] Linting (make lint) and tests (make test) pass in the development container

    If you made changes to securedrop-admin:

    • [ ] Linting and tests (make -C admin test) pass in the admin development container

    If you made changes to the system configuration:

    If you made non-trivial code changes:

    • [ ] I have written a test plan and validated it for this PR

    If you made changes to documentation:

    • [ ] Doc linting (make docs-lint) passed locally

    If you added or updated a code dependency:

    Choose one of the following:

    • [ ] I have performed a diff review and pasted the contents to the packaging wiki
    • [ ] I would like someone else to do the diff review
    opened by kushaldas 38
  • Increase bcrypt cost factor

    Increase bcrypt cost factor

    We currently use the default number of rounds (edit: cost factor, see below comments) for bcrypt to hash the codenames - 12. We could easily make brute force attacks more difficult by increasing this value. Given our threat model, 12 might not be enough.

    Thanks to John Adams for reporting this issue.

    opened by garrettr 37
  • Add v3 onion support to tor-hidden-services ansible role

    Add v3 onion support to tor-hidden-services ansible role

    Status

    Ready for review

    Description of Changes

    Fixes #4628 Fixes #4667

    Started adding related Ansible changes to have v3 onion services (including the authenticated ones).

    Testing

    v3 only

    • [ ] Fresh install
    • [ ] Rerun ./securedrop-admin install on a already installed system.

    For both the options above, make the following two changes in install_files/ansible-base/group_vars/all/site-specific

    v2_onion_services: false
    v3_onion_services: true
    

    For this case:

    v2/v3 alongside

    v2_onion_services: true
    v3_onion_services: true
    

    For this:

    v2 only

    There is also the third point to test which is not adding v2_onion_services or v3_onion_services to site-specific and instead the default values (v2 on, v3 off).

    This should keep the current v2 systems as it is, and no v3 details should be generated in the servers.

    Deployment

    Any special considerations for deployment? Consider both:

    1. Upgrading existing production instances.
    2. New installs.

    Checklist

    If you made changes to the server application code:

    • [ ] Linting (make lint) and tests (make -C securedrop test) pass in the development container

    If you made changes to securedrop-admin:

    • [ ] Linting and tests (make -C admin test) pass in the admin development container

    If you made changes to the system configuration:

    If you made non-trivial code changes:

    • [ ] I have written a test plan and validated it for this PR

    If you made changes to documentation:

    • [ ] Doc linting (make docs-lint) passed locally
    opened by kushaldas 34
  • Improvements in image upload functionality

    Improvements in image upload functionality

    Status

    Ready for review

    Description of Changes

    This PR-

    1. Fixes #2807 by resizing the uploaded logo to a maximum width of 500px, or a maximum height of 450px (whichever is higher) while maintaining the original aspect ratio. Maximum limit is chosen in accordance with the recommended size by SecureDrop docs. Images with dimensions below this constraint are not resized.

    2. Fixes #3043 by converting JPG/JPEG image files to PNG before saving them. Thus no matter which format the Admin chooses to upload, the final image is always a PNG file.

    3. Possibly fixes #2801 by adding a message at the logo upload screen informing the user about the recommended image size as per the docs.

    fofvv3l

    1. Fixes #3058 by only accepting valid image files.

    screenshot from 2018-02-22 22-27-11

    Dependencies Introduced

    1. Python Pillow, installed via pip

    2. libjpeg-dev, installed via apt

    Testing

    1. After successfully uploading, image size can be verified by checking the dimensions of securedrop/securedrop/static/i/custom_logo.png.

    2. After successfully uploading a JPG/JPEG image, it can be verified that securedrop/securedrop/static/i/ always contains custom_logo.png

    3. Journalist app should display the recommended size on the upload page.

    4. Try to upload a non-image file with an extension like JPG/JPEG/PNG. A warning message should appear that image cannot be processed.

    Checklist

    If you made changes to the app code:

    • [x] Unit and functional tests pass on the development VM
    UX goals: journalist experience 
    opened by aydwi 34
  • refactor ./securedrop-admin sdconfig from Ansible to python.

    refactor ./securedrop-admin sdconfig from Ansible to python.

    Status

    Ready for Review

    Description of Changes

    Fixes #2522

    Refactor ./securedrop-admin sdconfig from Ansible to python.

    Act I

    The commits up to securedrop-admin: refactor sdconfig as a python script included implement the basic features securedrop-admin needs to replace the YAML implementation. It produces the site-specific file will all know and love. With the nice addition that it can also be used to update it. The current value is displayed for the user to edit (with emacs & vi bindings) and is validated as soon as the user hits enter. Verifications involving multiple variables (i.e. fingerprint and public key) are done at the very end.

    Act II

    Each securedrop-admin: refactor sdconfig ABC commit is a replacement for the implementation of the corresponding YAML variable found in site-specific. Validation classes are implemented when a variable needs it and not in a different commit although they can be re-used later. Each variable is implemented in the order in which they originally showed in the Ansible implemenation. With the notable exception of the securedrop-admin: define ValidatePath commit which is a reminder of the ancient time when the logo was updated from securedrop-admin instead of the journalist admin interface.

    Act III

    Over time securedrop-admin grew from a tiny standalone script isolated at the root of the git repository to a handsome young module who moved with its relatives down in the securedrop directory. Alas, its users were different and it became clear securedrop-admin had to move to its own directory: admin. From ansible: trim validate role comment now obsolete up it got a setup.py, requirements and tox to run the tests, a Dockerfile and a Makefile to help the CI. It also was split in two: the setup action is now a standlone bootstrap.py script instead of being included in a rather contorted way into a single standalone script.

    Epilogue

    One day securedrop-admin could be uploaded to pypi and have its own repository even. But that's a story for another time.

    Testing

    In both Tails and the development environment, try to enter invalid (non existent domain name) or inconsistent (fingerprint not matching the public key) values to check the resulting interaction.

    In the Debian GNU/Linux stretch development environment

    • ./securedrop-admin setup
    • ./securedrop-admin sdconfig
    • fill all values
    • verify install_files/ansible-base/group_vars/all/site-specific has the desired variables and values

    In Tails

    • setup tails with persistence
    • git clone -b wip-dachary-2522-sdconfig https://github.com/freedomofpress/securedrop
    • cd securedrop
    • ./securedrop-admin setup
    • ./securedrop-admin sdconfig
    • verify install_files/ansible-base/group_vars/all/site-specific has the desired variables and values
    • ./securedrop-admin sdconfig # and change one value
    • vierify install_files/ansible-base/group_vars/all/site-specific has the desired variables and values

    In CI

    • verify the new .circleci/config.yml target admin-tests actually runs

    Deployment

    It is supposed to be a backward compatible replacement of `./securedrop-admin sdconfig``, reason why the documentation is not modified.

    Checklist

    If you made changes to the app code:

    • [x] Unit and functional tests pass on the development VM

    If you made changes to documentation:

    • [x] Doc linting passed locally
    feature ops/deployment 
    opened by ghost 32
  • Prevent automated submissions (CAPTCHA)

    Prevent automated submissions (CAPTCHA)

    Changed name due to debate over whether CAPTCHA is right method to use. Consensus is on developing a responsive approach that combines several methods, including CAPTCHAs.

    help wanted stale 
    opened by klpwired 30
  • make file submissions dis/allowable

    make file submissions dis/allowable

    Status

    Ready for review

    • See next section for tests outstanding

    Status of requested changes (since b5d493c)

    1. [x] fix: "Error strings [...], and also in the inline comment securedrop/source_templates/lookup.html, which could be confusing to sources." (1, 2)

    2. [x] fix: "Bug: textarea width on Source Interface"

    3. [x] refactor: "Proposed alternative language" for "Instance Configuration" page

      1. [x] fix: "UX issue: 'Update' button on Instance Configuration page"
      2. [x] fix: "UX issue: 'Document Uploads', 'Allow' language on Instance Configuration page"
    4. [x] refactor: versioned instance_config

      1. [x] "one configuration option per column"
      2. [x] migration to add column sets default value
      3. [x] "use the configuration option that has null valid_until. When we update a config, we store the historical configuration entry by setting valid_until=datetime.datetime.utcnow(), then store the new configuration with null valid_until."
      • [x] test: migrations
    5. [x] test: integration test

    Description of Changes

    1. [x] InstanceConfig versioned key-value store as outlined

      • [x] load_instance_config() sets each app's app.instance_config (via @before_request)
    2. [x] Source interface checks app.instance_config.allow_document_uploads; if False:

      1. /lookup hides the file input and
      2. changes its heading to "Submit Messages" (rather than "Submit Files or Messages") and other strings accordingly; and
      3. /submit skips processing of request.files.
      4. /metadata returns this setting as allow_document_uploads.
    3. [x] Journalist interface:

      1. /admin/config adds a section "Submission Preferences"; and
      2. /admin/update-submission-preferences updates InstanceConfig.allow_document_uploads.

    Testing

    Test by toggling the Prevent sources from uploading documents checkbox in the "Submission Preferences" section of the "Instance Config" view.

    1. If unchecked (default): Observe no changes from current behavior.

    2. If checked: Observe the changes described in (2) and (3) above.

    Deployment

    No action required. After upgrading, administrators may use the "Submission Preferences" section of the "Instance Config" view.

    Checklist

    If you made changes to the server application code:

    • [x] Linting (make lint) and tests (make test) pass in the development container
      • [x] Fix tests/test_i18n.py::test_verify_default_locale_en_us_if_not_defined_in_config (expected by end of day Monday, October 21)
    opened by wbaid 29
  • Some Source Interface uploads fail with Internal Server Error

    Some Source Interface uploads fail with Internal Server Error

    Description

    The SD Source Interface should support file uploads of up to 500MB, with larger uploads failing immediately. Instead, large file uploads <500MB are frequently failing after a long timeout.

    (This was initially reported as happening with files of 50MB or more, but it isn't consistently reproducible at that size.)

    Steps to Reproduce

    Using VMs or a hardware instance:

    1. Visit the Source Interface using the Tor Browser
    2. Click through to the /lookup page
    3. Upload a large file (50MB+)

    Expected Behavior

    File upload completes with success message on page.

    Actual Behavior

    Upload has a pretty good chance of failing with message below:

    screen-shot-2019-01-28-at-11 52 40-am bug priority/high able to reproduce 
    opened by zenmonkeykstop 29
  • Visualization of the SecureDrop architecture

    Visualization of the SecureDrop architecture

    Forking this from #249.

    @aegis said:

    Would be great to also present a graphic visualization of the SecureDrop system, like the 'Cryptocat Threat Model Connections Overview' image https://github.com/cryptocat/cryptocat/wiki/Threat-Model

    priority/low 
    opened by garrettr 29
  • Use shellcheck-py

    Use shellcheck-py

    Description

    We could use https://github.com/shellcheck-py/shellcheck-py to install shellcheck instead of relying on a docker image or OS-installed version.

    This would be more consistent with the rest of our developer tooling, making it easier to use.

    Learned about this via https://gerrit.wikimedia.org/r/plugins/gitiles/integration/config/+/de712d13fb2e7e3426cac11ee6dca533c4e973ce/tox.ini#30

    opened by legoktm 0
  • Develop automation to test new kernels

    Develop automation to test new kernels

    Splitting from https://github.com/freedomofpress/securedrop/issues/6514

    We now have a decent set of steps to run when testing new kernel builds documented at https://developers.securedrop.org/en/latest/kernel.html. In brief, it's to 1) run paxtest, 2) then meltdown-checker, and 3) then running a basic SecureDrop smoke test.

    At least 1 and 2 are easily automated, 3 could be with a bit more effort, but I think we can ignore it for now.

    My proposal for now is:

    • we have a script run on a timer, daily. It checks the latest kernel version, and if it's different from the latest stored version, it starts running the checks
    • the script installs the necessary apt dependencies, runs paxtest, capturing the output.
    • it downloads the latest meltdown-checker, runs it and captures the output.
    • it sends an email to securedrop@ (or some other address), with the log files for human review.

    Using email mostly avoids us needing to have some central actor/collector that logs into each node to run the tests or see the output.

    Presumably there would be some ansible role that enables the apt-test repo and installs the script.

    opened by legoktm 0
  • Retrying a failed download from a SecureDrop results in a 4k empty file being saved to disk

    Retrying a failed download from a SecureDrop results in a 4k empty file being saved to disk

    Description

    After a download from a SecureDrop fails when accessed from a Journalist Workstation, if you click the 'Retry' button, it "completes" the download by saving a 4kb empty text file, rather than the original submission.

    Steps to Reproduce

    1. Fill the local filesystem with enough data to nearly be out of storage space.
    2. Download a relatively large submission from a SecureDrop instance.
    3. The download should fail once the filesystem runs out of space.
    4. Make some more room on the disk.
    5. Click "Retry" on the download from inside Tor browser.
    6. An empty file will be downloaded.

    Expected Behavior

    Clicking "Retry" downloads the original submission.

    Actual Behavior

    Clicking "Retry" downloads an empty file.

    opened by nathandyer 1
  • Add a GNOME Shell Extension

    Add a GNOME Shell Extension

    Status

    Work in progress

    Description of Changes

    Fixes # 6531

    Changes proposed in this pull request:

    This adds a GNOME Shell extension to the Journalist and Admin Workstations. The goal of the extension is to provide a more consistent and better-supported method for linking a user to their SecureDrop interfaces, and to make it easier to access the management features of SecureDrop.

    As of now, the extension looks like this:

    sdgse

    The Shell Extension gets saved into the appropriate .dotfiles directory as part of the tailsconfig Ansible task, during install or upgrade.

    Although the code here is functional and can be included in the main project as-is, the intent of this PR is to provide a firmer foundation for testing and discussion. Every menu entry in the extension is functional, and it is ready for wider testing.

    There are some additional concerns that need to be ironed out:

    • Do we want to keep the icon in the titlebar where the extension is accessed? If so, do we use the generic icon, or do we create/install a symbolic SD icon?
    • Do we want to dynamically hide the administrative options when it is being used only on a journalist workstation? If yes, what is the most reliable method of detecting that difference?
    • Do we want to remove the current desktop icons altogether, or have this in addition to those icons (either temporarily or indefinitely until that support is removed from Tails)?

    Testing

    This needs to be widely tested across multiple installs.

    At a minimum, we should:

    • [x] Test that the extension gets added and activated with a clean install
    • [ ] Test that the extension gets added and activated while upgrading an existing install
    • [x] Test that each menu item in the extension reliably triggers the labeled action

    Deployment

    Deployment should be straight-forward, although as mentioned above, we need to test thoroughly for both clean install and upgrade paths.

    I have already tested with a clean install, and it should work with an upgrade, but would appreciate other confirmations.

    Checklist

    If you made changes to the server application code:

    • [x] Linting (make lint) and tests (make test) pass in the development container

    If you made changes to the system configuration:

    If you added or removed a file deployed with the application:

    • [ ] I have updated AppArmor rules to include the change

    If you made non-trivial code changes:

    • [ ] I have written a test plan and validated it for this PR

    Choose one of the following:

    • [x] I have opened a PR in the docs repo for these changes, or will do so later
    • [ ] I would appreciate help with the documentation
    • [ ] These changes do not require documentation
    opened by nathandyer 0
  • Stop pinning the

    Stop pinning the "builder" docker image

    Description

    We build our packages in a container using a custom docker image (see molecule/builder-focal). The way the image is currently used is that it's frozen/pinned, pushed to quay.io, and then the person building the packages will pull it down and use it, as is. But if there are any missing security updates, the build will fail after the fact and then you need to go through the hurdle of updating the builder, rebuilding packages, etc.

    Also during the last builder update, I noticed that the logic to detect pending security updates itself was buggy, because it simulates a dist-upgrade and sees if any packages will be pulled in from focal-security, except we don't intend to do a dist-upgrade, so it complaining that a package not in the container was a pending security update!

    The theory is that pinning the builder helps with reproducible builds, except it doesn't because the build isn't reproducible for other reasons.

    Proposal

    We just build the image on the fly. At runtime we see if there are any pending updates and if so, bail. The deployer can rebuild the image locally and restart the package building. For reproducibility, we will implement #6356, but that shouldn't block this.

    opened by legoktm 0
  • Convert cron jobs into systemd timers

    Convert cron jobs into systemd timers

    Description

    Port our 2 cron jobs into systemd timers

    Rationale

    • systemd timers are nicer to deal with, they have more configuration knobs and provide more diagnostic output
    • timers are defined in files, so manipulating them is much easier than needing to use something like ansible comments for crontabs
      • consider that efb2c766fe388c9cb22ac8c7bb5c89c214b7ddce would've just been adjusting the User=www-data line instead of needing to write and test a hacky bash migration step
    opened by legoktm 0
Releases(2.5.1)
  • 2.5.1(Dec 8, 2022)

  • 2.5.0(Oct 19, 2022)

    SecureDrop 2.5.0 was released on October 18, 2022. In addition to other fixes and improvements, it included new server-side session handling for the Journalist Interface and API, updates to production dependencies, and miscellaneous improvements in the Source and Journalist interfaces.

    Source code(tar.gz)
    Source code(zip)
  • 2.4.2(Aug 9, 2022)

    SecureDrop 2.4.2 was released on August 9, 2022. It updated the Linux kernel version used by the SecureDrop servers from 5.15.26 to 5.15.57 to include patches for the recently discovered Retbleed security issue.

    Source code(tar.gz)
    Source code(zip)
  • 2.4.1(Jul 20, 2022)

    SecureDrop 2.4.1 was released on July 20 2022. It included a fix for a bug that prevented initial messages with non-ASCII characters if the codename filter feature was enabled on the Source Interface.

    Source code(tar.gz)
    Source code(zip)
  • 2.4.0(May 24, 2022)

    SecureDrop 2.4.0 was released on May 24 2022. On top of several bugfixes and other improvements, the frontend of the source interface was refactored and its design updated, improving usability and accessibility. This release also introduces support for using SecureDrop in Portuguese (Portugal), thanks to a volunteer translator.

    Source code(tar.gz)
    Source code(zip)
  • 2.3.2(May 6, 2022)

  • 2.3.1(Apr 11, 2022)

    SecureDrop 2.3.1 was released on April 11 2022. It included fixes for a performance issue on instances with large GPG keyrings and for a bug affecting locale switching on the codename generation page.

    Source code(tar.gz)
    Source code(zip)
  • 2.3.0(Mar 30, 2022)

    SecureDrop 2.3.0 was released on March 29 2022. In addition to other bugfixes and improvements, it included functionality to restrict the use of tor2web proxies, discourage automated submissions, and enable administrators to set simple message filters.

    Source code(tar.gz)
    Source code(zip)
  • 2.2.1(Mar 10, 2022)

    SecureDrop 2.2.1 was released on March 10 2022. It updated the Linux kernel version used by the SecureDrop servers from 5.15.18 to 5.15.26 to include patches for recently discovered security issues.

    Source code(tar.gz)
    Source code(zip)
  • 2.2.0(Feb 17, 2022)

    SecureDrop 2.2.0 was released on February 17, 2022. It included accessibility and security improvements, expanded hardware support, and other bugfixes and enhancements.

    Source code(tar.gz)
    Source code(zip)
  • 2.1.0(Oct 20, 2021)

    SecureDrop 2.1.0 was released on October 19th 2021. It included accessibility improvements to the Source Interface, an increased 2FA secret length, and other bugfixes and improvements.

    Source code(tar.gz)
    Source code(zip)
  • 2.0.2(Aug 12, 2021)

    SecureDrop 2.0.2 was released on August 12th 2021. It updated the Linux kernel version used by the SecureDrop servers from 5.4.97 to 5.4.136 to include patches for recently discovered security issues.

    Source code(tar.gz)
    Source code(zip)
  • 2.0.1(Jul 8, 2021)

    SecureDrop 2.0.1 was released on July 8th 2021. It included dependency updates and test suite improvements, and was the first release with a tag signed with the new SecureDrop signing key.

    Source code(tar.gz)
    Source code(zip)
  • 2.0.0(Jun 23, 2021)

    SecureDrop 2.0.0 was released on June 23rd 2021. It removes support for installation on Ubuntu 16.04, removes support for v2 onion services, updates the logic for reply key generation, and includes many other fixes.

    Source code(tar.gz)
    Source code(zip)
  • 1.8.2(May 18, 2021)

    SecureDrop 1.8.2 was released on May 18th 2021. This release includes bugfixes for OSSEC alerts, the server restore playbook, and the Journalist Interface. It also includes a new public key to support a planned signing key rotation.

    Source code(tar.gz)
    Source code(zip)
  • 1.8.1(Apr 14, 2021)

  • 1.8.0(Mar 11, 2021)

    SecureDrop 1.8.0 was released on March 11th 2021. This release includes support for Ubuntu 20.04 (Focal Fossa), and several other improvements.

    Source code(tar.gz)
    Source code(zip)
  • 1.7.1(Jan 27, 2021)

    SecureDrop 1.7.1 was released on January 27, 2021. This is a bugfix release, resolving an issue affecting availability of Source and Journalist Interfaces for a subset of instances.

    Source code(tar.gz)
    Source code(zip)
  • 1.7.0(Jan 27, 2021)

    SecureDrop 1.7.0 was released on January 26, 2021. This release allows you to configure your organization’s name. It also includes support for Simplified Chinese, a Tor version update, and several bugfixes.

    Source code(tar.gz)
    Source code(zip)
  • 1.6.0(Oct 7, 2020)

    SecureDrop 1.6.0 was released on October 7, 2020. This release included a Tor update, various bugfixes, improved error-handling, and a number of community contributions.

    Source code(tar.gz)
    Source code(zip)
  • 1.5.0(Jul 28, 2020)

    SecureDrop 1.5.0 was released on July 28, 2020. This release included a kernel update, deprecation warnings for v2 onion services, improved error-handling in the API, and a number of community contributions

    Source code(tar.gz)
    Source code(zip)
  • 1.4.1(Jun 25, 2020)

    SecureDrop 1.4.1 was released on June 25, 2020. This release included a fix for the securedrop-admin utility, to correctly validate the instance configuration when v3 onion services are disabled.

    Source code(tar.gz)
    Source code(zip)
  • 1.4.0(Jun 18, 2020)

    SecureDrop 1.4.0 was released on June 17, 2020. This release included: version update to Tor 0.4.3.5; improved validation of server configuration changes and detection of misconfigurations; update to the SecureDrop release signing key expiration date; and several additions to documentation.

    Source code(tar.gz)
    Source code(zip)
  • 1.3.0(May 14, 2020)

    SecureDrop 1.3.0 was released on May 13, 2020. This release included: UI and behavior updates to the Source Interface; version updates to OSSEC, Tor, and the grsecurity-patched kernel; and many smaller changes and bugfixes.

    Source code(tar.gz)
    Source code(zip)
  • 1.2.2(Mar 16, 2020)

    SecureDrop 1.2.2 was released on March 16, 2020. This release contained dependency updates to address a security vulnerability in psutil (CVE-2019-18874) and fix a bug preventing updates to the Admin and Journalist Workstation virtualenv.

    Source code(tar.gz)
    Source code(zip)
  • 1.2.1(Feb 19, 2020)

    SecureDrop 1.2.1 was released on February 19, 2020. This release updated Tor Browser user agent detection, added caching of source keys, and removed the ability to change source codenames/designations.

    Source code(tar.gz)
    Source code(zip)
  • 1.2.0(Dec 4, 2019)

    SecureDrop 1.2.0 was released on December 3, 2019. This release added the option to disable document uploads in the Source Interface, improved submission cleanup using systemd, and updated the grsecurity-patched kernel to version 4.14.154.

    Source code(tar.gz)
    Source code(zip)
  • 1.1.0(Oct 21, 2019)

    SecureDrop 1.1.0 was released on October 21, 2019. This release includes migration of the admin code to Python 3 and support for Tails 4.

    Source code(tar.gz)
    Source code(zip)
  • 1.0.0(Sep 17, 2019)

    SecureDrop 1.0.0 was released on September 17, 2019. This release includes support for v3 onion services, faster and more reliable deletion, migration of the application code to Python 3, a UI and default logo update, and several other changes.

    Source code(tar.gz)
    Source code(zip)
  • 0.14.0(Jul 10, 2019)

    SecureDrop 0.14.0 was released on July 10, 2019. This release includes a kernel update, a change to a new default GPG keyserver, a feature to allow configuring full names for journalist accounts, the addition of Catalan as a new supported language, and other small fixes and updates.

    Source code(tar.gz)
    Source code(zip)
Owner
Freedom of the Press Foundation
Defending and supporting cutting-edge transparency journalism in the face of adversity.
Freedom of the Press Foundation
Askbot is a Django/Python Q&A forum. **Contributors README**: https://github.com/ASKBOT/askbot-devel#how-to-contribute. Commercial hosting of Askbot and support are available at https://askbot.com

ATTENTION: master branch is experimental, please read below Askbot - a Django Q&A forum platform This is Askbot project - open source Q&A system, like

ASKBOT 1.5k Dec 28, 2022
Abilian Social Business Engine - an enterprise social networking / collaboration platform.

About Abilian SBE (Social Business Engine) is a platform for social business applications, and more specifically collaborative / enterprise 2.0 busine

Abilian open source projects 63 Dec 29, 2022
GlobaLeaks is free, open source software enabling anyone to easily set up and maintain a secure whistleblowing platform.

GlobaLeaks is free, open souce software enabling anyone to easily set up and maintain a secure whistleblowing platform. Continous Integration and Test

GlobaLeaks 995 Jan 1, 2023
Submit issues and feature requests for our API here.

AIx GPT API Submit issues and feature requests for our API here. See https://apps.aixsolutionsgroup.com for more info. Python Quick Start pip install

AIx Solutions 7 Mar 27, 2022
Github-Checker - Simple Tool To Check If Github User Available Or Not

Github Checker Simple Tool To Check If Github User Available Or Not Socials: Lan

ميخائيل 7 Jan 30, 2022
A collection of various deep learning architectures, models, and tips

Deep Learning Models A collection of various deep learning architectures, models, and tips for TensorFlow and PyTorch in Jupyter Notebooks. Traditiona

Sebastian Raschka 15.5k Jan 7, 2023
Tips that improve your life in one way or another

Tips that improve your life in one way or another. This software downloads life tips from reddit.com/r/LifeProTips and tweet the most upvoted tips on Twitter.

Burak Tokman 2 Aug 4, 2022
A collection of tips for using MISP.

MISP Tip of the Week A collection of tips for using MISP. Published via BelgoMISP (todo) and this repository. Available in MD and JSON. Do you want to

Koen Van Impe 52 Jan 7, 2023
Generate links that users can use to submit messages encrypted with your public key.

Hawkpost Hawkpost lets you create unique links that you can share with the person that desires to send you important information but doesn't know how

Whitesmith 901 Dec 27, 2022
A Scapy implementation of SMS-SUBMIT and (U)SIM Application Toolkit command packets.

A Scapy implementation of SMS-SUBMIT and (U)SIM Application Toolkit command packets.

mnemonic 83 Dec 11, 2022
generate HPC scheduler systems jobs input scripts and submit these scripts to HPC systems and poke until they finish

DPDispatcher DPDispatcher is a python package used to generate HPC(High Performance Computing) scheduler systems (Slurm/PBS/LSF/dpcloudserver) jobs in

DeepModeling 23 Nov 30, 2022
Repo for All the Assignments I have to submit for Internship Application !😅

Challenges Repository for All the Assignments I have to submit for Internship Application ! ?? As You know, When ever We apply for an Internship, They

keshav Sharma 1 Sep 8, 2022
Python wrapper class for OpenVINO Model Server. User can submit inference request to OVMS with just a few lines of code

Python wrapper class for OpenVINO Model Server. User can submit inference request to OVMS with just a few lines of code.

Yasunori Shimura 7 Jul 27, 2022
GitHub Actions Version Updater Updates All GitHub Action Versions in a Repository and Creates a Pull Request with the Changes.

GitHub Actions Version Updater GitHub Actions Version Updater is GitHub Action that is used to update other GitHub Actions in a Repository and create

Maksudul Haque 42 Dec 22, 2022
Generate visualizations of GitHub user and repository statistics using GitHub Actions.

GitHub Stats Visualization Generate visualizations of GitHub user and repository statistics using GitHub Actions. This project is currently a work-in-

JoelImgu 3 Dec 14, 2022
Generate visualizations of GitHub user and repository statistics using GitHub Actions.

GitHub Stats Visualization Generate visualizations of GitHub user and repository statistics using GitHub Actions. This project is currently a work-in-

Aditya Thakekar 1 Jan 11, 2022
This is discord nitro code generator and checker made with python. This will generate nitro codes and checks if the code is valid or not. If code is valid then it will print the code leaving 2 lines and if not then it will print '*'.

Discord Nitro Generator And Checker ⚙️ Rᴜɴ Oɴ Rᴇᴘʟɪᴛ ??️ Lᴀɴɢᴜᴀɢᴇs Aɴᴅ Tᴏᴏʟs If you are taking code from this repository without a fork, then atleast

Vɪɴᴀʏᴀᴋ Pᴀɴᴅᴇʏ 37 Jan 7, 2023
Software to automate the management and configuration of any infrastructure or application at scale. Get access to the Salt software package repository here:

Latest Salt Documentation Open an issue (bug report, feature request, etc.) Salt is the world’s fastest, most intelligent and scalable automation engi

SaltStack 12.9k Jan 4, 2023
The Social-Engineer Toolkit (SET) repository from TrustedSec - All new versions of SET will be deployed here.

?? The Social-Engineer Toolkit (SET) ?? Copyright 2020 The Social-Engineer Toolkit (SET) Written by: David Kennedy (ReL1K) @HackingDave Company: Trust

trustedsec 8.4k Dec 31, 2022