[pkg-go] Bug#978650: podman: please provide a default container registry for looking up short image names

[Reinhard Tartler]

Control: reassign -1 golang-github-containers-common
Control: tag -1 wontfix
Control: severity -1 normal
Control: affects -1 podman

On Mon, Jan 4, 2021 at 3:47 PM Antonio Terceiro <terceiro at debian.org> wrote:

> 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
> 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?
>
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
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.

I hope this reasoning makes sense to you. I'm happy to discuss this further
and consider
additional thoughts and input on the matter.

-- 
regards,
    Reinhard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-go-maintainers/attachments/20210309/c2f3fa73/attachment.htm>