herald-for-android

Repository on GitHub, which provides public git repositories with URLs.

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

We have -beta1/ beta2 semver tags for intermediate releases. We have a public develop branch, and a public master/main branch with v tags for releases from either (depending on whether they are interim releases or not).

Repository on GitHub, which uses git. git is distributed.

https://github.com/theheraldproject/herald-for-android/releases - See release tag and title

We use v* tags. E.g. v1.0, v1.2-beta1

See list of releases here: https://github.com/theheraldproject/herald-for-android/releases

We don't publish a release if there is a known vulnerability to our code.

https://github.com/theheraldproject/herald-for-android/issues

We also provide templates for issues/features.

https://github.com/theheraldproject/herald-for-android/issues

We aim to respond within 5 days

We only close issues, never delete them. https://github.com/theheraldproject/herald-for-android/issues?q=is%3Aissue+is%3Aclosed

As per SECURITY.md file. The Linux Foundation Public Health currently does not have a standard policy or reporting mechanism (E.g. HackerOne) which we can use. I've raised this as an issue for the next TAC meeting. https://github.com/theheraldproject/herald-for-android/blob/develop/SECURITY.md

As per SECURITY.md file. The Linux Foundation Public Health currently does not have a standard policy or reporting mechanism (E.g. HackerOne) which we can use. I've raised this as an issue for the next TAC meeting.

We respond to all issue reports within 5 days. We have issued security patches in the past within 24 hours: https://github.com/theheraldproject/herald-for-android/releases/tag/v1.1.1

Gradle build system for local (developer, adopter) and automated CI (project release via GitHub Actions) builds

We use GitHub Actions and GitHub Packages where possible. We also use the appropriate packaging approach for each system (E.g. Maven Central for this Android repo)

Gradle builds. Maven packages.

Standard approach via gradle test. Branch protection rules for this to be ran for every PR to the develop or master/main branches.

Gradle

Currently covers all core library features. Elements requiring 2 device Bluetooth communication cannot be tested with unit tests, but we have a manual mechanism for this too. We abstract as much into classes as possible so there's little to test physically outside of unit tests.

GitHub Actions has just been implemented.

This is a standard policy. We require developers to use Test Driven Development.

We have just implemented a GitHub CI system that archives the test output HTML for every test as an artifact for each build (which is required for every single PR now). This is new though. There is a major (v2.0) version being released in the coming days adhering to this that all repos will adopt.

It is documented in the new Contributor's guide (published 17 May 2021): https://heraldprox.io/contribute

gradle lint is used

Every major release requires that all warnings are addressed, or documented and ignores with a link to the documentation where the ignore instruction is present. (Not applicable for Android, but the Zephyr C++ build system has such warnings, which is well known in that community).

For the Android/Java project this is done.

Myself (Adam Fowler) in the core committer team and as TSC Chair has this knowledge. Other contributors (not committers) do too.

I (Adam Fowler) has experience of this from industry, including OWASP and mobile application scanning tools. I am also familiar with NCSC secure coding requirements.

RandomSource supports various options. We use the SecureRandom's backup option as we have to support old phones (Dating back to 2010) and old versions of Android that would otherwise block indefinitely, leading to poor epidemiological efficacy for older phones (and thus would disproportionately negatively effect poorer people). See these classes for examples of security steps taken:- - https://github.com/theheraldproject/herald-for-android/tree/develop/herald/src/main/java/io/heraldprox/herald/sensor/datatype/random - https://github.com/theheraldproject/herald-for-android/blob/develop/herald/src/main/java/io/heraldprox/herald/sensor/datatype/PseudoDeviceAddress.java - https://github.com/theheraldproject/herald-for-android/blob/develop/herald/src/main/java/io/heraldprox/herald/sensor/payload/simple/K.java

We use provided cryptography where possible. There is a need in next version of the project to implement our own handshake and token mechanism to prevent relay and replay attacks over the wire. That will use DH and TOTP as a basis though. Initial design can be seen here: https://heraldprox.io/specs/payload-secured

Both our library and any dependencies will be Apache-2.0. OpenJDK implementations of core crypto features are available for Java primitives.

Met where applicable. Library adopters can configure a range of options, and plug in their own where needed.

We follow NIST SP recommendations and NCSC recommendations.

We do this where possible but we don't always use the very latest approaches. This is because, uniquely, we have to support platforms back to iOS 9.3 and Android SDK 21 in order to be widely usable on a very wide range of mobile devices so that poorer communities have access to life saving technology in our Digital Contact Tracing and eHealth solutions. Where a 'lowest common denominator' approach is used, we ensure that adopters can switch in/out a more secure provided algorithm, or replace it with their own algorithm. This allows us to provide maximum reach and recommend best practice without disadvantaging poor communities.

This is the preferred approach but in an anonymous system there are limits to what can be achieved. E.g. for the 'simple payload' a daily key is used to forward generate the 5 minute expiring 'ephemeral keys' for digital contact tracing. This is a 'good thing', as less information needs to be transmitted across mobile networks for devices to realise they have had exposure to an ill person. The identity behind this daily key is not known, and only transmitted to devices after the event and after individuals have been diagnosed. (This is the same way GAEN works). A new Secured Payload will provide this mechanism in a different way. This will use 'tokens' issued over an encrypted mechanism where this token is only exchanged with that device. This will be generated in such a way as to provide for perfect forward secrecy. (There will not be a common key basis to each token).

We don't store secrets. Where key storage features are used, we delegate this to the host OS. (E.g. it's managed in their secure enclaves, where available).

Used where provided by the host device. Where enough entropy is not provided (old Android phones), an external source of additional entropy is used to change the random bytes generated.

Source code: https and git+ssh source access. Builds on GitHub actions natively. Bluetooth transfer: Only certain approaches possible with completely anonymous data exchange. New Secured Payload will issue tokens and hash responses from devices, so even if the originating transfer is MITM'ed, the resultant 'exposure' data would fail to be authenticated.

Not done in our project

No confirmed vulnerabilities. All security mechanisms can also be replaced / switched out by downstream adopters of the library to more secure versions. Due to the wide range of android (SDK 21) and iOS (9.3+) devices we have to support, some options are more secure than others, but adopters can choose their preferred approach for all security functions.

Only time this has been necessary the fix was issued within 24 hours of the project team being notified.

GitHub secrets are used for the build pipeline. No repository contains secrets, usernames, or passwords.

Spotbugs now part of the unit_test GitHub Actions workflow, and ran on every PR to the develop or master/main branches as a pre-requisite check. This check also applies to administrators and cannot be bypassed.

Spotbugs now part of the unit_test GitHub Actions workflow, and ran on every PR to the develop or master/main branches as a pre-requisite check. This check also applies to administrators and cannot be bypassed. We also use the findsecbugs plugin to spotbugs.

A PR cannot be merged without tests passing, including static analysis (as of today). Standard issue report fix (E.g. new vulns, old code) have a target SLA of 5 days.

We use gitflow so commits happen on forks. Every PR though has these required. (I.e. a commit set cannot be merged without these passing).

Java project.