Stale CPAN email addresses delay security reporting

A scheduled profile update can undo an author contact change long after the author thinks it succeeded. That is one of the problems behind CPANSec asking authors today to retire their cpan.org addresses. Olaf Alders reports that MetaCPAN bugs allowed a cron job to reset profile information over the summer. Authors who already changed their contact details need to check the published result again.

The forwarding service itself ended months ago. The Perl NOC announcement on April 25 described spam and deliverability problems that made continued operation impractical. October exposes the remaining dependencies on that service. Contact metadata and account linking still refer to an address that no longer delivers mail.

Perl remains my choice for one-off text work after nearly thirty years of use. CPAN is part of that preference, because useful packages arrive with documentation and an identifiable maintainer. A broken contact address weakens that relationship even when the package continues working. Security reporting requires a way to reach the person who can change the code.

An edit is not the final published state

Alders asks authors to revisit profile edits because the persistence bugs could quietly replace them. This is more specific than an author forgetting to update an address. Someone could perform the requested maintenance and still appear unreachable later. The system publishing the metadata could restore the obsolete value without another deliberate action by the author.

That behavior explains why a reminder alone did not complete the transition. A profile form and its scheduled synchronization have to agree about which value is authoritative. When they disagree, the displayed contact can depend on which writer ran most recently. The author sees a successful interaction while a later process restores an earlier state.

This matters to CPANSec because contacting responsible authors is part of issuing advisories. The October post describes extra work finding an author when the public address ends in cpan.org. That work consumes time available for other security issues. The cost falls on the reporting process as well as on users whose messages bounce.

A public contact address is therefore operational metadata. Its purpose includes receiving reports that were not expected when the package shipped. The ability to download a release and read its documentation does not establish that its maintenance channel still works. Those services can remain available after the address has stopped delivering.

Account linking also depended on forwarding

The announcement identifies another consequence for accounts that have not yet linked PAUSE to MetaCPAN. The existing linking method sends a confirmation message to the cpan.org alias. With that route gone, the old method cannot complete. Alders says the team has not yet had the resources to implement a replacement.

This is a circular recovery problem for the affected user. The workflow needs confirmation through an address whose delivery service has ended. Repeating the same confirmation request cannot restore the missing transport. The application needs a different way to establish the account relationship, with an authorization process appropriate to that change.

The October notice does not announce such a replacement. Treating the problem as an available self-service migration would misdescribe the current state. For an unlinked account, the stated limitation remains until the maintainers provide another method. Updating public contact information and repairing account linking are related tasks with different implementations.

Distribution metadata has several publication paths

CPANSec already published contact-update guidance in June. It identifies addresses in distribution documentation and build configuration as well as author profiles. Updating a current profile does not rewrite historical release archives. A new release can publish corrected contact information for subsequent indexing.

The distinction is useful when deciding where a correction can take effect. An old tarball records the metadata shipped with that artifact. The current author profile can provide a maintained contact route without pretending the old archive has changed. Current documentation should direct readers toward that route where possible.

Commit history has a separate mechanism. The June guidance recommends a mailmap, and Git documents its mapping syntax. A mapping can associate an old commit identity with a current public identity for tools that use mailmaps. It does not operate an email forwarder or edit the original message stored in a commit.

Example Author <current@example.net> <author@cpan.org>

That example uses placeholder identities. Its purpose is to show that historical attribution and present contact can be associated without rewriting existing commits. Readers still need a working destination for an actual report, and a mailmap-aware display is only one place where that destination can appear.

Privacy remains part of the contact decision

The June guidance recognizes that forwarding aliases provided some authors with privacy. Replacing a dead alias does not require publishing a private personal inbox. A maintained public address can preserve separation between project correspondence and private mail. What matters for reporting is that the published route receives messages and has someone responsible for it.

The October problem combines an ended service with software that still depends on it. Correcting the address in visible metadata helps reporters today, while account-linking changes need maintainer work. For an author who already edited a profile, the immediate useful check is the address currently published after synchronization, because the earlier successful edit may not be the value readers now see.