Hackage.Security.Client.Repository.Remote

An implementation of Repository that talks to repositories over HTTP.

This implementation is itself parameterized over a HttpClient, so that it it not tied to a specific library; for instance, HttpClient can be implemented with the HTTP library, the http-client libary, or others.

It would also be possible to give _other_ Repository implementations that talk to repositories over HTTP, if you want to make other design decisions than we did here, in particular:

• We attempt to do incremental downloads of the index when possible.
• We reuse the Repository.Local to deal with the local cache.
• We download timestamp.json and snapshot.json together. This is implemented here because:
• One level down (HttpClient) we have no access to the local cache
• One level up (Repository API) would require _all_ Repositories to implement this optimization.

Top-level API

withRepository

Arguments

:: HttpLib

Implementation of the HTTP protocol

-> [URI]

"Out of band" list of mirrors

-> AllowContentCompression

Should we allow HTTP content compression?

-> WantCompressedIndex

Do we want a copy of the compressed index?

-> Cache

Location of local cache

-> RepoLayout

Repository layout

-> (LogMessage -> IO ())

Logger

-> (Repository -> IO a)

Callback

-> IO a

Initialize the repository (and cleanup resources afterwards)

We allow to specify multiple mirrors to initialize the repository. These are mirrors that can be found "out of band" (out of the scope of the TUF protocol), for example in a cabal.config file. The TUF protocol itself will specify that any of these mirrors can serve a mirrors.json file that itself contains mirrors; we consider these as _additional_ mirrors to the ones that are passed here.

NOTE: The list of mirrors should be non-empty (and should typically include the primary server).

TODO: In the future we could allow finer control over precisely which mirrors we use (which combination of the mirrors that are passed as arguments here and the mirrors that we get from mirrors.json) as well as indicating mirror preferences.

data AllowContentCompression

Should we allow HTTP content compression?

Since content compression happens before signature verification, users who are concerned about potential exploits of the decompression algorithm may prefer to disallow content compression.

Constructors

AllowContentCompression

DisallowContentCompression

data WantCompressedIndex

Do we want to a copy of the compressed index?

This is important for mirroring clients only.

Constructors

WantCompressedIndex

DontNeedCompressedIndex

File sizes

data FileSize

Constructors

FileSizeExact Int

For most files we download we know the exact size beforehand (because this information comes from the snapshot or delegated info)

FileSizeBound Int

For some files we might not know the size beforehand, but we might be able to provide an upper bound (timestamp, root info)

fileSizeWithinBounds :: Int -> FileSize -> Bool