A .ymp file isn't anything that you could do any useful inspection with anyway; that's just a small file to tell YaST what repo to add temporarily, then download and install one RPM from that repo, and then remove the temporarily added repo again.

But for an update repo like this one, I have doubts if that's really a very useful approach.

If you are expert enough to check the keys, I'd recommend you to go to the web interface that hosts that repo, download that one RPM, unpack it and inspect it at your leisure:

https://software.opensuse.org/package/openSUSE-build-key

-> "Expert Download"

-> "Grab binary packages directly"

-> select the RPM, in this case openSUSE-build-key-1.0-lp155.7.3.1.src.rpm, and download it to a temporary directory

-> unpack the RPM with 'unrpm':


[sh @ balrog] ~/tmp 5 % unrpm openSUSE-build-key-1.0-lp155.7.3.1.noarch.rpm
openSUSE-build-key-1.0-lp155.7.3.1.noarch.rpm:	57 blocks

[sh @ balrog] ~/tmp 6 % tree
.
├── openSUSE-build-key-1.0-lp155.7.3.1.noarch.rpm
├── openSUSE-build-key-1.0-lp155.7.3.1.src.rpm
└── usr
    ├── lib
    │   └── rpm
    │       └── gnupg
    │           ├── dumpsigs
    │           └── keys
    │               ├── gpg-pubkey-25db7ae0-645bae34.asc
    │               ├── gpg-pubkey-29b700a4-62b07e22.asc
    │               ├── gpg-pubkey-39db7c82-5847eb1f.asc
    │               ├── gpg-pubkey-3dbdc284-53674dd4.asc
    │               ├── gpg-pubkey-3fa1d6ce-63c9481c.asc
    │               └── gpg-pubkey-65176565-61a0ee8f.asc
    └── share
        ├── container-keys
        │   ├── opensuse-container-key-2023.asc
        │   └── opensuse-container-key.asc
        ├── doc
        │   └── packages
        │       └── openSUSE-build-key
        │           └── security_at_suse_de.asc
        └── pki
            └── containers
                └── opensuse-container-key-2023.pem

12 directories, 13 files


Then check the public keys.


If you don't have an 'unrpm' script (it's little more than a glorified 'cpio' call), install the 'build' package:

  sudo zypper in build

Created attachment 872638 [details]
unrpm script from build-20230215-150200.15.1.noarch

Have a look at this script; it's really pretty simple.

Created attachment 872639 [details]
Screenshot: Warning when a GPG key is actually about to be imported

When you go through with that all, if a new GPG key is actually imported. you will be presented with this warning that contains all the information about it: The fingerprint, the creation date, the expiration date, the URL, the repo name:

(Using one of my private repos here as an example because every Leap 15.5 user already has the 15.5 update GPG key imported):


"The following GnuPG key has been found in repository
home:shundhammer:qdirstat-stable
(https://download.opensuse.org/repositories/home:/shundhamme
r:/qdirstat-stable/15.5/):


ID: 36EC0437093DA05A
Name: home:shundhammer OBS Project 
Fingerprint: 6468 C568 549C 5E0F 2349 B17A 36EC 0437 093D A05A
Created: 12/08/2021
Expires: 02/16/2024


You can choose to import it into your keyring of trusted
public keys, meaning that you trust the owner of the key.
You should be sure that you can trust the owner and that
the key really belongs to that owner before importing it.


             [Trust]  [Cancel]


I have yet to see another piece of software that gives you a similar amount of information and also explanations.

If you didn't see this for the Leap 15.5 update repo, the reason is probably that you already got it during installation.

Thanks so much for the explanation I wonder, since the .ymp file seems to contain a free text field with a description that yast shows, maybe that one could be used to describe the key and fingerprint? I realize that could be tampered with, but at least this would prevent accidental imports of the wrong key. Or just allow people to identify without all that manual unrpm work what exact key they're even looking at. I was trying to find a specific key because zypper asked me to confirm one is truly from openSUSE, so since it wasn't listed on the wiki ( https://bugzilla.suse.com/show_bug.cgi?id=1219790 ) I began downloading official keys from various places to see if I could find it somewhere and confirm it's indeed the proper one. (Since zypper might be using HTTP and not HTTPS.) So there might be some use cases for displaying some info somewhere even if it doesn't make the .ymp otherwise much safer.

This is very much asking for "a little security"; which is on a similar level like being "a little pregnant"... ;-) It's a very binary thing.

I am not a security expert, so take this with a grain of salt:

If you have true concerns about the keys, IMHO the download/unrpm/inspect manually method outlined in comment #1 is the safest approach, but it still leaves a time gap between the download for inspection and the actual use; and time gaps are typical attack vectors.

Even safer is probably to install it and then, without using it for the time being, check it in the installed system (you can see the fingerprints in the repositories view, for example), and if you have any doubt, remove it again immediately. That would not leave a time gap, it would just need some self-discipline not to perform any package installation in the meantime.

Having said that, if you downloaded the RPM for inspection anyway, and you are sure that it's the real thing, simply install it manually with 

  sudo rpm -Uhv my.rpm

I don't follow, it's perfectly valid to check a HTTPS downloaded key to find the right one for the correct fingerprint because HTTP allows just arbitrary tampering, while HTTPS is pretty safe. Or what is your point that you're trying to make?

It just doesn't cover the use case of a malicious key being imported if openSUSE ever serves one, one that misrepresents itself, which I initially suggested might also be worth preventing but you seemed to disagree.

Security depends on the threat model and I don't see how preventing at least some of the possible attacks is somehow not worth it. If you call that "a little security" then yes there is something worthwile in that, depending on the threat model.

> simply install it manually with

That really is quite orthogonal to the use case of just wanting to see if the one zypper asks me for is served as the correct one officially from openSUSE. In that case I don't want to install arbitrary additional keys where i may not even know what they are for, but rather just to check if it's the one zypper is mentioning (so I know it's served from openSUSE through TLS-secured channels as an official one).

Maybe an additional comment: I realize with unrpm and other tools this is already solvable, and I did solve it yesterday. But I wasted an hour or so on this, and if there were more obvious ways to do this (seeing the fingerprint from the ymp, having all the official keys actually on the wiki instead of only some, etc.) then it would just speed up this procecss.

So I guess even if you leave out the security angle it just has some usability issues attached that would seem like rather easy to fix, hence my proposals. Sorry if this is just taking up your time, I didn't mean to do so, I just wanted to be helpful and spare others the same hour of searching fingerprints on the openSUSE site.

It does present you with the fingerprint etc. if you get that far in the process of adding the repo; see comment #3.

Sorry if I'm misunderstanding, but yast didn't seem to prevent me with any info at all, hence me making this ticket! That is what I was proposing, that when I open the .ymp in yast, that at some point I can see the fingerprint.

While it's nice that command line tools can do it, many people like me are going to be new to openSUSE and won't even know what a .ymp is and therefore just open it with the default tool, which is yast. I hope given that explanation, my suggestion makes a little bit more of sense! My apologies for taking up your time.