Excellent: I'll see if I can confirm the fixes for you some time next week.
The security indicator being absent makes sense: it's only "off" that's potentially concerning anyway.
Thanks again,
Toby Pinder | Software Developer
Smith Electric Vehicles
Thanks Toby!
I committed a small fix that should fix the UI glitch you were seeing for
the conference initiator (A).
As for the security status of the participants: they intentionally don't see
a security indication for the other participants because they cannot know if
they are encrypted or not.
A
/ | \
B C D
1) A sees all connection as secure
2) B, C, D see the connection to A as secure
3) B doesn't know if the connection of C and D to A is secure, hence there's
no indication
4) C (same but for B and D)
5) D (same but for B and C)
We used to propagate the status in cases 3-5 from case 2 down in earlier
versions, but this is wrong. While we hear all of the participants through
the encrypted channel to A, one of the participants could be connected to A
unencrypted. A could distribute its knowledge about the encryption status,
but this would again not be secure (B,C,D cannot prove whether A is telling
the truth).
So, once the build with the commit 60e4be3 is through, you should be good to
go.
Ingo
From: dev-bounces@jitsi.org<mailto:dev-bounces@jitsi.org> [mailto:dev-bounces@jitsi.org] On Behalf Of
Toby
Pinder
Sent: Donnerstag, 7. November 2013 17:53
To: dev@jitsi.org<mailto:dev@jitsi.org>
Subject: Re: [jitsi-dev] The state of XMPP Conferencing (and in-call UI
restriction)
Ingo,
Thanks a lot for this! Sorry for the delays in getting back to you (I had
to
find willing test subjects) but we've tried this today and it was
successful.
The version of Jitsi we used is equivalent to
https://github.com/jitsi/jitsi/commit/be3bcff1ec1d0df18fae184761e25d3454e40e
9
f.
It's referred to in the logs as "Smith Chat" but the changes are minor and
focused on cosmetics and changes like emoticons and default configuration.
In our test Person A called Person B and then we added Person C to upgrade
to
a conference. This worked without problems, and we added Person D to make
it
a four person call just to make sure without any issues too. However, the
padlock indicator for secure communication was inconsistent between users,
and appears to show that Person B is not secure.
I have attached the log file from the host (user A). Unfortunately I
failed
to get the correct logs from the other users on this one (I think they all
restarted Jitsi, rendering the "log.0" file useless to us and by the time
I
noticed it was too late).
I have also attached two screenshots. A.png shows the state of the
security
padlocks as observed by user A, and B.png shows the state of the security
padlocks as observed by users B, C and D. I believe this issue is cosmetic
rather than insecurity, but please let me know if there is anything you'd
like me to test with Wireshark etc. to confirm this. It makes sense that
the
UI might not have properly responded to the call "upgrade" scenario but
I'd
be happy to verify this given instructions.
Thanks once again,
Toby Pinder | Software Developer
Smith Electric Vehicles
Toby
Thanks for your logs. I just committed a hack that should at least fix the
bug you observed. I currently have no possibility to test SDES with XMPP,
but a conference with SIP and three SDES encrypted participants now worked
fine. Can you give it another try?
Ingo
> From: dev-bounces@jitsi.org<mailto:dev-bounces@jitsi.org> [mailto:dev-bounces@jitsi.org] On Behalf Of
Toby
> Pinder
> Sent: Dienstag, 5. November 2013 11:25
> To: dev@jitsi.org<mailto:dev@jitsi.org>
> Subject: Re: [jitsi-dev] The state of XMPP Conferencing (and in-call UI
> restriction)
> Oh and I apologise for the message density on this issue but I should
point
> out that my XMPP/SDES issue is wholly unrelated to Video Bridging, which
we
> haven't had the opportunity to even test yet.
>
>
>
> Hey David,
>
> There is no such requirement for regular conference calls (the one
> that Jitsi mixes and/or relays). It's not impossible that a bug
would
> prevent one scenario from happening while the other completes
> successfully but generally both work.
>
> Video bridge conferences do indeed need to be created as such. At
> least currently. We may want to make that automatic in the future.
>
> Cheers,
> Emil
>
> On Tue, Nov 5, 2013 at 1:07 AM, David Bolton
<davidkbolton@gmail.com><mailto:davidkbolton@gmail.com>
> <mailto:davidkbolton@gmail.com> wrote: > Tony, > >
To
switch from a
> two-person call to a conference call, I think you > actually have to
> start with a conference call to begin with. (In other > words
end
the
> two-person call and then go to "Tools > Create a > Conference
Call..."
> (or "Tools > Create a Video Bridge..."). > > I'm not able to
verify if
> this is correct right now, so let me know if > I'm wrong. > >
David
>> Hi Ingo (and
> devs), >> >> Sorry for the delay. We scheduled a test call
in
which
> myself (person A) called Ross (person B) and then I (person A) attempted
> to add David (person C). C was not able to join the call. Log files are
> attached. >> >> By the way, those logs show some unrelated
issues
to
> do with (person B), who is running Jitsi for Windows through Confluence
> on a Mac. We believe he had some DNS related issues but they are
> unrelated and we have tested this experiment with other users: we
> consistently reproduce the same problem. >> >> Potential
stacktrace of
> interest (in A.toby.log.0 line 441): >> >> 15:51:46.021 SEVERE:
[25]
> util.UtilActivator.uncaughtException().108 An uncaught exception
> occurred in thread=Thread[AWT-EventQueue-0,6,main] and message was: null
> java.lang.NullPointerException >> at
>
net.java.sip.communicator.impl.gui.main.call.conference.BasicConferencePa
> rtic ipantPanel.securityOn(BasicConferenceParticipantPanel.java:487) >>
> at
>
net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPan
> el.s ecurityOn(ConferencePeerPanel.java:523) >> at
>
net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPan
> el.i nitSecuritySettings(ConferencePeerPanel.java:315) >>
at
>
net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPan
> el.< init>(ConferencePeerPanel.java:243) >> at
>
net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPan
> el.< init>(ConferencePeerPanel.java:188) >> at
>
net.java.sip.communicator.impl.gui.main.call.conference.AudioConferenceCa
> llPa nel.updateViewFromModel(AudioConferenceCallPanel.java:187) >>
> at
>
net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCa
> llPa nel.updateViewFromModel(BasicConferenceCallPanel.java:521) >>
> at
>
net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCa
> llPa
>
nel.updateViewFromModelInEventDispatchThread(BasicConferenceCallPanel.jav
> a:64 0) >> at
>
net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCa
> llPa nel.updateViewFromModel(BasicConferenceCallPanel.java:497) >>
> at
>
net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCa
> llPa nel.initializeComplete(BasicConferenceCallPanel.java:383) >>
> at
>
net.java.sip.communicator.impl.gui.main.call.conference.AudioConferenceCa
> llPa nel.<init>(AudioConferenceCallPanel.java:132) >> at
>
net.java.sip.communicator.impl.gui.main.call.CallPanel.doUpdateViewFromMo
> delI nEventDispatchThread(CallPanel.java:1002) >> at
>
net.java.sip.communicator.impl.gui.main.call.CallPanel.updateViewFromMode
> lInE ventDispatchThread(CallPanel.java:2135) >> at
>
net.java.sip.communicator.impl.gui.main.call.CallPanel.access$300(CallPan
> el.j ava:65) >> at
>
net.java.sip.communicator.impl.gui.main.call.CallPanel$2.run(CallPanel.ja
> va:3 35) >> at
java.awt.event.InvocationEvent.dispatch(Unknown
> Source) >> at java.awt.EventQueue.dispatchEventImpl(Unknown
> Source) >> at java.awt.EventQueue.access$200(Unknown Source)
>>
> at java.awt.EventQueue$3.run(Unknown Source) >> at
> java.awt.EventQueue$3.run(Unknown Source) >> at
> java.security.AccessController.doPrivileged(Native Method) >>
at
> java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
> >> at java.awt.EventQueue.dispatchEvent(Unknown Source) >>
> at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
> >> at
java.awt.EventDispatchThread.pumpEventsForFilter(Unknown
> Source) >> at
> java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) >>
> at java.awt.EventDispatchThread.pumpEvents(Unknown Source) >>
> at java.awt.EventDispatchThread.pumpEvents(Unknown Source) >>
at
> java.awt.EventDispatchThread.run(Unknown Source) >> >> It
certainly
> seems to my uninitiated self that this is an issue during the
> negotiation interacting with the crypto, but I don't want to jump to
> conclusions. >> >> Thanks for your help, >> >> Toby
Pinder |
> Software Developer >> Smith Electric Vehicles >>
> -------------------------------------------------------------------
> --------------------- >> >> From: dev-bounces@jitsi.org<mailto:dev-bounces@jitsi.org>
> [mailto:dev-bounces@jitsi.org] On Behalf Of Toby Pinder >> Sent:
01
> November 2013 14:22 >> To: dev@jitsi.org<mailto:dev@jitsi.org> >> Subject: Re:
[jitsi-dev]
> The state of XMPP Conferencing (and in- call UI restriction) >> >>
My
> apologies, I'll have to get back to you on this on Monday Morning - I've
> been swamped with other stuff and my logs are only accessible from work.
> I may get some opportunity this weekend to do some tinkering with SIP
> for comparative purposes to see if that's working, but as I'd be
> operating "alone" without US collaborators and on a completely different
> stack I'm not sure how representative a test that would be. >> >>
Many
> thanks, >> Toby Pinder | Software Developer >> Smith Electric
Vehicles
> >> >> On 31/10/13 21:06, Ingo Bauersachs wrote: >>> I have
been
> experiencing issues with XMPP chat and SDES: as soon as a 3+ >>> person
> audio call is initiated from scratch it fails, and upgrading a 2
> person call to a 3 person one simply fails for that third person.
> >>> We have had success with this prior when testing without SDES
> encryption, >> and >>> the particular stacktrace in the attached log
> files makes me think it's an >>> issue with this encryption method. >>
> Could you please add/send those logs? >> >>> Is it possible
for SDES
> support to work with three person calls? >> Well, at least it
should.
> The key for each media stream is exchanged between >> the conference
> master and the corresponding participant. The participants >> don't
> know each other's keys. >> AFAIK it still works for SIP, so there
might
> be an issue in passing the keys >> from the XMPP layer down to the
> media layer. >> >>> And if not, >>> is there a
provisioning
setting I
> can use to disable this functionality? I >>> would like to disable
> various components of the In call UI actually - my >>> business has
no
> current need for "Hold" nor "Videochat" (especially as we >> are
> not using Jitsi Videobridge). Would it be possible to disable the UI >>
> buttons >>> for these without disabling eg Screen Sharing / Remote
> Desktop? I'm >> generally >>> interested in locking down Jitsi to a
> basic featureset before I roll in >> stuff >>> that I think
is
> "mature" enough and necessary, especially as there is some >>> user
> education that has to go on. >>> >>> Many thanks as always.
---
> >>> Toby Pinder >> Ingo >> >> >>
> _______________________________________________ >> dev mailing
list
>>
> dev@jitsi.org<mailto:dev@jitsi.org> >> Unsubscribe instructions and other list
options:
>>
> http://lists.jitsi.org/mailman/listinfo/dev >> >> >>
> _______________________________________________ >> dev mailing
list
>>
> dev@jitsi.org<mailto:dev@jitsi.org> >> Unsubscribe instructions and other list
options:
>>
> http://lists.jitsi.org/mailman/listinfo/dev > > >
> _______________________________________________ > dev mailing list
>
> dev@jitsi.org<mailto:dev@jitsi.org> > Unsubscribe instructions and other list options:
>
> http://lists.jitsi.org/mailman/listinfo/dev
>
>
>
> --
> Emil Ivov, Ph.D. 67000 Strasbourg,
> Project Lead France
> Jitsi
> emcho@jitsi.org<mailto:emcho@jitsi.org> PHONE: +33.1.77.62.43.30
> https://jitsi.org FAX: +33.1.77.62.47.31
>
> _______________________________________________ dev
mailing
list
> dev@jitsi.org<mailto:dev@jitsi.org> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev
>
>
>
>
_______________________________________________
dev mailing list
dev@jitsi.org<mailto:dev@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev
--
Toby Pinder | Telemetry Software Engineer
Switchboard +44 (0)845 077 9077
E. toby.pinder@smithelectric.com<mailto:toby.pinder@smithelectric.com>
W. www.smithelectric.com<http://www.smithelectric.com>
This email and any attachments thereto may contain private, confidential,
and
privileged material for the sole use of the intended recipient. Any
review,
copying, or distribution of this email (or any attachments thereto) by
others
is strictly prohibited. If you are not the intended recipient, please
contact
the sender immediately and permanently delete the original and any copies
of
···
On 07/11/13 22:45, Ingo Bauersachs wrote:
-----Original Message-----
On 05/11/13 22:57, Ingo Bauersachs wrote:
> -----Original Message-----
> On 05/11/13 00:40, Emil Ivov wrote:
> > > > > On 11/4/2013 11:18 AM, Toby Pinder wrote:
this email and any attachments thereto.
_______________________________________________
dev mailing list
dev@jitsi.org<mailto:dev@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev
--
Toby Pinder | Telemetry Software Engineer
Switchboard +44 (0)845 077 9077
E. toby.pinder@smithelectric.com<mailto:ross.cooney@smithelectric.com>
W. www.smithelectric.com<http://www.smithelectric.com/>
[cid:part15.01000206.06080400@smithelectric.com]
This email and any attachments thereto may contain private, confidential, and privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.
