| Cryptocraphic components in org.eclipse.runtime, and export restrictions [message #297285] |
Wed, 11 January 2006 05:07  |
Eclipse User |
|
|
|
Originally posted by: news.karsten-becker.de
Hi,
To be honest I just want to focus your attention on the following bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=121997
PROBLEM:
We want to deliver Eclipse/RCP Applications via the Internet.
Unfortunately one of my colleagues noticed the Export Control Statement
in the org.eclipse.runtime plugin's about.html. This made us quite
nervous and we talked to our ECC-Department which did not allow us to
distribute our applications via Internet.
Albeit we know that the mentioned SHA-1 Encryption algorithm is NOT
implemented in the Eclipse plugin itself, it makes delivering
applications via Internet still a risk.
And the only reason this crypto part exists is the usage in some CVS
code, which is not vital for RCP applications..
SOLUTION:
My proposed solution for back-ward compatibility would be to create a
fragment that contains this crypto stuff, so that you can deliver this
fragment independent from the more vital org.eclipse.runtime plugin.
For future releases I would propose a new plugin that deals with crypto
related functions.
This way you could easily deliver a application via Internet without
making yourself a head about this Export Control Statement.
Karsten
|
|
|
| Re: Cryptocraphic components in org.eclipse.runtime, and export restriction [message #297312 is a reply to message #297285] |
Wed, 11 January 2006 12:09  |
| Eclipse User |
|
|
|
Originally posted by: automatic.javalobby.org
> Albeit we know that the mentioned SHA-1 Encryption
> algorithm is NOT implemented in the Eclipse plugin
> itself, it makes delivering applications via Internet
> still a risk.
Just to be clear; you're talking about a legal risk, rather than a code/security risk, right?
> And the only reason this crypto part exists is the usage
> in some CVS code, which is not vital for RCP
> applications..
Actually, it's there to support AuthorisationHandler, and to make sure that passwords saved aren't easily readable by default. It's even part of the API; <a href=" http://help.eclipse.org/help31/topic/org.eclipse.platform.do c.isv/reference/api/org/eclipse/core/runtime/Platform.html#a ddAuthorizationInfo (java.net.URL,%20java.lang.String,%20java.lang.String,%20jav a.util.Map) ">org.eclipse.core.runtime.Platform.addAuthorizationInfo()</a >
It certainly could be useful in applications; for example, a mail application could use this to store a username/password for a remote mail server. And having it built-in to the platform makes it much easier to have a standard place rather than everyone adding their own.
That said, there's no reason why this API method couldn't still exist but throw an Exception if the appropriate fragment wasn't supplied.
Alex.
|
|
|
| Re: Cryptocraphic components in org.eclipse.runtime, and export restriction [message #297347 is a reply to message #297312] |
Thu, 12 January 2006 04:55 |
| Eclipse User |
|
|
|
Originally posted by: news.karsten-becker.de
Alex Blewitt wrote:
>> Albeit we know that the mentioned SHA-1 Encryption
>> algorithm is NOT implemented in the Eclipse plugin
>> itself, it makes delivering applications via Internet
>> still a risk.
>
> Just to be clear; you're talking about a legal risk, rather than a code/security risk, right?
That's correct.
>> And the only reason this crypto part exists is the usage
>> in some CVS code, which is not vital for RCP
>> applications..
>
> Actually, it's there to support AuthorisationHandler, and to make sure that passwords saved aren't easily readable by default. It's even part of the API; <a href=" http://help.eclipse.org/help31/topic/org.eclipse.platform.do c.isv/reference/api/org/eclipse/core/runtime/Platform.html#a ddAuthorizationInfo (java.net.URL,%20java.lang.String,%20java.lang.String,%20jav a.util.Map) ">org.eclipse.core.runtime.Platform.addAuthorizationInfo()</a >
Ahh, ok, I did not notice that it is a General Purpose API, because CVS
is explicitly mentioned in the about.html
> It certainly could be useful in applications; for example, a mail application could use this to store a username/password for a remote mail server. And having it built-in to the platform makes it much easier to have a standard place rather than everyone adding their own.
This definitely sounds like a real use-case for me. So I would support
creating a more sounding plugin for it. Maybe with chooseable encryption
algorithm. So that you can choose the storage strategy.
Karsten
|
|
|
|
|
|
| Re: Cryptocraphic components in org.eclipse.runtime, and export [message #297384 is a reply to message #297373] |
Thu, 12 January 2006 11:11 |
| Eclipse User |
|
|
|
Originally posted by: news.karsten-becker.de
Alex Blewitt wrote:
> Yeah, you need to be able to call C functions, which is going to require a bit of C DLL coding and/or native methods. But hey, they do it all the time for SWT/OSX :-)
>
> The API for Mac keychain access is described at:
>
> http://developer.apple.com/documentation/Security/Reference/ keychainservices/index.html
>
> You'll have to use the Carbon APIs (C) rather than Cocoa APIs (Objective-C) since Eclipse.app is a Carbon API. Touch base with me at my Gmail address (alex.blewitt) if you want help moving forwards with this; I've got a Mac and a semi-recent version of Xcode at home too ...
Aehm, I for my self meant the platform independent part of it, as I
(unfortunately) have no Mac :)
Karsten
|
|
|
Powered by
FUDForum. Page generated in 0.03430 seconds
Home