[Cryptography] RFC possible changes for Linux random device

Theodore Ts'o tytso at mit.edu
Sat Sep 13 20:40:52 EDT 2014


On Sat, Sep 13, 2014 at 03:32:15PM -0400, Sandy Harris wrote:
> Also, it would be a large patch. My program is over 1500 lines,
> though at least half of those are comments or scaffolding for
> testing it. Add the missing bits and some changes to current
> code to integrate it and it would be a 1000+ line patch. I am
> not sure whether or how that should be split up.

That's simple.  The patch should be split up so that each patch
changes *one* thing.  Think of the Japanese concept of Kaizen, where
each change has to be independent, small, auditable, and individually
justifiable.  And note that whitespace and formatting is considered one
thing.  *Please* don't change whitespace on unrelated lines at the
same time when you are making other changes.

The worst thing in the world is when I get a 1000+ line change, which
changes lots of things all at once, such that resulting patch is
impossible to reason about or audit.  If it takes me more than a few
minutes to review it in an email window, it will generally get put on
a backlog queue, and it's no longer on the fastpath.  So keep the each
individual patches as small as possible in terms of lines of change,
and do the simple bits first.  If you can convince me to merge in the
first few patches, it reduces the total number changes that still
needs to make, and it tends to be good the contributor's morale.

Where as if I get a 1000+ line patch, I might finally get a chance to
look at it several weeks or months later.  And when I do, I will
generally look at them for a few design inspirations, and then pull
them out, and make those changes one at a time, as I have time.
(Basically, if you don't do this patch refactoring, I will; at my own
copious spare time.  :-)   And if it's not obvious why the change is
made, and why, I will simply discard them out of hand.

This has happened more than once in the past, and usually people get
hurt/angry/upset and challenge my intelligence, my integrity, and my
paternity.  That's OK.  But the change is still not going in.  :-)

Cheers,

					- Ted

P.S.  It may help if you think of what hints you might give an NSA
agent who is trying to contribute in a Kleptographic trojan horse into
an open source project.  How would you do that?  Bury the change in a
thousand line patch.  Change whitespace all over the space to further
obfuscate the deadly change.  Etc.  Then do the exact opposite.  :-)


More information about the cryptography mailing list