Re: Introductions - want to contribute to NSS developer friendliness

[Robert Relyea]

On 06/17/2013 10:58 AM, Chris Newman wrote:
I'll mention one other usability issue. I am getting pressure from my 
employer to stop using NSS due to the MPL 2 license. I got less 
pressure when I could use NSS under the LGPL 2.1 branch of the 
tri-license. Switching to OpenSSL has been suggested. 
My understanding is you can morph MPL 2 into LGPL 2.1 if you need to 
(that's an explicit part of MPL 2). That was a prerequisite before NSS 
moved to MPL 2. OpenSSL doesn't help you if you have GPL issues since's 
it's an attributive license.


bob

-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Introductions - want to contribute to NSS developer friendliness

[Julien Pierre]

Chris,

On 6/17/2013 10:58, Chris Newman wrote:
I'll mention one other usability issue. I am getting pressure from my 
employer to stop using NSS due to the MPL 2 license. I got less 
pressure when I could use NSS under the LGPL 2.1 branch of the 
tri-license. Switching to OpenSSL has been suggested.


I believe we have just resolved this issue. More details by email.

Julien


--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

The NSS_SURVIVE_DOUBLE_BYPASS_FAILURE build option will be removed in NSS 3.15.1

[Wan-Teh Chang]

NSS has a build option NSS_SURVIVE_DOUBLE_BYPASS_FAILURE that enables
some code in the SSL library to turn off PKCS #11 bypass mode
automatically if the attempt to bypass PKCS #11 fails:

http://mxr.mozilla.org/security/search?string=NSS_SURVIVE_DOUBLE_BYPASS_FAILURE

I believe nobody is using that build option. I am going to remove that
build option so that the ss->ssl3.hs.messages structure member is only
used for one purpose: to buffer handshake messages until we establish
which handshake hash functions to use. This will simplify the logic of
determining when to stop buffering handshake messages.

If you are using the NSS_SURVIVE_DOUBLE_BYPASS_FAILURE build option,
please let me know. If you call SSL_CanBypass before enabling the PKCS
#11 bypass mode, you should not need the
NSS_SURVIVE_DOUBLE_BYPASS_FAILURE build option.

Thanks,
Wan-Teh Chang
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Introductions - want to contribute to NSS developer friendliness

[Rob Stradling]

On 17/06/13 18:58, Chris Newman wrote:


I think these would be good usability issues to address. When I
contributed that code, I was a Sun Microsystems employee and Sun was an
NSS contributor. However, I can not maintain or update that code as my
present employer does not have a code contribution agreement with
Mozilla to my knowledge.


Is there actually such a thing as a "code contribution agreement with 
Mozilla" ?


https://bugzilla.mozilla.org/show_bug.cgi?id=369879#c19
...suggests that there isn't (at least, not yet).

(A quick Google search finds a MoFo Committer's Agreement, but you don't 
need committer privileges in order to create a bug on Bugzilla, attach a 
patch, etc).


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Introductions - want to contribute to NSS developer friendliness

[Chris Newman]

--On June 17, 2013 10:23:52 -0400 Miloslav Trmač  wrote:

me and Milan Bartoš plan to spend some time working on making NSS easier
to develop for - to make sure there is easy to find documentation, the
applications don't need unnecessary boilerplate code, and so on.

The current list of items we'll try to improve is at
https://fedoraproject.org/wiki/User:Mitr/NSS:DeveloperFriendliness .  Any
comments are welcome.  We don't expect to touch the "actual
cryptography", only to improve the developer-facing APIs.

For the smaller items, you can expect proposed patches in bugzilla; for
the larger efforts we'll obviously send more detailed proposals for
discussion.

We've both done some work with and on NSS, but are by no means experts,
so please have some patience with us while we learn.


Here are two bugs where I raised a usability issue and contributed code:




I think these would be good usability issues to address. When I contributed 
that code, I was a Sun Microsystems employee and Sun was an NSS 
contributor. However, I can not maintain or update that code as my present 
employer does not have a code contribution agreement with Mozilla to my 
knowledge.


I'll mention one other usability issue. I am getting pressure from my 
employer to stop using NSS due to the MPL 2 license. I got less pressure 
when I could use NSS under the LGPL 2.1 branch of the tri-license. 
Switching to OpenSSL has been suggested.


- Chris

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Introductions - want to contribute to NSS developer friendliness

[Miloslav Trmač]

Hello all,
me and Milan Bartoš plan to spend some time working on making NSS easier to 
develop for - to make sure there is easy to find documentation, the 
applications don't need unnecessary boilerplate code, and so on.

The current list of items we'll try to improve is at 
https://fedoraproject.org/wiki/User:Mitr/NSS:DeveloperFriendliness .  Any 
comments are welcome.  We don't expect to touch the "actual cryptography", only 
to improve the developer-facing APIs.

For the smaller items, you can expect proposed patches in bugzilla; for the 
larger efforts we'll obviously send more detailed proposals for discussion.

We've both done some work with and on NSS, but are by no means experts, so 
please have some patience with us while we learn.

Thank you,
Mirek
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto