| Age | Commit message (Collapse) | Author |
|---|
|
|
|
(Note that this is not believed to work, but we may as well have it
in the right place till we remove it)
|
|
Inline its contents (which were all includes) into or.h, and some of
its contents into other places that didn't include or.h at all.
|
|
This is temporary, until src/or is split.
Putting this in containers would be another logical alternative,
except that addresses depend on containers, and we don't like
cycles.
|
|
There might be a better place for it in the long run, but this is
the best I can think of for now.
|
|
There might be a better place for it in the long run, but this is
the best we 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.
|
|
|
|
(Term is short for terminal)
|
|
Split the network-only and compression-only parts of buffers into
the appropriate modules.
|
|
|
|
Note that procmon does *not* go here, since procmon needs to
integrate with the event loop.
|
|
|
|
|
|
Note that the workqueue code does *not* go here: it is logically at
a higher level, since it needs to use libevent and the networking
stack.
|
|
Also, move "unescape_string()" to encoding too, since it's about
encoding data as C strings.
|
|
The "conffile" module knows about includes and filesystem access,
whereas confline doesn't. This will make it possible to put these
functions into libraries without introducing a cycle.
|
|
libtor-encoding is about various ways to transform data to and from
character sequences.
|
|
|
|
There are some additional changes to come: those points are marked
by XXXX.
|
|
|
|
The locking code gets its own module, since it's more fundamental
than the higher-level locking code.
Extracting the logging code was the whole point here. :)
|
|
|
|
|
|
|
|
I am calling the crypto library "crypt_ops", since I want
higher-level crypto things to be separated from lower-level ones.
This library will hold only the low-level ones, once we have it
refactored.
|
|
This one has no generated code.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Previously we had code like this for bad things happening from
signal handlers, but it makes sense to use the same logic to handle
cases when something is happening at a level too low for log.c to be
involved.
My raw_assert*() stuff now uses this code.
|
|
We had accumulated a bunch of cruft here. Now let's only include
src and src/ext. (exception: src/trunnel is autogenerated code, and
need to include src/trunnel.)
This commit will break the build hard. The next commit will fix it.
|
|
|
|
|
|
Add two new files (crypto_hkdf.c, crypto_hkdf.h) as new module of crypto.[ch].
This new module includes all functions and dependencies related to HKDF
operations. Those have been removed from crypto.[ch].
Follows #24658.
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
|
|
Included crypto_dh.h in some files in order to solve DH module dependency
issues.
Follows #24658.
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
|
|
|
|
This differs from our previous token bucket abstraction in a few
ways:
1) It is an abstraction, and not a collection of fields.
2) It is meant to be used with monotonic timestamps, which should
produce better results than calling gettimeofday over and over.
|
|
* FIXES part of #24658: https://bugs.torproject.org/24658
|
|
* 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
|
|
|
|
|
|
We're going to need this to make our anti-DoS code (see 24902) more
robust.
|
|
Included crypto_digest.[ch] into include.am in order to solve a compiling
issue. Also EOF line in crypto_digest.c added.
Follows #24658.
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
|
|
Included crypto_rsa.[ch] into include.am in order to resolve a compiling issue.
Follows #24658.
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
|
|
|
