[tbb-bugs] #23442 [Applications/Tor Browser]: Error building firefox for Windows 64 in security/pkix/lib/pkixnames.cpp

Tor Bug Tracker & Wiki blackhole at torproject.org
Sat Nov 18 18:59:34 UTC 2017

#23442: Error building firefox for Windows 64 in security/pkix/lib/pkixnames.cpp
 Reporter:  boklm                     |          Owner:  tbb-team
     Type:  task                      |         Status:  closed
 Priority:  Medium                    |      Milestone:
Component:  Applications/Tor Browser  |        Version:
 Severity:  Normal                    |     Resolution:  fixed
 Keywords:  TorBrowserTeam201710R     |  Actual Points:
Parent ID:                            |         Points:
 Reviewer:                            |        Sponsor:

Comment (by cypherpunks):

 Replying to [comment:8 tom]:
 > Replying to [comment:4 cypherpunks]:
 > > Replying to [comment:3 boklm]:
 > > > Adding an `#include <cstring>` to `pkixnames.cpp` is fixing the
 build issue:
 > > > https://gitweb.torproject.org/user/boklm/tor-browser-
 > > Not fixing. It's not even a workaround.
 > > "The proper fix needs to be consistent with the fix for bug 1189891:
 change the code to use std::equals and similar instead of mem*, and remove
 all #include <cstring>." Because of
 https://bugzilla.mozilla.org/show_bug.cgi?id=1189891#c0 and other funny
 > > > But maybe it can be fixed in the same way as
 > > It should have been fixed there "for memcmp/memmove/memset functions".
 > > Also 2 occurrences of `memcpy` in https://dxr.mozilla.org/mozilla-
 should be fixed in the same way.
 > > > However I'm wondering why we don't have the same issue for x86
 > > A lot of reasons why mem* were declared there, but all of them were
 > I spoke with Keeler about this. From his recollection there were no
 security concerns with the changes, it was just toolchain weirdness. He
 guesses that it was mostly a coincidence that we had to make those changes
 in security/pkix but not security/manager.
 > If there's no build that failing with it now he doesn't see a strong
 reason to move to std::copy, etc., but he is very concern about our cert
 verifier failing, and asked if they have testcases or steps to reproduce.
 That's why I asked you to talk to a person with enough competence. There's
 no coincidence in this case. Did you show him a citation from my comment?
 It's from https://bugzilla.mozilla.org/show_bug.cgi?id=1199624#c1 by Brian
 Smith. And if you "remove all #include <cstring>" from
 first, then you "see a strong reason to move to std::copy, etc." So, now
 it's easier to fix this bug instead of doing useless testing. Thanks.

Ticket URL: <https://trac.torproject.org/projects/tor/ticket/23442#comment:10>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

More information about the tbb-bugs mailing list