EDS, Encrypted Data Share, works as a "PGP for the Cloud." It is designed as a backend component with the vision that it should be possible to exchange data between multiple parties using encrypted storage. The data exchanged between the parties can be anything from simple files to complex data objects – EDS only cares about bytes.
Via the public (REST-based) API, it is possible to access the internal logic, where keys are unlocked, based on user credentials, and used to encrypt and decrypt data, storing only encrypted keys and data. Using the same basic mechanism as PGP, combining Asymmetric & Symmetric keys, it is possible for multiple parties to exchange data safely and securely.
Since EDS only focused on bytes and does not have any care for more information, it can be used to share either files between users or data objects between apps or applications. This makes EDS the perfect companion for anyone who has Data Protection & Privacy concerns, such as GDPR.
EDS is written in Java 25 / Jakarta EE 11, with no third-part dependencies, and runs on Quarkus, either as a JAR or as a container, on any Host or in any Cloud. For production, it uses a PostgreSQL database, and creates the tables itself; without a database configured, it uses an in-memory H2 database, for tests and demos. See RUNNING.md for details.
The final version 1.2 can be downloaded from haugr.net, version 2.0 will be a major upgrade, with a new domain, project name, and various internal changes that make it a breaking update. Initial development of version 2.0 has completed, with no more changes in the pipeline. The next phase will focus on testing to guarantee that the stability will remain high. The build requires Java 25, and Maven.
In the root folder, there exists a small script, eds.sh, which can be used to
build the entire project, run the EDS container and the FitNesse test suite:
./eds.sh build [--test] [--sbom] [--containers] [--podman]
./eds.sh run container | run fitnesse
./eds.sh stop container [--remove] | stop fitnesse
./eds.sh check status | check logsWith --podman, the Maven build runs in the Podman build container,
build.container, so only Podman is needed instead of a local Java. The
container image and the SBOM scans are still built and run on the host.
in the accessories/release folder, there is an OpenAPI Specification file,
openapi.json, which can be used to generate client code or documentation
for the REST API.
The build can generate CycloneDX SBOM files
(specification 1.6), in both JSON and XML format, via the
CycloneDX Maven Plugin.
SBOM generation is disabled by default, and is enabled with the sbom
profile:
mvn clean package -Psbom -DskipTestsThis produces the following files:
target/eds-<version>-cyclonedx.(json|xml)– the aggregated SBOM, covering all modules of the project.<module>/target/<module>-<version>-cyclonedx.(json|xml)– an SBOM for each individual module, e.g.eds-quarkus/target/eds-quarkus-2.0-SNAPSHOT-cyclonedx.json.
The SBOM files are attached to the build, so they will also be installed or
deployed together with the other artifacts when running mvn install -Psbom
or mvn deploy -Psbom -Prelease. Test scoped dependencies are not included.
Note, the plugin needs online access to Maven repositories, so it is skipped
when Maven runs in offline mode (-o).
The CI Build scans the aggregated SBOM with Grype, and fails if a vulnerability with severity High or Critical is found. The same scan can be run locally with:
grype sbom:target/eds-2.0-SNAPSHOT-cyclonedx.json --fail-on highVulnerabilities which have been reviewed and found not to apply to EDS, can be
suppressed in .grype.yaml, together with a justification.
The Maven SBOM only covers the Java libraries. The EDS container image, built
from accessories/podman/Containerfile, also contains operating
system packages and a Java runtime, so the CI Build generates a CycloneDX SBOM
for it with Syft, written to
target/container-eds-quarkus-cyclonedx.json. EDS does not ship a database
container, it uses an existing PostgreSQL database.
The container SBOM is scanned with Grype, and fails the build on High or Critical findings, like the Maven SBOM. All SBOMs and vulnerability reports are available as build artifacts. The container SBOM can be generated locally, after the Maven build, with:
# It's built with --format docker, because Podman's default OCI format silently drops the HEALTHCHECK
podman build --format docker -f accessories/podman/Containerfile -t eds-quarkus:local eds-quarkus/target
podman save --format oci-archive -o target/eds-quarkus.tar eds-quarkus:local
syft scan oci-archive:target/eds-quarkus.tar -o cyclonedx-json=target/container-eds-quarkus-cyclonedx.json
grype sbom:target/container-eds-quarkus-cyclonedx.json --fail-on highAll of the above, the Maven build, the container image, the SBOMs and the scans, can also be run in one step, with the same pass/fail rules as the CI Build. It requires Podman, Syft, Grype and jq:
./eds.sh build --sbom --containers # Maven & container SBOMs and scans
./eds.sh build --sbom # Only the Maven SBOM and scanAnyone for whom data protection is important may find EDS useful. It is designed so everything is stored encrypted in a way, so only those who the data belongs to may access it. This is achieved by ensuring that the full control over all Keys is placed with the users.
Besides encrypting all data stored, the EDS also has a number of features to ensure that the security is as high as it can be, considering that it can be deployed in a "hostile" environment.
- MasterKey – The MasterKey is used to encrypt and decrypt various information, and it must be set during startup, since it is not persisted anywhere.
- Invalidate Accounts, this allows a member to force the keys to be replaced internally, so it is possible to log in and view Circles. However, it will not be possible to extract data, as the keys are different from the ones that were used in the Circles.
- Data Corruption checks to verify if there have been alterations to encrypted data, which may result in inability to properly extract information.
This is the EDS 2.0 development branch, with the these features completed:
- Migrate code base to Java 25
- Migrate code base from Java 8 to Java 11
- Upgrade code base to Java 17
- Migrate from Java EE 7 to Jakarta EE 8
- Upgrade JavaEE/JakartaEE to JakartaEE 10
- Convert Date Objects to Java 8+ Time Objects
- Migrate to the haugr.net domain
- Rename Packages & Project to EDS
The overall quality of the software can only improve if more eyes look at it and help with implementing features and adding more tests. If you wish to join, please contact Kim Jensen (see below).
Code quality is important, which is why testing and quality checks are crucial. Unfortunately, with version 2.0, it is time to consider alternatives to FitNesse & Coverity from Synopsis, since neither supports Java 25.
The code is checked against as many analysis tools as possible. The final code must have zero issues of any kind before it is considered ready to be submitted into the main repository.
Documentation of code is also important, having silly comments is meaningless, but often it helps to add inline comments to explain intentions and reasoning for choices made. Commenting on code is banned, if it is commented out, it is meaningless and should be removed.
The EDS is released under Apache License 2 or APL2.
Kim dot Jensen at haugr dot net