Building open-source projects like immudb on the openSUSE Build Service

The Open Build Service is a powerful tool to build and distribute packages from sources in an automatic, consistent and reproducible way. OBS is for free for open-source projects and it can create images and installable packages for a wide range of operating systems (SUSE, Debain, Ubuntu, Red Hat, Windows, etc.) and hardware architectures (x86, AMD64, zSystems, Power, ARM etc.). In this blog we take a look at the openSUSE Build Service and use it to build immudb and immudb containers. After that, we notarize the resulting containers with Codenotary‘s CAS (Community Attestation Service). Please note: the demonstrated project and the images are not official releases, don’t use them for production.

First steps

I strongly recommend using openSUSE Tumbleweed for working on OBS projects. Otherwise, you have to eventually get obs packages yourself for your distribution (for example obs-service-go_modules).

Get the OSC Command-Line Tool:
zypper ar https://download.opensuse.org/repositories/openSUSE:/Tools/DISTRIBUTION/openSUSE:Tools.repo
zypper install os

Create an account on build.opensuse.org. Verify your email and do a login. Navigate to your profile in the top right corner. You will already have a home project called home:<yourusername>. Click on that project and create a subproject.

Call the subproject home:<yourusername>:playground and set “Disable build results publishing”. So no one will use your builds while developing/testing. Select repositories in the subproject. For this tutorial, we chose openSUSE Tumbleweed (x86) and openSUSE Factory zSystems (s390x).

Go to your terminal and create a directory for your obs project (mkdir obs) and checkout your project to create an empty directory named home:<yourusername>:playground:
osc checkout home:<yourusername>:playground

A method to quickly come up to speed with obs is to branch existing projects. That way you can take a look at the files of others and modify them to your needs. You can search through the “All Projects” on the OBS Website to find a project that is similar to yours. For this tutorial we do a branch of home:swind:apps immudb and container-immudb.

osc branch home:swind:apps immudb home:<yourusername>:playground

Do a checkout again and switch in the immudb directory. Now you can see the directory and files of the project in the command line. Most of the magic is happening in the specfile. New files can be added with the osc add command.

Changes have to be checked in by osc ci -m “add your comment here”. Checking in changes automatically triggers a build. This will most likely fail, if the project is still being developed. That’s why it is also possible to do an osc service runall. This will execute a local build. You can display the build status and progress with osc results. The webinterface will also show that and logs too.

immudb can be built with a webconsole. The webconsole is supplied as a .tar.gz file. OBS can obtain that file automatically by defining it in the _service file:

  <service name="download_url">
    <param name="protocol">https</param>
    <param name="host">github.com</param>
    <param name="path">codenotary/immudb-webconsole/releases/latest/download/immudb-webconsole.tar.gz</param>
  </service>
  <service name="recompress" mode="disabled">
    <param name="file">immudb-webconsole.tar.gz</param>
    <param name="compression">bz2</param>
  </service>

Installing Software built by OBS

If the build was successful, you can install the software by using the links from repourls.

osc repourls
https://download.opensuse.org/repositories/home:/swind:/apps/openSUSE_Tumbleweed/home:swind:apps.repo
https://download.opensuse.org/repositories/home:/swind:/apps/openSUSE_Factory_zSystems/home:swind:apps.repo

Perform a wget on the repo link. Copy the .repo content into /etc/zypp/repos.d. Now zypper finds immudb and is able to install it.

wget https://download.opensuse.org/repositories/home:/swind:/apps/openSUSE_Tumbleweed/home:swind:apps.repo

sudo cp home:swind:apps.repo /etc/zypp/repos.d
zypper search immudb
sudo zypper install immudb

Building Containers with OBS

OBS can also build containers. This feature can only be added via the cli:

osc meta prj home:swind:apps -e

We have to add a container section below the repositories chosen before (openSUSE Tumbleweed and openSUSE Factory zSystems). Adding containers will also require a dockerfile located in containers-immudb/dockerfile.

  <repository name="containers_s390x">
    <path project="home:swind:playground" repository="openSUSE_Factory_zSystems"/>
    <path project="openSUSE:Containers:Tumbleweed" repository="containers_s390x"/>
    <arch>s390x</arch>
  </repository>
  <repository name="containers">
    <path project="home:swind:playground" repository="openSUSE_Tumbleweed"/>
    <path project="openSUSE:Templates:Images:Tumbleweed" repository="containers"/>
    <arch>x86_64</arch>
  </repository>

The images can be found at the openSUSE Registry.

Using CAS to create a tamperproof SBOM for the containers

A Software Bill of Materials (SBOM) is a list of components in a piece of software. The Community Attestation Service stores all signatures inside of immudb, the standard for open source immutable databases. CAS is protected against tampering. All attestation data is integrity-checked and cryptographically verified by the CAS client. CAS is also protected against MITM attacks. The public key below is checked by every communication.

Install CAS and get your API and follow the steps of the “Get started” section.

Get the docker image built by OBS and run the container:

docker pull registry.opensuse.org/home/swind/apps/containers/opensuse/immudb:latest
docker run registry.opensuse.org/home/swind/apps/containers/opensuse/immudb:latest

Do a CAS login and authenticate/notarize containers:

cas --api-key yourkeyhere authenticate docker://registry.opensuse.org/home/swind/apps/containers/opensuse/immudb

Here is an excerpt of the response:

UID: 1646052629401311666
Kind: docker
Name: docker://registry.opensuse.org/home/swind/apps/containers/opensuse/immudb:latest
Hash: 9fd63beb230ee5547307a380c317f20375527b77bdece77adc44176558108b39
...
Apikey revoked: no
Status: TRUSTED

Summary

We’ve successfully built immudb on the openSUSE Build Service but not only that. We also created container images for different architectures and notarized them using Codenotary’s open-source Community Attestation Service. Building software automatically in a consistent and reproducable is the way to go. In this blog we notarized and authenticated the final container with CAS. Codenotary’s solutions could also ensure that the software is only built from trusted sources, generate a Software Bill of Materials, and connect it tamperproof to the final binaries.

CNIL Metrics & Logs

Self-Hosted performance monitoring and compliant log analysis for VMware vSphere, container and much more.

immudb

Built on the fastest immutable ledger technology. Open Source and easy to use and integrate into existing application.

Codenotary Cloud

Trusted CI/CD, SBOM and artifact
protection with cryptographic proof.
One CLI to manage all.

MOST POPULAR

Sorry. No data so far.

Subscribe to Our Newsletter

Get the latest product updates, company news, and special offers delivered right to your inbox.

Subscribe to our newsletter

Use Case - Tamper-resistant Clinical Trials

Goal:

Blockchain PoCs were unsuccessful due to complexity and lack of developers.

Still the goal of data immutability as well as client verification is a crucial. Furthermore, the system needs to be easy to use and operate (allowing backup, maintenance windows aso.).

Implementation:

immudb is running in different datacenters across the globe. All clinical trial information is stored in immudb either as transactions or the pdf documents as a whole.

Having that single source of truth with versioned, timestamped, and cryptographically verifiable records, enables a whole new way of transparency and trust.

Use Case - Finance

Goal:

Store the source data, the decision and the rule base for financial support from governments timestamped, verifiable.

A very important functionality is the ability to compare the historic decision (based on the past rulebase) with the rulebase at a different date. Fully cryptographic verifiable Time Travel queries are required to be able to achieve that comparison.

Implementation:

While the source data, rulebase and the documented decision are stored in verifiable Blobs in immudb, the transaction is stored using the relational layer of immudb.

That allows the use of immudb’s time travel capabilities to retrieve verified historic data and recalculate with the most recent rulebase.

Use Case - eCommerce and NFT marketplace

Goal:

No matter if it’s an eCommerce platform or NFT marketplace, the goals are similar:

  • High amount of transactions (potentially millions a second)
  • Ability to read and write multiple records within one transaction
  • prevent overwrite or updates on transactions
  • comply with regulations (PCI, GDPR, …)


Implementation:

immudb is typically scaled out using Hyperscaler (i. e. AWS, Google Cloud, Microsoft Azure) distributed across the Globe. Auditors are also distributed to track the verification proof over time. Additionally, the shop or marketplace applications store immudb cryptographic state information. That high level of integrity and tamper-evidence while maintaining a very high transaction speed is key for companies to chose immudb.

Use Case - IoT Sensor Data

Goal:

IoT sensor data received by devices collecting environment data needs to be stored locally in a cryptographically verifiable manner until the data is transferred to a central datacenter. The data integrity needs to be verifiable at any given point in time and while in transit.

Implementation:

immudb runs embedded on the IoT device itself and is consistently audited by external probes. The data transfer to audit is minimal and works even with minimum bandwidth and unreliable connections.

Whenever the IoT devices are connected to a high bandwidth, the data transfer happens to a data center (large immudb deployment) and the source and destination date integrity is fully verified.

Use Case - DevOps Evidence

Goal:

CI/CD and application build logs need to be stored auditable and tamper-evident.
A very high Performance is required as the system should not slow down any build process.
Scalability is key as billions of artifacts are expected within the next years.
Next to a possibility of integrity validation, data needs to be retrievable by pipeline job id or digital asset checksum.

Implementation:

As part of the CI/CD audit functionality, data is stored within immudb using the Key/Value functionality. Key is either the CI/CD job id (i. e. Jenkins or GitLab) or the checksum of the resulting build or container image.

White Paper — Registration

We will also send you the research paper
via email.

CodeNotary — Webinar

White Paper — Registration

Please let us know where we can send the whitepaper on CodeNotary Trusted Software Supply Chain. 

Become a partner

Start Your Trial

Please enter contact information to receive an email with the virtual appliance download instructions.

Start Free Trial

Please enter contact information to receive an email with the free trial details.