From LibreSSL versions 3.2.1 through 3.4.0, our configure script
would conclude that TLSv1.3 as supported, but it actually wasn't.
This led to annoying breakage like #40128 and #40445.
Now we give an error message if we try to build with one of those
versions.
Closes#40511.
Previously the logic was reversed, and always gave the wrong answer.
This has no other effect than to change whether we suppress
deprecated API warnings.
Fixes#40429; bugfix on 0.3.5.13.
Mingw headers sometimes like to define alternative scanf/printf
format attributes depending on whether they're using clang, UCRT,
MINGW_ANSI_STDIO, or the microsoft version of printf/scanf. This
change attempts to use the right one on the given platform.
This is an attempt to fix part of #40355.
Continue having a tor_gmtime_impl() unit test so that we can detect
any problems in our replacement function; add a new test function to
make sure that gmtime<->timegm are a round-trip on now-ish times.
This is a fix for bug #40383, wherein we ran into trouble because
tor_timegm() does not believe that time_t should include a count of
leap seconds, but FreeBSD's gmtime believes that it should. This
disagreement meant that for a certain amount of time each day,
instead of calculating the most recent midnight, our voting-schedule
functions would calculate the second-most-recent midnight, and lead
to an assertion failure.
I am calling this a bugfix on 0.2.0.3-alpha when we first started
calculating our voting schedule in this way.
In versions <=2.69, according to the autoconf docs, AC_PROG_CC_C99
is needed with some compilers, if they require extra arguments to
build C99 programs. In versions >=2.70, AC_PROG_CC checks for these
compilers automatically, and so the AC_PROG_CC_C99 macro is
obsolete.
So, what can you do if you want your script to work right with both
autoconf versions? IIUC, neither including AC_PROG_CC_C99 macro nor
leaving it out will give you the right behavior with both versions.
It looks like you need to look at the autoconf version explicitly.
(Now, the autoconf manual implies that it's "against autoconf
philosophy" to look at the autoconf version rather than trying the
behavior to see if it works, but they don't actually tell you how to
detect recoverably at autoconf-time whether a macro is obsolete or
not, and I can't find a way to do that.)
So, is it safe to use m4_version_prereq, like I do here? It isn't
listed in the autoconf 2.63 manual (which is the oldest version we
support). But a mailing list message [1] (which added the
documentation back in 2008) implies that m4_version_prereq has been
there since "at least back to autoconf 2.59".
https://lists.gnu.org/archive/html/autoconf-patches/2008-12/msg00025.html
So I think this will work.
I am basing this patch against Tor 0.3.5 since, if autoconf 2.70
becomes widespread before 0.3.5 is unsupported, we might need this
patch to continue 0.3.5 development. But I don't think we should
backport farther than 0.4.5 until/unless that actually happens.
This is part of a fix for #40355.
This is currently for the dircache module that can not be disabled by itself,
it is only disabled from the relay module.
Thus, we should not print in the configure summary the disable option.
Signed-off-by: David Goulet <dgoulet@torproject.org>
From c618c4f279, we changed the static
libevent.a path to be able to use the git repository or tarball directly but
that broke the "make install" setup that Tor Browser is using with Android.
In other words, the git repository and tarball put the "libevent.a" in
".libs/" where "make install" puts it in "lib/".
Using the --with-libevent-dir=..., which is mandatory for static libevent,
autoconf will take the path and use it for the includes (-I) and library (-L)
for which if it finds a "include/" and a "lib/" in the root, it will use
those.
However, with the git repo or tarball, the "lib/" doesn't exists thus autoconf
sets the library search path to be at the root and thus fails to find the
libevent.a in ".libs/".
This is a whole lot more work to make both cases work in our configure.ac thus
I'm reverting the change here to the Tor Browser case works again and the work
around for others is to either symlink the libevent.a at the root or use a
temporary make install directory.
One long term fix here would likely be to ask libevent to symblink the .a into
the root along the .la files and likely do the same for .so. Or, use the
"lib/" structure to contain the .a + .so files. Would be better than doing
ninji-tsu in our configure.ac
Fixes#40225
Signed-off-by: David Goulet <dgoulet@torproject.org>
The "-static" compile flag was set globally which means that all autoconf test
were attempting to be built statically and lead to failures of detecting
OpenSSL libraries and others.
This commit adds this flag only to the "tor" binary build.
There is also a fix on where to find libevent.a since it is using libtool, it
is in .libs/.
At this commit, there are still warnings being emitted that informs the user
that the built binary must still be linked dynamically with glibc.
Fixes#40111
Signed-off-by: David Goulet <dgoulet@torproject.org>
This changes the behaviour of `tor --version` in such a way.
```console
src/app/tor --version
Tor version 0.4.5.1-alpha-dev (git-46ccde66a97d7985).
Tor is running on Linux with Libevent 2.1.12-stable, OpenSSL 1.1.1h, Zlib 1.2.11, Liblzma 5.2.4, Libzstd 1.4.5 and Glibc 2.31 as libc.
Tor compiled with GCC version 10.2.0
```
Fixes#32102
