Re: Welcome to the "dev-security" mailing list
On Tuesday, 18 August 2020 05:57:19 CEST, Ragavendhiran Bhiman (rabhiman) via dev-security wrote: Hi, I am facing problems in NSS library libnsssoftkn package. Where can I report my problems on memory leak? Is it the right forum to post my query? https://bugzilla.mozilla.org/ Product: nss -> Libraries Thanks a lot. Regards, Raghavendran On 18/08/20, 9:24 AM, "dev-security on behalf of dev-security-requ...@lists.mozilla.org" dev-security-requ...@lists.mozilla.org> wrote: Welcome to the dev-security@lists.mozilla.org mailing list! To post to this list, send your message to: dev-security@lists.mozilla.org General information about the mailing list is at: https://lists.mozilla.org/listinfo/dev-security If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: https://lists.mozilla.org/options/dev-security/rabhiman%40cisco.com You can also make such adjustments via email by sending a message to: dev-security-requ...@lists.mozilla.org with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe without confirmation. It is: raghav1## Mailman can remind you of your lists.mozilla.org mailing list passwords once every month, although since most people don't like having their passwords mailed in the clear, this is disabled by default. If you prefer, you can enable this in your account options. There is a button on your options page that will email your current password to you. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: What are CERTDB_INVISIBLE_CA and CERTDB_GOVT_APPROVED_CA used for?
On Friday, 7 December 2018 23:26:32 CET Eli the Bearded wrote: > In mozilla.dev.security, Jeremy Rand wrote: > > I was digging through the NSS source code, and I ran across two > > undocumented trust flags: CERTDB_INVISIBLE_CA and CERTDB_GOVT_APPROVED_CA > > . > > > > As far as I can tell, CERTDB_INVISIBLE_CA seems to indicate that the UI > > should hide the existence of the CA from the user, while > > CERTDB_GOVT_APPROVED_CA seems to have something to do with crypto export > > regulations. I'm wondering if anyone can explain what exactly the > > intended purpose of these flags is, and whether they actually have any > > effect in any of the NSS software ecosystem (including Firefox, but also > > including the NSS certificate verifier, any of the various NSS tools > > distributed by Mozilla, and anything else that uses NSS that you're > > aware of). I can't think of any reason for CERTDB_INVISIBLE_CA to exist > > (other than making it easier for backdoors to be stealthily inserted, > > which I assume isn't the intended use case), and I'm also surprised that > > CERTDB_GOVT_APPROVED_CA is a thing in 2018 since (as far as I know) > > crypto export regulations haven't existed for a couple of decades. > > This four year old bug report claims they are not used anymore: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1045907 > > Comment 4 (in part): > > However, note line 1670. CERTDB_PRESERVE_TRUST_BITS is > > (CERTDB_USER | CERTDB_NS_TRUSTED_CA | > > CERTDB_VALID_CA | CERTDB_INVISIBLE_CA | CERTDB_GOVT_APPROVED_CA). > > So these don't have mappings through the PKCS #11 trust interface. > CERTDB_USER is set based on finding the associated private key. > CERTDB_GOVT_APPROVED_CA is set based on a different PKCS #11 > attribute. It's no longer used by NSS. > CERTDB_NS_TRUSTED_CA isn't used either. > > I'm not sure if CERTDB_VALID_CA or CERTDB_INVISIBLE_CA are even > stored anymore. I know NSS doesn't actually use them. > > Not sure if that's the reassurance you want. > > Elijah > -- > agrees that CERTDB_INVISIBLE_CA seems a dangerous thing yes, *if* it worked as its name suggests but NSS prises itself also on backwards compatibility, that unfortunately means that some identifiers that are no longer used need to be defined still as far as I can tell the MZBZ#1045907 is correct; while you can specify both the 'g' flag (to specify Government Approved CA) or 'i' (to supposedly make it invisible) in certutil trust flags, none of them have any effect - the CA remains visible and the 'G' flag is not reported I didn't find any other references to that constant: https://searchfox.org/nss/search?q=CERTDB_INVISIBLE_CA that would indicate special handling -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: nss build question:how to set CFLAGS and LDFLAGS
On Wednesday, 16 May 2018 15:05:21 CEST chenchao...@gmail.com wrote: > NSS-3.33 > > I wanted to get code coverage of nss(mainly certutil).So I tried to add > '-fprofile-arcs -ftest-coverage' to CFLAGS in command.mk. While it failed, > it seems it's because compiling and linking are separate. '-fprofile-arcs > -ftest-coverage' also need to be added to LDFLAGS,while I didn't find it. > > Can you tell me how to configure Makefile or others to get code coverage, or > is there any convenient way to set CFLAGS CXXFLAGS and LDFLAGS, just like > './configure CFLAGS=...' I believe that compiling the library with USE_GCOV=1 environment variable set should be enough. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Disable certain ciphers and hashing algorithms while building FF and TB
On Tuesday, 13 March 2018 11:15:18 CEST f masood via dev-security wrote: > On Tuesday, January 23, 2018 at 9:39:46 AM UTC+5, f masood wrote: > > 1 I am building Mozilla Firefox and Mozilla Thunderbird 52 versions from > > source code. > > > > 2 By default all the ciphers and hashing algorithms are enabled while > > building those two applications. > > > > 3 How can I disable certain ciphers and hashing algos while building these > > two applications ? Can I specify in the CONF file or something ? > > > > 4 e.g I want to disable ALL other ciphers just one AES to be enabled > > I want to disable ALL other hashing algorithms just one SHA256 to be > > enabled > > > > (I know the above can have issues while communicating with major > > websites/email server) > PING !!! not when building, but you can do it at runtime using the policy mechanism used by Fedora: https://fedoraproject.org/wiki/Changes/StrongCryptoSettings https://fedoraproject.org/wiki/Changes/CryptoPolicy -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
