Fix the type of signatures in metadata

[michaelpj]

Signatures are actually complex objects. We could use Value here since
it's unlikely that any consumers care about this, but it's cheap enough
to just define a structure for the signature objects.

In practice this isn't an issue because it seems like this field is
never populated in Hackage, but it can be populated if you build a
custom Hackage it can happen.

Fixes NixOS/cabal2nix#573.

[sternenseemann]

I wonder how risky a dependency hackage-security would be which would allow us to use the proper type for this it seems.

Sadly I fear we should avoid it, as it has a lot of dependencies which is annoying to have pulled in for cabal2nix.

[michaelpj]

Yeah, obviously using the proper parser would avoid a lot of these problems, but it's nice to have something minimal here! Just means we need to correct it if things are off :)

[sternenseemann]

In that light it seems actually better to go with Value, though: If users of hackage-db also have hackage-security available, it'd be possible to do parseJSON (signatures metaData) :: Parser Signatures if I'm not mistaken.

If we document that, I think that's a reasonable compromise and easy enough to use. If ppl want to actually deal with the signatures (i.e. verify them), they should probably be using the proper package anyways.

[michaelpj]

Isn't that outside the target usecases of this package? If you have hackage-security available, why would you use hackage-db for this?

I don't mind using Value just to indicate that we don't care what's there, but in the rest of the package you seem to not do that, which is why I thought putting in the structured version was better (especially since it's very simple!).

[sternenseemann]

See NixOS/cabal2nix#575.