Metadata-Version: 2.4
Name: suse-distro-blockchain
Version: 0.0.2
Summary: A tool to verify the state of current used repositories
Author-email: Adrian Schroeter <adrian@suse.de>
License: GPL-3.0-or-later
Classifier: Development Status :: 2 - Pre-Alpha
Classifier: Intended Audience :: Developers
Classifier: Intended Audience :: System Administrators
Classifier: Topic :: System :: Networking
Classifier: License :: OSI Approved :: GNU General Public License v3 or later (GPLv3+)
Requires-Python: >=3.12
Description-Content-Type: text/markdown
License-File: LICENSE
Requires-Dist: web3<8,>=7.5.0
Requires-Dist: eth-account
Requires-Dist: iniparse
Provides-Extra: tester
Requires-Dist: eth-tester; extra == "tester"
Dynamic: license-file


Motivation
==========

The SUSE and openSUSE distribution creation and shipment relies on centralized
trust points today. A breach at these critical points inside of the production
process could lead to an unwanted shipment of harmful content. 

Furthermore we rely on external service providers for providing our products.
While these can not modify the products, they can still replace them with
different SUSE or openSUSE signed content.

The goal of this implementation is to achieve a real zero-trust implementation
for our distribution building and shipment.

Using this first demo implementation we can provide a way how any consumer
can check the state of the current provided products. 


High-Level product tracking of a SUSE/openSUSE distribution
===========================================================

0. Review of submissions and aggregation of a product

   This first itertion of the implementation is excluding the tracking
   of each individual review steps. However a lot could be done here
   in a later extension.

   Important right now is just that the product/code stream owner defines
   a fixed set of sources for his product which can be reviewed by any
   party.

   It is also critical to have a secure identifier of this state. This
   could be for example provided via a SHA-256 reflog entry of a project
   git.

1. The product build

   The OBS instance is building now the product, which means any binary
   artifact out of given source. The artifact provides also an identifier
   which can be used for tracking.

   The fact that products are signed by OBS with a key don't matter 
   in our concept, since we don't want to rely on a centralised 
   secret (the gpg private signing key). It could be mis-used by
   an attacker in the same way when the attacker is also able to
   provide binaries which don't rely on the given the source.

   Keep in mind that the attacker could be also one of the OBS 
   administrators.
   Or from the POV of the OBS administrator, I don't want to have the
   power here to do so. Never being in the situation that someone could
   claim that I did something like this.

   However, we again need a secure identifier, like a SHA-256 sum again.

2. The content providers

   Published products get distributed via various channels and mirrors.

   This involves also all possible inhouse mirrors and any network
   infrastructure entities which may spoof network access (Esp. when
   you consider SSL CA authorities as not secure enough).

   While content provides can not sign repositories with own content,
   it is possible for them to block security updates. Or even provide older
   versions with known attack vectors formerly signed by openSUSE or SUSE.

   This scenario becomes even worse when it is a targeted attack to or inside
   of a larger organisation.

The problems solved by a blockchain contract for product tracking
=================================================================

1) The responsibilities get defined and documented in the contract.

2) Validation of the current state, avoiding any blocked content.

3) Any role or entity validation can be distributed over multiple
   persons. For example we can require 3 votes out of the team of 9 security
   managers to mark a source state as unsecure.

   In short a zero-trust implementation for a single entity.

4) We avoid the need of a product modification by having a second channel
   (the blockchain).
   For example no need to modify a git commit or existing file by
   providing an additional signature in place.
   We just need a secure reference, for example a SHA-256 sum to be stored
   in the blockchain.

Roles in this example setup
===========================

1) The Organisation owner / The contract deployer

   This can be for example the openSUSE board. They would deploy a contract
   which defines the roles and responsibilities. 

   They have no further involvement in the production process afterwards.

2) The product creator

   This would be the OBS administrator in this example. He is responsible
   to take a defined source state and producing binary shipments.

   He has the duty to register new product builds in the chain.

3) The validator

   She would rebuild the source and verifies that the same binary get created.

   She has the duty to acknowledge a registered product build as reproducable.

4) The security auditor

   He can register any product build as not-secure when grave issues appear.

   He has the duty to mark an existing product build as unsecure.

Involved software components
============================

1) The distribution contract can be found in ape/contracts/distro.vy

2) The tool to register a new product build for the OBS admin

3) The tool to modify a registered product build

4) The tool for the user to validate a product

