InfoSec M.Sc. from Ruhr Uni Bochum
| GitHub | https://github.com/3u13r |
| GitHub | https://github.com/3u13r |
@chandlerc I've also learned to distrust it. I only use it if I know that it exists. If it still cannot find it, then I press "." to start the in-browser VSCode thing and use the search there.
But this is quite resource heavy, especially if you don't close your tabs. So one might as well clone it directly.
Not sure if https://sourcegraph.com/search is better at this.
#ReproducibleBuilds bug of the week:
We noticed our rootfs wouldn't reproduce between systems with different file systems. Diffing two rootfs tarballs led us to a diff in packed certificate bundle files.
All packages installed by the rpm-based package manager were pinned by hash, so how could these files differ? We noticed that the total file length was the same, so we assumed an ordering problem. Looking into the SPEC file of the ca-certificates package, we saw that these files were generated in a post install hook with p11-kit.
Checking the code, we noticed that p11-kit would get the certs files using readdir(). But the order in which readdir() returns files is undefined! (and likely depends on the inode numbers of the fs)
So here is our fix, sorting the input files by paths to extract a reproducible bundle output: https://github.com/p11-glue/p11-kit/pull/656
There is no defined order in which readdir will return the entries of a directory. In practice, order can depend on inode number or similar. If we run p11-kit on different files systems with simila...
I've blogged before about creating vagrant images using mkosi as part of an investigation to move image creation to mkosi but also as I will be giving a talk at All Systems Go about Arch Linux images mkosi and reproducibility. With reproducible images in this article I mean that anyone …
Can you pull a container image with a known good digest from an untrusted registry?
It depends. Following the OCI distribution spec, a client is not required to validate the digest. Instead, the registry can send a header with another hash algorithm, and the client must validate using algo and hash from the header. A malicious registry can deliver both malicious manifests and blobs to a spec conform client.
Docker & containerd seem to check the digest as one might expect, many other clients don't.
My colleague @burger is proposing to tighten the spec and require clients to verify the digest if present: https://github.com/opencontainers/distribution-spec/issues/549
#container #security #OCI #containerd #Docker #Kubernetes #infosec
The use case Suppose I have a release workflow that builds reproducible container images, for example using Bazel or Nix image builders. Reproducibility guarantees that I can rebuild the image from...
We just released what I've been working on for the past months: Contrast, a tool for managing Confidential Containers at scale.
https://github.com/edgelesssys/contrast by @edgelesssystems
Seamlessly integrating with managed #Kubernetes, it offers a fully verifiable software stack. Using Confidential Computing, it allows running sensitive workloads in the public cloud with robust security, safeguarding against the cloud provider. Contrast also features a drop-in, attestation-based service mesh solution to secure inter-deployment communication.
Next Nix(OS) Learning Group Bochum meetup is around the corner, and we have an exiting new location!
2024/05/14, 18:00
at @daslabor
Learn how to use Nix as build system or discover the power of declarative system configuration!
Full annoncement (de): https://wiki.das-labor.org/w/Veranstaltung/6._Nix(OS)_Learning_Group_Meetup