[jitsi-dev] FW: [JIRA] Closed: (JITSI-952) The "Log Chat History" option will not stay off. This represents a security hole in that OTR chats remain accessible via Chat History.


#1

Help! I am not a programmer. This bug took me 45 minutes to figure out how to set up an account, log in and post it. I just don’t understand all this tech stuff - truly! Kindly HELP. Please!!! Please repost the bug as it is a valid issue. Thanks.

···

-----Original Message-----

From: Admin [mailto:Info@BizVault.com]

Sent: Thursday, June 09, 2011 3:17 PM
To: 'emcho (JIRA)'
Subject: RE: [JIRA] Closed: (JITSI-952) The "Log Chat History" option will not stay off. This represents a security hole in that OTR chats remain accessible via Chat History.

-----Original Message-----

From: emcho (JIRA) [mailto:jira-no-reply@java.net]

Sent: Thursday, June 09, 2011 3:05 PM
To: DynaProg@java.net
Subject: [JIRA] Closed: (JITSI-952) The "Log Chat History" option will not stay off. This represents a security hole in that OTR chats remain accessible via Chat History.

     [ http://java.net/jira/browse/JITSI-952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

emcho closed JITSI-952.
-----------------------

    Resolution: Incomplete

Hello and thanks for your report!

Note however that as our "Bugs and Issues" page [0] explains, we expect reports to first be submitted in the issue tracker once they have been discussed and confirmed as such on our dev mailing list [1]. This is really important to us and we've tried to made it clear throughout the site.

I'll therefore be marking this issue as Incomplete. Feel free to repost it on dev@jitsi.java.net and we'll reopen it if necessary.

[0] http://www.jitsi.org/index.php/Development/BugsAndIssues
[1] dev@jitsi.java.net

The "Log Chat History" option will not stay off. This represents a security hole in that OTR chats remain accessible via Chat History.
-----------------------------------------------------------------------------------------------------------------------------------------

                Key: JITSI-952
                URL: http://java.net/jira/browse/JITSI-952
            Project: jitsi
         Issue Type: Bug
        Environment: All.
           Reporter: DynaProg
  Original Estimate: 4 hours
Remaining Estimate: 4 hours

The "Log Chat History" option will not stay off. This represents a security hole in that OTR chats remain accessible via Chat History.
A user thus must manually delete all the XML Chat History log files after every usage, to ensure confidentiality of OTR chats.
Either this option (Log Chat History) must be placed in a permanent preferences file and thus made "sticky" (so as to survive both a reset and an upgrade to the program), or else a "SECURE DELETE HISTORY" feature/button/warning should be added to every chat conversation so the user may ensure that any OTR chats can be deleted effectively and permanently.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://java.net/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira


#2

This bug was already reported in February
http://java.net/jira/browse/JITSI-781

···

On 6/10/2011 7:56 AM, Admin wrote:

Help! I am not a programmer. This bug took me 45 minutes to figure out how to set up an account, log in and post it. I just don’t understand all this tech stuff - truly! Kindly HELP. Please!!! Please repost the bug as it is a valid issue. Thanks.

-----Original Message-----
From: Admin [mailto:Info@BizVault.com]
Sent: Thursday, June 09, 2011 3:17 PM
To: 'emcho (JIRA)'
Subject: RE: [JIRA] Closed: (JITSI-952) The "Log Chat History" option will not stay off. This represents a security hole in that OTR chats remain accessible via Chat History.

-----Original Message-----
From: emcho (JIRA) [mailto:jira-no-reply@java.net]
Sent: Thursday, June 09, 2011 3:05 PM
To: DynaProg@java.net
Subject: [JIRA] Closed: (JITSI-952) The "Log Chat History" option will not stay off. This represents a security hole in that OTR chats remain accessible via Chat History.

      [ http://java.net/jira/browse/JITSI-952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

emcho closed JITSI-952.
-----------------------

     Resolution: Incomplete

Hello and thanks for your report!

Note however that as our "Bugs and Issues" page [0] explains, we expect reports to first be submitted in the issue tracker once they have been discussed and confirmed as such on our dev mailing list [1]. This is really important to us and we've tried to made it clear throughout the site.

I'll therefore be marking this issue as Incomplete. Feel free to repost it on dev@jitsi.java.net and we'll reopen it if necessary.

[0] http://www.jitsi.org/index.php/Development/BugsAndIssues
[1] dev@jitsi.java.net

The "Log Chat History" option will not stay off. This represents a security hole in that OTR chats remain accessible via Chat History.
-----------------------------------------------------------------------------------------------------------------------------------------

                 Key: JITSI-952
                 URL: http://java.net/jira/browse/JITSI-952
             Project: jitsi
          Issue Type: Bug
         Environment: All.
            Reporter: DynaProg
   Original Estimate: 4 hours
  Remaining Estimate: 4 hours

The "Log Chat History" option will not stay off. This represents a security hole in that OTR chats remain accessible via Chat History.
A user thus must manually delete all the XML Chat History log files after every usage, to ensure confidentiality of OTR chats.
Either this option (Log Chat History) must be placed in a permanent preferences file and thus made "sticky" (so as to survive both a reset and an upgrade to the program), or else a "SECURE DELETE HISTORY" feature/button/warning should be added to every chat conversation so the user may ensure that any OTR chats can be deleted effectively and permanently.


#3

Hello,

I have this issue when i call with Jitsi on one of my computers: i cannot hear anything the first few seconds of a call. The sound indicator does move in this time, but nothing is played.
After this, the call works with no issues. The first second i hear is a bit garbled.

There is an error that pops up from time to time (but not every time):

09:32:58.591 SEVERE: util.UtilActivator.uncaughtException().88 An uncaught exception occurred in thread=Thread[Thread-229,6,main] and message was: null
java.lang.NullPointerException
  at net.java.sip.communicator.impl.neomedia.notify.PortAudioClipImpl.runOnceInPlayThread(PortAudioClipImpl.java:196)
  at net.java.sip.communicator.impl.neomedia.notify.PortAudioClipImpl.runInPlayThread(PortAudioClipImpl.java:133)
  at net.java.sip.communicator.impl.neomedia.notify.PortAudioClipImpl.access$000(PortAudioClipImpl.java:25)
  at net.java.sip.communicator.impl.neomedia.notify.PortAudioClipImpl$1.run(PortAudioClipImpl.java:71)

The machine has Debian 32-bit, ALSA only, Nvidia MCP77/78 HDMI (VIA VT 1708S) sound card. This might be a portaudio-alsa related issue too. Other apps have no such delay.

···

--
O zi buna,

Kertesz Laszlo


#4

Hi Everybody,

in code i have got a strange behavior
i have done a Felix launcher it install
correctly all the bundles i tell it.
but the start fails i don't know why

i suppose that the start method of the class bundle fails
but i can't see the log of bundleImpl in eclipse...

···

------------------------------------------------------------------------------------------------------------

// Now loop through the auto-start bundles and start them.
        for (Iterator i = configMap.keySet().iterator(); i.hasNext(); )
        {
            String key = ((String) i.next()).toLowerCase();
            if (key.startsWith(AUTO_START_PROP))
            {
                StringTokenizer st = new StringTokenizer((String) configMap.get(key), "\" ", true);
                for (String location = nextLocation(st); location != null; location = nextLocation(st))
                {
                    // Installing twice just returns the same bundle.
                    try
                    {
                        Bundle b = context.installBundle(location, null);
                        if (b != null)
                        {
                            b.start();
                        }
                    }
                    catch (Exception ex)
                    {
                        System.err.println("Auto-properties start: " + location + " ("
                            + ex + ((ex.getCause() != null) ? " - " + ex.getCause() : "") + ")");
                    }
                }
            }
        }


#5

Hello,

I found a workaround for this issue:
I put "aplay" in the Events section, Incoming call and Dialing options execute program line.
And i put "killall aplay" in the Events, Hang up sections execute program line.

Seems to work ok. But the issue remains still without these workarounds.

···

On Fri, 10 Jun 2011 09:47:49 +0300, Kertesz Laszlo <laszlo.kertesz@gmail.com> wrote:

Hello,

I have this issue when i call with Jitsi on one of my computers: i cannot hear anything the first few seconds of a call. The sound indicator does move in this time, but nothing is played.
After this, the call works with no issues. The first second i hear is a bit garbled.
There is an error that pops up from time to time (but not every time):

09:32:58.591 SEVERE: util.UtilActivator.uncaughtException().88 An uncaught exception occurred in thread=Thread[Thread-229,6,main] and message was: null
java.lang.NullPointerException
  at net.java.sip.communicator.impl.neomedia.notify.PortAudioClipImpl.runOnceInPlayThread(PortAudioClipImpl.java:196)
  at net.java.sip.communicator.impl.neomedia.notify.PortAudioClipImpl.runInPlayThread(PortAudioClipImpl.java:133)
  at net.java.sip.communicator.impl.neomedia.notify.PortAudioClipImpl.access$000(PortAudioClipImpl.java:25)
  at net.java.sip.communicator.impl.neomedia.notify.PortAudioClipImpl$1.run(PortAudioClipImpl.java:71)

The machine has Debian 32-bit, ALSA only, Nvidia MCP77/78 HDMI (VIA VT 1708S) sound card. This might be a portaudio-alsa related issue too. Other apps have no such delay.

--
O zi buna,

Kertesz Laszlo

Using Opera's revolutionary email client: http://www.opera.com/mail/


#6

Not enough information here...did you set the framework log level to 4 (i.e.DEBUG) in its config properties?

-> richard

···

On 6/10/11 5:14, Gaetan Abessolo wrote:

Hi Everybody,

in code i have got a strange behavior
i have done a Felix launcher it install
correctly all the bundles i tell it.
but the start fails i don't know why

i suppose that the start method of the class bundle fails
but i can't see the log of bundleImpl in eclipse...
------------------------------------------------------------------------------------------------------------

// Now loop through the auto-start bundles and start them.
for (Iterator i = configMap.keySet().iterator(); i.hasNext(); )
        {
            String key = ((String) i.next()).toLowerCase();
if (key.startsWith(AUTO_START_PROP))
            {
                StringTokenizer st = new StringTokenizer((String) configMap.get(key), "\" ", true);
for (String location = nextLocation(st); location != null; location = nextLocation(st))
                {
// Installing twice just returns the same bundle.
try
                    {
                        Bundle b = context.installBundle(location, null);
if (b != null)
                        {
                            b.start();
                        }
                    }
catch (Exception ex)
                    {
                        System.err.println("Auto-properties start: " + location + " ("
                            + ex + ((ex.getCause() != null) ? " - " + ex.getCause() : "") + ")");
                    }
                }
            }
        }