Tuesday, July 28, 2009

Politics as Usual

Everyone has their own perspective on the world and their own circumstances influencing their beliefs. What seems right and just to me can seem horrible and unfair to someone else. The founding fathers of the United States of America recognized this truth; in Federalist #10, James Madison wrote that the various competing regional, religious, and economic interests, factions, and parties would be the guarantor of American freedom and justice.

Everyone in America is entitled to their own opinion, representing their own interests. People can try to drum up support for their own ideas by sharing them with others and these ideas compete for mind share with the ideas of others among the American populace.

This is how politics in America works; it is like capitalism applied to the ephemeral world of ideas. And just like capitalism in the market, it should not be surprising that purveyors of ideas often have their own profit motives.

I suppose that statement is somewhat redundant because I believe, to most, the word "politics" is assumed to be the marketing of ideas with underlying profit motives. In which case, to be American is to be constantly embroiled in politics -- to be constantly inundated with ideas, sometimes of dubious motive.

Which is why it is imperative that we each form our own ideas, reflecting our own self-interests. I would dare say that each and every American has their own circumstances, their own obstacles, their own concerns, as well as their own hopes and dreams. And sometimes people's interests conflict.

So ask yourself: if you could change America in a way that would make your life better, what would you do? If you could improve absolutely anything, what would you do? How would you convince others to help you out? If people don't support your idea, what would you do?

Now ask yourself: what are others doing to try to influence you?

Monday, July 27, 2009

Subtle error in RFC 3665 "SIP Basic Call Flow Examples"

RFC 3665 is simply a collection of SIP call flow examples for reference to implementers. However, I noticed what appears to be a small error in section 3.2 "Session Establishment Through Two Proxies" with the digest values.

In step F2 "407 Proxy Authorization Required Proxy 1 -> Alice", the proxy responds with a Proxy-Authenticate header containing the nonce value "f84f1cec41e6cbe5aea9c8e88d359". However, in F4 "INVITE Alice -> Proxy 1", where the user agent should send back the same nonce value to the proxy server along with the calculated digest, it instead sends the nonce "wf84f1ceczx41ae6cbe5aea9c8e88d359". Clearly, this is a typographical error as the nonces are identical except for the leading "w".

A cursory scan of the rest of the examples in RFC 3665 did not turn up any more mismatched nonce values. The "wf84f1ceczx41ae6cbe5aea9c8e88d359" value appears in other call sequences involving proxy authentication while the "f84f1cec41e6cbe5aea9c8e88d359" value never appears again, implying the nonce value with the "w" character prefixed should be the "correct" value.

Interestingly, while the other nonce values used in examples appear to be 32-character hexadecimal representations of 128-bit values, the "wf84f1ceczx41ae6cbe5aea9c8e88d359" value does not fit this pattern as it is both 33-characters long and "w" is not a valid hexadecimal digit. Which leads me to believe that the "f84f1cec41e6cbe5aea9c8e88d359" value is actually the correct nonce value in the "407 Proxy Authorization Required Proxy 1 -> Alice" call flow and that the other instances where the "w"-prefixed value appears are just the same typographical error replicated via copy-and-paste.

What I don't know, and would be interested in finding out, is whether the calculated digest result value examples were calculated with the "f84f1cec41e6cbe5aea9c8e88d359" nonce or with the "w"-prefixed version. Unfortunately, the RFC does not tell us what password values they used to calculate the digests, so I cannot answer that question myself.

Calculating MD5 of binaries without debug symbols

If you compile a binary with gcc with debugging information enabled (-g), the MD5 of the resulting binary will change depending on the name of the directory you compile it in. Which means that if two developers compile the same source code with the same options on the same machine, only they do it in their own home directories, the MD5 of the resulting binaries may differ.

However, as soon as you strip the binaries, their MD5s will be the same.

Which leads me to this little tool I whipped up to compare two binaries without stripping them:

#!/bin/sh
# Display the MD5 of a file, ignoring any debugging symbols in
# binaries.

# The strip(1)/objdump(1) commands for removing debugging
# symbols do not support writing to stdout so we need to
# allocate a temp file to write the stripped binary too.
tempfoo=`basename $0`
TMPFILE=`mktemp -q /tmp/${tempfoo}.XXXXXX`
if [ $? -ne 0 ]; then
echo "$0: Can't create temp file, exiting..."
exit 1
fi

while [ "$1" != "" ]; do
# The following line is a cheezy way to accurately
# reproduce the same error messages as md5(1) when a
# specified file is unreadable.
md5 "$1" > /dev/null
if [ $? -eq 0 ]; then

# Try to strip symbols from the file on the
# assumption it is a binary and, if successful,
# compute the md5 of the stripped file. Note that
# objcopy is the same as the strip(1) command. If
# objcopy failed to parse the file (i.e. because it
# is not in ELF format), simply compute the md5 of
# the whole file since there are no debugging symbols
# to strip.
m=`(objcopy -g "$1" $TMPFILE >/dev/null 2>&1 && \
md5 -q $TMPFILE;) || md5 -q "$1"`

# Output the result in a md5(1)-compatible format.
echo "MD5($1) = $m"
fi
shift
done

rm $TMPFILE

Thursday, July 2, 2009

su Forces Terminal Echo to On

I just discovered an interesting quirk of the su command, at least on FreeBSD: it forces terminal echo to on and you cannot turn it back off. Interestingly, sudo does not have the same behavior. Here is a sample terminal session showing the behavior (input that was not echoed is shown in red):

[14:54:35] myhost:~ $ stty
speed 38400 baud;
lflags: echoe echok echoke echoctl pendin
iflags: -ixany -imaxbel
oflags: -oxtabs
cflags: cs8 -parenb
[14:54:38] myhost:~ $ stty -echo
[14:54:57] myhost:~ $ stty[enter] speed 38400 baud;
lflags: -echo echoe echok echoke echoctl pendin
iflags: -ixany -imaxbel
oflags: -oxtabs
cflags: cs8 -parenb
[14:55:00] myhost:~ $ sudo -s[enter] Password: mypassword[enter]
[14:55:15] myhost:~ # stty[enter] speed 38400 baud;
lflags: -echo echoe echok echoke echoctl pendin
iflags: -ixany -imaxbel
oflags: -oxtabs
cflags: cs8 -parenb
[14:55:20] myhost:~ # exit
[14:55:25] myhost:~ $ su[enter] Password: rootpassword[enter]
myhost# stty
speed 38400 baud;
lflags: echoe echok echoke echoctl pendin
iflags: -ixany -imaxbel
oflags: -oxtabs
cflags: cs8 -parenb
myhost# stty -echo
myhost# stty
speed 38400 baud;
lflags: echoe echok echoke echoctl pendin
iflags: -ixany -imaxbel
oflags: -oxtabs
cflags: cs8 -parenb
myhost#

As you can see, the -echo flag was preserved by the sudo session, but not be the su session. Furthermore, it was not possible to re-disable terminal echo within the su session -- it simply ignored the directive.

I suspect the cause is somewhere in the PAM libraries that su uses to authenticate the user. However, I would have expected sudo to use the same PAM libraries, so I cannot explain the difference in behavior.