| Age | Commit message (Collapse) | Author |
|---|
|
Fun fact: these files used to be called log.[ch] until we ran into
conflicts with systems having a log.h file. But now that we always
include "lib/log/log.h", we should be fine.
|
|
|
|
This function has a nasty API, since whether or not it invokes the
resolver depends on whether one of its arguments is NULL. That's a
good way for accidents to happen.
This patch incidentally makes tor-resolve support socks hosts on
IPv6.
|
|
These are now combined into an inaddr.[ch], since their purpose is
to implement functions for struct in_addr and struct in6_addr.
The definitions for in6_addr and its allies are now in a separate
header, inaddr_st.h.
Closes ticket 26532.
|
|
|
|
I am very glad to have written this script.
|
|
There might be a better place for it in the long run, but this is
the best I can think of for now.
|
|
|
|
|
|
I'm not sure of the best place to put this header long-term, since
both or/*.c and tools/tor-resolve.c use it.
|
|
These had become wrappers around their fd and socket variants; there
were only a few users of the original functions still remaining.
|
|
libtor-encoding is about various ways to transform data to and from
character sequences.
|
|
|
|
|
|
This function has been present since Windows XP.
|
|
|
|
|
|
This change makes it possible for us to change the list of libraries
more easily, without changing every single linker line.
|
|
Nothing in Tor has actually called assert() for some while.
|
|
|
|
|
|
crypto_log_errors() has been moved to crypto_util.[ch]. It was duplicated in
some files so they have been removed too.
Follows #24658.
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
|
|
|
|
We removed this file, but didn't take it out of EXTRA_DIST -- thus
breaking "make dist".
|
|
* ADD new /src/common/crypto_rand.[ch] module.
* ADD new /src/common/crypto_util.[ch] module (contains the memwipe()
function, since all crypto_* modules need this).
* FIXES part of #24658: https://bugs.torproject.org/24658
|
|
Signed-off-by: Isis Lovecruft <isis@torproject.org>
|
|
|
|
Folks have found two in the past week or so; we may as well fix the
others.
Found with:
\#!/usr/bin/python3
import re
def findMulti(fname):
includes = set()
with open(fname) as f:
for line in f:
m = re.match(r'^\s*#\s*include\s+["<](\S+)[>"]', line)
if m:
inc = m.group(1)
if inc in includes:
print("{}: {}".format(fname, inc))
includes.add(m.group(1))
import sys
for fname in sys.argv[1:]:
findMulti(fname)
|
|
Included crypto_digest.h in some files in order to solve xof+digest module
dependency issues. Removed crypto.h where it isn't needed anymore.
Follows #24658.
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
|
|
Also, rename the variable to have a more manageable name, and make
its scope more clear.
Fixes bug 24582; bugfix on 0.2.1.1-alpha.
|
|
|
|
|
|
|
|
This was introduced in 4ff170d7b1cbe4074cb852, and is probably
unreachable, but coverity complained about it (CID 1417761). Bug not
in any released Tor, so no changes file.
|
|
Most of these buffers were never actually inspected, but it's still
bad style.
|
|
- make tor_util static library name configurable
- fix Rust libary dependency order for Windows
|
|
Introduce a way to optionally enable Rust integration for our builds. No
actual Rust code is added yet and specifying the flag has no effect
other than failing the build if rustc and cargo are unavailable.
|
|
CVE-2008-0166 is long gone, and we no longer need a helper tool to
dump out public key moduli so folks can detect it.
Closes ticket 21842.
|
|
|
|
If a hostname is supplied to tor-resolve which is too long, it will be
silently truncated, resulting in a different hostname lookup:
$ tor-resolve $(python -c 'print("google.com" + "m" * 256)')
If tor-resolve uses SOCKS5, the length is stored in an unsigned char,
which overflows in this case and leads to the hostname "google.com".
As this one is a valid hostname, it returns an address instead of giving
an error due to the invalid supplied hostname.
|
|
They broke stem, and breaking application compatibility is usually a
bad idea.
This reverts commit 6e10130e18c80f4521e31b071455ae0b1bbea761,
commit 78a13df15842e8ab262e17825160386fadb77056, and
commit 62f52a888acc191bcb507d27d31d54e42e6effdd.
We might re-apply this later, if all the downstream tools can handle
it, and it turns out to be useful for some reason.
|
|
|
|
|
|
|
|
In our code to write public keys to a string, for some unfathomable
reason since 253f0f160e1185c, we would allocate a memory BIO, then
set the NOCLOSE flag on it, extract its memory buffer, and free it.
Then a little while later we'd free the memory buffer with
BUF_MEM_free().
As of openssl 1.1 this doesn't work any more, since there is now a
BIO_BUF_MEM structure that wraps the BUF_MEM structure. This
BIO_BUF_MEM doesn't get freed in our code.
So, we had a memory leak!
Is this an openssl bug? Maybe. But our code was already pretty
silly. Why mess around with the NOCLOSE flag here when we can just
keep the BIO object around until we don't need the buffer any more?
Fixes bug 20553; bugfix on 0.0.2pre8
|
|
|
|
The previous version of the new accessors didn't specify const but it
was changed in master.
|
|
|
|
|
|
|
