Re: NSS v3.52 and TLSv1.3's Post-Handshake Authentication -- completion notification?

[Martin Thomson]

On Wed, Jul 8, 2020 at 2:36 AM Daiki Ueno  wrote:
>
> Martin Thomson  writes:
>
> > I think that we considered this when we first landed this code, but
> > deferred adding any callbacks until it was clear what the right answer
> > was.  As you say, you get the callback, but you might not if the
> > request is rejected.
>
> I think that is about the server side.  On the client side, it seems
> even harder to detect the completion, because there will be no
> indication of acceptance until the next application data is sent.

Fair point, but we have never had a way to indicate that you consider
your peer to be authenticated as "X".  It's down to individual
authorization decisions to reflect whatever opinion you have formed.
For instance, a 403 response in HTTP might provide some more
information.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS v3.52 and TLSv1.3's Post-Handshake Authentication -- completion notification?

[Martin Thomson]

Daiki might have some ideas about how to approach this.

I think that we considered this when we first landed this code, but
deferred adding any callbacks until it was clear what the right answer
was.  As you say, you get the callback, but you might not if the
request is rejected.

On Tue, Jul 7, 2020 at 3:56 AM Alex Scheel  wrote:
>
> Greetings folks,
>
> With moz-bz#1561637 having landed upstream (and subsequently v3.52 being
> shipped downstream in Fedora), I've been testing JSS's SSLEngine with
> TLSv1.3 again.
>
> One of the issues I've had is there's no good indicator for either
> key-exchange or post-handshake auth being started or completed by either
> party (client or server).
>
> SSLEngine (in Java) for those unaware has (roughly) the following semantics:
>
>  - After beginHandshake() has been called, handshake status stays in
>NEED_WRAP, NEED_UNWRAP, or NEED_TASK until the handshake is
>complete. Then it moves to FINISHED and finally to
>NOT_HANDSHAKING.
>  - beginHandshake() is called implicitly the first time from wrap()
>and unwrap().
>  - If certs are required after the initial handshake (such as via PHA in
>TLSv1.3 or a full re-handshake when available in TLSv1.2 and earlier),
>beginHandshake() semantics apply again.
>
>
> The last requirement is the "hard" one under TLSv1.3.
>
> I've set a SSL_HandshakeCallback() that informs me when the initial
> handshake is completed. This works fine for both client and
> server-initiated re-handshakes under TLSv1.2. However, this callback
> is never executed under TLSv1.3 (in part) because PHA and re-key requests
> aren't strictly a new handshake.
>
> So what I ask are:
>
>  - Is there a reliable way to tell (as both a client and server) when
>PHA/rekey requests have started?
>
>  - Is there a reliable way to tell (as both a client and server) when
>PHA/rekey requests have completed?
>
>  - Is there a reliable way to tell (as both a client and server) when
>a handshake has been initiated by the other party (on TLS < 1.2)?
>
>
> I'm fine living without 1 and 3, but 2 is the more of an issue for me.
>
> I'd be happy to submit the code changes to trigger SSL_HandshakeCallback
> via TLSv1.3 PHA/re-key requests -- but I'm not sure if that'd technically
> conform to the function's documentation:
>
> > /*
> > ** Set the callback that gets called when a TLS handshake is complete. The
> > ** handshake callback is called after verifying the peer's Finished message 
> > and
> > ** before processing incoming application data.
> > **
> > ** For the initial handshake: If the handshake false started (see
> > ** SSL_ENABLE_FALSE_START), then application data may already have been sent
> > ** before the handshake callback is called. If we did not false start then 
> > the
> > ** callback will get called before any application data is sent.
> > */
> > typedef void(PR_CALLBACK *SSLHandshakeCallback)(PRFileDesc *fd,
> > void *client_data);
> > SSL_IMPORT SECStatus SSL_HandshakeCallback(PRFileDesc *fd,
> >SSLHandshakeCallback cb, void 
> > *client_data);
>
> It might be surprising behavior? But on the other hand, these two do
> kinda replace the (insecure) second handshake. Perhaps gating it behind
> an option flag would suffice though (SSL_HANDSHAKE_CALLBACK_FOR_PHA or
> some such)?
>
> When looking at the other SSL_SendCertificateRequest experimental API
> docs, it does say AuthCertificateComplete is called on the server side:
>
> > /* This function allows a server application to trigger
> >  * re-authentication (TLS 1.3 only) after handshake.
> >  *
> >  * This function will cause a CertificateRequest message to be sent by
> >  * a server.  This can be called once at a time, and is not allowed
> >  * until an answer is received.
> >  *
> >  * This function is not allowed for use with DTLS or when external
> >  * PSK authentication has been negotiated. SECFailure is returned
> >  * in both cases.
> >  *
> >  * The AuthCertificateCallback is called when the answer is received.
> >  * If the answer is accepted by the server, the value returned by
> >  * SSL_PeerCertificate() is replaced.  If you need to remember all the
> >  * certificates, you will need to call SSL_PeerCertificate() and save
> >  * what you get before calling this.
> >  *
> >  * If the AuthCertificateCallback returns SECFailure, the connection
> >  * is aborted.
> >  */
> > #define SSL_SendCertificateRequest(fd) \
> > SSL_EXPERIMENTAL_API("SSL_SendCertificateRequest", \
> >  (PRFileDesc * _fd),   \
> >  (fd))
>
>
> But this doesn't help on the client side. Additionally, my situation with
> AuthCertificateCallback is... complicated (it is either not explicitly set
> to use the default NSS value, set to something with no knowledge of my
> SSLEngine, or something with knowledge of the SSLEngine) -- so I'm 

Re: [ANNOUNCE] NSS 3.53 release

[Martin Thomson]

On Fri, Jun 12, 2020 at 1:16 AM Robert Relyea  wrote:
>
> On 6/10/20 10:48 PM, Martin Thomson wrote:
> > Is there an automated check we can run that will help us remember to
> > do this properly in future?  I really don't like having to remember
> > this sort of thing.
>
>
> There isn't, which is why it happened, I think we should have one
> though, where would be the best place to put it? nss/automation?

Any of our unit tests runners could catch this, it's a fairly cheap
thing to check on.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: [ANNOUNCE] NSS 3.53 release

[Martin Thomson]

Is there an automated check we can run that will help us remember to
do this properly in future?  I really don't like having to remember
this sort of thing.

On Thu, Jun 11, 2020 at 3:52 AM Robert Relyea  wrote:
>
> On 6/1/20 5:18 PM, JC Jones wrote:
> > The NSS team released Network Security Services (NSS) 3.53 on 29 May 2020. 
> > NSS 3.53 will be a long-term support release, supporting Firefox 78 ESR.
>
>
> Looks like we updated certdata.txt without updating the version number
> in nssckbi.h. This caused some problems because I pulled the 3.52
> certdata.txt, but with 3.53 coming out I verified that version number
> didn't change and didn't pick up the 3.53 change.
>
> We need to make sure we bump the version number when we make changes.
> Just a reminder for the future...
>
> Fortunately our QA tests found this, and I had already pushed our
> version number because I removed a bunch of expired certs (that weren't
> explicitly marked as untrusted). I'll create a bug to remove those from
> the upstream certdata.txt and that will put the versions in sync again.
>
>
> bob
>
>
> --
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS 3.47.1 build fail on windows

[Martin Thomson]

You shouldn't need to start the mozilla-build shell from within a VS
shell.  Our build uses vswhere and the registry to find the necessary
pieces.  That might be where things are going awry.

From looking at your output, you might want to check this path:
"/c/apps/MVS15/VC/Tools/MSVC/14.10.25017 /", which appears to have a
trailing space in our build output.  That comes from
${VCINSTALLDIR}/Auxiliary/Build/Microsoft.VCToolsVersion.default.txt so
maybe our script is failing to prune out a trailing space or an extra empty
line from that file.  If that file has been modified manually, or we have
an errant carriage return or something like that, then we might need to
make some changes to ensure that we don't catch that.  (We use 'cat', but
we could use 'head -1' instead.)

If that fails, then you help by sharing the output of:

(export target_arch=x64; bash -x /coreconf/msvc.sh)

There will be a lot of paths listed.  You could help by seeing which of
those, if any, don't exist.  Most should.  It's possible however that the
script is failing to find something important.

On Sat, Dec 21, 2019 at 4:20 AM Usha Nayak  wrote:

> On Wednesday, December 11, 2019 at 9:28:17 AM UTC-6, Usha Nayak wrote:
> > Hello,
> >
> > I'm trying to build NSS in debug mode ( I'm assuming if I don't set
> BUILD_OPT=1, default will be debug? ). I gathered from googling, to debug
> NSS, you need to set following env variables, but for that to work I would
> need to build NSS in debug mode:
> > > $ export NSPR_LOG_MODULES="all:5"
> > > $ export NSPR_LOG_FILE="/tmp/pkcs11.log"
> > > $ export NSS_DEBUG_PKCS11_MODULE="NSS Internal PKCS #11 Module"
> >
> >
> > Unfortunately, I have problem building NSS on windows. Since, I wasn't
> able to quite understand what the pre-reqs are for NSS from mozilla site, I
> ended up googling for that as well. Hopefully, this is the right approach.
> >
> > Here's what I did :
> > installed mozillabuild (v3.3)
> > installed gitbash
> > installed gyp
> > got ninja ( not sure if I even need this, regardless copied over
> ninja.exe to mozilla-build\python\Scripts)
> > downloaded nss-3.47-with-nspr-4.23 - unzipped
> >
> > Start->VS2017 -> launched 'x64 native Tools Command Prompt for VS2017'
> > **
> > ** Visual Studio 2017 Developer Command Prompt v15.9.13
> > ** Copyright (c) 2017 Microsoft Corporation
> > **
> > [vcvarsall.bat] Environment initialized for: 'x64'
> >
> > c:\apps\MVS15>set
> PATH=D:\apps\nss-prereq\mozilla-build\python;D:\apps\nss-prereq\mozilla-build\python\Scripts;%PATH%
> > c:\apps\MVS15>set MOZ_NO_RESET_PATH=1
> > c:\apps\MVS15>echo %PATH%
> >
> D:\apps\nss-prereq\mozilla-build\python;D:\apps\nss-prereq\mozilla-build\python\Scripts;c:\apps\MVS15\VC\Tools\MSVC\14.10.25017\bin\HostX64\x64;c:\apps\MVS15\Common7\IDE\VC\VCPackages;c:\apps\MVS15\Common7\IDE\CommonExtensions\Microsoft\TestWindow;c:\apps\MVS15\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team
> Explorer;c:\apps\MVS15\MSBuild\15.0\bin\Roslyn;c:\apps\MVS15\Team
> Tools\Performance Tools\x64;c:\apps\MVS15\Team Tools\Performance
> Tools;C:\Program Files (x86)\Microsoft Visual
> Studio\Shared\Common\VSPerfCollectionTools\\x64;C:\Program Files
> (x86)\Microsoft Visual
> Studio\Shared\Common\VSPerfCollectionTools\;C:\Program Files
> (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\x64\;C:\Program
> Files (x86)\HTML Help Workshop;C:\Program Files (x86)\Windows
> Kits\10\bin\10.0.17763.0\x64;C:\Program Files (x86)\Windows
> Kits\10\bin\x64;c:\apps\MVS15\\MSBuild\15.0\bin;C:\Windows\Microsoft.NET\Framework64\v4.0.30319;c:\apps\MVS15\Common7\IDE\;c:\apps\MVS15\Common7\Tools\;C:\ProgramData\Oracle\Java\javapath;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;C:\Program
> Files\Microsoft\Web Platform Installer\;C:\Program Files (x86)\Microsoft
> ASP.NET\ASP.NET Web Pages\v1.0\;C:\Program Files\Microsoft SQL
> Server\110\Tools\Binn\;C:\Users\nayak\.dnx\bin;C:\Program Files\Microsoft
> DNX\Dnvm\;C:\Program Files\Microsoft SQL
> Server\120\Tools\Binn\;D:\apps\nss-prereq\Git\cmd;C:\Users\nayak\AppData\Local\Microsoft\WindowsApps;;c:\apps\MVS15\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin;c:\apps\MVS15\Common7\IDE\CommonExtensions\Microsoft\CMake\Ninja
> > c:\apps\MVS15>cd D:\apps\nss-prereq\mozilla-build
> >
> > c:\apps\MVS15>D:
> >
> > c:\apps\MVS15>cd D:\apps\nss-prereq\mozilla-build
> >
> > c:\apps\MVS15>D:
> >
> > D:\apps\nss-prereq\mozilla-build>start-shell.bat
> > MozillaBuild Install Directory: D:\apps\nss-prereq\mozilla-build\
> >
> > nayak@svi6w273 ~
> > $ export USE_64=1
> >
> > nayak@svi6w273 ~
> > $ export NSS_DISABLE_GTESTS=1
> > nayak@svi6w273 /d/apps/nss-prereq/nss-3.47-with-nspr-4.23/nss-3.47/nss
> > $ ./build.sh
> > NSPR [1/5] configure ...
> > NSPR [2/5] make ...
> >
> > nayak@svi6w273 

Re: NSS3 (v3.14) on XP (FF52) - where to post questions about its API ?

[Martin Thomson]

Moved to dev-tech-crypto.

NSS has some limited certificate validation code, but you have to roll it
in. You can take a look at either tstclnt or firefox code to see how to put
something together. The firefox code is much more complex.

On Mon, 14 Oct. 2019, 12:37 R.Wieser,  wrote:

> Hello all,
>
> I have some questions about the NSS3 API (AFAIK v3.14, as came with FF52 -
> which is the last version which will run on XP), and am wondering if this
> is
> the correct place to ask questions about it.
>
> For example, although I can create an SSL connection, I have no idea how I
> should verify a peers certificate (I assume inside the
> SSL_AuthCertificateHook callback)
>
> Regards,
> Rudy Wieser
>
>
> ___
> dev-security mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security
>
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: WIP: TLS with GOST ciphersuites in NSS

[Martin Thomson]

Hi Paul,

I don't want to answer specific questions here, but I did want to address
the higher level point.

Integrating all the pieces for a new cipher suite is a major project.  I
strongly suggest that you work on doing this in pieces.  If you intend to
present a single patch that adds all the primitives and their integration
throughout the stack all the way to TLS, you are not likely to be
successful.  Working on small increments is definitely more likely to work.

For TLS pieces, we would want a very strong case for anything that isn't an
AEAD and anything that is being added to TLS 1.2 or earlier.  We would like
to avoid adding new features to anything earlier than TLS 1.3.

All that said, the bar for new cryptographic primitives in NSS has been
getting higher.  While we don't intend to block new primitives, we would
want to see some case made for their value and some due diligence regarding
the risks.  The
recent addition of HACL*-based primitives is the ideal, with code that is
formally verified for several properties.  We have taken primitives with
lesser assurances, but require strong justification. The recent change to
accept an X25519 implementation from a similar project for performance
reasons is one example of that.

Cheers,
Martin

On Wed, Jul 17, 2019 at 11:15 AM Paul Wolneykien 
wrote:

>
>   Hi!
>
>   I'm currently working on getting TLS with GOST ciphersuites in NSS:
>
>
> http://git.altlinux.org/people/manowar/packages/?p=nss.git;a=shortlog;h=refs/heads/gost-tls
>
>   That's work in progress. However, I have some questions and proposals
> to the NSS community.
>
>   New `SECOidTag algorithm` field in the `struct SECKEYECPublicKeyStr`.
> The algorithm tag (originated from a certificate) is used to determine
> how to parse the next `DEREncodedParams` field of that structure. In the
> upstream NSS code there is an assumption, that DER encoded parameters of
> an EC key always represent a single OID number. But that is not the
> case, at least, with GOST keys for which a SEQUENCE of parameters is
> supplied.
>   On the other hand, the proper way to interpret the encoded parameters
> can possibly be *guessed* from the DER structure itself (and the actual
> values there). For example: if there is a sequence of two OIDs in the
> encoded parameters (and the OID values are in the GOST domain) then most
> probably it's a GOST key.
>   However, the idea of having an identifier next to the encoded data
> which explicitly determines what is encoded seems more attractive to me.
>   What do you think?
>
>   Next, the PRF hashing algorithm in TLS versions prior 1.2. In the
> upstream NSS code there is currently no way of using a custom PRF
> hashing algorithm. That affects the calculation of the master secret and
> the encrypted TLS finishing message. With GOST ciphersuites you have to
> use GOST hashing for that with any TLS version.
>   I have no good solution here yet. Does it violate the TLS 1.0 and 1.1
> standards? And another thing: I can't find a corresponding mapping of
> the hashing algorithm to the TLS version in OpenSSL.
>
>   The third is the "stream" MAC mode. The idea that the MACing context
> shouldn't be re-created for each packet but rather re-used along with
> the whole sequence of packets in the session. That's how MACing works
> with GOST. I've added the `stream` flag to the `struct
> SFTKSessionContextStr` and then have to use a special PKCS#11 mechanism
> number in order to signal the softoken module to use that mode (the
> mechanism parameters are standardized, so there is no place for a
> `stream` flag).
>
> --
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Failed building NSS 3.44 on MacOSX

[Martin Thomson]

https://bugzilla.mozilla.org/show_bug.cgi?id=1561510 is where we should
keep discussing this.

On Wed, Jun 26, 2019 at 4:19 PM Martin Thomson  wrote:

> OK, this looks like I hit a problem in my system (which I only use
> rarely).  I am now hitting your issue.
>
> This is a failure in Bug 1310168. I don't know why this hasn't manifest
> before now, but the code there is not working as designed, which can you
> can see from this test:
>
> ```
> CC=a b c
> TEST := CC="$(CC)"
> TEST := $(filter-out b c,$(TEST))
> all:
> echo '<$(TEST)>'
> ```
>
> For some reason CC is being configured as 'CC -arch x86_64', but the fix
> in
> https://hg.mozilla.org/projects/nss/rev/ad2a42aed57a01cfc1d8b14fad8c782f52e17093
> doesn't work here if these arguments are at the end of the string.  Maybe
> it is because the version of make we now have on mac quotes the arguments
> (as it should). The fix is simple enough; I'll get something in review soon.
>
>
>
>
>
> On Wed, Jun 26, 2019 at 3:30 PM John Jiang 
> wrote:
>
>> Hi Martin,
>> Thanks for your reply!
>>
>> On Wed, Jun 26, 2019 at 8:58 AM Martin Thomson  wrote:
>>
>> > I had trouble myself, but it turns out that even if you are all up to
>> date,
>> > XCode isn't upgraded.  The error I get is the result of XCode being out
>> of
>> > date.
>> >
>> > Confirm by looking for a config.log in the NSPR directory.  If it
>> contains
>> > a message like the one below, the outdated XCode is the problem.
>> >
>> > configure:: gccconftest.c  >&5
>> > ld: malformed
>> >
>> file/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/lib/libSystem.tbd:4:18:
>> > error: unknown enumerated scalar
>> > platform:zippered
>> >  ^~~~
>> >  file
>> >
>> '/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/lib/libSystem.tbd'
>> > clang: error: linker command failed with exit code 1 (use -v to see
>> > invocation)
>> >
>> I don't find such stuff in my config.log.
>>
>> My config.log contains the following lines,
>> ==
>> configure:3466: checking for C compiler version
>> configure:3475: cc x86_64 --version >&5
>> Apple LLVM version 10.0.0 (clang-1000.10.44.4)
>> Target: x86_64-apple-darwin17.7.0
>> Thread model: posix
>> InstalledDir: /Library/Developer/CommandLineTools/usr/bin
>> configure:3486: $? = 0
>> configure:3475: cc x86_64 -v >&5
>> Apple LLVM version 10.0.0 (clang-1000.10.44.4)
>> Target: x86_64-apple-darwin17.7.0
>> Thread model: posix
>> InstalledDir: /Library/Developer/CommandLineTools/usr/bin
>> clang: error: no such file or directory: 'x86_64'
>> configure:3486: $? = 1
>> configure:3475: cc x86_64 -V >&5
>> clang: error: argument to '-V' is missing (expected 1 value)
>> clang: error: no such file or directory: 'x86_64'
>> clang: error: no input files
>> configure:3486: $? = 1
>> configure:3475: cc x86_64 -qversion >&5
>> clang: error: unknown argument: '-qversion'
>> clang: error: no such file or directory: 'x86_64'
>> clang: error: no input files
>> configure:3486: $? = 1
>> configure:3506: checking whether the C compiler works
>> configure:3528: cc x86_64conftest.c  >&5
>> clang: error: no such file or directory: 'x86_64'
>> configure:3532: $? = 1
>> configure:3570: result: no
>> configure: failed program was:
>> | /* confdefs.h */
>> | #define PACKAGE_NAME ""
>> | #define PACKAGE_TARNAME ""
>> | #define PACKAGE_VERSION ""
>> | #define PACKAGE_STRING ""
>> | #define PACKAGE_BUGREPORT ""
>> | #define PACKAGE_URL ""
>> | #define DEBUG 1
>> | /* end confdefs.h.  */
>> |
>> | int
>> | main ()
>> | {
>> |
>> |   ;
>> |   return 0;
>> | }
>> configure:3575: error: in
>>
>> `/Users/sha.jiang/work/software/nss/nss-3.44/nspr/Darwin17.7.0_cc_64_DBG.OBJ':
>> configure:3577: error: C compiler cannot create executables
>> See `config.log' for more details
>> ==
>>
>> I also checked the config.log for NSS 3.43, it looks cc doesn't use option
>> "x86_64".
>>
>> Thanks!
>>
>>
>> >
>> > On Sun, Jun 23, 2019 at 6:27 PM John Jiang 
>> > wrote:
>> >
>> > > Hi,
>> > > I tried to build NSS 3.44 on MacOSX 10.13.6 (Darwi

Re: Failed building NSS 3.44 on MacOSX

[Martin Thomson]

OK, this looks like I hit a problem in my system (which I only use
rarely).  I am now hitting your issue.

This is a failure in Bug 1310168. I don't know why this hasn't manifest
before now, but the code there is not working as designed, which can you
can see from this test:

```
CC=a b c
TEST := CC="$(CC)"
TEST := $(filter-out b c,$(TEST))
all:
echo '<$(TEST)>'
```

For some reason CC is being configured as 'CC -arch x86_64', but the fix in
https://hg.mozilla.org/projects/nss/rev/ad2a42aed57a01cfc1d8b14fad8c782f52e17093
doesn't work here if these arguments are at the end of the string.  Maybe
it is because the version of make we now have on mac quotes the arguments
(as it should). The fix is simple enough; I'll get something in review soon.





On Wed, Jun 26, 2019 at 3:30 PM John Jiang  wrote:

> Hi Martin,
> Thanks for your reply!
>
> On Wed, Jun 26, 2019 at 8:58 AM Martin Thomson  wrote:
>
> > I had trouble myself, but it turns out that even if you are all up to
> date,
> > XCode isn't upgraded.  The error I get is the result of XCode being out
> of
> > date.
> >
> > Confirm by looking for a config.log in the NSPR directory.  If it
> contains
> > a message like the one below, the outdated XCode is the problem.
> >
> > configure:: gccconftest.c  >&5
> > ld: malformed
> >
> file/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/lib/libSystem.tbd:4:18:
> > error: unknown enumerated scalar
> > platform:zippered
> >  ^~~~
> >  file
> >
> '/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/lib/libSystem.tbd'
> > clang: error: linker command failed with exit code 1 (use -v to see
> > invocation)
> >
> I don't find such stuff in my config.log.
>
> My config.log contains the following lines,
> ==
> configure:3466: checking for C compiler version
> configure:3475: cc x86_64 --version >&5
> Apple LLVM version 10.0.0 (clang-1000.10.44.4)
> Target: x86_64-apple-darwin17.7.0
> Thread model: posix
> InstalledDir: /Library/Developer/CommandLineTools/usr/bin
> configure:3486: $? = 0
> configure:3475: cc x86_64 -v >&5
> Apple LLVM version 10.0.0 (clang-1000.10.44.4)
> Target: x86_64-apple-darwin17.7.0
> Thread model: posix
> InstalledDir: /Library/Developer/CommandLineTools/usr/bin
> clang: error: no such file or directory: 'x86_64'
> configure:3486: $? = 1
> configure:3475: cc x86_64 -V >&5
> clang: error: argument to '-V' is missing (expected 1 value)
> clang: error: no such file or directory: 'x86_64'
> clang: error: no input files
> configure:3486: $? = 1
> configure:3475: cc x86_64 -qversion >&5
> clang: error: unknown argument: '-qversion'
> clang: error: no such file or directory: 'x86_64'
> clang: error: no input files
> configure:3486: $? = 1
> configure:3506: checking whether the C compiler works
> configure:3528: cc x86_64conftest.c  >&5
> clang: error: no such file or directory: 'x86_64'
> configure:3532: $? = 1
> configure:3570: result: no
> configure: failed program was:
> | /* confdefs.h */
> | #define PACKAGE_NAME ""
> | #define PACKAGE_TARNAME ""
> | #define PACKAGE_VERSION ""
> | #define PACKAGE_STRING ""
> | #define PACKAGE_BUGREPORT ""
> | #define PACKAGE_URL ""
> | #define DEBUG 1
> | /* end confdefs.h.  */
> |
> | int
> | main ()
> | {
> |
> |   ;
> |   return 0;
> | }
> configure:3575: error: in
>
> `/Users/sha.jiang/work/software/nss/nss-3.44/nspr/Darwin17.7.0_cc_64_DBG.OBJ':
> configure:3577: error: C compiler cannot create executables
> See `config.log' for more details
> ==
>
> I also checked the config.log for NSS 3.43, it looks cc doesn't use option
> "x86_64".
>
> Thanks!
>
>
> >
> > On Sun, Jun 23, 2019 at 6:27 PM John Jiang 
> > wrote:
> >
> > > Hi,
> > > I tried to build NSS 3.44 on MacOSX 10.13.6 (Darwin Kernel Version
> > 17.7.0).
> > > Just run "make nss_build_all" in directory nss-3.44/nss, and got the
> > below
> > > errors,
> > > mkdir -p ./../nspr/Darwin17.7.0_cc_64_OPT.OBJ
> > > cd ./../nspr/Darwin17.7.0_cc_64_OPT.OBJ ; \
> > > CC="cc x86_64" CXX="g++ x86_64" sh ../configure \
> > > --disable-debug --enable-optimize --enable-64bit \
> > >
> > >
> >
> --with-dist-prefix='path/to/nss-3.44/nss/../dist/Darwin17.7.0_cc_64_OPT.OBJ'
> > > \
> > >
> > >
> >
> --with-dist-includedir='path/to/nss-3.44/nss/../dist/Darwi

Re: Failed building NSS 3.44 on MacOSX

[Martin Thomson]

I had trouble myself, but it turns out that even if you are all up to date,
XCode isn't upgraded.  The error I get is the result of XCode being out of
date.

Confirm by looking for a config.log in the NSPR directory.  If it contains
a message like the one below, the outdated XCode is the problem.

configure:: gccconftest.c  >&5
ld: malformed 
file/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/lib/libSystem.tbd:4:18:
error: unknown enumerated scalar
platform:zippered
 ^~~~
 file 
'/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/lib/libSystem.tbd'
clang: error: linker command failed with exit code 1 (use -v to see invocation)


On Sun, Jun 23, 2019 at 6:27 PM John Jiang  wrote:

> Hi,
> I tried to build NSS 3.44 on MacOSX 10.13.6 (Darwin Kernel Version 17.7.0).
> Just run "make nss_build_all" in directory nss-3.44/nss, and got the below
> errors,
> mkdir -p ./../nspr/Darwin17.7.0_cc_64_OPT.OBJ
> cd ./../nspr/Darwin17.7.0_cc_64_OPT.OBJ ; \
> CC="cc x86_64" CXX="g++ x86_64" sh ../configure \
> --disable-debug --enable-optimize --enable-64bit \
>
> --with-dist-prefix='path/to/nss-3.44/nss/../dist/Darwin17.7.0_cc_64_OPT.OBJ'
> \
>
> --with-dist-includedir='path/to/nss-3.44/nss/../dist/Darwin17.7.0_cc_64_OPT.OBJ/include'
> checking build system type... x86_64-apple-darwin17.7.0
> checking host system type... x86_64-apple-darwin17.7.0
> checking target system type... x86_64-apple-darwin17.7.0
> checking for whoami... /usr/bin/whoami
> checking for gcc... cc x86_64
> checking whether the C compiler works... no
> configure: error: in `path/to/nss-3.44/nspr/Darwin17.7.0_cc_64_OPT.OBJ':
> configure: error: C compiler cannot create executables
> See `config.log' for more details
> make: *** [../nspr/Darwin17.7.0_cc_64_OPT.OBJ/config.status] Error 77
>
> but on the same machine, I didn't get any trouble when building NSS 3.43.
> --
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: [ANNOUNCE] NSS 3.44 Release

[Martin Thomson]

On Thu, May 16, 2019 at 2:03 PM Miklos Vajna  wrote:

> Is it possible to use this static mode when building via the provided
> Makefile?
>

No.  We're gradually phasing out support for Makefiles.  They are very hard
to maintain.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Is there some problem with treeherder?

[Martin Thomson]

+Dustin Mitchell  who might have some insight into this.

On Tue, Mar 19, 2019 at 6:03 AM Robert Relyea  wrote:

> I've been trying to get an nss-try builds with nss-tools for a couple of
> days now, but it looks like both nss-try and nss are not properly
> running any tests. Is there an outage, or do we need someone to kick the
> try servers?
>
>
> bob
>
> --
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Possible ABI break when updating from NSS 3.39 to 3.41

[Martin Thomson]

We routinely run similar checks on our builds and track the changes that
libabigail reports.  We require that ABI changes, even of the benign sort
you found are reviewed and accepted.  The set of expected changes between
releases is found here:

https://hg.mozilla.org/projects/nss/file/tip/automation/abi-check

As you can see, mostly these files are empty, indicating no change to the
ABI.  You should see that those files from the 3.41 release match with your
report (there were no changes in 3.40).

https://hg.mozilla.org/projects/nss/file/NSS_3_41_RTM/automation/abi-check


On Mon, Jan 21, 2019 at 1:59 AM  wrote:

> Jan 19, 2019, 5:58 PM by p...@nohats.ca :
>
> > On Sat, 19 Jan 2019, > emersonbern...@tutanota.com  emersonbern...@tutanota.com>>  wrote:
> >
> >> Infreedesktop-sdk[1] <>> https://gitlab.com/freedesktop-sdk <
> https://gitlab.com/freedesktop-sdk>>> > we're trying to keep ABI
> compatibility when updating elements like cups to new releases. In order to
> achieve this we use libabigail[2] <>> https://sourceware.org/libabigail <
> https://sourceware.org/libabigail/>>> > tool to automate ABI compat
> checks. During update NSS from 3.39 to 3.41 (we missed 3.40 release) our
> tool produced following complaint:
> >>
> >
> > Why do you call that an ABI break? It has added values to an enum, and
> > the only "change" was to the value specifying the roof of the enum ?
> >
> > Paul
> >
> I just reported output from an automation tool and asked for opinion.
> Confirming that it's just a false positive is what I expected to get. Thank
> you for help.
>
> Emerson
> --
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Debug info on NSS tools

[Martin Thomson]

You need to build a debug build with -DDEBUG. Disabling optimization is a
different thing.

The default build with build.sh or make nss_build_all should be fine.

On Sat, 5 Jan. 2019, 11:40 John Jiang  I had read that page. In fact, SSLDEBUG and SSLTRACE were used in my last
> try.
> My NSS was built with "BUILD_OPT=0", so I supposed it is a debug build.
> How can I double-check this point?
>
> Thanks!
>
> On Sat, Jan 5, 2019 at 12:34 AM Kai Engert  wrote:
>
> > Does this page help?
> > You might need a debug build (i.e. build yourself with debugging
> enabled).
> >
> > https://wiki.mozilla.org/NSS:Tracing
> >
> > Kai
> >
> > On 03.01.19 13:51, John Jiang wrote:
> > > Just tried it, but looked not work.
> > >
> > > $ export SSLDEBUG=1
> > > $ export SSLTRACE=127
> > > $ tstclnt -v ...
> > > I didn't get more logs.
> >
> --
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Debug info on NSS tools

[Martin Thomson]

Try exporting SSLTRACE=100.

That might be too much detail, but lower numbers are still useful.  I find
that 20-ish gets some fairly useful logging.

On Thu, Jan 3, 2019 at 6:12 PM John Jiang  wrote:

> Can NSS tools, like selfserv and tstclnt, output debug info?
> My NSS binary is built with debug mode.
>
> I try to enable the debug logs for selfserv and tstclnt, but don't get any
> useful option.
> Option -v just outputs a bit more logs. That's not enough for me.
> I wish the tools can output more details on TLS handshaking.
> --
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Using AES256 cipher directly...?

[Martin Thomson]

On Fri, Dec 7, 2018 at 12:26 PM Paul Smith  wrote:
> Another thing that I didn't bring up: I need to implement this in other
> languages (at least Java and Python), so clients can connect to the
> service.  So I need to consider availability in other crypto libraries
> like Python ssl and javax crypto or BouncyCastle.  I'm sure they have
> HKDF too of course.

I have code in nodejs and Python that uses all the primitives I
mentioned, so yeah.  The crypto libraries on github.com/web-push-libs
should be a gold mine if you have to go cross-language.

> My session key is already larger than 256bits so I don't need
> expansion, and I'll only ever extract a single AES key from each
> session key.  Is HKDF still recommended?  I'm definitely no expert.

Yes, HKDF is best practice here.

> I have two concerns with GCM.  One is that the folks pushing for this
> change specifically requested CTR.  I can certainly counter-propose but
> it could be one of these "the customer is always right" things, at
> least until we get to full TLS support.  We understand that CTR doesn't
> provide any MAC facilities.

GCM is just CTR mode with a MAC.  So all the limitations of CTR apply,
plus the lack of authentication means that the ciphertext will be
malleable.  I don't believe that there are many settings where lack of
authentication is safe.

> The second concern is that I understood you can only safely encrypt
> 64GiB with a given key/IV in GCM.  Because our connections are so long-
> lived and are constantly sending traffic I'm confident that we will
> need to send more than that over a connection lifetime.  Of course I
> don't understand GCM as well as CTR so maybe I'm wrong about the
> specifics of this limitation.

The limits on GCM derive mostly from the limits on authentication and
risk of collision.  See http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf
for that analysis.

If you have individual records (which I believe that you do), then you
can send 2^28 (ish) records of 2^14 bytes each provided that the IV is
guaranteed unique.  If you need more, then you can generate new key/IV
pairs with rekeying.  See
https://tools.ietf.org/html/draft-irtf-cfrg-re-keying-13

Without a MAC the limit is 1.  I can't emphasize the value of AEAD enough here.

> > Random nonces are probably not as good as a deterministic nonce (like
> > a counter).
>
> My plan was to use a 64bit random nonce appended with a 64bit counter
> for CTR mode.

You can derive a random part from the SRP secret, just like TLS does
and XOR that with a counter.  For CTR mode, that might be better than
relying on a CSPRNG.  It also means that you don't need to send
randomness with every record.

> I appreciate the code pointers and will study them; if you could narrow
> it down or give more specifics (even just function names I should be
> looking for) that would be very helpful.

The code points to specific functions.  Take a look at the PK11_* calls.

> Starting from its man pages I was able to read the libressl code to get
> an idea of how to use that interface, but I couldn't find any similar
> API docs for NSS; I'll try delving into the NSS code as well if I can
> find my footing.

Yeah, it's a failing.  NSS isn't very well documented (we spend our
time on de-crufting it mostly).
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Using AES256 cipher directly...?

[Martin Thomson]

Hi Paul,

I think NSS has all you need here.  Including TLS 1.3 should you
prefer that.  Unfortunately, we can't say that we have a PAKE, so I
appreciate that you aren't able to just drop that in.  In the
meantime,,,

On Fri, Dec 7, 2018 at 9:18 AM Paul Smith  wrote:
> I have a session key from SRP.  I need the following:
>  * SHA256 (?) to convert the session key into a 256bit key for AES

For key derivation, you probably want HKDF with SHA-256 rather than a
straight hash function.

I have an example of this that you can look at:
https://searchfox.org/nss/source/lib/ssl/tls13hkdf.c - that's ALL the
code for TLS 1.3, but a good basis for a design..

>  * AES256, preferably in CTR mode but I can handle that myself easily
>if I have access to the block cipher.

I think that what you want is AES-GCM rather than one of the modes
closer to the block function.  Do you have a constraint that prevents
records from being expanded?

There are examples of how to use that in the TLS 1.3 code:
https://searchfox.org/nss/rev/3b6a2dd92c56b13f15ad3d0bf2a0e451b898612f/lib/ssl/tls13con.c#3571

>  * Strong RNG for generating a CTR nonce.  I can use my own RNG if it's
>easier.

Random nonces are probably not as good as a deterministic nonce (like
a counter).  But if you need one, then PK11_GenerateRandom() works
very well.  Use the above site to look for examples.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Tyring to buld NSS 3.38 - Win10 x64

[Martin Thomson]

The current process is a bit broken.  See
https://bugzilla.mozilla.org/show_bug.cgi?id=1434943 for more.  Some
people report success with the patch there, but it's not completely
ready.
On Tue, Aug 14, 2018 at 6:00 AM Will Barnz  wrote:
>
> I'm trying to build NSS 3.38. I've downloaded and installed the latest 
> Mozilla Build environment and am running the script within it.
>
> I've got multiple compilers installed as I sometimes use one for a specific 
> purpose.
>
> Borland C++ builder
> CygWin
> MinGW (Code::Blocks)
>
> and Visual Studio 2017 with the latest update (which breaks 8.1 environment 
> compatibility)
>
> I want to build it using the VC++ compiler in Visual Studio... but this is 
> what I get when I run the script:
>
> $ make nss_build_all
> expr: syntax error
> expr: syntax error
> expr: syntax error
> mkdir -p ./../nspr/WIN954.0_DBG.OBJ
> cd ./../nspr/WIN954.0_DBG.OBJ ; \
> CC=cl CXX=cl sh ../configure \
> --enable-win32-target=WIN95 \
> --with-dist-prefix='$(topsrcdir)/../dist/WIN954.0_DBG.OBJ' \
> --with-dist-includedir='$(topsrcdir)/../dist/WIN954.0_DBG.OBJ/include'
> checking build system type... i686-pc-mingw32
> checking host system type... i686-pc-mingw32
> checking target system type... i686-pc-mingw32
> checking for cl... cl
> checking for whoami... /c/WINDOWS/System32/whoami
> checking whether the C compiler works... no
> configure: error: in `/c/nss-3.38/nspr/WIN954.0_DBG.OBJ':
> configure: error: C compiler cannot create executables
> See `config.log' for more details
> make: *** [../nspr/WIN954.0_DBG.OBJ/config.status] Error 77
>
>
>
>
> any ideas? command line parameters? suggestions?
>
>
> NOTE: if this is a duplicate from me, ignore the first. I tried to post it 
> and didn't see it show up.
> --
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: How do selfserv and tstclnt specify RSASSA-PSS certificate?

[Martin Thomson]

This was a feature we supported, but we have an open item to restore
full PSS support for TLS after some changes in TLS 1.3 reassigned the
meaning of the codepoints.  (It's been a few months, and a low
priority item, but it is still on my todo list).  Getting selfserv and
tstclnt to use those keys requires the stack to support them fully,
which - right now - it doesn't.
On Thu, May 31, 2018 at 2:31 AM John Jiang  wrote:
>
> Hi,
> I'm using NSS 3.37.
>
> Tried to specify a RSASSA-PSS certificate for selfserv and tstclnt, but
> looks no option supports this certificate type: "Must specify at least one
> certificate nickname using '-n' (RSA), '-S' (DSA), or 'e' (EC)."
> But it looks the current NSS supports RSASSA-PSS.
> --
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Identifying the NSS version/tag from a n NSS source tree?

[Martin Thomson]

In the gecko tree, there is a file called TAG-INFO that lists the exact NSS
revision.
On Fri, May 18, 2018 at 7:21 AM Jonathan Wilson  wrote:

> I have an NSS source tree (that is, the contents of security\nss as seen
in
> a Gecko source tree), how can I figure out what version of NSS or what NSS
> revision/tag it matches up to?

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

Re: Building NSS 3.32.1 on Solaris

[Martin Thomson]

That looks like you haven't got a c++ compiler that supports c++11.  You
can disable building the tests with NSS_DISABLE_GTESTS.
On Fri, May 18, 2018 at 3:30 AM Usha Nayak  wrote:

> Hi Wan-Teh

> Thanks for replying and appreciate your help.

> Modifying the file as you suggested did get us further than before.
> However, stumbled into another issue during building process (gmake
> build_nss_all):

> CC -o SunOS5.11_64_OPT.OBJ/gtest/src/gtest-all.o -c -xO4 -KPIC -DSVR4
> -DSYSV -D__svr4 -D__svr4__ -DSOLARIS -D_REENTRANT  -xarch=v9  -DXP_UNIX
> -UDEBUG -DNDEBUG -DN  SS_NO_INIT_SUPPORT
> -DUSE_UTIL_DIRECTLY -DNO_NSPR_10_SUPPORT
> -DSSL_DISABLE_DEPRECATED_CIPHER_SUITE_NAMES -Igtest/include/ -Igtest
> -I../../../dist/SunOS5.11_64_OPT.  OBJ/include
> -I../../../dist/public/gtest -I../../../dist/private/gtest  -std=c++0x
> gtest/src/gtest-all.cc
> CC: Warning: -xarch=v9 is deprecated, use -m64 -xarch=sparc instead
> "gtest/src/gtest.cc", line 4108: Warning: Likely null pointer dereference
> (*(((int *)0))): testing::TestPartResult::~TestPartResult
> rm -f SunOS5.11_64_OPT.OBJ/libgtest.a
> ar cr SunOS5.11_64_OPT.OBJ/libgtest.a
> SunOS5.11_64_OPT.OBJ/gtest/src/gtest-all.o
> echo SunOS5.11_64_OPT.OBJ/libgtest.a
> SunOS5.11_64_OPT.OBJ/libgtest.a
> rm -f SunOS5.11_64_OPT.OBJ/libgtest1.so
> CC -xarch=v9 -G -h libgtest1.so -z combreloc -z defs -z ignore  -o
> SunOS5.11_64_OPT.OBJ/libgtest1.so
> SunOS5.11_64_OPT.OBJ/gtest/src/gtest-all.o   ../../../dist/Su
>  nOS5.11_64_OPT.OBJ/lib/libsectool.a
> -L../../../dist/SunOS5.11_64_OPT.OBJ/lib
> -L../../../dist/SunOS5.11_64_OPT.OBJ/lib -lnssutil3
> -L../../../dist/SunOS5.11_64_OPT  .OBJ/lib
> -lplc4 -lplds4 -lnspr4  -lssl3 -lsmime3 -lnss3 -lthread -lnsl -lsocket
> -lposix4 -ldl -lc
> CC: Warning: -xarch=v9 is deprecated, use -m64 -xarch=sparc instead
> Undefined   first referenced
>   symbol in file
> std::string::basic_string(const std::string &)
> SunOS5.11_64_OPT.OBJ/gtest/src/gtest-all.o
> std::stringbuf::overflow(int) SunOS5.11_64_OPT.OBJ/gtest/src/gtest-all.o
> std::string::_M_mutate(unsigned long, unsigned long, unsigned long)
>   SunOS5.11_64_OPT.OBJ/gtest/src/gtest-all.o
> std::ios_base::ios_base()
> SunOS5.11_64_OPT.OBJ/gtest/src/gtest-all.o
> std::ios_base::~ios_base()
> SunOS5.11_64_OPT.OBJ/gtest/src/gtest-all.o
> operator new[](unsigned long)
>   SunOS5.11_64_OPT.OBJ/gtest/src/gtest-all.o
> operator new(unsigned long)
>   SunOS5.11_64_OPT.OBJ/gtest/src/gtest-all.o
> std::ostream::write(const char*, long)
> SunOS5.11_64_OPT.OBJ/gtest/src/gtest-all.o
> std::stringbuf::_M_sync(char*, unsigned long, unsigned long)
> SunOS5.11_64_OPT.OBJ/gtest/src/gtest-all.o
> std::ctype::_M_widen_init()const
> SunOS5.11_64_OPT.OBJ/gtest/src/gtest-all.o
> std::__throw_out_of_range_fmt(const char*, ...)
> SunOS5.11_64_OPT.OBJ/gtest/src/gtest-all.o
> std::string::append(const char*, unsigned long)
>   SunOS5.11_64_OPT.OBJ/gtest/src/gtest-all.o
> std::string::append(const std::string &)
>   SunOS5.11_64_OPT.OBJ/gtest/src/gtest-all.o
> __cxa_allocate_exception
> SunOS5.11_64_OPT.OBJ/gtest/src/gtest-all.o
> std::string::insert(unsigned long, const char*, unsigned long)
>  SunOS5.11_64_OPT.OBJ/gtest/src/gtest-all.o
> std::string::find(const char*, unsigned long, unsigned long)const
>   SunOS5.11_64_OPT.OBJ/gtest/src/gtest-all.o
> vtable for __cxxabiv1::__si_class_type_info
> SunOS5.11_64_OPT.OBJ/gtest/src/gtest-all.o
> [Hint: static member vtable for __cxxabiv1::__si_class_type_info must be
> defined in the program]

> std::string::swap(std::string &)
> SunOS5.11_64_OPT.OBJ/gtest/src/gtest-all.o
> std::ostream::put(char)
>   SunOS5.11_64_OPT.OBJ/gtest/src/gtest-all.o
> std::runtime_error::what()const
> SunOS5.11_64_OPT.OBJ/gtest/src/gtest-all.o
> std::__throw_length_error(const char*)
>   SunOS5.11_64_OPT.OBJ/gtest/src/gtest-all.o
> __cxa_guard_release
>   SunOS5.11_64_OPT.OBJ/gtest/src/gtest-all.o

std::__detail::_List_node_base::_M_transfer(std::__detail::_List_node_base*,
> std::__detail::_List_node_base*)
SunOS5.11_64_OPT.OBJ/gtest/src/gtest-all.o
> std::ostream::operator<<(int)
>   SunOS5.11_64_OPT.OBJ/gtest/src/gtest-all.o
> std::string::find(char, unsigned long)const
> SunOS5.11_64_OPT.OBJ/gtest/src/gtest-all.o
> __atomic_fetch_add_8
> SunOS5.11_64_OPT.OBJ/gtest/src/gtest-all.o
> std::__throw_logic_error(const char*)
> SunOS5.11_64_OPT.OBJ/gtest/src/gtest-all.o
> __cxa_end_catch
>   SunOS5.11_64_OPT.OBJ/gtest/src/gtest-all.o
> std::string::append(unsigned long, char)
>   SunOS5.11_64_OPT.OBJ/gtest/src/gtest-all.o
> __cxa_begin_catch
>   SunOS5.11_64_OPT.OBJ/gtest/src/gtest-all.o
> std::string::basic_string(const std::string &, unsigned long, unsigned
> long)  SunOS5.11_64_OPT.OBJ/gtest/src/gtest-all.o
> std::stringbuf::seekpos(std::fpos<__mbstate_t>, std::_Ios_Openmode)
> 

Re: [ANNOUNCE] NSS 3.37 Release

[Martin Thomson]

Yes, aside from the version number the two versions are identical.

On Mon, 14 May 2018, 21:51 Kai Engert,  wrote:

> On 14.05.2018 13:24, Kai Engert wrote:
> > On 14.05.2018 11:11, Kurt Roeckx wrote:
> >> On 2018-05-08 22:49, Kai Engert wrote:
> >>> Notable changes:
> >>> * The TLS 1.3 implementation was updated to Draft 28.
> >>
> >> I find it unfortunate that you update the draft version to 28 and did
> >> not keep it at 26 like some other implementations, since the protocol
> >> did not change since draft 26. This makes it harder to actually test
> >> things.
> >
> > Are there relevant technical changes between 26 and 28 ?
> >
> > See https://bugzilla.mozilla.org/show_bug.cgi?id=1446643#c4 in which EKR
> > suggests (IIUC) that there are no changes between 26 and 28.
>
> I meant, no technical changes for NSS are required between 26 and 28, if
> I understand EKR's comment correctly.
>
> Kai
>
> --
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: selfserv and tstclnt on SNI

[Martin Thomson]

These sound like simple bugs.  Most are probably good first bugs for
someone looking to contribute.

On Thu, Feb 8, 2018 at 6:13 PM, John Jiang  wrote:
> Hi,
> Using NSS 3.35.
>
> It looks tstclnt always send SNI extension, even though no option "-a".
> As for selfserv, I suppose it should have an option for configuring
> multiple certificates (nicknames) for server side. But I don't find it.
>
> In addition, option "-n" means rsa_nickname, but with my testing, it also
> works with the nicknames for DSA and ECDSA certificates, though such
> nicknames should use options -S and -e respectively.
> --
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: how do I test if NSS supports an algorithm at build time?

[Martin Thomson]

We do this probing in NSS because we can't guarantee that the softoken
implementation matches the libssl implementation version.  Yeah,
strange world we live in, right?

The probe is a little ugly, because there isn't a straight function
you can call that says "this algorithm is supported":

This is where we filter out algorithms that we don't like:
https://searchfox.org/nss/rev/aa30a457e9cf58909c44244fa37a0d234c2914cc/lib/ssl/sslgrp.c#76

If you trace this down, it basically ends up with the code that
creates a key pair in that group:
https://searchfox.org/nss/rev/aa30a457e9cf58909c44244fa37a0d234c2914cc/lib/ssl/ssl3ecc.c#439

As you say, conditioning on version is easy enough.

On Thu, Feb 8, 2018 at 4:13 AM, Andrew Cagney  wrote:
> On 7 February 2018 at 11:45, Andrew Cagney  wrote:
>> On 7 February 2018 at 10:41, Franziskus Kiefer  wrote:
>>> You should probably try to detect this at runtime.
>>> At compile time you can simply check if SEC_OID_CURVE25519 exists and fail
>>> (or do something else) if it doesn't.
>
> If SEC_OID_CURVE25519 was a #define then a build time test would be
> easy.  Alas, it's an enum.
> So without sucking in autoconf, is there some official proxy for this.
> If all else fails there should be a version number in the header.
>
>>> At runtime you could try using SEC_OID_CURVE25519 (with your own define to
>>> 355) and have a fallback if NSS gives you an error on using it.
>
> While NSS has what I'll loosely describe as its ABI guarantee and this
> magic should work.  I'd rather to not go there.
>
> I'm more comfortable with building against version X and only accept
> version >=X at runtime.
>
> Andrew
> --
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS: Unable to verify close_notify in client code?

[Martin Thomson]

See SSL_AlertReceivedCallback().

On 20 Dec. 2017 6:22 am, "Johann 'Myrkraverk' Oskarsson"
 wrote:

> Hi,
>
> Is it really impossible to verify if the server sent close_notify in a
> normal NSS client application?
>
> In both cases, PR_Read() returns zero with no error messages or status
> difference of any kind.
>
> I have tentatively verified that ssl3_HandleAlert() is called with
> AlertDescription zero == close_notify, using dtrace, when my server
> properly terminates the connection with PR_Close().  No such probe
> (in the client) fires if I just kill the server (naturally).
>
> My problem is that in the client code *I cannot distinguish the two*
> (with or without close_notify) in normal PR_Read() loop.  There appears
> to be no publicly available API to retrieve the status of the
> recvCloseNotify flag.
>
> And the ssl3_HandleAlert code does not propagate the condition, instead
> the internal error = SSL_ERROR_CLOSE_NOTIFY_ALERT variable is simply
> ignored, and it returns with SECSuccess.
>
> This is situation is current as of changeset 14194:04fc9a90997b,
> Mon Dec 18 11:05:28 2017 +0100.
>
> How is NSS client code supposed to detect proper termination by the
> other party?
>
> I would call this a serious breach of security in the NSS public API.
>
>
> --
> Johann | email: invalid -> com | www.myrkraverk.com/blog/
> I'm not from the Internet, I just work there. | twitter: @myrkraverk
> --
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Security implications for TLS validation post handshake

[Martin Thomson]

I think that Alex and Kurt partially answered your questions.

On Wed, Oct 18, 2017 at 8:27 PM, Gregory Szorc  wrote:
> I'm very naive about how TLS libraries are implemented and how the TLS
> handshake works.

The basic design is that the client decides what to offer and then the
server picks.  You can decide to offer fewer options, which risks the
server having no good option to choose from.   As you suggested, you
could let the server pick from a larger set and then decide
afterwards, but that's wasteful and probably unnecessary except for
version negotiation.

As Kurt points out, version negotiation works differently (except in
TLS 1.3, but if we could rely on that being available, we wouldn't be
having this discussion).  For versions you offer version X, which
implies support for all versions up to that value.  If the server
picks a value that is too low, you have to drop the connection
afterwards.  An API for that is now commonplace in TLS stacks, but it
might not be available to you.  Patching Python to use that API isn't
an insane path to choose, but I wouldn't depend on that.

The two things you need to think about are versions and ciphersuites.
You need to think about both unfortunately, because willingness to use
particular ciphersuites can lead to version downgrades.

> Question:
>
> Python exposes the negotiated TLS protocol version and cipher info post TLS
> handshake (results of OpenSSL's SSL_get_version() and
> SSL_get_current_cipher() functions). So it is possible to examine these
> values to determine whether to proceed with the connection. My question is:
> what are the dangers or concerns in doing so? I'm assuming there's a
> surface area of downgrade-type attacks in play. But I'm not sure the
> specifics.

If you have the option to use the OpenSSL APIs that Kurt was talking
about, that is ideal.  Tell the stack what you want and let it handle
things.

If you want to know what a "good" configuration looks like, starting
with something like what Firefox uses is fine, but we do a few
inadvisable things in the name of compatibility, so get someone who
knows the space to review the specifics of your plan.  (The only thing
I'm aware of is that we offer a 3DES suite, which you really don't
want.)

As for downgrade, if you have a policy and stick to it, downgrade
attacks are contained.  Rule of thumb: don't change your position
about anything, especially based on stuff that you get from the
network.  Again, ask for help here to be sure.

> If you aren't able to limit the advertisement of TLS 1.0 and 1.1 protocols
> from the client, is it safe to validate the TLS-level security from
> negotiated protocol and cipher info? Is the TLS protocol version itself
> sufficient or does it need to be supplemented with e.g. a "safe" list of
> ciphers?

You definitely need a policy for both versions and ciphers.  There are
also a bunch of other recommendations here:
https://tools.ietf.org/html/rfc7525, but you will want a translator
for that.

If the only API surface you have appears after the connection is
established, as long as you don't *use* the connection (or anything
you get from it) before checking that the result is OK, then you are
safe.  We do this for HTTP/2 in Firefox; you just have to be careful
not to accidentally use the connection.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: error: nss-softokn, ec.c, ECCurve25519 undeclared

[Martin Thomson]

This should be defined in ecl-exp.h, which is transitively included
from ec.c via blapi.h and blapit.h.

On Thu, Sep 28, 2017 at 10:10 AM, Captain Wiggum  wrote:
> I build nss and nss-softokn on a regular basis and follow periodic updates.
> I am seeing this new error with nss-softokn-3.28.3.tar.gz:
>
> ec.c:21:7: error: 'ECCurve25519' undeclared here (not in a function)
>  { ECCurve25519,
>
> Does this ring any bells? Or any suggestion appreciated.
> --
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

[ANNOUNCE] NSS 3.29.2 Release

[Martin Thomson]

The NSS team has released Network Security Services (NSS) 3.29.2

No new functionality is introduced in this release.
This is a patch release to fix an issue with TLS session tickets.

The full release notes are available at
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.29.2_release_notes

The HG tag is NSS_3_29_2_RTM. NSS 3.29.2 requires NSPR 4.13.1 or newer.

NSS 3.29.2 source distributions are available for secure download:
https://ftp.mozilla.org/pub/security/nss/releases/NSS_3_29_2_RTM/src/
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: xmlsec / ECDSA problem

[Martin Thomson]

On Sat, Feb 18, 2017 at 8:59 AM, Jeremy Rowley
 wrote:
> It's still permitted in the policy.
>
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs
> /policy/#inclusion

Yes, well...  The policy says P-512, which doesn't actually exist.
The intent is clear though.  I've asked Kathleen to correct that.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: xmlsec / ECDSA problem

[Martin Thomson]

On Thu, Feb 16, 2017 at 4:22 AM, Gervase Markham  wrote:
> Did things break when we disabled it?

A few things.  It lasted less than a day in Nightly before we got
multiple bug reports.

> Do we know why Chrome decided not to support it? Two NIST curves is enough?

That's my understanding.  P-521 isn't busted, it's just a little
inefficient and not enough stronger than P-384 (or X448) that it is
worth keeping around when faced with a working quantum computer.  That
and the fact that more options is more code to carry, more options to
signal, and so forth.  I think that's the reasoning.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: xmlsec / ECDSA problem

[Martin Thomson]

On Thu, Feb 16, 2017 at 3:44 AM, Gervase Markham  wrote:
> There seemed to be some confusion recently in m.d.s.policy about whether
> NSS, and then Firefox, supported P-521 for server auth certs. Can
> someeone clear it up for me and tell me what the situation is? :-)

Sure.  Both NSS and Firefox support P-521.  We still accept TLS
handshakes that use it (for both key exchange and signing).  I believe
that it is also supported in webcrypto.

I believe that Chrome doesn't support P-521 in TLS.  We tried to
follow them, but only briefly.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: xmlsec / ECDSA problem

[Martin Thomson]

On Wed, Feb 15, 2017 at 7:59 PM, Miklos Vajna  wrote:
> To avoid solving multiple problems at once, probably I'll go for an
> other ECDSA testcase first where the parameter is supported by NSS. :-)

The best supported curve is P-256 (i.e., secp256r1), but P-384
(secp384r1) and P-521 (secp521r1) are also well supported.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Can wrapped master secret be unwrapped only using fields from sslSessionID structure?

[Martin Thomson]

The details of how NSS constructs these values is internal to a given
NSS version and might change in different versions.  For instance, the
indices and what they mean are highly likely to change in an upcoming
version.

On Wed, Jan 25, 2017 at 4:11 AM, Maxim Rise  wrote:
> Hello.
>
> I am trying to write a python script for unwrapping wrapped_master_secret
> for a given wrapped_master_secret in the command line. Can
> wrapped_master_secret be unwrapped only using fields from sslSessionIDStr
> structure (masterModuleID, masterSlotID, masterWrapIndex, masterWrapMech,
> masterWrapSeries)? Can you point me in the right direction?
>
> PS: I am new in the NSS and PCKS11.
>
> Thank you! :)
> --
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Building NSS failed on Mac OS X 10.10 with "unknown warning group '-Wvarargs'"

[Martin Thomson]

Hi John,

Could you open a bug?
https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS=Libraries

On Thu, Dec 29, 2016 at 5:19 PM, John Jiang  wrote:
> Hi,
> I tried to build NSS 3.27.1 [1] on Mac OS X 10.10, but the building ended
> with the following message:
> ocsp.c:2200:32: error: unknown warning group '-Wvarargs', ignored
> [-Werror,-Wunknown-pragmas]
> #pragma GCC diagnostic ignored "-Wvarargs"
>^
> 1 error generated.
> make[2]: *** [Darwin14.1.0_64_OPT.OBJ/ocsp.o] Error 1
> make[1]: *** [libs] Error 2
> make: *** [libs] Error 2
>
> How to resolve this issue?
> Thanks!
>
> [1]
> https://ftp.mozilla.org/pub/security/nss/releases/NSS_3_27_1_RTM/src/nss-3.27.1-with-nspr-4.13.tar.gz
> --
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS and NSPR compilation error: ssl3con.c:36:18: fatal error: zlib.h: No such file

[Martin Thomson]

You can compile with

make nss_build_all NSS_SSL_ENABLE_ZLIB=

To disable zlib.  It's not a feature you want, we just keep it because
some existing users depend on it.

On Thu, Oct 20, 2016 at 11:10 PM, Kai Engert  wrote:
> On Thu, 2016-10-20 at 10:13 +, Ding Yangliang wrote:
>> ssl3con.c:36:18: fatal error: zlib.h: no such file or directory
>
> zlib.h is a file that should be provided by your development environment.
>
> I don't know what package on Ubuntu provides that file, but I'm guessing the
> name should be similar to zlib-dev.
>
> Kai
>
> --
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: How to get details of certificate?

[Martin Thomson]

On Sun, May 22, 2016 at 5:16 PM, RJT  wrote:
>  `certutil -L -d sql:${HOME}/.pki/nssdb`

That lists the names, then you can dump the details:
 `certutil -L -d sql:${HOME}/.pki/nssdb -n `
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: [ANNOUNCE] NSS 3.24 Release

[Martin Thomson]

On Mon, May 23, 2016 at 1:55 AM, Trick, Daniel
 wrote:
> make BUILD_OPT=1


Try: make BUILD_OPT=1 nss_build_all

You have to build NSPR first, and this does that for you.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Disabling all uses of elliptical curves

[Martin Thomson]

On Wed, May 11, 2016 at 11:08 PM, Hubert Kario  wrote:
> I haven't tested it, but I don't think that will stop NSS trusting RSA
> certificates signed by ECC CAs.

There are plenty of things that NSS will still do with ECC if you
disable ECC cipher suites.  That's for sure.  If you are scared of
ECC, then compile it out with NSS_DISABLE_ECC.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Cipher suits, signature algorithms, curves in Firefox

[Martin Thomson]

On Fri, May 6, 2016 at 10:12 AM, Peter Bowen  wrote:
> Is a reasonable path to implement
> https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-10 and
> treat ECDHE suites as being DHE using a Supported Group?  This would
> avoid new cipher suite IDs and accomplish the same result.

I'm implementing it now.  Not because we need it for TLS 1.2 (where
it's not clear that it is 100% safe), but because we need it for TLS
1.3.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Cipher suits, signature algorithms, curves in Firefox

[Martin Thomson]

On Fri, May 6, 2016 at 9:33 AM, Brian Smith  wrote:
> So, I don't think that dropping AES-256 is the right thing to do. Instead,
> the ECDHE-AES-256-GCM cipher suites should be added to Firefox. Note that
> they were just recently added to Google Chrome.

These are also coming to NSS, likely in 3.25 (Firefox 49 if everything
goes to plan).  Supporting different PRF hashes (we need SHA-384 for
those suites) turns out to be a little bit intrusive.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Disabling all uses of elliptical curves

[Martin Thomson]

At the TLS layer, you can disable all suites that require ECC.

On Sat, Apr 30, 2016 at 4:40 AM, Franziskus Kiefer  wrote:
> there's no runtime option but you can disable it at compile time with
> NSS_DISABLE_ECC, see [1]
>
> [1]
> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Reference/NSS_environment_variables
>
> On Fri, Apr 29, 2016 at 3:44 PM, jonetsu  wrote:
>
>> Hello,
>>
>> Is there a run-time option to disable all and every uses of elliptical
>> curves ?
>>
>> If not, is there a compile option ?
>>
>> Thanks.
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://mozilla.6506.n7.nabble.com/Disabling-all-uses-of-elliptical-curves-tp354147.html
>> Sent from the Mozilla - Cryptography mailing list archive at Nabble.com.
>> --
>> dev-tech-crypto mailing list
>> dev-tech-crypto@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-tech-crypto
>>
> --
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: server-side OCSP stapling

[Martin Thomson]

AIUI,  support for stapling in NSS is pretty primitive. You are expected to
make the OCSP query yourself and use the API to configure the server.
On Mar 2, 2016 7:42 AM, "Rob Crittenden"  wrote:

> I don't see a way to implement OCSP stapling on the server side.
>
> SSL_SetStapledOCSPResponses() is I think what one would use to set the
> response in the SSL session but I don't see a way to get the response
> from the OCSP handler. At least, I don't see a way without implementing
> my own status checker and overriding statusConfig->statusChecker ala
> CERT_EnableOCSPChecking().
>
> Am I missing something?
>
> thanks
>
> rob
> --
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: -Werror vs. NetBSD

[Martin Thomson]

Yes,  the landing of the first patches for TLS 1.3 was a bit messy.  We are
working on fixing these problems.  We do have a requirement for c99, which
might account for the //comments.  We are trying not to land any of those
though.
On Feb 4, 2016 8:27 PM, "Thomas Klausner" <t...@giga.or.at> wrote:

> Hi Martin!
>
> Thanks for the reply.
>
> Yes, of course I can file a bug report for that. I guess I should
> finish the patch first?
>
> For two days now, I see a different build failure though:
>
> gcc -o NetBSD7.99.26_64_OPT.OBJ/tls13hkdf.o -c -O -fPIC -DPIC  -ansi -Wall
> -Wno-switch -pipe -DNETBSD -Dunix -DHAVE_STRERROR -DHAVE_BSD_FLOCK -Wall
> -Werror -DXP_UNIX -UDEBUG -DNDEBUG -DUSE_UTIL_DIRECTLY -DNO_NSPR_10_SUPPORT
> -DSSL_DISABLE_DEPRECATED_CIPHER_SUITE_NAMES -DNSS_ENABLE_SSL_ZLIB
> -I/usr/pkg/include/nspr -I/usr/X11R6/include
> -I./../dist/NetBSD7.99.26_64_OPT.OBJ/include -I./../dist/public/
> -I./../dist/private/ -I/usr/X11R6/include
> -I../../dist/NetBSD7.99.26_64_OPT.OBJ/include -I../../dist/public/
> -I../../dist/private/ -I/usr/X11R6/include
> -I../../../dist/NetBSD7.99.26_64_OPT.OBJ/include -I../../../dist/public/nss
> -I../../../dist/private/nss  tls13hkdf.c
> tls13hkdf.c:15:1: error: expected identifier or '(' before '/' token
>  // TODO(e...@rtfm.com): Export this separately.
>  ^
> tls13hkdf.c:15:12: error: stray '@' in program
>  // TODO(e...@rtfm.com): Export this separately.
> ^
> tls13hkdf.c: In function 'tls13_HkdfExpandLabel':
> tls13hkdf.c:136:5: error: implicit declaration of function
> 'tls13_EncodeUintX' [-Werror=implicit-function-declaration]
>  ptr = tls13_EncodeUintX(keySize, 2, ptr);
>  ^
> tls13hkdf.c:136:9: error: assignment makes pointer from integer without a
> cast [-Werror]
>  ptr = tls13_EncodeUintX(keySize, 2, ptr);
>  ^
> tls13hkdf.c:137:9: error: assignment makes pointer from integer without a
> cast [-Werror]
>  ptr = tls13_EncodeUintX(labelLen + kLabelPrefixLen, 1, ptr);
>  ^
> tls13hkdf.c:142:9: error: assignment makes pointer from integer without a
> cast [-Werror]
>  ptr = tls13_EncodeUintX(handshakeHashLen, 1, ptr);
>  ^
> cc1: all warnings being treated as errors
>
>  Thomas
>
>
> On Mon, Feb 01, 2016 at 11:15:14AM +1100, Martin Thomson wrote:
> > Hi Thomas,
> >
> > Do you think that you could push these patches to bugzilla?  See
> >
> https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS=Libraries
> >
> > And it would be easier to review this as a single patch, I think,
> > since all the changes are fairly simple.
> >
> > On Sat, Jan 30, 2016 at 11:40 PM, Thomas Klausner <t...@giga.or.at> wrote:
> > > Hi!
> > >
> > > Recently nss turned on -Werror by default for all platforms. I think
> > > that's a good idea. However, it majorly broke the build on NetBSD with
> > > lots of these types of messages:
> > >
> > > certcgi.c: In function 'MakeNameConstraints':
> > > certcgi.c:1654:6: error: array subscript has type 'char'
> [-Werror=char-subscripts]
> > >
> > > The reason is that NetBSD is very picky about the use of the ctype
> > > functions. To cite the man page ctype(3):
> > >
> > > CAVEATS
> > >  The first argument of these functions is of type int, but only a
> very
> > >  restricted subset of values are actually valid.  The argument
> must either
> > >  be the value of the macro EOF (which has a negative value), or
> must be a
> > >  non-negative value within the range representable as unsigned
> char.
> > >  Passing invalid values leads to undefined behavior.
> > >
> > >  Values of type int that were returned by getc(3), fgetc(3), and
> similar
> > >  functions or macros are already in the correct range, and may be
> safely
> > >  passed to these ctype functions without any casts.
> > >
> > >  Values of type char or signed char must first be cast to unsigned
> char,
> > >  to ensure that the values are within the correct range.  Casting a
> > >  negative-valued char or signed char directly to int will produce a
> > >  negative-valued int, which will be outside the range of allowed
> values
> > >  (unless it happens to be equal to EOF, but even that would not
> give the
> > >  desired result).
> > >
> > >
> > > I've started fixing these, attached is a first batch of patches. More
> > > are needed, but I wanted to find out first how to make sure they get
> > > applied.
> > >
&

Re: -Werror vs. NetBSD

[Martin Thomson]

Hi Thomas,

Do you think that you could push these patches to bugzilla?  See
https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS=Libraries

And it would be easier to review this as a single patch, I think,
since all the changes are fairly simple.

On Sat, Jan 30, 2016 at 11:40 PM, Thomas Klausner  wrote:
> Hi!
>
> Recently nss turned on -Werror by default for all platforms. I think
> that's a good idea. However, it majorly broke the build on NetBSD with
> lots of these types of messages:
>
> certcgi.c: In function 'MakeNameConstraints':
> certcgi.c:1654:6: error: array subscript has type 'char' 
> [-Werror=char-subscripts]
>
> The reason is that NetBSD is very picky about the use of the ctype
> functions. To cite the man page ctype(3):
>
> CAVEATS
>  The first argument of these functions is of type int, but only a very
>  restricted subset of values are actually valid.  The argument must either
>  be the value of the macro EOF (which has a negative value), or must be a
>  non-negative value within the range representable as unsigned char.
>  Passing invalid values leads to undefined behavior.
>
>  Values of type int that were returned by getc(3), fgetc(3), and similar
>  functions or macros are already in the correct range, and may be safely
>  passed to these ctype functions without any casts.
>
>  Values of type char or signed char must first be cast to unsigned char,
>  to ensure that the values are within the correct range.  Casting a
>  negative-valued char or signed char directly to int will produce a
>  negative-valued int, which will be outside the range of allowed values
>  (unless it happens to be equal to EOF, but even that would not give the
>  desired result).
>
>
> I've started fixing these, attached is a first batch of patches. More
> are needed, but I wanted to find out first how to make sure they get
> applied.
>
> I'll also attach two patches for the included zlib. It doesn't compile
> because of missing prototypes for read/write/close, so I added an
> #include  in two places.
>
> Thanks,
>  Thomas
>
> --
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto