545 Followers
0 Following
310 Posts
The Trinity Desktop Environment (TDE) project is a computer desktop environment for Unix-like operating systems with a primary goal of retaining the function and form of traditional desktop computers.
websitehttps://www.trinitydesktop.org/
join ushttps://www.trinitydesktop.org/helpwanted.php
donatehttps://www.trinitydesktop.org/donate.php

KMail was not able to correctly verify the GPG signatures of messages that were both encrypted and signed, although it had no problems with signed but non encrypted messages. This has now been fixed and will be part of the upcoming #TDE R14.1.6 release.
More info can be found at https://mirror.git.trinitydesktop.org/gitea/tde/tdepim/issues/187 and https://mirror.git.trinitydesktop.org/gitea/tde/tdepim/issues/190.

Updated PSB/PTB packages are or will soon be available on the #Trinity mirrors.

KMail fails to verify GPG signatures of certain types of encripted messages

I recently started using KMail in conjunction with GPG to encrypt and sign outgoing emails, as well as decrypt and verify signatures of incoming emails. While encryption, decryption, and signing works as expected, verifying signatures does not. Let's say I have a contact whose all public GPG keys are imported into my GPG keyring - this includes the master certifying [C] key, as well as authentication [A], signing [S], and encryption [E] sub-keys. I stress that the certifying key has no signing capability and there is a separate signing sub-key. This differs from GPG defaults, which, when generating a master key, give it both certifying and signing capability [CS]. However, a common practice is to remove the signing capability from the master key and have a dedicated signing key - this setup follows that practice. When I receive email signed with [S] subkey, KMail cannot verify the signature; it claims that while the signature is valid, the key with which the message was signed is unknown. However, the supposedly unknown key is a signing sub-key imported into my keyring. This suggests that when KMail tries to verify a signature, it only looks at master keys present in GPG keyring, but not their sub-keys. I think this is wrong. Other observations: * If email comes from someone, whose master key is both certifying and signing [CS], the signature is verified without problems. * An interesting case is signing of sent emails. Email is signed correctly, but the reported key fingerprint is that of a master key, not the signing key. This is where my GPG knowledge reaches its limit: my master key only has [C] capability, but not [S] - therefore it should not be possible to sign anything with it. I also note, that if I send email to myself, KMail can correctly verify the signature, i.e. based on the fingerprint of a master key it correctly finds the signing subkey. Putting it all together, it seems that KMail assumes that when an email is signed, fingerprint of the master key needs to be provided. Given master key fingerprint, KMail can find a signing sub-key. However, it does not search subkeys by default, so when the signing fingerprint is that of a subkey, KMail cannot find it in the keyring. I note, that most other email clients (or: essentially all signed emails that I receive) provide only the signing subkey fingerprint, and thus their signatures cannot be verified. Please take these conjectures with a grain of salt though: I am not a GPG expert, nor am I knowledgeable about KMail's internals.

TDE Gitea Workspace

Info for #TDE users on Debian-like distros (either PSB/PTB or the next stable release).

In the last couple of weeks there has been some package renaming to better comply with Debian conventions. If you are experiencing #Trinity-related package conflicts while updating your system, please try one of the following methods:

1. apt-get full-upgrade
2. aptitude upgrade
3. apt upgrade (should be fine)
4. from aptitude TUI, use `U`

Few packages are affected so far and there may be some more coming.

We are pleased to announce that #TDE R14.1.5 is now available on @gentoo for building. The R14.1.x branch of the Gentoo packaging repository has been updated to provide ebuild scripts for the latest stable version of #Trinity. At the same time, ebuild scripts for R14.1.2 have been removed. For more info, check out the packaging code at https://mirror.git.trinitydesktop.org/gitea/TDE/tde-packaging-gentoo/src/branch/r14.1.x
We are aware of at least another smaller bug when changing translucency settings, but that does not require a session restart.
In the very near future we will also remove the option "Apply translucency only to decoration" since it has been broken for 10+ years and fixing it would require considerable effort, which we deemed not worth it.

In the past few days, several bug fixes for twin's translucency settings have been added to #TDE's code. Using translucency should now provide a smoother experience, with less annoying bugs that previously required restarting a session or twin.
For more info see the current WIP version of "R14.1.6 release notes" at https://mirror.git.trinitydesktop.org/gitea/TDE/tde/issues/242.

Updated PSB/PTB packages are or will soon be available on the #Trinity mirrors.

Debian-based distros are updating cdbs and removing old files, relying more on debhelper instead (see for example https://metadata.ftp-master.debian.org/changelogs//main/c/cdbs/cdbs_0.4.182_changelog). This makes building #TDE in such distributions de facto impossible.
As a workaround, we have added the removed functionality under tde-cdbs, but in future we will be making changes to better integrating with newer versions of debhelper.
In parallel we continue to work on porting all #Trinity code to cmake, which will make the issue go away in full.

A small improvement for #TDE's Konqueror. The desktop is an important place for many users, so we have added a "Go to Desktop" entry to the "Go" menu for a quick way to navigate to it.

Updated PSB/PTB packages are already available on the #Trinity mirrors.

If you use #TDE's kvirc, you probably know that the GUI is only available in English.
We have fixed some long existing bugs and translations into other languages are now working again. Autodetection of the selected TDE language is not yet functional, but you can choose your own language in "Configure KVIrc → General options → Language → Force language".

Updated PSB/PTB packages are already available on the #Trinity mirrors.

Loong64 is now an official supported architecture in @debian (see https://lists.debian.org/debian-devel-announce/2025/12/msg00004.html) and will be part of the Forky release.

We have added support for loong64 in #TDE Preliminary Stable and Testing Builds, at the moment for sid and later for forky. If you have a Loong64 machine, try it out and let us know your experience.

Packages are already available on the #Trinity mirrors. Find out how to install them at these pages:
- PSB: https://wiki.trinitydesktop.org/Preliminary_Stable_Builds
- PTB: https://wiki.trinitydesktop.org/Preliminary_Testing_Builds

loong64 is now an official architecture

Info for #Trinity developers and contributors.

We have recently increased the accepted C++ standard for #TDE code to c++17. From now on, feel free to use any of the functionalities provided by it.
It also means that you need a C++ compiler that supports such standard. For all the distributions on which we are currently building TDE, that should not be a problem.