On Tue, Mar 09, 2021 at 08:38:44AM -0500, Reinhard Tartler wrote: > 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 <[email protected]> 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.
Fair enough. Thanks for replying.
signature.asc
Description: PGP signature
