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']

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?

Control: done -1 2.2.1+dfsg1-1

Ah yes the version in exprimental does fix this. Thanks!

[terceiro@fedora ~]$ podman --version
podman version 2.2.1

On Thu, Dec 31, 2020 at 9:26 AM Antonio Terceiro <terceiro@debian.org> 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.

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?

Yes, exactly.

Hi there,

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

yes please :)

+1

Apologies to bug you again, but given the "only small, targeted fixes"
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

Context is what version of podman to ship in Debian bullseye

On Thu, Jan 14, 2021 at 11:29 AM Antonio Terceiro <terceiro@debian.org> wrote:

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?

[...]

If I read the freeze policy correctly, the new version should be in
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?

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

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?

Thanks!

a.

Debian testing (bullseye)/unstable currently ship with version 2.1.1.
https://packages.qa.debian.org/libp/libpod.html

Best,
-rt

My bad.

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.

Hi,

On Sun, 24 Jan 2021 15:02:17 -0500 Reinhard Tartler <siretart@gmail.com> wrote:

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?

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

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

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

Hi,

a voice against changing the status quo here and this stays
"wontfix". I do NOT want to see this bug reopened :-).

From a security perspective, having an implicitly setup registry can
lead to supply chain attacks. 

Example: we have our own company set-up registry where we are mirroring
official image names and tags after setting up some extra changes (e.g.
additional CA certificates for TLS substitution). 

If you allow automatically pulling from docker.io, and a user does by
mistake "docker run unqualified:latest", then they get the wrong
version which means using unsafe containers (we have our own security
scanner, the one from docker.io is not strong enough). It's better for
us that they get an error and that they need to manually specify the
registry to make their intent clear (we don't want to forbid pulling
from docker.io, there are good use cases for that, especially to build
the initial images inside our own private registry).

Also, if you are not on a tty (e.g. in a Gitlab runner), of course you
won't be asked from where to pull from, the default will simply be
taken.

So please don't change the current behavior unless you have a strong
reason to. Users that want to allow pulling from docker.io by default
can do it via a trivial config file whose syntax is well documented.

The podman pull official man page says it better than me:

      When users specify images that do not include the container
      registry where the image is stored, this is called a short name.
      The use of unqualified-search registries entails an ambiguity as
      it is unclear from which registry a given image, referenced by a
      short name, may be pulled from.

      Using short names is subject to the risk of hitting squatted
      registry namespaces. If the unqualified-search registries are set
      to ["public-registry.com", "my-private-registry.com"] an attacker
      may take over a namespace of public-registry.com such that an
      image may be pulled from public-registry.com instead of the
      intended source my-private-registry.com.

No, upstream does not do it by default because it's considered a
security issue.

think

Hi,

a voice against changing the status quo here. 

From a security perspective, having an implicitly setup registry can
lead to supply chain attacks. 

Example: we have our own company set-up registry where we are mirroring
official image names and tags after setting up some extra changes (e.g.
additional CA certificates for TLS substitution). 

If you allow automatically pulling from docker.io, and a user does by
mistake "docker run unqualified:latest", then they get the wrong
version which means using unsafe containers (we have our own security
scanner, the one from docker.io is not strong enough). It's better for
us that they get an error and that they need to manually specify the
registry to make their intent clear (we don't want to forbid pulling
from docker.io, there are good use cases for that, especially to build
the initial images inside our own private registry).

Also, if you are not on a tty (e.g. in a Gitlab runner), of course you
won't be asked from where to pull from, the default will simply be
taken.

So please don't change the current behavior unless you have a strong
reason to. Users that want to allow pulling from docker.io by default
can do it via a trivial config file whose syntax is well documented.

The podman pull official man page says it better than me:

   When  users  specify  images that do not include the container
   registry where the image is stored, this is called a short name. The
   use of  unqualified-search  registries entails an ambiguity as it is
   unclear from which registry a given image, referenced by a short
   name, may be pulled from.

   Using  short  names is subject to the risk of hitting squatted
   registry namespaces. If the unqualified-search registries are set
   to  ["public-registry.com",   "my-private-registry.com"] an attacker
   may take over a namespace of public-registry.com such that an image
   may be pulled  from public-registry.com  instead  of  the  intended
   source my-private-registry.com.

No, upstream does not do it by default.

This for me is one case where if you want convenience and is fine in
your context, you can just set it up on your own, much like bash
aliases are also easy to setup for your use case.

Cheers,
Matteo
think
in
over
change
choice
expectation