Note: With rK3e029a4ed0059116febe05924a14009ca622e3c5 autogen.sh was extended with targets to run converage scripts. However, there is no real documentation and it is questionable whether autogen.sh is the right place - after all the coverage stuff needs more support in a project which can't be easily done in a general way in autogen.sh. These chnages to autogen.sh have meanwhile be replaced by standard autogen.sh.

This was resolved in a different way.

This issue is not concrete enough to have some kind of "done" so ->invalid

This issue is invalid.

1.10.0 released

Mostly done

I just tried it w/ the current master and it works. First, it displays the upload dialog and progress bar. After a second or two a message pops up that the upload was successful and I'll get a confirmation request my mail later. Clicking Ok on the message hides both dialogs.

I'll look into it

Right. Now I see the wks page in advanced setup. In basic setup there is only a minimal wks info page. WKS confirmation email is send in both cases. Good.

It's only displayed in the advanced mode. Also, what do you mean w/ no response?

Sorry... I tested the current nightly build from today. There is no WKS upload dialog in Enigmail's setup wizard (default setup). And my manually upload test (via context menu from Engimails key management) gets no response...
@kai Can you please check the current state in upstream. Thanks.

it is: 073bc2b01d1f60c85ba4206f3ff37bc618b4a4a9

@kai Can you say when your patch will be upstream? We wait for a public nightly build of enigmail with all your wkd/wks changes.

Without a committment to code review workflows, this is meaningless.

Won't fix in favor of decentralisation.

No new tools.

Revisited patch

Commited with https://commits.kde.org/kleopatra/bfb379a204dc36e86689685b2c56727c87128cdb

Patch submitted

@marcus ping

Patch was accepted into Enigmail: 5e39a44f17f9ef45fd04d3069ba5d6f3092e28d6

Patch improved & submitted

Patch submitted

We already have 71 new users. The site seems to be known in the community.

Another option is to distribute the secret subkey to all hackers who need to be able to read that. We won't need any backward security due to our transparency goal. At the time we add a new hacker to the list we can simply create a new subkey. With the extend privat key format we would also have a method to add information to the secret key, so that we can track who got one.

In T3133#96706, @marcus wrote:

I don't have the full picture here, but maybe this gives you some fresh ideas:

About problem 1: Am I understanding it correctly that all builds share an install tree that is continuiously updated by all builds in all projects (for the same flavor)?

I don't have the full picture here, but maybe this gives you some fresh ideas:

Can you add a description?

There is a prototype implementation in the branch neal/encrypted-mailing-lists . A paper describing the design is at: ftp://ftp.gnupg.org/people/neal/openpgp-mailing-lists.pdf . The design was reviewed by Matt Green and DKG. DKG suggested using a slightly different OpenPGP construct (specfically, using user attribute packets instead of my encrypted subkey hack).