Skip to Content.
Sympa Menu

en - Re: [sympa-users] Status of pgp support in Sympa

Subject: The mailing list for listmasters using Sympa

List archive

Chronological Thread  
  • From: Olivier Salaün <address@concealed>
  • To: Andreas Speck at lists <address@concealed>
  • Cc: address@concealed
  • Subject: Re: [sympa-users] Status of pgp support in Sympa
  • Date: Wed, 04 Aug 2010 14:33:37 +0200

Hi Andreas,

Back in 2004, Christian Mock had patched Sympa to provide PGP signature and encryption. Unfortunately the patch was not acceptable asis and we did not integrate it. In the meanwhile Sympa internals have changed a bit and I can't put a hand on it.

Attached is the thread from 2004 we had with Christian.

Adding PGP support is not currently on our roadmap. However, if one comes with a clean patch, we will integrate it.

Le 04/08/2010 12:20, Andreas Speck at lists a écrit :
I remember reading about plans to add pgp-support to sympa, but can't
find anything in the documentation yet.

I found the following feature request though:
https://sourcesup.cru.fr/tracker/index.php?func=detail&aid=4295&group_id=23&atid=170

Has any work been done on pgp support?

Would this partial implementation work for Sympa-6.0.x?

Best wishes,
Andreas

--- Begin Message ---
  • From: Christian Mock <address@concealed>
  • To: Aumont - Comite Reseaux des Universites <address@concealed>
  • Cc: address@concealed
  • Subject: [sympa-authors] Re: Sympa and PGP, finally!
  • Date: Mon, 22 Mar 2004 13:26:08 +0100
On Mon, Mar 22, 2004 at 09:02:11AM +0100, Aumont - Comite Reseaux des
Universites wrote:

> We have noticed that a lot of users thinks that 4.0b.2 is a newer
> version then 4.0. That is why we named this version 4.1. Now odd version
> number will be dedicated to stable version and even number to
> developpement version. 4.2 will be named 4.3 ! We will start working on
> it now mainly to add TT2 parsing engine. (A CVS stable branch 4.1.x will
> be maintened to integrate bug patches).

Wouldn't it be better to do it the other way 'round, i.e. stable == even,
unstable == odd, like a lot of projects seem to do now?

> What a strange feature ! Please could you explain more about your needs ?

We're running a closed user-group setup, where it is important that
users can verify the authenticity of other user's mails; that is the
reason for the "proxy-signing" feature.

Another thing is that with ascii armored PGP signed+encrypted mails carry
a "combined" signature and encryption, which means running "gpg --decrypt"
strips the signature; so there's no signature to pass along. This can
also happen with PGP/MIME, but with ascii armored PGP it's always the case.

> Sympa is now a kind of S/MIME <-> PGP gateway. My opinion is that it is
> not a good thing to replace a signature (pgp or S/mime) based on the sender
> private key by a signature based on the list private key. I understand

I think it depends; if you have the requirement as above, and you decide
you trust the list server anyways (as we also store the decrypted
messages in the archive), I think it's OK.

> to add some Sympa/Robot parameter to control if the robot is a PGP/SMIME
> signature gateway or if the robot keeps unchanged any signature.
> Do you agree with this ?

That's something I haven't thought about, but it is a very good idea.
So I'll introduce a per-list parameter that defaults to "pass along
the signature unmodified".

ciao,

cm.

--
Christian Mock Wiedner Hauptstr. 15
Senior Security Engineer 1040 Wien
CoreTEC IT Security Solutions GmbH +43-1-5037273

--- End Message ---
--- Begin Message ---
  • From: Aumont - Comite Reseaux des Universites <address@concealed>
  • To: Christian Mock <address@concealed>
  • Cc: address@concealed
  • Subject: [sympa-authors] Re: Sympa and PGP, finally!
  • Date: Mon, 22 Mar 2004 09:02:11 +0100
Christian Mock wrote:

hi,

I'm the one that talked about adding PGP support to sympa years ago,
if your remember.

Of course we do remember you !

Well, the customer finally ordered, and I'm nearly done -- I'm running
a test system right now so our closed user group can see if it works for
them, and expect to go into production by beginning or mid of april.

How do we go about integrating it into the official codebase? I see you
released 4.1 yesterday (why 4.1? I was expecting 4.0 after the 4.0[ab]
series...), are there plans for 4.2?

We have noticed that a lot of users thinks that 4.0b.2 is a newer version then 4.0. That is why we named this version 4.1. Now odd version number will be dedicated to stable version and even number to developpement version. 4.2 will be named 4.3 ! We will start working on it now mainly to add TT2 parsing engine. (A CVS stable branch 4.1.x will be maintened to integrate bug patches).

What I've done is giving PGP the same level of support as S/MIME, both
for ascii armored PGP and PGP/MIME (RFC3156); when a message comes in
via e.g. S/MIME and goes out to a PGP user, the original signature is
removed, and the message is "proxy signed" with the list's PGP key.
What a strange feature ! Please could you explain more about your needs ? Sympa is
now a kind of S/MIME <-> PGP gateway. My opinion is that it is not a good
thing to replace a signature (pgp or S/mime) based on the sender private key by a
signature based on the list private key. I understand that this can be usefull if
users can't recognize of the S/MIME or PGP signature format. Therefore our
proposition is to include your contrib but to add some Sympa/Robot parameter to
control if the robot is a PGP/SMIME signature gateway or if the robot keeps
unchanged any signature.
Do you agree with this ?

Which
encryption method to use (smime, pgp_ascii, pgp_mime) is a per-user/per-list
property (stored in subscriber_table in a new column "encryption"), settable via web interface, etc.pp.

Great !


From the structure of the code, the main thing I've done is separate out
crypto-related code to a new module crypto.pm; that provides a method-
independent interface to the code calling it, e.g. "encrypt(message, rcpt,
scheme)"; PGP and S/MIME code is split out into pgp.pm and smime.pm and
contains the specific functions (so there's pgp::encrypt_mime, pgp::encrypt_ascii and smime::encrypt, e.g.). The "Message" object
has also undergone some changes to streamline the crypto-related things,
and the process for sending out mails to a list has been reworked...

It sounds very good !

Regards
Serge Aumont

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


--- End Message ---
--- Begin Message ---
  • From: Christian Mock <address@concealed>
  • To: Aumont - Comite Reseaux des Universites <address@concealed>
  • Cc: Olivier Salaun - CRU <address@concealed>
  • Subject: Sympa and PGP, finally!
  • Date: Fri, 19 Mar 2004 19:06:12 +0100
hi,

I'm the one that talked about adding PGP support to sympa years ago,
if your remember.

Well, the customer finally ordered, and I'm nearly done -- I'm running
a test system right now so our closed user group can see if it works for
them, and expect to go into production by beginning or mid of april.

How do we go about integrating it into the official codebase? I see you
released 4.1 yesterday (why 4.1? I was expecting 4.0 after the 4.0[ab]
series...), are there plans for 4.2?

What I've done is giving PGP the same level of support as S/MIME, both
for ascii armored PGP and PGP/MIME (RFC3156); when a message comes in
via e.g. S/MIME and goes out to a PGP user, the original signature is
removed, and the message is "proxy signed" with the list's PGP key. Which
encryption method to use (smime, pgp_ascii, pgp_mime) is a per-user/per-list
property (stored in subscriber_table in a new column "encryption"),
settable via web interface, etc.pp.

>From the structure of the code, the main thing I've done is separate out
crypto-related code to a new module crypto.pm; that provides a method-
independent interface to the code calling it, e.g. "encrypt(message, rcpt,
scheme)"; PGP and S/MIME code is split out into pgp.pm and smime.pm and
contains the specific functions (so there's pgp::encrypt_mime,
pgp::encrypt_ascii and smime::encrypt, e.g.). The "Message" object
has also undergone some changes to streamline the crypto-related things,
and the process for sending out mails to a list has been reworked...

regards,

cm.

--
Christian Mock Wiedner Hauptstr. 15
Senior Security Engineer 1040 Wien
CoreTEC IT Security Solutions GmbH +43-1-5037273

--- End Message ---



Archive powered by MHonArc 2.6.19+.

Top of Page