htvend is a tool to help you capture any internet dependencies needed in order to perform a task.

It builds a manifest of internet assets needed, which you can check-in with your project.

The idea being that this serves as an upstream package lock file for any asset type, and that you can re-use this to rebuild your application if the upstream assets are removed, or if you are without internet connectivity.

Has an experimental GitHub action to integrate within your GitHub build, archiving assets to S3.

[1] https://github.com/continusec/htvend

The intent was to support basic build systems accessing package eco-systems that tend to always serve the same response for the same URL.

Docker registries do this reasonably well, as do Maven repos.

It wasn't intended to be a full on proper archiving proxy (and I'll admit I hadn't heard that term - I'll look into it and see what else exists in that space).

The main use-case I had in mind for this is private projects, that are developed on workstations which have internet access, but are deployed to other environments using CI/CD systems with less network access. If both systems have access to a common blob store, then that can be populated with htvend build on a workstation and replayed at build time with htvend offline.

For that, there's no need to capture additional request information, as the focus wasn't to support getting a manifest file and being able to reliably re-download all the blobs from internet (and often those responses may have changed in the interim). And for the same reason, would expect to only need to one response per URL, per assets.json file.

Does that make sense?

    func foo() (retErr error) {
        f, err := os.Create("out.txt")
        if err != nil {
            return fmt.Errorf("error opening file: %w", err)
        }
        defer func() {
            err := f.Close()
            if err != nil && retErr == nil {
                retErr = fmt.Errorf("error closing file: %w", err)
            }
        }()
        _, err = f.Write([]byte("hello world!"))
        return err
    }

Our team managed to screw-up some pretty major DNS due to a valid terraform plan that looked OK, but in reality then deleted a bunch of records, before failing (for some reason I can't remember) before it could create new ones.

And of course, we forgot that although we had shortened TTL on our records, the TTL on the parent records that I think get hit when no records are found were much longer, so we had a real bad afternoon. :)

    lifecycle {
      create_before_destroy = true
    }

To calculate ground speed (as required for navigation and fuel planning) you need true airspeed (not indicated) as well as wind direction and speed.

See some discussion here: https://www.quora.com/In-aviation-what-is-the-difference-bet...

IAS is what the pilots care about while flying because it’s what matters for aerodynamics (ie stall speed)

ie if your code itself is split into modules, they won't work (as they are imported by their full path, not relatively), and anything in your vendor dir is also ignored when used outside of a GOPATH entry.

See RFC6962 Certificate Transparency logs and their consistency proofs for a widely used example.

There are ways to work around this, for example objecthash[0] describes a small modification that prepends the input data with 32 bytes of random data before hashing in order to prevent this.

[0] https://github.com/benlaurie/objecthash#redactability

One "trend", or rather bad habit that I've noticed a lot in discussion with other developers recently, and this doc also falls into, is that there seems to more focus on "input sanitisation" rather than "output escaping".

Regardless of what's been done to input, if the result is that you have a string that you need to embed into another string, then you need to know how to escape that appropriately for the context in which it's being used. Whether the data is user generated, or taken from your database, always assume that it's trying to break your app, and always escape it on output.