[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: race bug !?

From: Chet Ramey
Subject: Re: race bug !?
Date: Fri, 29 Jan 2021 08:50:06 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.1

On 1/28/21 6:33 PM, Jean-Jacques Brucker wrote:

100 % reproducible on my Debian, package version 5.1-2:

$ echo "dc30a6d79f3b47e310b8b9f5fbadba57" | tee >( xxd  -r -p | base64) | tee >(xxd  -r -p | basenc --base64url )

Without looking at this too closely, this is always going to be somewhat
`racy', for two reasons. First, the process substitutions are executed
asynchronously, so their execution is non-deterministic. Second, the word
expansions in pipelines happen after the shell forks, and after piping is
done, so the standard output of the process substitution is the same as
the standard output of its parent: the pipe.

You can see this by using `wc' to count the lines the second pipeline element receives:

$ echo "dc30a6d79f3b47e310b8b9f5fbadba57" | tee >( xxd  -r -p | base64 ) | wc
       2       2      58

I first thought I missed something about base64url encoding, after hours or digging and digging documentation I tried :

$ echo "dc30a6d79f3b47e310b8b9f5fbadba57" | xxd  -r -p | basenc --base64url

Those 4 extra characters "z0Vh" are quite disturbing :-/

You're not encoding the same data. You've got the original string you
echoed plus the output of the first encoding process substitution.

``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]