Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#978650: podman: please provide a default container registry for looking up short image names
505 views
Skip to first unread message
Antonio Terceiro
Dec 29, 2020, 12:50:03 PM12/29/20
to
Package: podman
Version: 2.1.1+dfsg1-3
Severity: wishlist
When running stuff that was originally written for docker, image names
will usually be provided in their short form, i.e. debian:10,
fedora:rawhide. In the current state of the Debian packaging, those will
fail like this:
$ cat Containerfile
FROM debian
$ podman build -t foobar .
STEP 1: FROM debian
Error: error creating build container: (image name "debian" is a short name and no search registries are defined in /etc/containers/registries.conf): while pulling "debian" as "localhost/debian": Error initializing source docker://localhost/debian:latest: error pinging docker registry localhost: Get "https://localhost/v2/": dial tcp [::1]:443: connect: connection refused
On Fedora, on the other hand, this just works, because their
registries.conf provides by default a list of as few registries
registries where to look up unqualified image names:
[terceiro@fedora tmp]$ grep -v '^#' /etc/containers/registries.conf
unqualified-search-registries = ['registry.fedoraproject.org', 'registry.access.redhat.com', 'registry.centos.org', 'docker.io']
I don't think we want to include the fedora/redhat/centos registries,
but we should include at least the docker.io registry, which is the _de
facto_ standard in the container world at the moment. So can we please
provide something like the line below by default in
/etc/containers/registries.conf?
unqualified-search-registries = ['docker.io']
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads)
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), LANGUAGE=pt_BR:pt:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages podman depends on:
ii conmon 2.0.20-1
ii containernetworking-plugins 0.8.7-1
ii crun 0.15.1+dfsg-1
ii golang-github-containers-common 0.26.3+ds1-2
ii init-system-helpers 1.60
ii libc6 2.31-6
ii libdevmapper1.02.1 2:1.02.173-1
ii libgpgme11 1.14.0-1+b2
ii libseccomp2 2.5.1-1
ii runc 1.0.0~rc92+dfsg1-5
Versions of packages podman recommends:
ii buildah 1.16.6+dfsg1-2
ii catatonit 0.1.5-2
ii fuse-overlayfs 1.2.0-1
ii slirp4netns 1.0.1-1
ii tini 0.19.0-1
ii uidmap 1:4.8.1-1
Versions of packages podman suggests:
pn containers-storage <none>
-- no debconf information
Version: 2.1.1+dfsg1-3
Severity: wishlist
When running stuff that was originally written for docker, image names
will usually be provided in their short form, i.e. debian:10,
fedora:rawhide. In the current state of the Debian packaging, those will
fail like this:
$ cat Containerfile
FROM debian
$ podman build -t foobar .
STEP 1: FROM debian
Error: error creating build container: (image name "debian" is a short name and no search registries are defined in /etc/containers/registries.conf): while pulling "debian" as "localhost/debian": Error initializing source docker://localhost/debian:latest: error pinging docker registry localhost: Get "https://localhost/v2/": dial tcp [::1]:443: connect: connection refused
On Fedora, on the other hand, this just works, because their
registries.conf provides by default a list of as few registries
registries where to look up unqualified image names:
[terceiro@fedora tmp]$ grep -v '^#' /etc/containers/registries.conf
unqualified-search-registries = ['registry.fedoraproject.org', 'registry.access.redhat.com', 'registry.centos.org', 'docker.io']
I don't think we want to include the fedora/redhat/centos registries,
but we should include at least the docker.io registry, which is the _de
facto_ standard in the container world at the moment. So can we please
provide something like the line below by default in
/etc/containers/registries.conf?
unqualified-search-registries = ['docker.io']
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads)
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), LANGUAGE=pt_BR:pt:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages podman depends on:
ii conmon 2.0.20-1
ii containernetworking-plugins 0.8.7-1
ii crun 0.15.1+dfsg-1
ii golang-github-containers-common 0.26.3+ds1-2
ii init-system-helpers 1.60
ii libc6 2.31-6
ii libdevmapper1.02.1 2:1.02.173-1
ii libgpgme11 1.14.0-1+b2
ii libseccomp2 2.5.1-1
ii runc 1.0.0~rc92+dfsg1-5
Versions of packages podman recommends:
ii buildah 1.16.6+dfsg1-2
ii catatonit 0.1.5-2
ii fuse-overlayfs 1.2.0-1
ii slirp4netns 1.0.1-1
ii tini 0.19.0-1
ii uidmap 1:4.8.1-1
Versions of packages podman suggests:
pn containers-storage <none>
-- no debconf information
Reinhard Tartler
Dec 31, 2020, 8:20:04 AM12/31/20
to
Can you please try the podman version in experimental? I believe what you describe (the shortnames) should work with version 2.2 just fine thanks to the shortnames.conf file.
Also, what version of podman did you use in Fedora for this test?
-rt
regards,
Reinhard
Reinhard
Antonio Terceiro
Dec 31, 2020, 9:40:04 AM12/31/20
to
Control: done -1 2.2.1+dfsg1-1
On Thu, Dec 31, 2020 at 08:14:08AM -0500, Reinhard Tartler wrote:
> Can you please try the podman version in experimental? I believe what you
> describe (the shortnames) should work with version 2.2 just fine thanks to
> the shortnames.conf file.
Ah yes the version in exprimental does fix this. Thanks!
> Also, what version of podman did you use in Fedora for this test?
[terceiro@fedora ~]$ podman --version
podman version 2.2.1
On Thu, Dec 31, 2020 at 08:14:08AM -0500, Reinhard Tartler wrote:
> Can you please try the podman version in experimental? I believe what you
> describe (the shortnames) should work with version 2.2 just fine thanks to
> the shortnames.conf file.
> Also, what version of podman did you use in Fedora for this test?
podman version 2.2.1
Reinhard Tartler
Dec 31, 2020, 1:50:04 PM12/31/20
to
As I thought. Experimental has version 2.2, unstable/testing currently 2.1
What you are asking for is one (maybe the?) major new feature introduced in 2.2.0.
-- regards,
Reinhard
Reinhard
Antonio Terceiro
Jan 4, 2021, 4:00:04 PM1/4/21
to
On Thu, Dec 31, 2020 at 11:26:49AM -0300, Antonio Terceiro wrote:
> Control: done -1 2.2.1+dfsg1-1
>
> On Thu, Dec 31, 2020 at 08:14:08AM -0500, Reinhard Tartler wrote:
> > Can you please try the podman version in experimental? I believe what you
> > describe (the shortnames) should work with version 2.2 just fine thanks to
> > the shortnames.conf file.
>
> Ah yes the version in exprimental does fix this. Thanks!
Actually, this only solves the issue for the few official images that
> Control: done -1 2.2.1+dfsg1-1
>
> On Thu, Dec 31, 2020 at 08:14:08AM -0500, Reinhard Tartler wrote:
> > Can you please try the podman version in experimental? I believe what you
> > describe (the shortnames) should work with version 2.2 just fine thanks to
> > the shortnames.conf file.
>
> Ah yes the version in exprimental does fix this. Thanks!
are listed by default in
/etc/containers/registries.conf.d/shortnames.conf
Other image names still won't work. But I guess unqualified names are an
anti-pattern in general?
Reinhard Tartler
Jan 4, 2021, 6:20:03 PM1/4/21
to
Yes, exactly.
regards,
Reinhard
Reinhard
Faidon Liambotis
Jan 9, 2021, 6:30:05 AM1/9/21
to
Hi there,
On Thu, Dec 31, 2020 at 01:39:52PM -0500, Reinhard Tartler wrote:
> As I thought. Experimental has version 2.2, unstable/testing currently 2.1
> What you are asking for is one (maybe the?) major new feature introduced in
> 2.2.0.
That's helpful! I was wondering what your plans were with regards to
bringing 2.2 to unstable. With my limited testing, things look to work
OK with it. It'd be great to release bullseye with a version supporting
short names!
Thank you for your efforts in maintaining the podman/libpod/etc. stack.
Regards,
Faidon
On Thu, Dec 31, 2020 at 01:39:52PM -0500, Reinhard Tartler wrote:
> As I thought. Experimental has version 2.2, unstable/testing currently 2.1
> What you are asking for is one (maybe the?) major new feature introduced in
> 2.2.0.
bringing 2.2 to unstable. With my limited testing, things look to work
OK with it. It'd be great to release bullseye with a version supporting
short names!
Thank you for your efforts in maintaining the podman/libpod/etc. stack.
Regards,
Faidon
Antonio Terceiro
Jan 14, 2021, 11:50:04 AM1/14/21
to
On Sat, Jan 09, 2021 at 12:58:05PM +0200, Faidon Liambotis wrote:
> Hi there,
>
> On Thu, Dec 31, 2020 at 01:39:52PM -0500, Reinhard Tartler wrote:
> > As I thought. Experimental has version 2.2, unstable/testing currently 2.1
> > What you are asking for is one (maybe the?) major new feature introduced in
> > 2.2.0.
>
> That's helpful! I was wondering what your plans were with regards to
> bringing 2.2 to unstable. With my limited testing, things look to work
> OK with it. It'd be great to release bullseye with a version supporting
> short names!
yes please :)
> Hi there,
>
> On Thu, Dec 31, 2020 at 01:39:52PM -0500, Reinhard Tartler wrote:
> > As I thought. Experimental has version 2.2, unstable/testing currently 2.1
> > What you are asking for is one (maybe the?) major new feature introduced in
> > 2.2.0.
>
> That's helpful! I was wondering what your plans were with regards to
> bringing 2.2 to unstable. With my limited testing, things look to work
> OK with it. It'd be great to release bullseye with a version supporting
> short names!
> Thank you for your efforts in maintaining the podman/libpod/etc. stack.
Faidon Liambotis
Jan 23, 2021, 7:00:03 AM1/23/21
to
On Thu, Jan 14, 2021 at 01:29:06PM -0300, Antonio Terceiro wrote:
> On Sat, Jan 09, 2021 at 12:58:05PM +0200, Faidon Liambotis wrote:
> > On Thu, Dec 31, 2020 at 01:39:52PM -0500, Reinhard Tartler wrote:
> > > As I thought. Experimental has version 2.2, unstable/testing currently 2.1
> > > What you are asking for is one (maybe the?) major new feature introduced in
> > > 2.2.0.
> >
> > That's helpful! I was wondering what your plans were with regards to
> > bringing 2.2 to unstable. With my limited testing, things look to work
> > OK with it. It'd be great to release bullseye with a version supporting
> > short names!
>
> yes please :)
Apologies to bug you again, but given the "only small, targeted fixes"
> On Sat, Jan 09, 2021 at 12:58:05PM +0200, Faidon Liambotis wrote:
> > On Thu, Dec 31, 2020 at 01:39:52PM -0500, Reinhard Tartler wrote:
> > > As I thought. Experimental has version 2.2, unstable/testing currently 2.1
> > > What you are asking for is one (maybe the?) major new feature introduced in
> > > 2.2.0.
> >
> > That's helpful! I was wondering what your plans were with regards to
> > bringing 2.2 to unstable. With my limited testing, things look to work
> > OK with it. It'd be great to release bullseye with a version supporting
> > short names!
>
> yes please :)
freeze is approaching quickly (< 3 weeks remaining) I was wondering of
your future plans with 2.2, or perhaps 3.0-rc1. If you need any help or
another set of eyes or hands, let us know :)
Best,
Faidon
Reinhard Tartler
Jan 24, 2021, 7:50:03 AM1/24/21
to
Context is what version of podman to ship in Debian bullseye
You're welcome.
In the community meeting on Dec 1 (cf. https://podman.io/community/meeting/notes/2020-12-01/#brent-baude)
Brent Baude (with some clarifications from Dan Walsh, IIRC) stated that version 2.2
won't make it into any RHEL release. RHEL 8.3 will go with podman 2.1, whereas RHEL 8.4
will go straight with podman 3.0. podman 2.2 will only be in Fedora, and given the
development velocity and support burden for the podman team, I was hesitating with
committing on podman 2.2 for bullseye. That's not a hard no from my side, I'm happy
to hear other opinions.
One could be to let's go straight for podman 3.0. Since Debian is going to have a
hard-freeze on 2021-03-12, that's kind of tight, but if doable if we collaborate.
There are a couple of dependencies that we need to update in experimental and I would
really appreciate help with it.
So folks, what do you think?
regards,
Reinhard
Reinhard
Shengjing Zhu
Jan 24, 2021, 8:00:03 AM1/24/21
to
On Sun, Jan 24, 2021 at 8:44 PM Reinhard Tartler <sire...@gmail.com> wrote:
>
> Context is what version of podman to ship in Debian bullseye
[...]
>
> Context is what version of podman to ship in Debian bullseye
>
> One could be to let's go straight for podman 3.0. Since Debian is going to have a
> hard-freeze on 2021-03-12, that's kind of tight, but if doable if we collaborate.
> There are a couple of dependencies that we need to update in experimental and I would
> really appreciate help with it.
If I read the freeze policy correctly, the new version should be in
> One could be to let's go straight for podman 3.0. Since Debian is going to have a
> hard-freeze on 2021-03-12, that's kind of tight, but if doable if we collaborate.
> There are a couple of dependencies that we need to update in experimental and I would
> really appreciate help with it.
time before soft-freeze(aka 2021-2-12)?
It seems upstream has released 3.0.0-rc1 already. So if you want 3.0
to be in bullseye, a good start might be uploading 3.0.0~rc1 to
experimental first, then talk to the release team?
--
Shengjing Zhu
Reinhard Tartler
Jan 24, 2021, 9:20:03 AM1/24/21
to
That sounds like a good plan. It also looks like the required
updates to containers/* isn't as bad as I thought, I'm updating buildah
right now, and see how much is missing for 3.0.0~rc1. If it is not, I'll
upload to experimental and start that conversation.
best,
-rt
-rt
regards,
Reinhard
Reinhard
Antoine Beaupré
Jan 24, 2021, 1:50:03 PM1/24/21
to
least an update on that front that's solid?
Thanks!
a.
--
The illusion of freedom will continue as long as it's profitable to
continue the illusion. At the point where the illusion becomes too
expensive to maintain, they will just take down the scenery, they will
pull back the curtains, they will move the tables and chairs out of
the way and you will see the brick wall at the back of the theater.
- Frank Zappa
Reinhard Tartler
Jan 24, 2021, 2:10:04 PM1/24/21
to
On Sun, Jan 24, 2021 at 1:44 PM Antoine Beaupré <ana...@debian.org> wrote:
Could we still upload 2.1 or 2.2 to unstable in the meantime to have at
least an update on that front that's solid?
Debian testing (bullseye)/unstable currently ship with version 2.1.1.
Antoine Beaupré
Jan 24, 2021, 2:20:04 PM1/24/21
to
--
How inappropriate to call this planet 'Earth' when it is quite clearly
'Ocean'.
- Arthur C. Clarke
Reinhard Tartler
Jan 24, 2021, 3:10:03 PM1/24/21
to
ok, I managed to build 3.0.0~rc1 and even managed to use docker-compose with it.
Things look promising! I've pushed my local branch to salsa at
https://salsa.debian.org/debian/libpod/-/tree/experimental and plan to upload
to experimental later today.
regards,
Reinhard
Reinhard
Andrej Shadura
Feb 23, 2021, 8:50:03 AM2/23/21
to
Hi,
On Sun, 24 Jan 2021 15:02:17 -0500 Reinhard Tartler <sire...@gmail.com>
It would appear you forgot to include a default registry setting in the
package for the new podman release. Could you please have a look?
--
Cheers,
Andrej
On Sun, 24 Jan 2021 15:02:17 -0500 Reinhard Tartler <sire...@gmail.com>
package for the new podman release. Could you please have a look?
--
Cheers,
Andrej
Reinhard Tartler
Mar 9, 2021, 8:50:04 AM3/9/21
to
Control: reassign -1 golang-github-containers-common
Control: tag -1 wontfix
Control: severity -1 normal
Control: affects -1 podman
In short, yes.
podman does support what you are asking for, it is just not enabled
by default.
If you wish to, you may set the option "unqualified-search-registries" for your user
podman does support what you are asking for, it is just not enabled
by default.
If you wish to, you may set the option "unqualified-search-registries" for your user
in $HOME/.config/containers/registries.conf, or system-wide in /etc/containers/registries.conf.
This is documented in great detail on http://manpages.debian.org/containers-registries.conf
In general, I would find it a reasonable choice to not trust the images on docker.io
in general. You may want to prefer another container registry, possibly a local one, over the
one hosted by hub.docker.com. Possibly you require encryption or other security features.
Podman offers a lot of knobs that are documented in that manpage.
As package maintainer, setting the option of an unqualified path makes decisions on behalf
of the local system administrator that I'm not necessarily comfortable making in general. By
refusing to set this, I am trying to raise awareness of the security implication and hope this
encourages users that may not be familiar with the security implications of using OCI images
from untrusted sources to do some additional research.
additional thoughts and input on the matter.
--
regards,
Reinhard
Reinhard
Tomas Pospisek
Dec 28, 2021, 7:00:03 AM12/28/21
to
Package: podman
Followup-For: Bug #978650
X-Debbugs-Cc: Antonio Terceiro <terc...@debian.org>, Reinhard Tartler <sire...@gmail.com>, Andrej Shadura <andrew....@collabora.co.uk>
Debian's podman isn't able to resolve short names out of the box.
It seems however that upstream is (I have not verified that - I'm
infering that from looking at an example [1]).
Behaving differently from vanilla upstream will mean that recipes
working out of the box with upstream will fail on Debian.
I respect and consider valid the argument about the security aspect of
using short-names brought forward by Reinhard in [2]. What I'd like to
question is the weighting of:
* convenience
* being compatible with upstream
versus
* security aspect
We gain securty by breaking convenience and compatibility with upstream.
That's the price we pay here for that bit of security.
Now let's consider the security part. It's a given that if you are using
a random container image then you *will* get a random container image.
Which is maybe not a very wise thing to do.
However *are* people using random images without a second thought? And
additionaly: do we want to protect people from using random images from
the internet? It is a given that Unix is giving you the gun and if you
point it at your foot and pull the trigger then the result will be bad.
Being a Unix system admin one *must* be traditionally careful.
How is this different with short-names? Why do we now have to protect
the admin or the user?
I think just like with everything else, recipes on the internet do *not*
include random short-names but instead standard ones, such as official
python or debian images. Also users are aware that installing a random
container will execute random code on one's system.
Therefore I'd like to argue that going with upstream behavior would be
the better setting.
Whichever way the argument goes: thanks a lot for maintaining podman!
*t
[1] https://github.com/ansible-community/ansible-bender/blob/master/simple-playbook.yaml
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978650#90
-- System Information:
Debian Release: 11.2
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-10-amd64 (SMP w/8 CPU threads)
Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), LANGUAGE=de_CH:de
ii containernetworking-plugins 0.9.0-1+b6
ii golang-github-containers-common 0.33.4+ds1-1
ii init-system-helpers 1.60
ii iptables 1.8.7-1
ii libc6 2.31-13+deb11u2
ii libdevmapper1.02.1 2:1.02.175-2.1
ii libgpgme11 1.14.0-1+b2
ii libseccomp2 2.5.1-1+deb11u1
ii runc 1.0.0~rc93+ds1-5+b2
Versions of packages podman recommends:
ii buildah 1.19.6+dfsg1-1+b6
ii fuse-overlayfs 1.4.0-1
ii golang-github-containernetworking-plugin-dnsname 1.1.1+ds1-4+b7
ii slirp4netns 1.0.1-2
-- Configuration Files:
/etc/cni/net.d/87-podman-ptp.conflist [Errno 13] Keine Berechtigung: '/etc/cni/net.d/87-podman-ptp.conflist'
-- no debconf information
Followup-For: Bug #978650
X-Debbugs-Cc: Antonio Terceiro <terc...@debian.org>, Reinhard Tartler <sire...@gmail.com>, Andrej Shadura <andrew....@collabora.co.uk>
Debian's podman isn't able to resolve short names out of the box.
It seems however that upstream is (I have not verified that - I'm
infering that from looking at an example [1]).
Behaving differently from vanilla upstream will mean that recipes
working out of the box with upstream will fail on Debian.
I respect and consider valid the argument about the security aspect of
using short-names brought forward by Reinhard in [2]. What I'd like to
question is the weighting of:
* convenience
* being compatible with upstream
versus
* security aspect
We gain securty by breaking convenience and compatibility with upstream.
That's the price we pay here for that bit of security.
Now let's consider the security part. It's a given that if you are using
a random container image then you *will* get a random container image.
Which is maybe not a very wise thing to do.
However *are* people using random images without a second thought? And
additionaly: do we want to protect people from using random images from
the internet? It is a given that Unix is giving you the gun and if you
point it at your foot and pull the trigger then the result will be bad.
Being a Unix system admin one *must* be traditionally careful.
How is this different with short-names? Why do we now have to protect
the admin or the user?
I think just like with everything else, recipes on the internet do *not*
include random short-names but instead standard ones, such as official
python or debian images. Also users are aware that installing a random
container will execute random code on one's system.
Therefore I'd like to argue that going with upstream behavior would be
the better setting.
Whichever way the argument goes: thanks a lot for maintaining podman!
*t
[1] https://github.com/ansible-community/ansible-bender/blob/master/simple-playbook.yaml
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978650#90
-- System Information:
Debian Release: 11.2
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-10-amd64 (SMP w/8 CPU threads)
Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), LANGUAGE=de_CH:de
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages podman depends on:
ii conmon 2.0.25+ds1-1.1
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages podman depends on:
ii containernetworking-plugins 0.9.0-1+b6
ii golang-github-containers-common 0.33.4+ds1-1
ii init-system-helpers 1.60
ii iptables 1.8.7-1
ii libc6 2.31-13+deb11u2
ii libdevmapper1.02.1 2:1.02.175-2.1
ii libgpgme11 1.14.0-1+b2
ii libseccomp2 2.5.1-1+deb11u1
ii runc 1.0.0~rc93+ds1-5+b2
Versions of packages podman recommends:
ii fuse-overlayfs 1.4.0-1
ii golang-github-containernetworking-plugin-dnsname 1.1.1+ds1-4+b7
ii slirp4netns 1.0.1-2
ii tini 0.19.0-1
ii uidmap 1:4.8.1-1
Versions of packages podman suggests:
pn containers-storage <none>
ii docker-compose 1.25.0-1
ii uidmap 1:4.8.1-1
Versions of packages podman suggests:
pn containers-storage <none>
-- Configuration Files:
/etc/cni/net.d/87-podman-ptp.conflist [Errno 13] Keine Berechtigung: '/etc/cni/net.d/87-podman-ptp.conflist'
-- no debconf information
Laurent Bigonville
Sep 27, 2022, 8:40:03 AM9/27/22
to
Hello,
Sorry for coming back to the topic here, but I (still) personally think
that defining "unqualified-search-registries" with sensible default
(dockerhub and quay.io?) is a better solution.
For what I understand, the two arguments here against are 1) it's not
up-to debian to choose the registries for the users 2) there are
security concerns about using random images.
IMVHO, it's still the role of a distribution to provide sensible
defaults to their users (lot/all packages are already doing so today in
the distribution). The fact that the package is adding that
shortnames.conf file (with a selected subset of images) is actually
forcing our users to use images (and not just repositories).
With unqualified-search-registries set, podman WILL ask the user from
where they want to pull the image from (currently nothing is asked),
this would actually allow the user to have MORE control and clarity over
the repository they uses.
I also not sure what would happen if the package maintainer would change
the content of that file to point to an other repository (let's say
because of a dispute), the user would start pulling an image they are
not expecting? With setting "unqualified-search-registries", the choice
of the user is preserved.
To that, I would also add that, AFAICS, debian is breaking expectation
for users coming from other distributions here.
So would it be possible to reconsider the solution here?
Kind regards,
Laurent Bigonville
Sorry for coming back to the topic here, but I (still) personally think
that defining "unqualified-search-registries" with sensible default
(dockerhub and quay.io?) is a better solution.
For what I understand, the two arguments here against are 1) it's not
up-to debian to choose the registries for the users 2) there are
security concerns about using random images.
IMVHO, it's still the role of a distribution to provide sensible
defaults to their users (lot/all packages are already doing so today in
the distribution). The fact that the package is adding that
shortnames.conf file (with a selected subset of images) is actually
forcing our users to use images (and not just repositories).
With unqualified-search-registries set, podman WILL ask the user from
where they want to pull the image from (currently nothing is asked),
this would actually allow the user to have MORE control and clarity over
the repository they uses.
I also not sure what would happen if the package maintainer would change
the content of that file to point to an other repository (let's say
because of a dispute), the user would start pulling an image they are
not expecting? With setting "unqualified-search-registries", the choice
of the user is preserved.
To that, I would also add that, AFAICS, debian is breaking expectation
for users coming from other distributions here.
So would it be possible to reconsider the solution here?
Kind regards,
Laurent Bigonville
0 new messages