[feature request] Support header hints for newer versions and known vulnerabilities

[lucidNTR]

I thought a long time for the best way to allow yarn like "update all", listing of outdated dependencies and showing known vulnerabilities in deno without introducing central entities or being non idiomatic for deno and this is what i came up with:

support two new http headers on code download:

given i reference a code file similar to:

import { green } from 'https://deno.land/std@0.126.0/fmt/colors.ts'

when deno would fetch this file, whenever the following http headers are present log a realtime warning:

for hinting to a later version: Link: <https://deno.land/std@0.128.0/fmt/colors.ts>; rel="latest-version"

for warning about known vulnerabilities: Link: <https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-1472>; rel="vulnerability", <https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-1474>; rel="vulnerability"

additionally deno would do a cheap http HEAD request upon using a locally cached resources to warn about outdated or vulnerable dependencies, with cached result to not do a check more than once x days. this also has the nice effect that the head request would discover availability issues of external referenced dependencies so we could warn that a rebuild/refetch would fail.

additionally we can introduce a 'deno scan' or 'deno outdated' command that does an ad hoc refetch of the headers for all referenced files.

Considered alternatives:

• well known path of json file with versions and vulnerabilities, pros: no need for server support to add the headers, cons: we would have to find a way to know at what point of the path we need to check for this file and this would put a strict structure expectation of what a "package" is but this is much more flexible in deno than nodejs, also this would mean noise when trying to load the version and vulnerability files from servers that don't have those, similar to annoying search engine requests to robots.txt on all webservers

• checking in a reposity/service, pros: would have a central configurable source of truth similar to how artifactory etc. are setup, cons: this would bring back a lot of annoyances from npm that we tried to get rid of such as having to configure a package server and complex setups for multiple sources of code

[AnInternetTroll]

Seems related to this discussion

[kitsonk]

One consideration in this is that, irrespective of cache headers, the DENO_DIR/deps (remote modules cache) is treated as immutable, meaning that the headers (and therefore modules) are only ever retrieved once, unless --reload is specified. When reload is specified, an ETag header is sent (if received on the original request) and not modified is handled.

The problem with the first part of this suggestion is that would make such "warning" headers not easy to implement without changing behaviour in a significantly breaking way. @lucacasonato and I discussed this when we started respecting caching headers (to a degree) with the registry completions, but left alone the deps cache.

[lucidNTR]

@kitsonk got ya. this would be fixed by adding the cli params in a way similar to this ,right? (igonre the exact wording for now)

--reload --audit-only

--reload --show-outdated-only

--reload would trigger the fetch dependencies logic and the other flags could disable the actual overwriting of dependencies and instead refetch only the headers with a HEAD

the notion of etag is also a good point. it depends if we are using strong or weak etags:

If the conditional GET used a strong cache validator (see [RFC 2068], section 13.3.3), the response SHOULD NOT include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers.

imho it would be totally fine to include the vulnerability warnings and hints for updated resources in a "strong cache validation request". If we are using weak etags, its best not to break RFC and it would be a bit trickier, but maybe switching to strong etags would then be the lesser evil?

[lucidNTR]

@AnInternetTroll

Seems related to this discussion

Thanks for the link and sorry i did not find that discussion before creating the ticket. What i really like compared to the x-deno-xy option is that the link header is by default a list so its possible to return all known vulnerabilities and also it allows to have consistent semantics of latest version hints and vulnerabillities. lastly the link header is so generic it would not be limited to deno, i can totally imagine if this catches on, that chrome console-logs a warning about vulnerabilities in the same way if the dev tools are open and an es module is loaded in the browser