The docker way of updating containers is to build a new image with the updated binaries and files, which creates a security concern.
The docker way is not anymore running "zypper update" in the containment but to update the whole image in the image registry (hub docker if we are talking about public registry) and then pull the image update from there, stop the outdated containments and replace them by starting new containments based on the new image.
This process breaks our current security update workflow since our workflow is based on running "zypper update" at the host, or in this case, in the containment.
Thus, what we need is a way to update the images in the registry when there are new RPM updates.
When we talk about updating RPMs, we have to make a distinction of 2 cases:
- The RPM is in the base image
- The RPM is in a layer above the image
The idea of the project is to make use of the "Remote Build Trigger" feature in the public registry "Docker Hub" [1] to trigger automatic builds of containers which need to be rebuilt.
[1] https://docs.docker.com/docker-hub/builds/
This project is part of:
Hack Week 12
Activity
Comments
-
over 10 years ago by jordimassaguerpla | Reply
The design on how to solve this is:
1- add a layer in the docker image which updates the packages, thus "zypper up" command in the Dockerfile.
2- get a list of RPMs installed on the docker image
3- get metadata from the update repo
4- based on the information from 2 and 3, decide to trigger a rebuild
-
over 10 years ago by jordimassaguerpla | Reply
I'll start by doing 1 and 2 manually, that is, editing the Dockerfile on a docker example and running "rpm -qa" on that docker example. Thus I'll focus on 3 and 4.
-
over 10 years ago by jordimassaguerpla | Reply
after talking to Flavio, I'll redesign it as:
1- add a layer in docker image which applies patches: "zypper ref && zypper patch" 2- run "docker run --rm IMAGE zypper list-patches" 3- if 2 returns a list of patches, trigger a rebuild
-
over 10 years ago by jordimassaguerpla | Reply
1- add a layer in docker image which applies patches: "zypper ref && zypper patch"
2- run "docker run --rm IMAGE zypper list-patches"
3- if 2 returns a list of patches, trigger a rebuild
-
-
over 10 years ago by jordimassaguerpla | Reply
Yes I could do that but that wouldn't update existing images in docker hub.
-
-
over 10 years ago by jordimassaguerpla | Reply
dc-update is a shell script that pulls the image from a registry (i.e. docker hub), checks if there are pending updates, and if so, adds a layer with the updated packages (by running "zypper patch" and commiting afterwards), and finally pushes the image back to the registry (i.e. docker hub).
It also works with fedora.
-
-
over 10 years ago by jordimassaguerpla | Reply
Web interface:
https://github.com/jordimassaguerpla/dc-update-web
It has no yet multiuser support and it requires the dockercfg file to be in the home directory of the user running the web. Adding multiuser support will be the next step.
-
over 10 years ago by jordimassaguerpla | Reply
It requires the dcupdate to be in the path. I am going to create an RPM with the dcupdate.
-
over 10 years ago by jordimassaguerpla | Reply
It has support for multiple users. Authentication is with github. RPM for dc-update:
http://download.opensuse.org/repositories/home:/jordimassaguerpla:/dc-update
-
over 10 years ago by jordimassaguerpla | Reply
and here there is a screenshot
https://github.com/jordimassaguerpla/dc-update-web/blob/master/screenshots/hackweek12.png
-
over 10 years ago by jordimassaguerpla | Reply
I had presented the project in the docker meetup group in Barcelona last wednesday. People found it interesting and pointed out a problem if the image had been built with a DockerFile and, after updating it with the dc-update script, you try to rebuild it again based on the DockerFile.
This script can be used for updating base images which won't get new code and so no rebuilds or it could be changed to trigger a rebuild based on the DockerFile instead of adding a layer with "zypper/yum update".
In anyway, I've get to practice with docker and rails and have learn a lot, thus it has been worth doing this project :-) .
Similar Projects
Looking at Rust if it could be an interesting programming language by jsmeix
Get some basic understanding of Rust security related features from a general point of view.
This Hack Week project is not to learn Rust to become a Rust programmer. This might happen later but it is not the goal of this Hack Week project.
The goal of this Hack Week project is to evaluate if Rust could be an interesting programming language.
An interesting programming language must make it easier to write code that is correct and stays correct when over time others maintain and enhance it than the opposite.
Help Create A Chat Control Resistant Turnkey Chatmail/Deltachat Relay Stack - Rootless Podman Compose, OpenSUSE BCI, Hardened, & SELinux by 3nd5h1771fy
Description
The Mission: Decentralized & Sovereign Messaging
FYI: If you have never heard of "Chatmail", you can visit their site here, but simply put it can be thought of as the underlying protocol/platform decentralized messengers like DeltaChat use for their communications. Do not confuse it with the honeypot looking non-opensource paid for prodect with better seo that directs you to chatmailsecure(dot)com
In an era of increasing centralized surveillance by unaccountable bad actors (aka BigTech), "Chat Control," and the erosion of digital privacy, the need for sovereign communication infrastructure is critical. Chatmail is a pioneering initiative that bridges the gap between classic email and modern instant messaging, offering metadata-minimized, end-to-end encrypted (E2EE) communication that is interoperable and open.
However, unless you are a seasoned sysadmin, the current recommended deployment method of a Chatmail relay is rigid, fragile, difficult to properly secure, and effectively takes over the entire host the "relay" is deployed on.
Why This Matters
A simple, host agnostic, reproducible deployment lowers the entry cost for anyone wanting to run a privacy‑preserving, decentralized messaging relay. In an era of perpetually resurrected chat‑control legislation threats, EU digital‑sovereignty drives, and many dangers of using big‑tech messaging platforms (Apple iMessage, WhatsApp, FB Messenger, Instagram, SMS, Google Messages, etc...) for any type of communication, providing an easy‑to‑use alternative empowers:
- Censorship resistance - No single entity controls the relay; operators can spin up new nodes quickly.
- Surveillance mitigation - End‑to‑end OpenPGP encryption ensures relay operators never see plaintext.
- Digital sovereignty - Communities can host their own infrastructure under local jurisdiction, aligning with national data‑policy goals.
By turning the Chatmail relay into a plug‑and‑play container stack, we enable broader adoption, foster a resilient messaging fabric, and give developers, activists, and hobbyists a concrete tool to defend privacy online.
Goals
As I indicated earlier, this project aims to drastically simplify the deployment of Chatmail relay. By converting this architecture into a portable, containerized stack using Podman and OpenSUSE base container images, we can allow anyone to deploy their own censorship-resistant, privacy-preserving communications node in minutes.
Our goal for Hack Week: package every component into containers built on openSUSE/MicroOS base images, initially orchestrated with a single container-compose.yml (podman-compose compatible). The stack will:
- Run on any host that supports Podman (including optimizations and enhancements for SELinux‑enabled systems).
- Allow network decoupling by refactoring configurations to move from file-system constrained Unix sockets to internal TCP networking, allowing containers achieve stricter isolation.
- Utilize Enhanced Security with SELinux by using purpose built utilities such as udica we can quickly generate custom SELinux policies for the container stack, ensuring strict confinement superior to standard/typical Docker deployments.
- Allow the use of bind or remote mounted volumes for shared data (
/var/vmail, DKIM keys, TLS certs, etc.). - Replace the local DNS server requirement with a remote DNS‑provider API for DKIM/TXT record publishing.
By delivering a turnkey, host agnostic, reproducible deployment, we lower the barrier for individuals and small communities to launch their own chatmail relays, fostering a decentralized, censorship‑resistant messaging ecosystem that can serve DeltaChat users and/or future services adopting this protocol
Resources
- The links included above
- https://chatmail.at/doc/relay/
- https://delta.chat/en/help
- Project repo -> https://codeberg.org/EndShittification/containerized-chatmail-relay
Exploring Rust's potential: from basics to security by sferracci
Description
This project aims to conduct a focused investigation and practical application of the Rust programming language, with a specific emphasis on its security model. A key component will be identifying and understanding the most common vulnerabilities that can be found in Rust code.
Goals
Achieve a beginner/intermediate level of proficiency in writing Rust code. This will be measured by trying to solve LeetCode problems focusing on common data structures and algorithms. Study Rust vulnerabilities and learning best practices to avoid them.
Resources
Rust book: https://doc.rust-lang.org/book/
vex8s-controller: a kubernetes controller to automatically generate VEX documents of your running workloads by agreggi
Description
vex8s-controller is an add-on for SBOMscanner project.
Its purpose is to automatically generate VEX documents based on the workloads running in a kubernetes cluster. It integrates directly with SBOMscanner by monitoring VulnerabilityReports created for container images and producing corresponding VEX documents that reflect each workload’s SecurityContext.
Here's the workflow explained:
- sbomscanner scans for images in registry
- generates a
VulnerabilityReportwith the image CVEs - vex8s-controller triggers when a workload is scheduled on the cluster and generates a VEX document based on the workload
SecurityContextconfiguration - the VEX document is provided by vex8s-controller using a VEX Hub repository
- sbomscanner configure the VEXHub CRD to point to the internal vex8s-controller VEX Hub repository
Goals
The objective is to build a kubernetes controller that uses the vex8s mitigation rules engine to generate VEX documents and serve them through an internal VEX Hub repository within the cluster.
SBOMscanner can then be configured to consume VEX data directly from this in-cluster repository managed by vex8s-controller.
Resources