new gpg project key

[totaam]

Seeing how many problems we have with the old expired GPG key: #3846, #3848, #3858, #3861

The best thing to do is probably to start with a brand new project key, instead of using my personal one.

This is going to be a pain, trying to figure out which distributions support what types of keys and subkeys is going to take time too.
(ie: Debian discarding the whole key if there is a SHA1 signature in it instead of ignoring that signature.. why, oh why)

[totaam]

Type of key

RedHat's how to sign rpms with GPG documentation is very poor and does not cover the types of keys or the use of subkeys at all: it only says generate a gpg key pair on the machine.
The Debian packaging uses gpg directly, so in theory it should be able to handle more (any?) types of key, though they did previously manage to make a mess of things by ignoring keys with SHA1 signatures instead of ignoring the signature! (#3446 - see also #3485)
MS Windows: the detached .gpg signatures are also done by calling gpg directly, but the exe is signed as per #1499. (perhaps generate a new key?)
MacOS can be ignored since it doesn't use gpg (of course it doesn't): #2388

I wanted to use an ecc key with a signing-only subkey, unfortunately RPM only supported RSA (and legacy DSA) keys until very recently (2021): rpm-software-management/rpm@23770e1
Full list of supported key formats found in the rpm source code here:
https://github.com/rpm-software-management/rpm/blob/26d3802390602c6aadc523bfb84426914c8fa050/sign/rpmgensig.c#L157-L165

As for subkeys, Pitfalls with RPM and GPG states that Your key cannot have any sub-keys.
Also You must generate the RPM with a V3 GPG signature (CentOS 5.5 can't verify V4 signatures), but since we don't care about CentOS 5, 6 or even 7, can we avoid using this nasty gpg command line that RedHat recommends?

%__gpg_sign_cmd %{__gpg} gpg --force-v3-sigs --batch --verbose --no-armor \
   --passphrase-fd 3 --no-secmem-warning -u "%{_gpg_name}" -sbo %{__signature_filename} --digest-algo sha256 %{__plaintext_filename}'

Is this still relevant in 2023? Who knows. Can we use sha512? Not documented either.
this ticket says that Fixed upstream now (by just ignoring subkeys)
Can we, or can't we?

Fun read: It's a cluster of RPM bugs: Not just one bug, or two bugs. A nest of the critters. RPM fails (failed?) to validate signed packages, didn't understand v4 GPG signatures but didn't notice it didn't understand them, didn't understand some key sizes and types but didn't notice it didn't understand that, and also choked on subkeys!
That doesn't exactly inspire confidence. So, no subkeys then.

Size of key

Hopefully, all the package validation tools can handle 4096 bits nowadays - that was not always the case!

Expiry

10 years to avoid having to go through this pain again.

Result:

Using a (4) RSA (sign only), 4096 bits, 10 year expiry key for xpra@xpra.org:

pub   rsa4096/0x73254CAD17978FAF 2023-06-10 [SC] [expires: 2033-06-07]
      Key fingerprint = B499 3B57 3231 48E3 7977  E5D8 7325 4CAD 1797 8FAF
uid                              Xpra <xpra@xpra.org>

Use the "old" key to sign it with "ultimate trust":

gpg -u 0x18ADB31CF18AD6BB   --sign-key "Xpra <xpra@xpra.org>"

Upload to key servers and xpra.org:

gpg --keyserver keyserver.ubuntu.com --send-keys  0x73254CAD17978FAF
gpg --keyserver pgp.mit.edu --send-keys  0x73254CAD17978FAF

The key can now be found on these keyservers:
https://keyserver.ubuntu.com/pks/lookup?search=0x73254CAD17978FAF&op=index
https://pgp.mit.edu/pks/lookup?search=0x73254CAD17978FAF&op=index

And now also at this URL:
https://xpra.org/xpra-2023.gpg
https://xpra.org/xpra-2023.asc

Sign beta repositories

(on a remote host via ssh gpg agent forwarding)

• start the gpg agent pointing at this key:

gpg-agent --homedir /mnt/USB-GPG-KEY/.gnupg --use-standard-socket --daemon

• connect to the remote host with agent forwarding:
  (remembering to add no-autostart to gpg.conf)

Testing it

(in progress)

• Fedora:
  Edit /etc/yum.repos.d/xpra-beta.repo to point to the new key, then dnf will show something like this:

Xpra Beta 37 - x86_64                                                                                                                                                                1.8 kB/s | 1.2 kB     00:00    
Importing GPG key 0x17978FAF:
 Userid     : "Xpra <xpra@xpra.org>"
 Fingerprint: B499 3B57 3231 48E3 7977 E5D8 7325 4CAD 1797 8FAF
 From       : https://xpra.org/xpra-2023.gpg
Is this ok [y/N]: y
Key imported successfully

• Debian Bookworm:
  Download the new key and edit /etc/apt/sources.list.d/xpra-beta.sources to point to it.

So far, so good.
Next:

• updating the download wiki page
• making new stable releases using the new key

[totaam]

The MS Windows installer is now signed using a brand new key, generated as before using makecert as per signing code using signtool.

makecert.exe -r -pe -n "CN=Xpra,E=xpra@xpra.org" -ss CA -sr CurrentUser -a sha256 -cy authority -sky signature -sv xpra-ca.pvk xpra-ca.cer
certutil.exe -user -addstore Root xpra-ca.cer
makecert.exe -pe -n "CN=Xpra,E=xpra@xpra.org" -a sha256 -cy end  -sky signature -ic xpra-ca.cer -iv xpra-ca.pvk -sv xpra.pvk xpra.cer

And this new signing key expires in 2040:

The following certificate was selected:
    Issued to: Xpra
    Issued by: Xpra
    Expires:   Sun Jan 01 06:59:59 2040
    SHA1 hash: C59AEF9FC6E8BC8DA7750908DF653FBA0AFEA614

Done Adding Additional Store
Successfully signed: Xpra-Python3-x86_64_Setup_5.0-r33673.exe

Number of files successfully Signed: 1
Number of warnings: 0
Number of errors: 0

And the certificate files are now here:

• CA: xpra-ca.cer
• signing: xpra.cer
  To add this as a "Trusted Publisher":

certutil.exe -user -addstore Root xpra-ca.cer

(I couldn't figure out how to make it trust this CA only for installing software, either from the GUI or the command line)

[totaam]

For Debian / Ubuntu distributions using the old /etc/apt/sources.list.d/xpra[-beta].list source file, use this command to add the new key:

wget -qO - https://xpra.org/xpra-2023.asc | sudo apt-key add -

If using the new xpra[-beta].sources files instead, use this command to update the repository specific key:

sudo wget -O "/usr/share/keyrings/xpra.asc" https://xpra.org/xpra-2023.asc

[John-Ghra]

This still does not work.

[markmandel]

I believe the command should be:

sudo wget -O "/usr/share/keyrings/xpra.asc" https://xpra.org/xpra-2023.asc

But can confirm that this did work for me! Huzzah!

[SkyperTHC]

reported in #3861, this is the cut & paste solution (as root):

bash -c '{ : \
		&& wget -O "/usr/share/keyrings/xpra.asc" https://xpra.org/xpra-2023.asc \
		&& wget -O "/etc/apt/sources.list.d/xpra-beta.sources" https://raw.githubusercontent.com/Xpra-org/xpra/master/packaging/repos/bookworm/xpra-beta.sources \
		&& apt-get update \
		&& pkg=("xpra" "xpra-html5") \
		&& { [[ $HOSTTYPE != aarch64 ]] && pkg+=("xpra-x11"); true; `### x86_64 only`;  } \
		&& apt-get install -y --no-install-recommends "${pkg[@]}" \
		&& rm -f /var/lib/apt/lists/xpra*; }'

Edited by maintainer: please don't do that!

[stdedos]

I am not sure if one should be "lightly" meddling with the internals of apt-get - nor if we should recommend it 😕

The "average Joe's" way is documented in https://github.com/Xpra-org/xpra/wiki/Download (I am just now updating it a little bit to match the transient nature of this ticket)

[SkyperTHC]

I am not sure if one should be "lightly" meddling with the internals of apt-get - nor if we should recommend it 😕

The "average Joe's" way is documented in https://github.com/Xpra-org/xpra/wiki/Download (I am just now updating it a little bit to match the transient nature of this ticket)

The described way at https://github.com/Xpra-org/xpra/wiki/Download doesnt work on kali (pub key error), see #3861. The only work-around atm seems to be to use the -beta branch. Would it make sense to describe on the webpage that the default branch is not working and that only the -beta branch works for the time being?

[stdedos]

Would it make sense to describe on the webpage that the default branch is not working and that only the -beta branch works for the time being?

I agree that it could be beneficial to inform users on the webpage about the current status of the default branch. However, I will defer this to @totaam for a final decision. It's possible that he is on the brink of deploying a stable version, signed with the new key - making all of these obsolete.

That said, I do have some reservations about suggesting complex or potentially hazardous commands in a visible issue. We're all responsible for our own terminals - that goes without saying. A little caution can also go a long way, especially when dealing with "potentially dangerous commands" on an elevated terminal, and dealing with "you-shouldn't-care" esoterics.

[totaam]

I have been on the brink of deploying the new GPG key to all the repos for a while. This will finally include the stable repo since the deployment to the beta one seems have gone well. (ignoring "it doesn't work" type of messages which are unactionable)
I will not be re-signing ~100GB of older stable packages (for various reasons, not least of which security implications) - these will be moved to an archive area and eventually to an offline backup.

So, to get there, I still need to:

• release 3.1.5
• release 4.4.6
• release new versions of the html5 client from each supported branch

To do that, I have to first test as many combinations as possible (including 5.0 beta) on as many platforms as possible, with as many browsers as possible.

Each one of these steps can take many days. For a start, doing a full build from a single branch takes multiple days - even on the new hardware VPO has provided - and when things go wrong, and they invariably do, then I have to start again.
I am skipping over all the other daily tasks that aren't going to wait just because people think their problem is more important: renewing hosting, check, renewing SSL certificates, check, backups, check, storm caused power cut, check.. and many many more

---

I'm also keenly aware that a number of other projects / organizations are relying on the xpra repositories. The constant stream of complaints about the GPG key was an eye opener.
Funny that, because when it comes to supporting the project, financially or otherwise, the silence has been deafening.

This is making me seriously re-consider the way this project is managed and in particular, my role in it.
Perhaps now would be a good time to move on.

[stdedos]

This is making me seriously re-consider the way this project is managed and in particular, my role in it.
Perhaps now would be a good time to move on.

🕯️ 🕯️ 🕯️ 🕯️ 🕯️ 🕯️ 🕯️ 🕯️ 🕯️ 🕯️

It could be. If your labor is only appreciated by words, and "projects / organizations" are not willing to step in (but are willing to "cash in") ... maybe you should not torture yourself. 🥲

[markmandel]

This is making me seriously re-consider the way this project is managed and in particular, my role in it.
Perhaps now would be a good time to move on.

Uh. OSS Maintainer burnout sucks. I'm sorry. Just letting you know that I love this project and promote it wherever I go. Please find a maintainable pace for yourself.

From my perspective -- as long as there is a documented way for me to install xpra from the repos, I'm good. I don't care if I have to switch approaches every so often as things change. It's free software, that's the price of doing business.

Also, thanks for jumping on getting these fixes in etc. It really is appreciated.

Also, I don't know if it helps, but is there a way we could push testing down to the community - at least some?

[totaam]

It's all live:
https://xpra.org/list/shifter-users/2023-June/002981.html

[DiagonalArg]

This works on Ubuntu, and I can confirm it in 22.04:

$ sudo wget -O "/etc/apt/trusted.gpg.d/xpra.gpg" https://xpra.org/xpra-2023.gpg

$ cat /etc/apt/sources.list.d/xpra.list 
deb [arch=amd64] https://xpra.org/ jammy main

[DiagonalArg]

This is making me seriously re-consider the way this project is managed and in particular, my role in it.
Perhaps now would be a good time to move on.

I'm just an individual occasionally using xpra at home, but if there were an obvious way to do it, I'd buy you a coffee occasionally. Put it on the xpra.org webpage? If you've got a budget, you might also put a little thermometer indicating how much you need.

Edit: I'm only just seeing the "sponshorship" link below. I'm not going to buy you a coffee through this Microsoft platform though...

[totaam]

I'm not going to buy you a coffee through this Microsoft platform though...

@DiagonalArg What's wrong with "this Microsoft platform"? AFAICT, they don't take a cut.

[stdedos]

https://docs.github.com/en/sponsors/receiving-sponsorships-through-github-sponsors/about-github-sponsors-for-open-source-contributors#sponsorship-payouts as of now:

Sponsorship payouts
GitHub Sponsors does not charge any fees for sponsorships from personal accounts, so 100% of these sponsorships go to the sponsored developer or organization. GitHub Sponsors charges a fee of up to 6% for sponsorships from organization accounts. The 6% fee is split between the following:

3% credit card processing fee
3% GitHub service processing fee
Organizations can save the 3% credit card processing fee by switching to invoiced billing for sponsorships. For more information, see "Paying for GitHub Sponsors by invoice."

For information about timing for payments from GitHub Sponsors, see "GitHub Sponsors Additional Terms."

For more information, see "Managing your payouts from GitHub Sponsors."

I assume @totaam qualifies as an individual, even though https://github.com/Xpra-org/xpra itself is an org.

[DiagonalArg]

Additionally, I have no interest in linking my identity and interests for Microsoft.