Thanks! On just the description I have some concerns I need to at least think about:

• do we want to provide an API just for small artifacts? I think this is probably acceptable: it does simplify things for us and the user (if you are dealing with a small artifact then dealing with an iterator is just another hoop to jump through)
• Avoiding the cache completely sounds like a bad idea: it promotes bad practices (re-downloading things over and over). The main user experience pain point is that a user that just wants the bytes needs to jump through two hoops: first call tuf API, then read the file. Whether cache is written to is related but not tied to this.
• A related API snag is that reading from cache still requires reading a file... so users can't completely avoid reading files:
  • We should likely have a test or an example that shows the whole API use (get_targetinfo, find_cached_target+ read cache file, download_target_bytes) to make sure we understand how the new API is used
  • to really make the API simpler we would want the new method to cover all of
    • find_cached_target
      • if found, read cache, return bytes
    • download the target bytes
      • write cache
      • return bytes

I did mention cache timing in the bug but that was probably a mistake on my part: We certainly don't want to avoid caching because of fears that this somehow leaks timing info.

Possible paths forward

I can see a few possible potential routes:

1. follow your solution but include writing to cache
   • users in reality still need to deal with reading cached files so it's not as useful as it could be... I'm not very enthusiastic about this option: it feels like it grows API surface without really making things easier
2. Implement the higher level method idea that combines cache lookup, download and writing to the cache so the user experience is better
   • This was not part of the original API design because we wanted things to work with huge files... but since we're prepared to compromise on that for this bit of API, we could do it
   • I wonder if we can go all the way and have a Updater.get_target_bytes(self, target_path: str) -> bytes instead? This would call get_targetinfo, then find_cached_target (on cache hit read the file and return early), then download target, store it in cache, return bytes
   • this would have most impact, making the API a lot simpler for this small file use case. There might be some unforeseen complications though

I think there might be something to the second option if you're willing to experiment with it and see how it looks like

Also I'd appreciate it if you document which parts of the work (code, tests, PR message) are AI generated