I hate top-posting like this, but thanks to people doing "reply to all" instead
of just replying to the followup-to the conversation has ended up in two
separate newsgroups...
In any case, from my point of view separating the RNG and hash parts of NSS from
the crypto parts would be _very_ desirable. Can we do that in the 1.9 timeframe?
-Boris
Frank Hecker wrote:
Christopher Aillon wrote re the -disable-crypto flag:
IIRC, the main reason for the flag existing was a legal one, not a
technical one. U.S. export restrictions need to be accounted for.
They are much more relaxed these days but I'm not really that sure of
the details.
The basic situation with regard to US export regulations is as follows
(the usual disclaimers apply: I am not a lawyer, this is not legal
advice): Assume we have a software product with encryption
functionality. If that software is open source (source code under an
open source license, or binaries compiled from that code) then you can
export the code with minimal restrictions, e.g., by putting it up on a
web site for general download. However if the software is proprietary
then you still have to apply to the US government for permission,
although this is relatively straightforward to get for the typical types
of products we're concerned with.
At present I think the most likely use of -disable-crypto would be by a
company producing a proprietary application based on XULrunner, where
the application didn't need encryption functionality and the company
wanted to leave it out in order to simplify export issues. I have no
idea how widespread this practice is, so I don't know the extent to
which it justifies maintaining -disable-crypto.
One other possibility for the future would be to modify NSS to separate
out the encryption parts from the non-encryption parts (the RNG, hash
functions, etc.), and include the non-encryption parts by default,
leaving -disable-crypto to govern only the encryption functionality.
However I don't know whether this would be practical or useful.
Frank
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
