ietf-openpgp
[Top] [All Lists]

Re: Packet length: header vs. context

2007-01-07 17:14:32

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ian touched on many of the salient points of this dilemma. The most  
correct answer to the problem you pose is "mu."

This is something that you have to make a personal decision on.

Let's suppose that the standard said something definitive on this.  
Many people have gotten into a lot of trouble by over-implementing  
standards. Let's suppose, for example, that you reject the key. Let's  
then suppose that someone finds that they can't import in keys that  
were created with software X on OS Y with a key size of a prime  
number of bits.

Well -- what do you do? There are people who want to use your code  
and can't, and it's not your fault. Screw 'em, they're the ones who  
got the standard wrong.

But when it turns out that the problem is that your software doesn't  
work with the new OpenPGP in Linux that runs underneath Windows  
Mobile Horizon that ships in the new Apple iTunesFone (when it  
creates keys 1987 bits long (selected because it's a prime number  
*and* the year programmer's GF was born -- cool, huh?)) and because  
of it, people can't download music from WalMart's GNU Music Share --  
well, the story on Slashdot is going to have *your* software's name  
on the headline, not theirs. You'll be changing your code to ignore  
that one extra byte because otherwise every phone in Korea has to be  
re-flashed, and it's faster for you to change than them. (Something  
similar to this happened to PGP once, but I changed the name of the  
country in my explanation.)

An alternative to just accepting that packet would be to lop off the  
extra data (which will be ignored), and make the length correct.

When you implement a protocol, there are often more choices than  
being anal or passing idiocy through. In the one you've given, it's  
almost certainly true that you can tweak the packet to the right size  
and not affect anything else. So why not do so?

It might also be a good thing to tell the people who are doing  
something dumb that they're doing something dumb, but don't expect  
them to fix it tomorrow, especially since there's a workaround. When  
it's been a couple of years and no fix has arrived, you have earned  
the right to be snarky, but by then you probably forgot the  
workaround you put in your code, too.

As for your second question -- where partial lengths can be used --  
what's your real question? Do you want to use them in places other  
than data packets? Is someone subjecting you to them and it's a pain  
in the neck to parse them?

It's Sunday afternoon and I need to run some errands, so I don't want  
to go crawl through the spec. I *believe* that they can be used  
anywhere. But I also believe they shouldn't be used everywhere. In  
the case of a 400-byte packet header, whatever would possess someone  
to do that? Yeah, I'm sure it's legal, but don't do it. If it's the  
software I'm responsible for that's doing something cringe-worthy,  
I'm sorry.

Partial lengths exist so that you can process arbitrarily large  
chunks of data that don't fit in memory and might even be  
inconvenient for you to know the size of a priori. That really means  
data packets. However, as a software engineer, I think that even if  
some idiot chopped up a 400-byte key packet into 2-byte partials,  
your software ought to work. If it doesn't, you have to consider who  
the idiot is. That brings us back to the original consideration.  
Welcome to being a software engineer. Sometimes the things we have to  
do because other people are idiots suck. A sense of humor helps deal  
with it, but doesn't prevent it from sucking.

        Jon


-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.5.2
Charset: US-ASCII

wj8DBQFFoYiZsTedWZOD3gYRAjbyAJwLiOgAYYHSjANqhkaPDpKZ9V1b8QCgpFr3
eLbCx4/y6vWM8hIeqYHNh9k=
=jbmi
-----END PGP SIGNATURE-----