About Pull Request conflict may happen on PR #642

[AlexanderSlokov]

Dear @karimz1 ,

I read through your pull request #642 , and +5000 lines of code change "may" introduce some breaking change hit directly on my current PR. So how can we merge our PRs, you go first, or I go first? I think code change always come before the infra and devops tasks. Need your guide on this.

All the best,
Aleksandr.

P/S: Good news! The Hardened Image worked and the integration plus playwright e2e tests ran smooth! I updated my PR's descriptions, so you may want to see the number of VCEs reduced! If we take a look, the high CVEs on Pillow and Python webserver are addressable. Can you imaging that? imgcompress will achieve a tier A badge of Docker Image, exactly like those Docker Hardened Images of Docker, Inc catalog!

[karimz1]

Hey @AlexanderSlokov

Thanks for the heads-up, and great work on the Hardened Image. Reaching a potential Tier A Docker Image badge for imgcompress would be a huge achievement.

About my PR: don’t worry, I would not merge 5k lines directly all at once. I worked on one large branch first, but next week I plan to split it into smaller, safer PRs.

I would prefer to merge your changes first, then rebase/merge mine afterwards and test everything against your updates then publish the new Version. That should be the safest way to avoid breaking your work.

I’ll review your PR this weekend. I’m currently a bit limited because I’m sick, but by then I should be able to go through it properly.

Also, since the Docker hardening is such an important improvement, I think you should be visibly credited in the README, not only in the release notes. Feel free to choose a spot and text you like, maybe with a small Docker hardening badge or icon and link to your profile.

All the best,
Karim

[AlexanderSlokov]

​Hey @karimz1,

​First and foremost, I'm sorry to hear you're feeling under the weather. Please take all the time you need to rest and recover. Health comes first, and the PR isn't going anywhere!

​Your plan for the merge order is definitely the safest approach to avoid regressions. I'll be on standby to help resolve any Docker-related conflicts when you start bringing your new code in.

​Regarding the README credit: I am deeply honored by your offer. It means a lot coming from you. I'll draft a small, clean "Docker Image: Hardened" badge and a brief line of text. I'll put it in a separate commit later so you can review it once you're back in action.

​Rest up, drink plenty of water, and get well soon!

​All the best,
Aleksandr.

[AlexanderSlokov]

Hey @karimz1,

​Just a quick follow-up and a slight correction to my own excitement in the P/S above! 😅

​I went down the rabbit hole reading about the official Docker Hardened Image (DHI) program. Then I realized that while our current PR #626 functionally "hardens" the image, getting that actual "Docker Hardened Image" status (defined by the DHI program) requires a fully secured software supply chain.

​It turns out we would need to implement image signing (e.g., using Sigstore/Cosign), generate SBOMs, and enforce strict provenance attestations in our CI/CD pipeline. That is a lot of work that needs to be done.

​So, conceptually, we are making our Docker Image more... "secured"! That is a more precise term and appropriate definition.

​But I do have hope that we just unlocked a great roadmap for the future. I'd love to explore adding Cosign signatures and SBOM generation in future PRs, once our current work is safely merged.

​Cheers,
Aleksandr.

[AlexanderSlokov]

@karimz1, you know, I tried DHI build with Its yaml file, and:

The current Dockerfile on #626 was actually... less CVEs, or the attestation + SBOM on DHI build is stronger, so it can detect Zero-day CVEs on debian?

I have no idea, but oh boy, the DHI Build is beautiful! It can curate and cherry-pick OS deps by itself. All I just need to do is tell it that I want:

# ─────────────────────────────────────────────────────────────────────────────
# Image contents
# ─────────────────────────────────────────────────────────────────────────────
# DHI solver installs system packages directly (replaces extract_deps.sh + ldd
# + dpkg-L + ldconfig). Application files come from the artifact-carrier stage
# built by the regular Dockerfile.
contents:
  packages:
    - '!mawk'
    - '!original-awk'
    - base-files
    # Container init (PID 1 signal forwarding + zombie reaping)
    - dumb-init
    # ── Pillow / imaging native deps ──
    - ghostscript
    - libjpeg62-turbo
    - libpng16-16
    - libtiff6
    - libwebp7
    - libopenjp2-7
    - libimagequant0
    - libheif1
    - liblcms2-2
    - libfreetype6
    - libharfbuzz0b
    - libfribidi0
    - libxcb1
    - zlib1g
    - libgif7
    # ── C++ runtime (onnxruntime, granian) ──
    - libstdc++6
    - libgomp1

But still, joke on me 🤡

[karimz1]

Wow that is even better please do it in your pr love it more as it is less likely to break by internal changes ❤️

[AlexanderSlokov]

But right now, I can not say that I can control how this YAML declarative build work as this is the first time I ever use it. So, I would like to introduce it in the later PR, comes with bump up Pillow + rmbg CVEs. You can go to my fork and see what I am testing, on branch test-dhi-build.

I do want to past this weekend's PR preview first:) Infrastructure changes are always needed to do slowly as they are big and easily churn up to burn out you.

Hope you are well now, remember to rest too.

All the best,

Aleksandr.

[karimz1]

Thanks a lot, I feel much better now. I must say, your PR looks very good. I’ve merged it and I'll implement the auth to dhi.io in CI now.