Dev

dev@lists.roundcube.net

4301 discussions

Start a nNew thread

Enigma logging
by Kyle Francis 23 Aug '16

23 Aug '16

2 1

QP-encoding and decoding within a plugin
by Rimas Kudelis 18 Aug '16

18 Aug '16

Hi, is there an official way to QP-encode and QP-decode a text string from within a RoundCube plugin? Thanks! Rimas

2 2

RC 1.2.1 - Enigma signed e-mail validation failure
by sgironella＠schema31.it 28 Jul '16

28 Jul '16

Hi. I'm facing a strange behaviour on latest RC version. I've enabled Enigma plugin and I'm able to create my key pairs, sign and encrypt messages. The strange thing is I couldn't verify signed messages at all, even if decryption in perfectly working. I've debugged GPG class (vendor/pear-pear.php.net/Crypt_GPG/Crypt/GPG.php) to verify what he was doing and why sign validation always fails. Within _SIGN() method, I've added following lines to log what he was going to sign: _$rc = rcmail::get_instance();_ _$rc->console('---------------------------------');_ _$rc->console('SIGN INPUT');_ _$rc->console($input);_ _$rc->console('---------------------------------');_ Same thing within _VERIFY() method, to log what is going to verify: _$rc = rcmail::get_instance();_ _$rc->console('---------------------------------');_ _$rc->console('VERIFY INPUT');_ _$rc->console($input);_ _$rc->console('---------------------------------');_ _$rc->console('VERIFY SIGNATURE');_ _$rc->console($signature);_ _$rc->console('---------------------------------');_ Here is my full output for the sequence: * user send a new signed email to himself * user goes to inbox and open signed e-mail I've noticed that the signed message has an extra newline between main headers and body (take a look at the highlited rows) so I thing that's why sign verification fails (content doesn't match with original message). _[27-Jul-2016 15:10:38 +0200]: <cmnloql4> ---------------------------------_ _[27-Jul-2016 15:10:38 +0200]: <cmnloql4> SIGN INPUT_ _[27-JUL-2016 15:10:38 +0200]: <CMNLOQL4> CONTENT-TYPE: MULTIPART/ALTERNATIVE;_ _ BOUNDARY="=_944CBD90B0D51928FF049222817A4B03"_ _--=_944CBD90B0D51928FF049222817A4B03_ _Content-Transfer-Encoding: 7bit_ _Content-Type: text/plain; charset=US-ASCII_ _This is an HTML content..._ _--=_944cbd90b0d51928ff049222817a4b03_ _Content-Transfer-Encoding: quoted-printable_ _Content-Type: text/html; charset=UTF-8_ _<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=_ _=3DUTF-8" /></head><body style=3D'font-size: 10pt; font-family: Verdana,Gen=_ _eva,sans-serif'>_ _<p>This is an HTML content...</p>_ _</body></html>_ _--=_944cbd90b0d51928ff049222817a4b03--_ _[27-Jul-2016 15:10:38 +0200]: <cmnloql4> ---------------------------------_ _[27-Jul-2016 15:10:45 +0200]: <cmnloql4> ---------------------------------_ _[27-Jul-2016 15:10:45 +0200]: <cmnloql4> VERIFY INPUT_ _[27-JUL-2016 15:10:45 +0200]: <CMNLOQL4> CONTENT-TYPE: MULTIPART/ALTERNATIVE;_ _ BOUNDARY="=_944CBD90B0D51928FF049222817A4B03"_ _--=_944CBD90B0D51928FF049222817A4B03_ _Content-Transfer-Encoding: 7bit_ _Content-Type: text/plain; charset=US-ASCII_ _This is an HTML content..._ _--=_944cbd90b0d51928ff049222817a4b03_ _Content-Transfer-Encoding: quoted-printable_ _Content-Type: text/html; charset=UTF-8_ _<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=_ _=3DUTF-8" /></head><body style=3D'font-size: 10pt; font-family: Verdana,Gen=_ _eva,sans-serif'>_ _<p>This is an HTML content...</p>_ _</body></html>_ _--=_944cbd90b0d51928ff049222817a4b03--_ _[27-Jul-2016 15:10:45 +0200]: <cmnloql4> ---------------------------------_ _[27-Jul-2016 15:10:45 +0200]: <cmnloql4> VERIFY SIGNATURE_ _[27-Jul-2016 15:10:45 +0200]: <cmnloql4> -----BEGIN PGP SIGNATURE-----_ _Version: GnuPG v1_ _iQEcBAEBAgAGBQJXmLLOAAoJEB1v3mO3A8Wpz6QH/015jrt7YkfGT8pE1nyjpHHe_ _JoCEmugkpmEgJ6wjTgU1SHQos5l1mKqFhsrzpdNghO11yqB/NxOjxOpqSkE9c9c1_ _dXr/H53cLfqPULMD5dqGBFua180BUdLAQ0Nvyll7kD8Y/irU5ccrwA1e3Cb9RYp0_ _sGplLYcD7pPKthCGQfFzPslL9Fj82MBJigm46cKa7pqYhJDNkM4q4zsqtNXcTUqB_ _HcFhEL3+Q21bAbie+B8hDw2SUYGEZORf+sLUrW1oQLLG5ld6XZywCDDKdpq6F+ET_ _OzVaXta8cMIg5dwP/10VALlqYavlzjY/0h7lBmEgm5W/ehs7XuReur45LsS1KJg=_ _=Q6j9_ _-----END PGP SIGNATURE-----_ _[27-Jul-2016 15:10:45 +0200]: <cmnloql4> --------------------------------_ Anyone is facing the same issue? Maybe it's not an Enigma related issue but a Roundcube behaviour because it happes even on not signed e-mails (but in this case it doesn't bother at all). Any help would be really appreciate. Thanks. Stefano

3 4

Update 1.2.1 published
by Thomas Bruederli 26 Jul '16

26 Jul '16

Dear subscribers We just published the first service release to update the stable version 1.2. It contains some important bug fixes and improvements in the recently introduced Enigma plugin for PGP encryption. See the detailed Changelog in the wiki [1] or on the the release page [2]. This release is considered stable and we recommend to update all productive installations of Roundcube with this version. Download it from GitHub via https://roundcube.net/download. As usual, don’t forget to backup your data before updating! Best, Thomas [1] https://github.com/roundcube/roundcubemail/wiki/Changelog#release-121 [2] https://github.com/roundcube/roundcubemail/releases/tag/1.2.1

1 0

RC 1.2 - Corrupted e-mail headers while sending an html empty message
by sgironella＠schema31.it 14 Jul '16

14 Jul '16

Hello all, I've recently posted a bug reporting to the Roundcube community forum [1] We have noticed a strange behavior with a fresh Roundcube 1.2 install (no additional plugins enabled nor 'strange' custom config defined). To reproduce this, send an e-mail using the html editor, leaving a blank content. Received e-mail has a 'text/html' content-type (instead of the expected 'multipart'). therefore client view raw mime-parts as e-mail content. Note that sent e-mail (taken from sender 'sent' mailbox) has the right content-type (multipart) so it's perfectly readable. In addition, we have recorded a tcpdump session, that confirm our impression of having two separate libraries handling in a different way SMPT (for delivery) and IMAP (for storing e-mail within 'sent' inbox) sections; that's what we got: IMAP SESSION (SAVE E-MAIL TO 'SENT' MAILBOX) - Note the right mime-type and boundary here * OK [CAPABILITY IMAP4rev1 AUTH=LOGIN AUTH=CRAM-MD5 ID LITERAL+] dbmail 3.2.3 ready. A0001 LOGIN xxxxx@xxxxxx xxxxxxx A0001 OK [CAPABILITY IMAP4rev1 ACL RIGHTS=texk NAMESPACE CHILDREN SORT QUOTA THREAD=ORDEREDSUBJECT UNSELECT IDLE ID UIDPLUS WITHIN CONDSTORE LITERAL+ ENABLE QRESYNC] User utente1(a)mail.qa.schema31.it authenticated A0002 LSUB "" Sent * LSUB (\hasnochildren) "/" "Sent" A0002 OK LSUB completed A0003 LIST "" Sent * LIST (\hasnochildren) "/" "Sent" A0003 OK LIST completed A0004 APPEND Sent (\Seen) {936+} MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_17681037babd7dadb94a79c2cf51cb1f" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Jul 2016 14:23:01 +0200 From: Utente di TEST <utente1(a)mail.qa.schema31.it> To: stefano.gironella(a)gmail.com Subject: prova 2 Organization: SC31 Message-ID: <a46919e3b0380e0dc85f82e475581740(a)mail.qa.schema31.it> X-Sender: utente1(a)mail.qa.schema31.it User-Agent: Roundcube Webmail/1.2.0 --=_17681037babd7dadb94a79c2cf51cb1f Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII --=_17681037babd7dadb94a79c2cf51cb1f Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset= =3DUTF-8" /></head><body style=3D'font-size: 10pt; font-family: Verdana,Gen= eva,sans-serif'> </body></html> --=_17681037babd7dadb94a79c2cf51cb1f-- A0004 OK [APPENDUID 2028 2695213] APPEND completed A0005 LOGOUT * BYE A0005 OK LOGOUT completed SMTP SESSION (E-MAIL DISPATCH) - Note that content-type here is 'text/html' (maybe taken from the first non-empty mime-part?) 220 litio.roma.schema31.it ESMTP Sendmail 8.14.5/8.14.5; Thu, 14 Jul 2016 14:23:01 +0200 (CEST) EHLO localhost 250-litio.roma.schema31.it Hello [10.33.100.158], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-STARTTLS 250-DELIVERBY 250 HELP MAIL FROM:<utente1(a)mail.qa.schema31.it> 250 2.1.0 <utente1(a)mail.qa.schema31.it>... Sender ok RCPT TO:<stefano.gironella(a)gmail.com> 250 2.1.5 <stefano.gironella(a)gmail.com>... Recipient ok DATA 354 Enter mail, end with "." on a line by itself MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Jul 2016 14:23:01 +0200 From: Utente di TEST <utente1(a)mail.qa.schema31.it> To: stefano.gironella(a)gmail.com Subject: prova 2 Organization: SC31 Message-ID: <a46919e3b0380e0dc85f82e475581740(a)mail.qa.schema31.it> X-Sender: utente1(a)mail.qa.schema31.it User-Agent: Roundcube Webmail/1.2.0 --=_6e4cf8211c48e997305a4faab4020297 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII --=_6e4cf8211c48e997305a4faab4020297 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset= =3DUTF-8" /></head><body style=3D'font-size: 10pt; font-family: Verdana,Gen= eva,sans-serif'> </body></html> --=_6e4cf8211c48e997305a4faab4020297-- . 250 2.0.0 u6ECN1Je026469 Message accepted for delivery QUIT 221 2.0.0 litio.roma.schema31.it closing connection Links: ------ [1] http://www.roundcubeforum.net/index.php/topic,23529.0.html

3 4

Mailvelope default keyring identifier
by Kyle Francis 12 Jul '16

12 Jul '16

I noticed in app.js the default mailvelope keyring identifier is set to this.user_id, which is a long unique identifier. This produced an unexpected behavior for me. My use case was as such: I initially installed Mailvelope, exported my GPG keys from roundcube/enigma and loaded them into Mailvelope (no issues). Then I attempted to encrypt an outgoing email using the Mailvelope api plugin (vice the enigma plugin) and was told that Mailvelope was unable to find the requisite public keys for the intended recipient. Wait, what? I just imported those in the last step... In debugging app.js through the browser I saw that the keyring was in fact empty, yet the only keyring I saw through the plugin interface in Firefox was the default keyring that I had previously imported keys into. It wasn't until I used the mailvelope API to manually open the settings page for the new keyring that I was able to in face see the alternate keyring (and subsequently add keys to it). As it turns out, the default keyring identifier used by the Mailvelope plugin is in fact 'mailvelope'. Would it make more sense to default to that keyring instead of initializing a new one off of the user_id in Roundcube? Are there any conflicts that I'm not thinking of? I suggest this change since I wasn't even able to find the new roundcube keyring from the user interface in the first place. To me this seems "more intuitive", but then again my HCI course isn't until the fall semester ;) If this would be useful I would be more than happy to submit a PR. Kyle

2 1

Updating Crypt_GPG version
by Kyle Francis 11 Jul '16

11 Jul '16

I saw the changes for adding the option to exporting Private GPG keys from the Enigma plugin which is awesome. I was doing some testing with my SMIME work making sure I didn't break anything when I noticed that exporting private GPG keys fails for me because I don't have the latest version of Crypt_GPG which has the new exportPrivateKeys function. Since the vendor folder isn't included in the github repo, what would be the best way to update my local copy of Crypt_GPG? Can I just copy Crypt_GPG-1.4.2/{Crypt,data} to roundcubemail/vendor/pear-pear.php.net/Crypt_GPG? Kyle

2 2

Accessing Mailvelope Keyring
by Kyle Francis 11 Jul '16

11 Jul '16

I just started playing around with the Mailvelope support in v1.2 and I it looks quite nice. I wasn't aware that Mailvelope now supports adding attachements and that was a pleasant surprise. In attempting to implement the hybrid PGP decryption model (decrypting the session key in the client and passing the session key back to the server for full decryption) I was hoping to tap into the mailvelope keyring as I figure it will be more secure in terms of storage than attempting to write my own using openpgp.js. I see where mailvelope is loaded in app.js and "this" refers to an instance of rcube_webmail. However, from the plugin space (i.e. enigma.js) the "this" class is of type rcmail and notably "this" does not contain the previously initialized "mailvelope_keyring". Since my javascript fu is not as strong as my php fu, would anyone be able to point me in the right direction of how to access the mailvelope_keyring from inside the plugin space, specifically enigma.js? -Kyle

2 1

[1.3] Drop mail() support
by A.L.E.C 28 Jun '16

28 Jun '16

PHP mail() is just too simple for such a sophisticated app as Roundcube. I propose to drop mail() support and require smtp_server setting. Is there any reason to keep it? https://github.com/roundcube/roundcubemail/issues/5340 -- Aleksander 'A.L.E.C' Machniak Kolab Groupware Developer [http://kolab.org] Roundcube Webmail Developer [http://roundcube.net] --------------------------------------------------- PGP: 19359DC1 @@ GG: 2275252 @@ WWW: http://alec.pl

1 0

Enigma decryption password prompt
by Kyle Francis 28 Jun '16

28 Jun '16

2 5

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Dev