email interface for Trac: a proposal
Hi everyone, I have been working my way through a wish list of Trac features, and started from implementing an interface to create and reply to tickets via email. I now have a simple prototype, but before proceeding I'd like to receive some feedback on my proposal so far. So here is my masterplan: 1. Verify that the email is signed and the signature is recognised. For the moment and during the first pilot we could restrict this feature to @tpo addresses and verify the key w/ the info we have in db.tpo. Further on, we can verify the key by importing eventually missing keys from known keyservers. I am implementing step 1 through procmail and a simple script. 2. If the email has a valid signature, check permissions for the users, parse the email and create the ticket or reply to a thread. I am implementing step 2 through a python script, so that I can interface directly with Trac libraries. Note that I am assuming that I am receiving somehow the email on the server. For testing purpose I have been configuring postfix, but this of course might change in prod. A couple of questions I now have. - Do you have any particular concern with this setup? - Anything I should consider when introducing a change in a tpo infrastructure machine? One last thing: the architecture is simple enough but I'd like to share my scripts and procmail setup, so that you can all have a look. Can I get a git repo for this project? Thanks, - s
On 09 Dec (18:54:32), Silvia [Hiro] wrote:
Hi everyone,
I have been working my way through a wish list of Trac features, and started from implementing an interface to create and reply to tickets via email.
I now have a simple prototype, but before proceeding I'd like to receive some feedback on my proposal so far.
So here is my masterplan:
1. Verify that the email is signed and the signature is recognised. For the moment and during the first pilot we could restrict this feature to @tpo addresses and verify the key w/ the info we have in db.tpo. Further on, we can verify the key by importing eventually missing keys from known keyservers.
I am implementing step 1 through procmail and a simple script.
2. If the email has a valid signature, check permissions for the users, parse the email and create the ticket or reply to a thread.
One thing here that could block a user is the GPG key expiration. If the key is expired, I guess the validation should fail but would be nice that the user gets a meaningful message at that point. In that case, this setup will need to have a quick way to retrieve a key that is in the database but not working (expired). Not sure how to pull that off but I'll let you think about it :). I personally like this validation so we avoid unauthenticated SPAM on our trac which is already bad enough sometimes with cypherpunks account. Thanks hiro! David
I am implementing step 2 through a python script, so that I can interface directly with Trac libraries.
Note that I am assuming that I am receiving somehow the email on the server. For testing purpose I have been configuring postfix, but this of course might change in prod.
A couple of questions I now have.
- Do you have any particular concern with this setup?
- Anything I should consider when introducing a change in a tpo infrastructure machine?
One last thing: the architecture is simple enough but I'd like to share my scripts and procmail setup, so that you can all have a look. Can I get a git repo for this project?
Thanks,
- s
_______________________________________________ tor-project mailing list tor-project@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
On Fri, 09 Dec 2016, David Goulet wrote:
One thing here that could block a user is the GPG key expiration. If the key is expired, I guess the validation should fail but would be nice that the user gets a meaningful message at that point.
In that case, this setup will need to have a quick way to retrieve a key that is in the database but not working (expired). Not sure how to pull that off but I'll let you think about it :).
If your key in db.torproject.org is expired, you screwed up. You file a ticket with tpa to have it updated. This isn't something that trac (or other consumers of the keyring) need to work around imo. weasel -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal https://www.palfrader.org/ | `. `' Operating System | `- https://www.debian.org/
Hi, I have shared the first version here: https://gitweb.torproject.org/admin/trac/trac-email.git/ You will find procmail config, perl script verifying gpg signature (very simple), python script to verify user permissions and create/update trac tickets (still WIP). Looking forward to get more feedback on the proposed changes. - s On 10/12/16 09:31, Peter Palfrader wrote:
On Fri, 09 Dec 2016, David Goulet wrote:
One thing here that could block a user is the GPG key expiration. If the key is expired, I guess the validation should fail but would be nice that the user gets a meaningful message at that point.
In that case, this setup will need to have a quick way to retrieve a key that is in the database but not working (expired). Not sure how to pull that off but I'll let you think about it :). If your key in db.torproject.org is expired, you screwed up. You file a ticket with tpa to have it updated. This isn't something that trac (or other consumers of the keyring) need to work around imo.
weasel
On Mon, 12 Dec 2016, Silvia [Hiro] wrote:
I have shared the first version here: https://gitweb.torproject.org/admin/trac/trac-email.git/
You will find procmail config, perl script verifying gpg signature (very simple), python script to verify user permissions and create/update trac tickets (still WIP).
Looking forward to get more feedback on the proposed changes.
I just glanced at it briefly, but the verify script has me worried. It uses Perl without 'use strict', nowadays open() really should use >= 3 arguments, and I am not convinced the script actually verifies that the entire mail is signed. Also, you can't reliably cont on the exit code of gpg for verifying signatures. Cheers, -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal https://www.palfrader.org/ | `. `' Operating System | `- https://www.debian.org/
Apologies, I was eager to get some feedback and forgot to mention that the intention was to get rid of the perl part and move verification into and trac ticket management into the same script. I am now managing the trust part of the signature verification ( https://gitweb.torproject.org/admin/trac/trac-email.git/ ), but still heavy WIP. Will ask for feedback when I have a more complete prototype, so it is more clear how I want this to work. -s On 12/12/16 23:29, Peter Palfrader wrote:
On Mon, 12 Dec 2016, Silvia [Hiro] wrote:
I have shared the first version here: https://gitweb.torproject.org/admin/trac/trac-email.git/
You will find procmail config, perl script verifying gpg signature (very simple), python script to verify user permissions and create/update trac tickets (still WIP).
Looking forward to get more feedback on the proposed changes. I just glanced at it briefly, but the verify script has me worried. It uses Perl without 'use strict', nowadays open() really should use >= 3 arguments, and I am not convinced the script actually verifies that the entire mail is signed.
Also, you can't reliably cont on the exit code of gpg for verifying signatures.
Cheers,
Hi, So I have a bare minimum prototype here: https://gitweb.torproject.org/admin/trac/trac-email.git/tree/notify.py But I have started thinking that maybe this shouldn't be a simple script parsing emails. Maybe I am over-thinking this but I am seeing a need in having a service that can perform basic cryptographic verification and small integrations. I will list a few examples: 1. Trac email interface to open and reply to tickets. 2. Trac authentication for xmprpc (better than just http auth) 3. Encrypted mailing lists What I am outlining here is a simple service where, for example, we can send a signed request via REST APIs and perform some actions. So for example 1 the service will check an email account and verify signatures to open/reply to trac tickets. For example 2 there will be an API endpoint where we can send a signed request to interact with trac (better than http auth which is the standard for xmlrpc plugin). Example 3 involves people sending encrypted emails w/ the server key, and the server decrypting the email, encrypting with the participant keys and sending the encrypted emails. In this case I wouldn't reinvent the wheel and I would opt for integrating w/ schleuder (https://git.codecoop.org/schleuder/schleuder3/). - Note I am aware of the GPG 2 requirement and haven't fully considered this just yet ;) Thoughts? Ideas? - s On 13/12/16 13:20, Silvia [Hiro] wrote:
Apologies, I was eager to get some feedback and forgot to mention that the intention was to get rid of the perl part and move verification into and trac ticket management into the same script.
I am now managing the trust part of the signature verification (
https://gitweb.torproject.org/admin/trac/trac-email.git/
), but still heavy WIP.
Will ask for feedback when I have a more complete prototype, so it is more clear how I want this to work.
-s
On 12/12/16 23:29, Peter Palfrader wrote:
On Mon, 12 Dec 2016, Silvia [Hiro] wrote:
I have shared the first version here: https://gitweb.torproject.org/admin/trac/trac-email.git/
You will find procmail config, perl script verifying gpg signature (very simple), python script to verify user permissions and create/update trac tickets (still WIP).
Looking forward to get more feedback on the proposed changes. I just glanced at it briefly, but the verify script has me worried. It uses Perl without 'use strict', nowadays open() really should use >= 3 arguments, and I am not convinced the script actually verifies that the entire mail is signed.
Also, you can't reliably cont on the exit code of gpg for verifying signatures.
Cheers,
_______________________________________________ tor-project mailing list tor-project@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
On 15 Dec. 2016, at 21:41, Silvia [Hiro] <hiro@torproject.org> wrote:
Hi,
So I have a bare minimum prototype here: https://gitweb.torproject.org/admin/trac/trac-email.git/tree/notify.py
But I have started thinking that maybe this shouldn't be a simple script parsing emails. Maybe I am over-thinking this but I am seeing a need in having a service that can perform basic cryptographic verification and small integrations. I will list a few examples:
1. Trac email interface to open and reply to tickets.
2. Trac authentication for xmprpc (better than just http auth)
3. Encrypted mailing lists
What I am outlining here is a simple service where, for example, we can send a signed request via REST APIs and perform some actions.
So for example 1 the service will check an email account and verify signatures to open/reply to trac tickets.
For example 2 there will be an API endpoint where we can send a signed request to interact with trac (better than http auth which is the standard for xmlrpc plugin).
Example 3 involves people sending encrypted emails w/ the server key, and the server decrypting the email, encrypting with the participant keys and sending the encrypted emails. In this case I wouldn't reinvent the wheel and I would opt for integrating w/ schleuder (https://git.codecoop.org/schleuder/schleuder3/). - Note I am aware of the GPG 2 requirement and haven't fully considered this just yet ;)
Thoughts? Ideas?
Are you familiar with db.torproject.org? It does something similar to this for SSH key and password management. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
On 15/12/16 13:09, teor wrote:
Are you familiar with db.torproject.org? It does something similar to this for SSH key and password management. Yep, but this would be something we can use w/ a REST call. I.e. instead of authenticating via http to trac and use the xmlrpc plugin, we just send the request signed.
Hi Silvia, Silvia [Hiro]:
I have been working my way through a wish list of Trac features, and started from implementing an interface to create and reply to tickets via email.
I now have a simple prototype, but before proceeding I'd like to receive some feedback on my proposal so far.
Thanks for your work! Some random thoughts: How about Trac interface for mailing list? It is proved to be a fast and convenient way to coordinate. It's also simple and straightforward to submit and apply patches to/from mailing list. Yes, mailing list lacks numbering and actual tracking (tagging, assignment) that Trac has. Maybe we can just build a 'smart' mail list server that can add tracking (e.g. via modifying headers or Subject) and is able to export threads to Trac (so who like Trac will be able to use it, e.g. 'cypherpunks' account). With Trac there is a long loop for each ticket. For example, imagine that there is a tiny typo: * Fire up your Browser * Head out to Trac * Login * Create new ticket * Attach a patch + Solve captcha (and enable JS) * Modify patch that it needs_review | * Download patch from Trac * Apply it * Mark ticket as closed IMO, this can be replaced just with two emails (postprocessed/tagged?): [ Subject: Title, Body: Message, Patch] [ Subject: Titile, Body: Applied/Status change] Also this can glue together whole discussion in both mailing list and Trac. P.S. Probably it's just me who don't like the web. -- Ivan Markin
On Fri, 09 Dec 2016, Silvia [Hiro] wrote:
1. Verify that the email is signed and the signature is recognised. For the moment and during the first pilot we could restrict this feature to @tpo addresses and verify the key w/ the info we have in db.tpo. Further on, we can verify the key by importing eventually missing keys from known keyservers.
I am implementing step 1 through procmail and a simple script.
2. If the email has a valid signature, check permissions for the users, parse the email and create the ticket or reply to a thread.
If they mail is signed by a key in the torproject.org keyring, that should be good enough. I don't think we need to set up per-user privileges. Accountability is quite sufficient. -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal https://www.palfrader.org/ | `. `' Operating System | `- https://www.debian.org/
participants (5)
-
David Goulet -
Ivan Markin -
Peter Palfrader -
Silvia [Hiro] -
teor