I don't understand why this loop is designed this way.

First, it assumes field names are either lower-case or capitalized, but "Case is not significant in field names, but is significant in field values." according to https://cabal.readthedocs.io/en/3.4/cabal-package.html#package-descriptions

Also I find the logic of checking keys one by one with both forms, and using them to split is confusing. I think you can simplify the loop to something like this:

keys = ["name", "version", "synopsis", "author", "description"]
for line in lines:
    (key, value) = line.split(":", 1)
    key = key.lower()
    if key in keys:
        result[key] = value.strip()
        keys.remove(key)

ok, simpler. I added a check against ":" if not it failed on comment and multilines

Finally, it does not support multi-line values, which seem to be common for descriptions (and are valid as synopsis too, I assume)

Last commit fix the issues. By the way please note that "synopsis" is the field used on the forge to display a title and description is more like a README content.
We add description field when we discover that in some old versions synopsis were missing but description was present.

The current implementation use synopsis and fallback to description if any, and description may be multiline. Can you confirm its ok this way or do you prefer we use description as a default?

Also description is the only multiline field that we need to manage.
At this point I did not take to time to find a .cabal file that have a multiline description and and empty synopsis, so the last test is quite useless.

That code still does not parse multiline values, for instance we would miss full description by parsing that cabal file.

You should add tests for that function to cover the edge cases.

Last commit goes this way and the last commented test pass. Even if the cabal file is not parsed correctly, we have acceptable data to load the archive.
Regarding cabal file, if I understand correctly it looks like its the base data authority. The hackage api has an endpoint that returns cabal file and the content is exactly the same as the one in tar.gz. So if there is human errors the api won't help.
We should have less error now!

Do agree for description part, but for author the problem is that p_info.author is of type Person, so I let it like this.
I'm not sure if \n is mandatory after description, in previous loaders its always there, but its missing from your code, should I remove it?

Ah right, use this instead then:

author_str = intrinsic_metdata.get("author")
author = Person.from_fullname(author_str.encode()) if author_str else p_info.author

description = intrinsic_metadata.get("synopsis", intrinsic_metadata.get("description"))

message = (
    f"Synthetic release for Haskell source package {p_info.name} "
    f"version {p_info.version}\n"
)

if description:
    message += f"\n{description}"

description has been removed

Thanks I was not sure about how to deal with that