Please add GPG keys to SKS keyservers

[hvisage]

Good day, could you please add the GnuPG keys to the SKS/etc. GnuPG keyservers instead of having to fetch it from the mendix website?

wget -q -O - https://packages.mendix.com/mendix-debian-archive-key.asc | apt-key add -

[knorrie]

Can you explain your usecase?

The signing key can be rotated, and the https link always gives you the current one.

Besides that, the only thing that should be done with it is after that installing the debian-mendix-archive-keyring package, and then removing the manually added key again.

And, then keep the debian-mendix-archive-keyring up to date (unattended-upgrades!), so you won't be surprised after the signing key has rotated (which doesn't happen too often, and the new key will always be in that package for a month or maybe two in advance).

Hm, I see that last step (removing manually added key) is not in the documentation at https://github.com/mendix/m2ee-tools/blob/master/doc/install-1.md

[hvisage]

The use case: Ansible/automated installations.

Adding to the SKS keyservers/etc. you add the key, and then the Debian apt checks it from there, instead of having to pull that from a site that just might not be as available the moment I’m doing the installation, and besides, then it is “out there” ;) Makes a lesser step for the sysadmins doing installation.

On 16 Jan 2019, at 18:43 , Hans van Kranenburg notifications@github.com wrote:

Can you explain your usecase?

The signing key can be rotated, and the https link always gives you the current one.

Besides that, the only thing that should be done with it is after that installing the debian-mendix-archive-keyring package, and then removing the manually added key again.

And, then keep the debian-mendix-archive-keyring up to date (unattended-upgrades!), so you won't be surprised after the signing key has rotated (which doesn't happen too often, and the new key will always be in that package for a month or maybe two in advance).

Hm, I see that last step (removing manually added key) is not in the documentation at https://github.com/mendix/m2ee-tools/blob/master/doc/install-1.md https://github.com/mendix/m2ee-tools/blob/master/doc/install-1.md — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mendix/m2ee-tools/issues/35#issuecomment-454850061, or mute the thread https://github.com/notifications/unsubscribe-auth/ALH1SaWYs7FHukxlB3XAy-lyI54-T3-zks5vD1abgaJpZM4S-qn0.

---

Hendrik Visage HeViS.Co Systems Pty Ltd T/A Envisage Systems / Envisage Cloud Solutions +27-84-612-5345 or +27-21-945-1192 hvisage@envisage.co.za

[knorrie]

Can you elaborate? Why would "https://packages.mendix.com" not be available at the same moment that any keyserver is (this sounds like if your system has working external connectivity or not).

Note that (afaik) anyone can push public keys, so If you want to have some key on a keyserver cluster, you can cause that to happen right now.

You might also like to be able to verify whatever you pull from a keyserver to match some trust path that you're comfortable with. The key that's on the https location has my signature on it, that could be a start. Maybe we can meet at Mendix World 2019 so you can verify that signature was really me?

Still, this will not solve key rotation happening, since it will just be a new key replacing the old one, and you would have no clue where the new key is.

[hvisage]

packages.mendix.com http://packages.mendix.com/ could be “down” for reasons like BGP routing problems as an example, while the packages might still be on my apt-cache-ng server. I could have the Mendix instance (behind firewalls) only be given http access to the DMZ’d package cache on apt-cache-ng and the SKS server inside the organisation, but nothing else.

The keys being loaded into SKS will “solve” that problem as a “default” place where those keys that isn’t in the local keystore/cache, is fetched from, thus, you create a new key, you load it in the SKS servers, then it gets fetch from there when it sees the package with the new key, no need for a manual wget/curl and gpg add key. At least that is what I found when I deployed a custom Java deb for my environment.

But if that is a problem to add the keys to the SKS servers, then I’m not going to push it any further, it was a request to ease things with minimal impact (in my humble opinion) from the Mendix package creators. But if that is a problem I’ll rather close this ticket than spend any further effort on it.

(RE Mendix 2019: I’m not a dev on the MEndix side, I’m a SysAdmin on the Ops side keeping a couple of Mendix instances operational, so my clients have no intention of sponsoring my tickets for Mendix 2019 ;( )

On 17 Jan 2019, at 03:46 , Hans van Kranenburg notifications@github.com wrote:

Can you elaborate? Why would "https://packages.mendix.com https://packages.mendix.com/" not be available at the same moment that any keyserver is (this sounds like if your system has working external connectivity or not).

Note that (afaik) anyone can push public keys, so If you want to have some key on a keyserver cluster, you can cause that to happen right now.

You might also like to be able to verify whatever you pull from a keyserver to match some trust path that you're comfortable with. The key that's on the https location has my signature on it, that could be a start. Maybe we can meet at Mendix World 2019 so you can verify that signature was really me?

Still, this will not solve key rotation happening, since it will just be a new key replacing the old one, and you would have no clue where the new key is.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mendix/m2ee-tools/issues/35#issuecomment-455011373, or mute the thread https://github.com/notifications/unsubscribe-auth/ALH1SbzMQ4gvaEUn8PW8XlxSZqvfnFd5ks5vD9YJgaJpZM4S-qn0.

---

Hendrik Visage HeViS.Co Systems Pty Ltd T/A Envisage Systems / Envisage Cloud Solutions +27-84-612-5345 or +27-21-945-1192 hvisage@envisage.co.za

[knorrie]

Ok, you have to choose for yourself how to do things, and I'm indeed just giving unsolicited advise.

I'm interpreting your description above as "When I have a missing GPG key when doing apt operations, I'll just fetch it."

If that's what you mean, I would really recommend against doing that. The repo signing keys are there to help you make sure you're actually getting Mendix stuff and not some other packages from a MitM-ed connection. If you get an apt error about missing signing keys and then fetch them from keyservers, then you're not protected against this at all?

Another idea: if you have a proxy box that is serving a cached archive, then you can also keep the debian-mendix-archive-keyring package up to date on that one and serve the file /usr/share/keyrings/debian-mendix-archive-keyring.gpg somewhere and use that to bootstrap new systems, by throwing that file in /etc/apt/trusted.gpg.d