-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I make a patch who improve the search :
- - When you click on a message, the previous/next button switch between
search result, and not all mails.
- - When you return to the list, the search is memorized
The patch close : http://trac.roundcube.net/ticket/1483883. I send it on
the ticket too.
Regards,
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: http://firegpg.tuxfamily.org
iEYEARECAAYFAkefffIACgkQjKKs5/FTCjXxgQCgle6fJm4cTMiG6MuAlq+L1Td0
zhMAniGFRDKTcZpbIGbMRcwor99g6v3D
=hhwd
-----END PGP SIGNATURE-----
--
Maximilien Cuony [The_Glu]
http://theglu.org
--- 8< --- detachments --- 8< ---
The following attachments have been detached and are available for viewing.
http://detached.gigo.com/rc/jr/uVTaa7ap/search-pattch
Only click these links if you trust the sender, as well as this message.
--- 8< --- detachments --- 8< ---
_______________________________________________
List info: http://lists.roundcube.net/dev/
Hi guys,
we progressed a bit with the merge ("translating" changes made since
the 0.1-rc1 release to devel-vnext branch) over the last weekend
including yesterday. I think we are half way there. If you follow
commits (1), you can check it out. I didn't have any time testing yet
and will hopefully continue tomorrow.
As Thomas previously wrote, we then need to work on 0.1 tickets (2),
if any of the developers could help out - it would be really
appreciated. After all we have 22 contributors (well, 21) according to
Ohloh (3) which theoretically means we have the resources.
Cheers,
Till (and also Tomasz)
1, <http://trac.roundcube.net/browser/branches/devel-vnext>
2, <http://trac.roundcube.net/query?status=new&status=assigned&status=reopened&…>
3, <http://www.ohloh.net/projects/240/analyses/latest/contributors>
_______________________________________________
List info: http://lists.roundcube.net/dev/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I make two small patches to correct two smalls problems :
First, When we got a new mail, the title of the page change (the number of
new mails is showed). But if we click to set a message as read, or delete
it,
the title counter is not updated.
So !
- - When a message is moved or deleted, the counter is updated [only for
inbox)
- - When a message is read/unread on the list, the counter is updated [only
for inbox]
- - If you access roundcube with an url like ?_task=mail&_mbox=INBOX,
counter
is updated (only for inbox)
- - If you read a message and return to the list, the counter is updated
- - We you read a message, the counter is updated too (counter is here when
you read the message). I don't know if it's a
good idea, but is hard to disable this (it's possible, but it's mean a lot
of changes)
- - If you navigate between folders and go to inbox, the counter is
updated.
- - When a new message is received, the title is updated, only for inbox !
(I
think this feature for trash is not very useful ;) )
It's fix http://trac.roundcube.net/ticket/1484650 :)
Second :
We you click on a list, and re-click later on the same row, the row is
showed as selected, but not in the interface (for example in the mail list
button for actions (replay...) switch to disables)
I didn't really found the problem in the code, but I find a way to fix the
problem. I tested the lists with my edit, and I don't see any changes in
they comportment, so I think it's ok.
All patches are based on the trunk, lasted revision. I hope you will patch
the trunk if there is no problems :)
Regards,
- --
Maximilien Cuony [The_Glu]
http://theglu.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: http://firegpg.tuxfamily.org
iEYEARECAAYFAkebNgoACgkQjKKs5/FTCjUYJgCfaoNMSYcPgGOmAyWlgrBiGfGt
XDEAniLuQJva9R+hmctKwr5yoQlZwwve
=dm/6
-----END PGP SIGNATURE-----
--- 8< --- detachments --- 8< ---
The following attachments have been detached and are available for viewing.
http://detached.gigo.com/rc/pf/7yJFnqq1/patch1-unreadcounter.txthttp://detached.gigo.com/rc/pf/7yJFnqq1/patch2-long-double-c.txt
Only click these links if you trust the sender, as well as this message.
--- 8< --- detachments --- 8< ---
_______________________________________________
List info: http://lists.roundcube.net/dev/
Hi Guys,
Something there I miss on round cube is the possibility to save all
attachments at once (or all images from one e-mail).
There is any plan? Someone already developed this feature?
--
Rodrigo Carvalhaes
DBA PostgreSQL
_______________________________________________
List info: http://lists.roundcube.net/dev/
Hello everyone,
I hope this isn't something already discussed, but I didn't find
anything in the archive:
What feature I really miss is marking/flagging messages. Like
Thunderbird supports (the yellow star) and also most of the common
e-mail-clients.
Are there any plans / did anyone already start with that?
Raphael
_______________________________________________
List info: http://lists.roundcube.net/dev/
That sounds like a good feature. GMail does it nicely where it
automatically ZIPs all the attachments into a zipfile for easier
downloading. Something like that would be nice, and not too difficult if
the installation has the ZZIPlib or zlib module installed.
-Ben
_______________________________________________
List info: http://lists.roundcube.net/dev/
On Wed, 23 Jan 2008 16:36:23 +0100, "Maximilien Cuony [The_Glu]" <maximilien(a)theglu.org> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
>> On one last note; I can't help but notice the omission of keyservers
>> in any of these scenarios. I mean you /must/ use them. Yet nobody
>> even mentions the possibility of /them/ being trustworthy.
>
> Just to be sure, you're speaking about checking signs with key on servers
> (like pgp.mit.edu) ?
Or:
wwwkeys.pgp.net, or www.keyserver.net, or subkeys.pgp.net, or
blackhole.pca.dfn.de, or pks.aaiedu.hr, or random.sks.keyserver.penguin.de.
Yes. :)
--Chris
>
> Regards,
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (GNU/Linux)
> Comment: http://firegpg.tuxfamily.org
>
> iEYEARECAAYFAkeXXvIACgkQjKKs5/FTCjVtzQCdEbI/7X8nbGF4ty3W0sJ9nNWp
> vAQAn0TZKGI7kK0g+od60alY3JtWCBl8
> =SC3e
> -----END PGP SIGNATURE-----
>
>
> On Fri, 18 Jan 2008 02:56:12 -0800, chris# <chris#(a)codewarehouse.NET>
> wrote:
>>
>>
>>
>> On Thu, 17 Jan 2008 20:22:41 +0100, till <klimpong(a)gmail.com> wrote:
>>> Dear Maximilien,
>>>
>>> On Jan 17, 2008 4:17 PM, Jason Fesler <jfesler(a)gigo.com> wrote:
>>>> (...)
>>>> Oh well, off my soap box. Implement what you want. I just hope any
>>>> README or whatever includes some paranoia.
>>>
>>> +1
>>>
>>> I'm not strictly against this feature but then again I wouldn't upload
>>> my key to *any* provider.
>>>
>>> Think about the general risk. I am not saying that someone will spy on
>>> you and steal your key but what if they get hacked etc..
>>
>> Then their ssl certs will /also/ be at risk. Hell, It /really/ is not
>> difficult
>> to "lift" their certs, and implement a little DNS cache poisoning and
>> claim to be them. Then /you/ as their user will continue to use a server
>> you /believe/ to be them. While all the while, they're (the hackers)
>> in complete control of your mail. Phishing also comes to mind.
>>
>>> There are
>>> multiple scenarios that come to mind. I guess it's fine to have this
>>> feature when you are in total control of your environment and don't
>>> mind the risk.
>>>
>>> Anyway, having said that - and since no one else said, "OH I AM
>>> WORKING ON THIS", go knock yourself out. ;-)
>>
>> I believe it is a worthy cause in both cases. It would simply be more
>> feasible as a "server side" solution.
>>
>> On one last note; I can't help but notice the omission of keyservers
>> in any of these scenarios. I mean you /must/ use them. Yet nobody
>> even mentions the possibility of /them/ being trustworthy.
>>
>>>
>>> Till
>> /////////////////////////////////////////////////////
>> Service provided by hitOmeter.NET internet messaging!
>> .
>>
>>
>> _______________________________________________
>> List info: http://lists.roundcube.net/dev/
> --
> Maximilien Cuony [The_Glu]
> http://theglu.org
/////////////////////////////////////////////////////
Service provided by hitOmeter.NET internet messaging!
.
_______________________________________________
List info: http://lists.roundcube.net/dev/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
> On one last note; I can't help but notice the omission of keyservers
> in any of these scenarios. I mean you /must/ use them. Yet nobody
> even mentions the possibility of /them/ being trustworthy.
Just to be sure, you're speaking about checking signs with key on servers
(like pgp.mit.edu) ?
Regards,
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: http://firegpg.tuxfamily.org
iEYEARECAAYFAkeXXvIACgkQjKKs5/FTCjVtzQCdEbI/7X8nbGF4ty3W0sJ9nNWp
vAQAn0TZKGI7kK0g+od60alY3JtWCBl8
=SC3e
-----END PGP SIGNATURE-----
> On Fri, 18 Jan 2008 02:56:12 -0800, chris# <chris#(a)codewarehouse.NET>
> wrote:
>>
>>
>>
>> On Thu, 17 Jan 2008 20:22:41 +0100, till <klimpong(a)gmail.com> wrote:
>>> Dear Maximilien,
>>>
>>> On Jan 17, 2008 4:17 PM, Jason Fesler <jfesler(a)gigo.com> wrote:
>>>> (...)
>>>> Oh well, off my soap box. Implement what you want. I just hope any
>>>> README or whatever includes some paranoia.
>>>
>>> +1
>>>
>>> I'm not strictly against this feature but then again I wouldn't upload
>>> my key to *any* provider.
>>>
>>> Think about the general risk. I am not saying that someone will spy on
>>> you and steal your key but what if they get hacked etc..
>>
>> Then their ssl certs will /also/ be at risk. Hell, It /really/ is not
>> difficult
>> to "lift" their certs, and implement a little DNS cache poisoning and
>> claim to be them. Then /you/ as their user will continue to use a server
>> you /believe/ to be them. While all the while, they're (the hackers)
>> in complete control of your mail. Phishing also comes to mind.
>>
>>> There are
>>> multiple scenarios that come to mind. I guess it's fine to have this
>>> feature when you are in total control of your environment and don't
>>> mind the risk.
>>>
>>> Anyway, having said that - and since no one else said, "OH I AM
>>> WORKING ON THIS", go knock yourself out. ;-)
>>
>> I believe it is a worthy cause in both cases. It would simply be more
>> feasible as a "server side" solution.
>>
>> On one last note; I can't help but notice the omission of keyservers
>> in any of these scenarios. I mean you /must/ use them. Yet nobody
>> even mentions the possibility of /them/ being trustworthy.
>>
>>>
>>> Till
>> /////////////////////////////////////////////////////
>> Service provided by hitOmeter.NET internet messaging!
>> .
>>
>>
>> _______________________________________________
>> List info: http://lists.roundcube.net/dev/
> --
> Maximilien Cuony [The_Glu]
> http://theglu.org
--
Maximilien Cuony [The_Glu]
http://theglu.org
_______________________________________________
List info: http://lists.roundcube.net/dev/
Vincent Bernat wrote:
> A vulnerability was discovered in Roundcube:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=455840
>
> It seems that there is no fix yet. Any idea on this topic?
This is not strictly a RoundCube vulnerability but Internet Explorer's
intended behaviour.
I'm not sure if we need to prevent IE doing something that Microsoft
wants it to do (http://openmya.hacker.jp/hasegawa/security/expression.txt):
'As a result of having confirmed in our company development department,
this phenomenon is the behavior by design of Internet Explorer,
and it was judged it does not fit the definition of vulnerability.'
On the other hand, if a 'fix' can prevent IE users into more trouble
than they already are :), and it won't break any functionality, I see no
problem working around this 'feature'.
I'll try to find out what other webmails do about this.
A workaround would be for IE users to turn off the 'Prefer HTML' option.
Robin
PS. Interesting, the posting on securityfocus says 'Author was contacted
on 2007-05-11' but I don't recall any _specific_ vulnerability being
reported on the dev-mailing list around that time. Unfortunately the
archives are down right now so I cannot check my external memory.
_______________________________________________
List info: http://lists.roundcube.net/dev/