[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-commits] [torspec] branch main updated: State that "base32" always means RFC4648, unpadded.
This is an automated email from the git hooks/post-receive script.
nickm pushed a commit to branch main
in repository torspec.
The following commit(s) were added to refs/heads/main by this push:
new 9dee2f8 State that "base32" always means RFC4648, unpadded.
new 71ed0ed Merge remote-tracking branch 'tor-gitlab/mr/119'
9dee2f8 is described below
commit 9dee2f8efac9a03b1b1f64345c0faa0740c5a48c
Author: Ian Jackson <ijackson@xxxxxxxxxxxxxxxxxxxxxx>
AuthorDate: Tue Mar 7 13:20:13 2023 +0000
State that "base32" always means RFC4648, unpadded.
I found src/lib/encoding/binascii.[ch] in the C Tor codebase.
It has
#define BASE32_CHARS "abcdefghijklmnopqrstuvwxyz234567"
The function "base32_encode" says "Implements base32 encoding as in
RFC 4648.". Now, that RFC says that it's supposed to be padded unless
explicitly stated otherwise. However, the padding is pointless and
neither our "base32_encode" nor our "base32_decode" seem to implemnet
it.
I hope that we are using the same base32 encoding everywhere, but have
not checked.
---
tor-spec.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tor-spec.txt b/tor-spec.txt
index 69ed12e..34a3b44 100644
--- a/tor-spec.txt
+++ b/tor-spec.txt
@@ -109,6 +109,8 @@ see tor-design.pdf.
We use "byte" and "octet" interchangeably. Possibly we shouldn't.
+ Some specs mention "base32". This means RFC4648, without "=" padding.
+
0.1.1. Encoding integers
Unless we explicitly say otherwise below, all numeric values in the
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits