[tor-commits] [torspec] branch main updated: State that "base32" always means RFC4648, unpadded.

[gitolite role]

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 at chiark.greenend.org.uk>
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.