| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Based on David's review.
|
|
|
|
|
|
Closes ticket 32137.
|
|
|
|
This frees us from a dependency on include order.
|
|
|
|
Using a standard ending here will let other tools that expect
markdown understand our output here.
This commit was automatically generated with:
for fn in $(find src -name '*.dox'); do \
git mv "$fn" "${fn%.dox}.md"; \
done
|
|
This is an automatically generated commit, made with:
find src -name '*.dox' | \
xargs perl -i -ne 'print unless (m#^\s*/?\*\*/?\s*$#);'
|
|
|
|
This commit was automatically generated with:
find src -name '*.dox' |xargs perl -i -pe 's{\@dir ([^/])}{\@dir /$1};'
|
|
This includes app, core, feature, lib, and tools, but excludes
ext, test, and trunnel.
This was generated by the following shell script:
cd src
for dname in $(find lib core feature app tools -type d |grep -v \\.deps$); do
keyword="$(echo "$dname" |sed -e "s/\//_/" )"
target="${dname}/${keyword}.dox"
echo "$target"
cat <<EOF >"$target"
/**
@dir ${dname}
@brief ${dname}
**/
EOF
git add "$target"
done
|
|
If a file doesn't use the file command (either \file or @file),
Doxygen won't try to process it.
|
|
A .may_includes file can be "advisory", which means that some
violations of the rules are expected. We will track these
violations with practracker, not as automatic errors.
|
|
|
|
Turns out that we were only recording the "b_digest" but to have
bidirectionnal authenticated SENDMEs, we need to use the "f_digest" in the
forward cell situation.
Because of the cpath refactoring, this commit plays with the crypt_path_ and
relay_crypto_t API a little bit in order to respect the abstractions.
Previously, we would record the cell digest as the SENDME digest in the
decrypt cell function but to avoid code duplication (both directions needs to
record), we now do that right after iff the cell is recognized (at the edge).
It is now done in circuit_receive_relay_cell() instead.
We now also record the cell digest as the SENDME digest in both relay cell
encryption functions since they are split depending on the direction.
relay_encrypt_cell_outbound() and relay_encrypt_cell_inbound() need to
consider recording the cell digest depending on their direction (f vs b
digest).
Fixes #30428
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
Create some functions to eventually be able to hide crypt_path_t.crypto.
|
|
As per review from nickm, keep as much as we can the relay_crypto_t object
opaque.
Part of #26288
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
From nickm's review, improve the names of some functions.
Part of #26288
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Because this function is poking within the relay_crypto_t object, move the
function to the module so we can keep it opaque as much as possible.
Part of #26288
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
This way, we reduce the load by only hashing when we absolutely must.
Part of #26288
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
The digest object is as large as the entire internal digest object's state,
which is often much larger than the actual set of bytes you're transmitting.
This commit makes it that we keep the digest itself which is 20 bytes.
Part of #26288
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
In order to do so, depending on where the cell is going, we'll keep the last
cell digest that is either received inbound or sent outbound.
Then it can be used for validation.
Part of #26288
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
|
|
The parts for handling cell formats should be in src/core/or.
The parts for handling onionskin queues should be in src/core/or.
Only the crypto wrapper belongs in src/core/crypto.
|
|
|
|
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.
|
|
I am very glad to have written this script.
|
|
This commit won't build yet -- it just puts everything in a slightly
more logical place.
The reasoning here is that "src/core" will hold the stuff that every (or
nearly every) tor instance will need in order to do onion routing.
Other features (including some necessary ones) will live in
"src/feature". The "src/app" directory will hold the stuff needed
to have Tor be an application you can actually run.
This commit DOES NOT refactor the former contents of src/or into a
logical set of acyclic libraries, or change any code at all. That
will have to come in the future.
We will continue to move things around and split them in the future,
but I hope this lays a reasonable groundwork for doing so.
|
