Brain fart, sorry, I meant “which problems are these” but I have since seen your reply in the thread where I proposed simplification.
> On 2 Nov 2026, at 11:45, Jarek Potiuk <[email protected]> wrote: > > The ones we build on? > > Docker Hardened Images (Python images). Generally wdely accepted as a way > how to keep your images as secure as possible (they are patching their > images up to few times a day). > > They are freely available and free for commercial use - Apache 2.0 licensed > (these are the community images we are using). > > They also have commercial FIPS compliant drop-in replacements, which people > can use as base images when following our 'build your own image' recipe. > > This is a bonus because our users can easily achieve FIPS compliance and > users often asked for it. So we do not have to provide it - they can pay > Docker for access to those FIPS compliant replacement base images. > > More info: > > Hardened Images | Docker https://share.google/J7g1i0JXzdUGHkW6G > > J. > > > > > > > On Mon, Nov 2, 2026, 12:22 Ash Berlin-Taylor via dev <[email protected]> > wrote: > >> What images are these? >> >>> On 1 Nov 2026, at 22:06, Jarek Potiuk <[email protected]> wrote: >>> >>> Actually - after seeing the kind of issues we faced even after my last >>> email 2 days ago -> the issues (and complexity of solutions) might be >>> somewhat intimidating to our users >>> >>> I personally think we should provide a bridge for our users. >>> >>> While I **strongly** believe DHI approach is good and has strong security >>> implications, some of my users for 3.4.* would prefer to use the >> "original" >>> setup. >>> >>> I am fine for 3.5 - to drop all kind of legacy images, but I think that >>> might be to ""steep** change - and being able to just switch to `FROM >>> apache/aifrlow:legacy-3.11` is an easy way to address all kinds of >>> incompatibilities. >>> >>> If we got (and we did) 3 library compatibility issues that required a >>> change in how the image uses the base DHI image - our users will have >> even >>> more of that - and they will reach out to us. >>> >>> Are we ready to handle our user's problems? >>> >>> For me - the easiest approach would be: >>> >>> * here are some general ways and you might follow it >>> * but if you have no time/energy to follow it - the legacy image will >> keep >>> you running. >>> >>> I would always ask anyone who says "drop it": Are you ready to solve >>> problems of our users if they see problems? >>> >>> My answer is: Yes - try to fix it following our vague instructions, if >> you >>> fail, use the legacy image for an easy fallback. >>> >>> What is the answer if we decide not to publish legacy image ? Ash, Jed? >>> what would you answer to the users? (and I am not precluding any answer - >>> we just have to remember that this should be the answer PMC is firmly >>> behind, no matter who is answering it) >>> >>> On Fri, Oct 30, 2026 at 7:02 PM Jed Cunningham <[email protected] >>> >>> wrote: >>> >>>> I still lean toward B, myself. My take is that leaving C as an option >>>> injects some uncertainty for both sides, and offering legacy flavors >> just >>>> kicks the can down the road. >>>> >>>> DHI is relatively new, so in theory it'll become more stable as time >> goes >>>> on. >>>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
