AI 버그 보고 노이즈를 방지하기 위해 Pfsync 패킷 헤더 필드 이름이 변경됨

As a consequence of one such report, Theo de Raadt (deraadt@ ) committed a change to pfsync(4) to rename an otherwise unused field in the pfsync(4) packet header. The commit message reads, List: openbsd-cvs Subject: CVS: cvs.openbsd.org: src From: Theo de Raadt Date: 2026-04-12 3:16:04 CVSROOT: /cvs Module name: src Changes by: [email protected] 2026/04/11 21:16:04 Modified files: sys/net : if_pfsync.c if_pfsync.h Log message: The pfcksum[] field in the pfsync packet header is not a hash of the packet. It provides absolutely no security benefits, keep reading to find out. According to dlg, during early development this field was hopefully going to be a hash related to the ruleset for optimizing state match. That approach was abandoned (I guess because ruleset drift between firewalls happens too often during normal practice). As is usual in protocol development, at least 6 people were already using pfsync in production, so for compatibility the field was not removed... and forgotten. On send, it was left as zero, due to the full-header zero initialization code. So there is no useful checksum or hash stored in this field called 'pfcksum[PF_MD5_DIGEST_LENGTH]'. Actually there isn't a single line of code in the entire tree which writes to this array. Besides the field definition in the structure, there is 1 comment elsewhere mentioning the field. So no code at all. I said no code, which is why there is no code checking it on receive, not even checking if it is still zero. An (obviously) AI-assisted report (which I do not intend to share) arrived which tells us FOR SURE that field is being computed on send, but not checked on arrival which is a security risk!!!! It goes into extensive detail saying where various parts of this subsystem are and how it all fits together but apparently it is all an elaborate fiction built upon two words 'pfcksum' and 'PF_MD5_DIGEST_LENGTH'. No words about security principles are found anywhere in the code or in the manual page because everyone uses this on a dedicated wire between firewall boxes. The human who caused an AI to generate that report did not "peer-review" the result (hint: the command is grep) before sending it to us, and has caused David to pull a muscle when his eyes rolled back too far. To avoid future confusion by AI+humans, rename the field from pfcksum[PF_MD5_DIGEST_LENGTH] to spare[16]. ok dlg In a related commit, Theo also updated the pfsync(4) man page with clearer words about the security, or rather lack of, in the protocol itself. This means, dear friends, that in the upcoming OpenBSD 7.9 release, pfsync(4) will have improved documentation as well as a spare field in its packet header. By Mario Campos (marioc) [email protected] on >As is usual in protocol development, at least 6 people were already using pfsync in production, so for compatibility the field was not removed... Does this suggest that the protocol is fixed-length, and, for that reason, the field cannot be removed but can instead be renamed? Reply By Kristof Provost (kp) [email protected] on I suspect I know exactly what bug report you got, because FreeBSD got the same one. (And didn't share it with OpenBSD because it was ... well, this.) Reply