Andrew Morton submitted some documentation explaining the use of the "Signed-off-by" and "Acked-by" tags added when patches are submitted for conclusion into the Linux kernel. "The Signed-off-by: tag implies that the signer was involved in the development of the patch, or that he/she was in the patch's delivery path," the documentation explains, "if a person was not directly involved in the preparation or handling of a patch but wishes to signify and record their approval of it then they can arrange to have an Acked-by: line added to the patch's changelog." When asked about the possibility of including "Tested-by" tags, Andrew replied, "I think it's very useful information to have. For a start, it tells you who has the hardware and knows how to build a kernel. So if you're making a change to a driver and want it tested, you can troll the file's changelog looking for people who might be able to help."

The thread went on to discuss if Ack and Nack patches were useful from non-maintainers. Andrew suggested that a without additional information they don't offer much, "it's better to just provide constructive, detailed technical comments and from that it becomes pretty obvious to all parties whether or not the patch has a future. If you did properly provide that useful feedback then the 'ack' or 'nack' bit becomes redundant." He went on to stress the need for useful feedback, "frankly, I don't trust a simple 'ack' much at all. It's the kernel equivalent of 'whoa, kewl!'"

A vulnerability in TCP, the transmission control protocol, recently received some exposure in the media. Paul Watson released a white paper titled Slipping In The window: TCP Reset Attacks at the 2004 CanSecWest conference, providing a much better understanding of the real-world risks of TCP reset attacks.

To better understand the reality of this threat, KernelTrap spoke with Theo de Raadt [interview], the creator of OpenBSD, an operating system which among other goals proactively focuses on security. In this article, we aim to provide some background into the workings of TCP, and then to build upon this foundation to understand how resets attacks work.

This is the first article in a two part series. The second article will look into how TCP stacks can be hardened to defend against such attacks. Toward this goal, we spoke with members of the OpenBSD team to learn what they have done so far, and what further plans they have to minimize the impact of reset attacks.