I do not need anything except a SIP client (a ZRTP-capable one), so whooping 60 MegaBytes in the installation folder (even after I've removed the outdated JRE version which was forcibly installed with v2.2.4603.9615) is way too much.
Are there any plans to provide an installer to select only those parts of Jitsi that a user actually needs?
Regards.
--
winXP-SP3, JREv7u40
Hey ZAO,
I do not need anything except a SIP client (a ZRTP-capable one), so
whooping 60 MegaBytes in the installation folder (even after I've
removed the outdated JRE version which was forcibly installed with
v2.2.4603.9615) is way too much.
Jitsi does not install a JRE. It just unzips one in its installation
folder. No other applications are affected.
OTOH, removing it could cause unexpected behaviour and hence be a problem.
Are there any plans to provide an installer to select only those parts of
Jitsi that a user actually needs?
No. Having in mind that it is relatively difficult today to obtain an HDD
with a capacity below 200GB, and that the new average is closer to 1TB, we
don't see the ~100MB size as a problem.
Emil
On 30 Sep 2013 12:11, "ZAO" <zao@profitt.ru> wrote:
Hey ZAO,
I do not need anything except a SIP client (a ZRTP-capable one), so whooping 60 MegaBytes in the installation folder (even after I've removed the outdated JRE version which was forcibly installed with v2.2.4603.9615) is way too much.
Jitsi does not install a JRE.
Yes, Jitsi's installer simply brought in the OUTDATED and INSECURE version of JRE. This is plainly wrong. Why does it do so in the first place?
It just unzips one in its installation folder. No other applications are affected.
If Jitsi depends on JRE - just check for its' presence and warn a user if (the minimum required version of) JRE was not found.
OTOH, removing it could cause unexpected behavior and hence be a problem.
As far as I can see - Jitsi v2.2.4603.9615 works under the JRE v7u40 quite well (at least, SIP-wise).
Do you test Jitsi for compatibility with the current JRE?
If not, why?
Are there any plans to provide an installer to select only those parts of Jitsi that a user actually needs?
No. Having in mind that it is relatively difficult today to obtain an HDD with a capacity below 200GB, and that the new average is closer to 1TB, we don't see the ~100MB size as a problem.
One could also keep in mind that some of us use Eee PC 900 with just 4GB of disk space (with ~2.5GB occupied by OS/software). So ~150MB (a good ~100MB of which is NOT needed!) simply does not fit in.
Regards.
On Mon, 30 Sep 2013 14:20:53 +0400, Emil Ivov <emcho@jitsi.org> wrote:
On 30 Sep 2013 12:11, "ZAO" <zao@profitt.ru> wrote:
Hey ZAO,
Hey ZAO,
I do not need anything except a SIP client (a ZRTP-capable one), so
whooping 60 MegaBytes in the installation folder (even after I've removed
the outdated JRE version which was forcibly installed with v2.2.4603.9615)
is way too much.Jitsi does not install a JRE.
Yes, Jitsi's installer simply brought in the OUTDATED and INSECURE version
of JRE. This is plainly wrong.
Could you please point us to the security vulnerabilities that you
believe might be affecting you?
Why does it do so in the first place?
Above all, we do this because requiring the user to install their own
JRE is a killer for a large percentage of users.
Also, different JREs have different features and it is possible that
things in Jitsi break across versions.
It just unzips one in its installation folder. No other applications are
affected.If Jitsi depends on JRE - just check for its' presence and warn a user if
(the minimum required version of) JRE was not found.
Things don't only break when going back in versions. APIs get
obsoleted or their behaviour changes so upgrading to a newer version
can also introduce regressions.
OTOH, removing it could cause unexpected behavior and hence be a problem.
As far as I can see - Jitsi v2.2.4603.9615 works under the JRE v7u40 quite
well (at least, SIP-wise).
I believe we recently removed most of the problems with 1.7 and were
planning on upgrading soon. We just haven't got around to it.
Do you test Jitsi for compatibility with the current JRE?
On occasion yes. Specifically once we start considering an upgrade.
If not, why?
We only have so much time on our hands and a todo list that would
require orders of magnitude more.
Are there any plans to provide an installer to select only those parts of
Jitsi that a user actually needs?No. Having in mind that it is relatively difficult today to obtain an HDD
with a capacity below 200GB, and that the new average is closer to 1TB, we
don't see the ~100MB size as a problem.One could also keep in mind that some of us use Eee PC 900 with just 4GB of
disk space (with ~2.5GB occupied by OS/software). So ~150MB (a good ~100MB
of which is NOT needed!) simply does not fit in.
Yes of course, however there is this time issue I mentioned just
above, which makes us care mostly about the bulk of our (potential)
users and less about the corner cases. Contributions are welcome. If
enough EeePC users are just as nice as yourself and willing to work on
a segmented installer, we'd be happy to have a look at it.
Cheers,
Emil
On Mon, Sep 30, 2013 at 12:40 PM, ZAO <zao@profitt.ru> wrote:
On Mon, 30 Sep 2013 14:20:53 +0400, Emil Ivov <emcho@jitsi.org> wrote:
On 30 Sep 2013 12:11, "ZAO" <zao@profitt.ru> wrote:
Regards.
_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users
--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31
Could you please point us to the security vulnerabilities that you believe might be affecting you?
Do you mean the JRE changelog?
Every time Oracle releases an update, it urges to install it - removing all previous versions.
It is insecure to have the known-vulnerable/exploitable code installed along with the updated one. A malware will simply use the old JRE do to its' sinister things.
Why does it do so in the first place?
Above all, we do this because requiring the user to install their own JRE is a killer for a large percentage of users.
Look at MS then - if a program that need a .NET installed does not find it, it simply downloads what was missing.
A large percentage of users will welcome a smaller Jitsi installer file, provided they have the current JRE. Most of them do because of the JAVA auto-update feature.
Also, different JREs have different features and it is possible that things in Jitsi break across versions.
...snip...
Things don't only break when going back in versions. APIs get obsoleted or their behavior changes so upgrading to a newer version can also introduce regressions.
Yes, that's what testing is for.
I expected you to not ship the untested code.
I believe we recently removed most of the problems with 1.7 and were planning on upgrading soon. We just haven't got around to it.
Could you please just compile Jitsi against the latest JRE, but not bundle JRE into an installer?
Or, at least, have a JRE-free one (like OpenOffice does)?
Do you test Jitsi for compatibility with the current JRE?
On occasion yes. Specifically once we start considering an upgrade.
Well, Jitsi is free and users are not expected to demand anything from the development team. But the security issues a another story - when an exploit is found in the underlaying library - everyone is affected. The program should be rebuilt against the latest version.
Nobody wants his computer to become a part of a botnet.
so much time on our hands and a todo list that would require orders of magnitude more.
One could also keep in mind that some of us use Eee PC 900 with just 4GB of disk space (with ~2.5GB occupied by OS/software). So ~150MB (a good ~100MB of which is NOT needed!) simply does not fit in.
Yes of course, however there is this time issue I mentioned just above, which makes us care mostly about the bulk of our (potential) users and less about the corner cases. Contributions are welcome. If enough EeePC users are just as nice as yourself and willing to work on a segmented installer, we'd be happy to have a look at it.
Alas, I'm not a software designer. My contribution is VERY limited. I'm just a SIP-client user, and I can only comment on system security.
Regards.
On Mon, 30 Sep 2013 14:59:19 +0400, Emil Ivov <emcho@jitsi.org> wrote:
Hey ZAO,
Could you please point us to the security vulnerabilities that you believe
might be affecting you?Do you mean the JRE changelog?
No, I actually meant the specific vulnerability that you believe might
be exposing you.
Every time Oracle releases an update, it urges to install it - removing all
previous versions.
It is insecure to have the known-vulnerable/exploitable code installed along
with the updated one. A malware will simply use the old JRE do to its'
sinister things.
No, this is precisely want CANNOT happen because we don't install the
JRE. We just unbundle it in Jitsi's directory. There's no way a
malware could use it to gain access to your station.
Why does it do so in the first place?
Above all, we do this because requiring the user to install their own JRE
is a killer for a large percentage of users.Look at MS then - if a program that need a .NET installed does not find it,
it simply downloads what was missing.
A large percentage of users will welcome a smaller Jitsi installer file,
provided they have the current JRE.
Our experience is actually quite the opposite and shows that users
prefer not to be bothered with this. We used to have an on-line
installer for Java on windows and that seemed to be a pain for many.
Most of them do because of the JAVA
auto-update feature.
As explained, the auto-update feature is precisely what we'd like to
avoid because it could introduce regressions.
Also, different JREs have different features and it is possible that
things in Jitsi break across versions.
...snip...
Things don't only break when going back in versions. APIs get obsoleted or
their behavior changes so upgrading to a newer version can also introduce
regressions.Yes, that's what testing is for.
I expected you to not ship the untested code.
Yes and this is why we ship with specific Java versions.
I believe we recently removed most of the problems with 1.7 and were
planning on upgrading soon. We just haven't got around to it.Could you please just compile Jitsi against the latest JRE, but not bundle
JRE into an installer?
Or, at least, have a JRE-free one (like OpenOffice does)?
Not currently on our todo list and I don't think we'll do this in the
recent future as it is only likely to create problems rather than
resolve any.
Do you test Jitsi for compatibility with the current JRE?
On occasion yes. Specifically once we start considering an upgrade.
Well, Jitsi is free and users are not expected to demand anything from the
development team. But the security issues a another story - when an exploit
is found in the underlaying library - everyone is affected. The program
should be rebuilt against the latest version.
Nobody wants his computer to become a part of a botnet.
True and this would have been relevant if there was actually a
security issue here.
so much time on our hands and a todo list that would require orders of
magnitude more.One could also keep in mind that some of us use Eee PC 900 with just 4GB
of disk space (with ~2.5GB occupied by OS/software). So ~150MB (a good
~100MB of which is NOT needed!) simply does not fit in.Yes of course, however there is this time issue I mentioned just above,
which makes us care mostly about the bulk of our (potential) users and less
about the corner cases. Contributions are welcome. If enough EeePC users are
just as nice as yourself and willing to work on a segmented installer, we'd
be happy to have a look at it.Alas, I'm not a software designer. My contribution is VERY limited. I'm just
a SIP-client user, and I can only comment on system security.
Ah OK. Not a problem, it's just that you were quite generous in your
advice so I assumed a background and a certain experience in software
development.
Cheers,
Emil
On Mon, Sep 30, 2013 at 1:41 PM, ZAO <zao@profitt.ru> wrote:
On Mon, 30 Sep 2013 14:59:19 +0400, Emil Ivov <emcho@jitsi.org> wrote:
Regards.
_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users
--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31
No, this is precisely what CANNOT happen because we don't install the JRE. We just unbundle it in Jitsi's directory. There's no way a malware could use it to gain access to your station.
Since it is there (the old JRE, I mean), since Jitsi can use it - any other local code can use it.
Hence - vulnerability.
Yes and this is why we ship with specific Java versions.
You ship THE known-to-be-exploitable version right now. 3 (three) patches behind the current version.
Ah OK. Not a problem, it's just that you were quite generous in your advice so I assumed a background and a certain experience in software development.
Not a development but the security audit and management.
Regards.
On Mon, 30 Sep 2013 18:30:30 +0400, Emil Ivov <emcho@jitsi.org> wrote:
You don't understand how the JRE works. When the JRE is INSTALLED, the
browser plug-in is installed into the browsers' plugins folder. If
it's not installed, the browser plugin files are not copied over, so
IT IS ESSENTIALLY INVISIBLE TO ALL BROWSERS.
There is ABSOLUTELY NO WAY that any browser can trigger an old JRE
just because a JRE is unpacked in an arbitrary location on the hard
drive. Simply because the browser plugin for that JRE is NOT in the
browser!.
If I download and install Java 7 u40, my browsers will use that, the
secure version. I can then go and download and unpack Java 6, Java 5,
even Java 1.4 in my own private app, those versions will NOT be used
by any browsers, simply because there's no way for the browsers to
know there's an old JRE somewhere and the files to link the browser to
the JRE are NOT installed!.
I hope you get the point now.
FC
On Mon, Sep 30, 2013 at 11:11 AM, ZAO <zao@profitt.ru> wrote:
Since it is there (the old JRE, I mean), since Jitsi can use it - any other
local code can use it.
Hence - vulnerability.
--
During times of Universal Deceit, telling the truth becomes a revolutionary act
Durante épocas de Engaño Universal, decir la verdad se convierte en un
Acto Revolucionario
- George Orwell
No, this is precisely what CANNOT happen because we don't install the
JRE. We just unbundle it in Jitsi's directory. There's no way a malware
could use it to gain access to your station.
Since it is there (the old JRE, I mean), since Jitsi can use it - any
other local code can use it.
Hence - vulnerability.
Well, no. It doesn't work that way. Jitsi executes Java locally because it
has the right to. If a malware application has the right to do this then it
really doesn't need java to do mischief and the version of the JRE is quite
irrelevant.
Yes and this is why we ship with specific Java versions.
You ship THE known-to-be-exploitable version right now. 3 (three) patches
behind the current version.
Again, Jitsi uses Java in a way that makes it unusable in common
internet-based attacks. I have repeatedly asked you to point us to problems
that you believe could also apply in our case. You haven't done this which
makes me thing you are more interested in expressing frustration about the
fact that Jitsi's size doesn't fit your personal requirements, which makes
this conversation pointless.
You should simply look for a smaller size application with the same
features.
Good luck,
Emil
--sent from my mobile
On 30 Sep 2013 17:13, "ZAO" <zao@profitt.ru> wrote:
On Mon, 30 Sep 2013 18:30:30 +0400, Emil Ivov <emcho@jitsi.org> wrote:
You ship THE known-to-be-exploitable version right now. 3 (three) patches behind the current version.
Again, Jitsi uses Java in a way that makes it unusable in common internet-based attacks.
The full and unabridged copy of JRE v7u20 is there to use for everybody.
And since Jitsi itself is Java - you simply cannot claim it is defect-free - in the first place because it is based on the very same vulnerable/exploitable version of JRE/JDK.
So a dedicated attack on Jitsi itself, or through a browser on the JRE will definitely succeed.
I have repeatedly asked you to point us to problems that you believe could also apply in our case. You haven't done this which makes me thing you are more interested in expressing frustration about the fact that Jitsi's size doesn't fit your personal requirements, which makes this conversation pointless.
See above. I'm not attacking neither you nor Jitsi. I'm trying to convince you that the presence of the well-known-to-be-exploitable code is bad and should be avoided.
You should simply look for a smaller size application with the same features.
I do, but not with the same features - I do not need no FB/Google/MSN/etc connectivity - I need just a clean and simple SIP client with ZRTP, which will run on almost any hardware a backpacker may have at hand in remote corner of Burma.
Regards.
You ship THE known-to-be-exploitable version right now. 3 (three) patches
behind the current version.Again, Jitsi uses Java in a way that makes it unusable in common
internet-based attacks.The full and unabridged copy of JRE v7u20 is there to use for everybody.
And since Jitsi itself is Java - you simply cannot claim it is defect-free -
in the first place because it is based on the very same
vulnerable/exploitable version of JRE/JDK.
So a dedicated attack on Jitsi itself, or through a browser on the JRE will
definitely succeed.
This is wrong and I have already explained why. Jitsi does not deploy
Java in a way that would make it usable to browsers in any way. The
only entities that can launch Jitsi's Java instance are those that
have enough permissions to do mischief without it.
I believe this is going beyond confusion and into deliberate
misinformation. Please stop.
I have repeatedly asked you to point us to problems that you believe could
also apply in our case. You haven't done this which makes me thing you are
more interested in expressing frustration about the fact that Jitsi's size
doesn't fit your personal requirements, which makes this conversation
pointless.See above. I'm not attacking neither you nor Jitsi. I'm trying to convince
you that the presence of the well-known-to-be-exploitable code is bad and
should be avoided.
The only thing of which you are convincing me is that you are either
not reading my e-mails or you don't really understand that problems
that you are trying to describe. This is the fourth time that I am
asking: please point us to a specific vulnerability report that you
believe could be exploited in Jitsi's JRE. Nothing originating from a
browser applies here. Is there anything else you have in mind?
You should simply look for a smaller size application with the same
features.I do, but not with the same features - I do not need no FB/Google/MSN/etc
connectivity - I need just a clean and simple SIP client with ZRTP, which
will run on almost any hardware a backpacker may have at hand in remote
corner of Burma.
You have stated your requirements and they have been answered.
Emil
On Mon, Sep 30, 2013 at 7:05 PM, ZAO <zao@profitt.ru> wrote:
Regards.
_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users
--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31
