Implementing a WKS solution

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Implementing a WKS solution

GnuPG - Dev mailing list
Hi,

It seems to me that the wiki page of WKS is a bit outdated:
https://wiki.gnupg.org/WKS
The RFC description seems to be up to date, but it also says that it
is a "draft". The manual pages of gpg-wks-server and gpg-wks-client
may need some updates too.

A page with information that seems outdated does not inspire
confidence in people. Personally I believe that WKS works well, but I
have seen people who are seeking alternative solutions because they
say that it "never moved past the alpha stage".
So, what is the status of WKS? Is it tested and safe?

Another issue that I have come across is that procmail seems to be
unmaintained for a long time (https://lwn.net/Articles/416901/). One
of the recommended replacements is maildrop, which is also more
readable, and a bit safer (because it saves mails to a temporary file
first, before processing them). Has anyone tried it for WKS, or has
any idea on how to convert the procmail recipe to a maildrop recipe?
Actually I don't mind that procmail is unmaintained or less readable,
as long as I have a recipe that works as expected, and I know that it
has no safety or robustness problems.

Finally, I am implementing a generic mail server solution with WKD+WKS
support. It would be great if someone could help with checking that I
am doing it correctly and safely:
- https://gitlab.com/docker-scripts/postfix/-/blob/master/docs/3-wkd-wks.md
- https://gitlab.com/docker-scripts/postfix/-/blob/master/cmd/wkd.sh
- https://gitlab.com/docker-scripts/postfix/-/blob/master/scripts/wks.sh
- https://gitlab.com/docker-scripts/postfix/-/blob/master/tests/test3.sh

I have tested it myself and it works. But I am more interested in
testing how safe it is if someone tries to break it. I don't doubt the
strength of GPG or the WKS protocol, but I doubt my skills in Postfix
configuration (which is quite complex to be honest). I am going to
make a test mailserver installation soon, so that anyone interested
may try to check it and identify any problems.

Thanks,
Dashamir

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: Implementing a WKS solution

GnuPG - Dev mailing list
On Wed, Feb 10, 2021 at 9:59 PM Dashamir Hoxha <[hidden email]> wrote:

> Finally, I am implementing a generic mail server solution with WKD+WKS
> support. It would be great if someone could help with checking that I
> am doing it correctly and safely:
> - https://gitlab.com/docker-scripts/postfix/-/blob/master/docs/3-wkd-wks.md
> - https://gitlab.com/docker-scripts/postfix/-/blob/master/cmd/wkd.sh
> - https://gitlab.com/docker-scripts/postfix/-/blob/master/scripts/wks.sh
> - https://gitlab.com/docker-scripts/postfix/-/blob/master/tests/test3.sh
>
> I have tested it myself and it works. But I am more interested in
> testing how safe it is if someone tries to break it. I don't doubt the
> strength of GPG or the WKS protocol, but I doubt my skills in Postfix
> configuration (which is quite complex to be honest). I am going to
> make a test mailserver installation soon, so that anyone interested
> may try to check it and identify any problems.

I have installed a test mailserver for the domain `tst1.fs.al`. More
details on this post:
https://community.fsfe.org/t/testing-a-mail-server-with-wkd-wks-support/606

I am sure it has some problems, because I am not sure that everything
is correct.
Please help me to find and fix any problems.

Happy #ilovefs day, and happy hacking.
Dashamir

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: Implementing a WKS solution

GnuPG - Dev mailing list
In reply to this post by GnuPG - Dev mailing list
On Wed, Feb 10, 2021 at 9:59 PM Dashamir Hoxha <[hidden email]> wrote:

> It seems to me that the wiki page of WKS is a bit outdated:
> https://wiki.gnupg.org/WKS
> The RFC description seems to be up to date, but it also says that it
> is a "draft". The manual pages of gpg-wks-server and gpg-wks-client
> may need some updates too.

By the way, I am willing to help with updating these pages, if help is needed.

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: Implementing a WKS solution

GnuPG - Dev mailing list
In reply to this post by GnuPG - Dev mailing list
On Wed, Feb 10, 2021 at 9:59 PM Dashamir Hoxha <[hidden email]> wrote:

> Another issue that I have come across is that procmail seems to be
> unmaintained for a long time (https://lwn.net/Articles/416901/). One
> of the recommended replacements is maildrop, which is also more
> readable, and a bit safer (because it saves mails to a temporary file
> first, before processing them). Has anyone tried it for WKS, or has
> any idea on how to convert the procmail recipe to a maildrop recipe?

I replaced procmail by maildrop:
https://gitlab.com/docker-scripts/postfix/-/commit/0351603cd55aae57f2fc82e3d13c7b18744f0b67

I am not sure if maildrop is better, but at least it seems to be still
maintained:
https://sourceforge.net/p/courier/mailman/courier-maildrop/?viewmonth=202102

Some useful pages that helped me to make the migration:
- https://www.courier-mta.org/maildropex.html
- http://toehold.blogspot.com/2004/05/migrating-from-procmail-to-maildrop.html
- http://www.postfix.org/MAILDROP_README.html
- https://www.courier-mta.org/maildrop/maildrop.html
- https://www.courier-mta.org/maildrop/maildropfilter.html

Regards,
Dashamir

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: Implementing a WKS solution

GnuPG - Dev mailing list
On Wed, Feb 17, 2021 at 12:08 AM Dashamir Hoxha <[hidden email]> wrote:

> I replaced procmail by maildrop

I dropped FROM_DAEMON check. Besides being ugly (in maildrop) it
didn't work as expected.
Upon thinking about it, it seems that it is needed in case a mail sent
from gpg-wks-server is bounced back for some reason. But in this case
gpg-wks-server should be able to detect that it is an invalid message
and should discard it. So, FROM_DAEMON check is not necessary after
all. Is my thinking correct?

Dashamir

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: Implementing a WKS solution

Bernhard Reiter-7
In reply to this post by GnuPG - Dev mailing list
Hi Dashamir,

Am Sonntag 14 Februar 2021 16:24:54 schrieb Dashamir Hoxha via Gnupg-devel:
> On Wed, Feb 10, 2021 at 9:59 PM Dashamir Hoxha <[hidden email]> wrote:
> > It seems to me that the wiki page of WKS is a bit outdated:
> > https://wiki.gnupg.org/WKS
> > The RFC description seems to be up to date, but it also says that it
> > is a "draft".

thanks for the hints.
(I've did some simple updates.)

Yes, a lot of drafts take a long while until they get to a more official
status. In the case of WKS, I am not sure which working group is responsible
and if it is active. Still, it is fine to use drafts, as WKS is a step further
from WKD, it may take even more time to distribute.

> > The manual pages of gpg-wks-server and gpg-wks-client
> > may need some updates too.
>
> By the way, I am willing to help with updating these pages,
> if help is needed.

Help is always appreciated and it is a wiki, so you can just go ahead.
Coordinate here, do not just replace stuff or call it official, but rather
mark it or link additional information.

The hint with procmail is certainly a good one, it would be useful to
have a tested recipie without it, which is simple.

Regards,
Bernhard

--
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Implementing a WKS solution

GnuPG - Dev mailing list
On Mon, Feb 22, 2021 at 11:08 AM Bernhard Reiter <[hidden email]> wrote:
> Help is always appreciated and it is a wiki, so you can just go ahead.
> Coordinate here, do not just replace stuff or call it official, but rather
> mark it or link additional information.

Wiki is good, but a documentation system based on git flow (with merge
requests, reviews, etc.) might be better.
Anyway, I tried to register and login, but I failed.

I have just published a WebKey server which can be integrated with a
mail server as an external component, in order to provide WKD+WKS
support for it:
- https://gitlab.com/docker-scripts/webkey
If I try to update the WKS docs I will use this one as a reference for
the configurations, commands etc:
- https://gitlab.com/docker-scripts/webkey/-/blob/master/scripts/setup.sh

Basically I would recommend (or do) these changes:
- Remove the instructions about Installing GnuPG from the source code,
since this should be explained somewhere else; assume that the users
can easily install GnuPG from a package.
- Update the instructions for building a WKD and add the configuration
of Apache2.
- Update the instructions for building a WKS and replace procmail with maildrop.
- Update the instructions for testing WKD/WKS and add some details
about testing with Thunderbird+Enigmail.
- Update the list of WKD/WKS solutions and add there
https://gitlab.com/docker-scripts/webkey

> The hint with procmail is certainly a good one, it would be useful to
> have a tested recipie without it, which is simple.

I am testing this maildrop recipe and it seems to work well:
- https://gitlab.com/docker-scripts/webkey/-/blob/master/scripts/setup.sh#L121-137

By the way, using the header 'X-WKS-Loop' with 'gpg-wks-server' seems
superfluous to me, since 'gpg-wks-server' already adds automatically
the header 'Wks-Phase', which should be sufficient for detecting a
loop. Am I missing something?

Regards,
Dashamir

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: Implementing a WKS solution

Ingo Klöcker
On Montag, 22. Februar 2021 16:31:14 CET Dashamir Hoxha via Gnupg-devel wrote:
> By the way, using the header 'X-WKS-Loop' with 'gpg-wks-server' seems
> superfluous to me, since 'gpg-wks-server' already adds automatically
> the header 'Wks-Phase', which should be sufficient for detecting a
> loop. Am I missing something?

Well, X-WKS-Loop is a single purpose header. Wks-Phase is another header with
specific purpose and semantics. It's usually not a good idea to (ab)use some
header for a completely orthogonal second purpose. (Using one artifact for one
purpose only is a general advice in software engineering.)

What if in a later version phase tracking is solved differently? Then you are
stuck with a header that is only used for loop detection and has the then
completely inappropriate and confusing name Wks-Phase.

Regards,
Ingo

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Implementing a WKS solution

GnuPG - Dev mailing list
On Mon, Feb 22, 2021 at 9:14 PM Ingo Klöcker <[hidden email]> wrote:

>
> On Montag, 22. Februar 2021 16:31:14 CET Dashamir Hoxha via Gnupg-devel wrote:
> > By the way, using the header 'X-WKS-Loop' with 'gpg-wks-server' seems
> > superfluous to me, since 'gpg-wks-server' already adds automatically
> > the header 'Wks-Phase', which should be sufficient for detecting a
> > loop. Am I missing something?
>
> Well, X-WKS-Loop is a single purpose header. Wks-Phase is another header with
> specific purpose and semantics. It's usually not a good idea to (ab)use some
> header for a completely orthogonal second purpose. (Using one artifact for one
> purpose only is a general advice in software engineering.)
>
> What if in a later version phase tracking is solved differently? Then you are
> stuck with a header that is only used for loop detection and has the then
> completely inappropriate and confusing name Wks-Phase.

It seems to me that phase tracking, no matter how it is done, solves
the loop problem as well, because 'gpg-wks-server' will discard a
message if it is not in the correct sequence. That's why there is no
need to check for a loop outside 'gpg-wks-server'.

>
> Regards,
> Ingo
> _______________________________________________
> Gnupg-devel mailing list
> [hidden email]
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: Implementing a WKS solution

GnuPG - Dev mailing list
On Mon, 22 Feb 2021 21:25, Dashamir Hoxha said:

> message if it is not in the correct sequence. That's why there is no
> need to check for a loop outside 'gpg-wks-server'.

Do not mix protocol layers - it is just stupid to do so.  Mail is
already garrulous enough and thus there is nothing to gain from saving a
few header lines.

BTW, procmail is one of the most reliable and matured mail tool.
Together with uucp and a bulk of other standard software.


Salam-Shalom,

   Werner

--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Implementing a WKS solution

GnuPG - Dev mailing list
On Mon, Feb 22, 2021 at 10:40 PM Werner Koch <[hidden email]> wrote:
> Do not mix protocol layers - it is just stupid to do so.  Mail is
> already garrulous enough and thus there is nothing to gain from saving a
> few header lines.

I am trying to make the procmail/maildrop recipe as simple as possible
(but not simpler). I am not trying to save a few header lines.

> BTW, procmail is one of the most reliable and matured mail tool.
> Together with uucp and a bulk of other standard software.

I have no reason to doubt this. Do you think that using procmail is
better than using maildrop?

By the way, I am not really sure that the way that I am using to
integrate a mail server with the WKS server is the best or most easy
one:
https://gitlab.com/docker-scripts/webkey#configuration-on-the-mail-server
I have just tried different postfix options until I found a way that works.
Some review or feedback from any postfix experts would be useful.

Thanks,
Dashamir

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: Implementing a WKS solution

GnuPG - Dev mailing list
In reply to this post by GnuPG - Dev mailing list
> BTW, procmail is one of the most reliable and matured mail tool.

The last maintainer of procmail disagrees:

https://marc.info/?l=openbsd-ports&m=141634350915839&w=2

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: Implementing a WKS solution

GnuPG - Dev mailing list
On Tue, 23 Feb 2021 01:40, Robert J. Hansen said:

> The last maintainer of procmail disagrees:

Well, that is the opinion of a maintainer who worked on it for 2 or 3
years, expressed his opinion 13 years later, and meanwhile 7 more years
passed by.  Santiago Vila is still maintaining procmail for Debian and
he did so for nearly 25 years.  The last overflow detected by fuzzing
was found and fixed in 2017.

Agreed, procmail had its history of bugs back in the 90ies.  But a lot
of software had these problems and even the poster boy of severe bugs,
sendmail, is nowadays a pretty solid thing.


Salam-Shalom,

   Werner

--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Implementing a WKS solution

GnuPG - Dev mailing list
In reply to this post by GnuPG - Dev mailing list
Werner Koch via Gnupg-devel wrote...

> BTW, procmail is one of the most reliable and matured mail tool.

But at the same time using a complex and fragile configuration syntax.
No problem if you see that every day and know all the ins and outs. But
for me, user of procmail since 2004, every change I have to do, every
few months or so, makes me nervous whether things will still work as
expected. And reading other people's recipies can easily turn into
headache.

And I am biased due to a major desaster many, many years ago when a
co-worker accidentially placed a newline character into the rc,
resulting in, if memory serves me right, something like

    *
    ^Header: content

which was valid procmail but went unnoticed until the next day.

In other words, the procmailrc format is not something I would want to
recommend anywhere. While still better than sendmail.cf or ircd "lines",
it's too risky. Today's computing ressources are really sufficient
enough to allow focussing on being more readable and less error-prone.

    Christoph

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

procmail and maildrop for WKS? (Re: Implementing a WKS solution)

Bernhard Reiter-7
Am Dienstag 23 Februar 2021 11:09:45 schrieb Christoph Biedl via Gnupg-devel:
> In other words, the procmailrc format is not something I would want to
> recommend anywhere.

Any changes to mail filtering must be tested.
(Personally I found the syntax fine when using procmails many years ago. Then
sieve was complex on different parts. Guess it is the problem that is
complex.)

If procmail itself does not have known flaws, then of course the programming
style, language and config format maybe old style, but we can still recommend
its usage, because of its widespread use and long time maturity.

Naturally, it is cool to have alternative recipies for maildrop
and other solutions, we must just see who maintains them. ;)

Best Regards,
Bernhard

--
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Wiki as documentation (and registration problems) (was: Implementing a WKS solution)

Bernhard Reiter-7
In reply to this post by GnuPG - Dev mailing list
Am Montag 22 Februar 2021 16:31:14 schrieb Dashamir Hoxha via Gnupg-devel:
> Wiki is good, but a documentation system based on git flow (with merge
> requests, reviews, etc.) might be better.

The wiki has a lower access barrier, so it is easier to make changes.
On the other hand the information can be less reliable (because many people
can just change it). Andre any myself keep an eye on changes a bit, so bad
changes get reverted in a reasonable timeframe.

> Anyway, I tried to register and login, but I failed.

Please email me personally with the details
if there is something wrong with the wiki registration.

Best Regards,
Bernhard

--
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Wiki as documentation (and registration problems) (was: Implementing a WKS solution)

GnuPG - Dev mailing list
On Fri, Feb 26, 2021 at 3:37 AM Bernhard Reiter <[hidden email]> wrote:
>
> Am Montag 22 Februar 2021 16:31:14 schrieb Dashamir Hoxha via Gnupg-devel:
> > Wiki is good, but a documentation system based on git flow (with merge
> > requests, reviews, etc.) might be better.
>
> The wiki has a lower access barrier, so it is easier to make changes.
> On the other hand the information can be less reliable (because many people
> can just change it). Andre any myself keep an eye on changes a bit, so bad
> changes get reverted in a reasonable timeframe.

Information management is hard.

I find wikis are the best way to disseminate long term, less
frequently changing information. In contrast, README's don't work.
They have not worked in 50 years and they are not going to magically
start working now. Mailing lists are good for immediate problems, like
break fix. But mailing lists are harder to search and follow.
Information is too disjoint and spread across multiple posts.

Wikis have a confounding property (to me) that they always arrive at
the right answer. It does not matter that contributors are not subject
matter experts. The crowd always arrives at the right answer. Someone
wrote a paper explaining the property, but I have never been able to
locate it. Also see
https://www.npr.org/sections/money/2015/08/07/430372183/episode-644-how-much-does-this-cow-weigh.

Wikis are also well indexed by search engines so users who make an
effort to search can readily find the information. In one experiment
OpenSSL performed, the topic of "How to compile and install openssl"
was tested. The subject used to get 10 to 20 questions a month on the
OpenSSL mailing list. After adding a detailed wiki page on the
subject, the mailing list questions dropped to nearly 0.

I also find it a good habit to... When someone asks a question on the
mailing list or Stack Overflow, add a topic about it in your wiki.
When the next person asks the same question, provide a link to the
topic in your wiki. Search engines pick up on those inward links and
drive your canonical answer to the top. Then, users find your
canonical answer more easily.

Wikis also help relieve project maintainers from writing all the
documentation themselves. If a project maintainer complains they don't
have time, then they need to use the right tool for the job and learn
to delegate to the crowd.

Jeff

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: Wiki as documentation (and registration problems) (was: Implementing a WKS solution)

Bernhard Reiter-7
Jeff,

Am Freitag 26 Februar 2021 10:05:11 schrieb Jeffrey Walton via Gnupg-devel:
> Information management is hard.
>
> I find wikis are the best way to disseminate long term, less
> frequently changing information.

thanks for adding more general arguments in favour of using wiki.gnupg.org!
Many good points!

Two minor notes:
a) I've seen wikis rot, so they are much harder to clean up then.
   -> They need to be maintained, if they go a certain critical mass,
      wikis are less useful then doc files done by the devs in SCM.
b) I've seen the crowd being wrong (especially on design and science
   questions). Encryption potentially is such a topic.

Still I think wiki.gnupg.org is a plus for GnuPG, OpenPGP and the Free
Software end-to-end encryption community. It can use more help, naturally.

Best Regards,
Bernhard


--
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (673 bytes) Download Attachment