As far I see these calls will be used in the AutoYaST configuration module only. (Not during an installation). It is around handling/installing/creating Images which speed ups installation. I have tried to run it but without success. 
It is a quite old undocumented feature. I have only found an example:
 <software>
    <image>
      <image_location>http://taylor/</image_location>
      <image_name>uwe</image_name>
      <script_location>file:///tmp/fetch_image.sh</script_location>
      <script_params config:type="list">
        <listentry>http://taylor//uwe.tar.gz</listentry>
      </script_params>
      <run_kickoff config:type="boolean">true</run_kickoff>
    </image>
    <instsource>http://taylor/11.2_install_i586/DVD1/</instsource>
    <patterns config:type="list">
      <pattern>apparmor_opt</pattern>
      <pattern>base</pattern>
      <pattern>yast2_install_wf</pattern>
      <pattern>sw_management</pattern>
      <pattern>apparmor</pattern>
    </patterns>
    <packages config:type="list">
      <package>kernel-default</package>
    </packages>
  </software>

and a funny string:

"Here you can choose to use Novell pre-defined images to speed up RPM installation."

I have doubts that this feature has been used by any user in the last 5 years because it is undocumented and at least for me not really understandable. 
Lukas, do you have more information about it ? For me it is a candidate for dropping it.

(In reply to Matthias Gerstner from comment #0)
> We
> think the proper way to do that would be to specify the additionally trusted
> repository keys (their IDs and fingerprints) in the autoyast XML
> configuration
> and only trust them explicitly during installation.

That would be IMO a feature request

(In reply to Stefan Schubert from comment #2)
> I have doubts that this feature has been used by any user in the last 5
> years because it is undocumented and at least for me not really
> understandable. 
> Lukas, do you have more information about it ? For me it is a candidate for
> dropping it.

I don't have any more information about it either.
I've never seen anyone using it (well, reporting a bug, requesting an
enhancement, etc.).
And it's undocumented, so really a candidate to kill.

(In reply to locilka@suse.com from comment #3)
> (In reply to Matthias Gerstner from comment #0)
> > We
> > think the proper way to do that would be to specify the additionally trusted
> > repository keys (their IDs and fingerprints) in the autoyast XML
> > configuration
> > and only trust them explicitly during installation.
> 
> That would be IMO a feature request

Well security is not especially keen to have that feature, we'd just like to
have things safe, that said ...

> I don't have any more information about it either.
> I've never seen anyone using it (well, reporting a bug, requesting an
> enhancement, etc.).
> And it's undocumented, so really a candidate to kill.

... killing it would even be safer :-)

Added to our Trello board

@Stefan, what's the status here? We have an autoyast2 update in the pipeline and would like to fix this as well.

(In reply to Alexander Bergmann from comment #6)
> @Stefan, what's the status here? We have an autoyast2 update in the pipeline
> and would like to fix this as well.

We haven't planned for this yet. It's just a P3 BTW. IMO, dropping the
feature should be done in new products only and well tested.

It's a feature that
- is undocumented
- nobody uses
- creates images that are no longer used anyway (AFAIK)

So, looks like a dead code. Is there any real need for removing that code
now? Or is that just because you have another AY patch to be released soon?

PS: We plan AY refactoring, such code-drop could be part of it.

(In reply to locilka@suse.com from comment #7)
> We haven't planned for this yet. It's just a P3 BTW. IMO, dropping the
> feature should be done in new products only and well tested.
> 
> It's a feature that
> - is undocumented
> - nobody uses
> - creates images that are no longer used anyway (AFAIK)
> 
> So, looks like a dead code. Is there any real need for removing that code
> now? Or is that just because you have another AY patch to be released soon?

This sounds a bit contradictory. It's dead code but removing it should be well
tested? So AutoinstSoftwareClass.createImage() is dead code?

To solve this bug from a security perspective all that would need to be done
is removing those three occurences of `--gpg-auto-import-keys` and if you
think it's not used anyways then this should be very low risk.

Zypper and the repository infrastructure are at the core of the distribution
security and having code around that auto import's GPG keys should not be
taken lightly, be it supposedly dead, or not.

Comment #7 still applies.
P3 == Basically no chance to get changed. I'm sorry.

I've added this to the planned AutoYaST refactoring/cleanup task.
Planned for ~SLE 15 SP3

We'll use CVE-2019-18905 to track this. CRD is 2020-06-08 as per our policy, but from our POV we can make it public right away, since we will not try to get this fixed in old products and are fine with it being removed in 15.3

Standard disclaimer:
This issue will be handled according to our disclosure policy outlined in
https://en.opensuse.org/openSUSE:Security_disclosure_policy

The information listed here is not public. Please
- do not talk to other people about this unless they're involved in fixing the issue
- do not make this bug public

In accordance with our policy we will make this issue public latest at
Internal CRD: 2020-06-08 or earlier
This is the latest possible date and we prefer to make it public earlier if the
situation allows it. In that case we'll post a comment here setting the new
date.

Only a member of the security team is allowed to make this issue public. Please speak to us if you want to take part in  the public disclosure.

In doubt please talk to us on IRC (#security) or send us a mail (security@suse.de).

Created attachment 832246 [details]
AutoYaST: Installation from images

Here's where you can see it "in action".
The screenshot comes from 15.1 and it's behavior is actually broken,
radio-buttons do not work as expected. In fact, the feature can't be
used at all. No reports about that so far.

Alexander, the AutoYaST configuration (on a running system) offers
functionality that pretends to allow for creating pre-configured images
for "installation from images". This feature does not work in UI and
Security Team has found a potential security issue (if the UI actually worked)
in the code.

What should we do and in which SPs? E.g., we still have time to remove this
from SLE 15 SP2, especially as there are no images created by SUSE and the UI
for creating images is broken anyway (looks like last change was in 2016).

Hi Lukas,
I would like to see this being addressed in 15SP2. Although it is 'dead code' I understand it is still a valid vulnerability as per comment #7 of Matthias.

If 'removing those three occurrences of `--gpg-auto-import-keys`  is sufficient for security', we should do this for SP2. 
Please also look into 15:GA and 15SP1.

A proper refactoring for SP3 can then be done.

OK, I'll ask to team to remove those calls.

SLE 15 SP3 should IMO remove the whole image creation UI.
It's too late for SP2 now.

I have submitted the patches:
SLE 15 SP2:
https://github.com/yast/yast-autoinstallation/pull/570
https://build.suse.de/request/show/213516

SLE 15 GA:
https://github.com/yast/yast-autoinstallation/pull/571
SR: 213522

SLE15 SP1:
https://github.com/yast/yast-autoinstallation/pull/572
SR: 213529

openSUSE-SU-2020:0676-1: An update that solves one vulnerability and has 6 fixes is now available.

Category: security (moderate)
Bug References: 1109310,1133045,1140711,1164105,1168123,1168281,1170082
CVE References: CVE-2019-18905
Sources used:
openSUSE Leap 15.1 (src):    autoyast2-4.1.15-lp151.2.12.1

Fixed according to comment #16 .. comment #31.