v0.12.1

go-ipfs v0.12.1 Release

This patch release fixes a security issue with the docker-compose.yaml file in which the IPFS daemon API listens on all interfaces instead of only the loopback interface, which could allow remote callers to control your IPFS daemon. If you use the included docker-compose.yaml file, it is recommended to upgrade.

See also the security advisory: GHSA-fx5p-f64h-93xc

Thanks to @LynHyper for finding and disclosing this.

Changelog

Full Changelog

• github.com/ipfs/go-ipfs:
  • fix: listen on loopback for API and gateway ports in docker-compose.yaml

❤ Contributors

Contributor	Commits	Lines ±	Files Changed
guseggert	1	+10/-3	1

v0.12.0

go-ipfs 0.12.0 Release

We're happy to announce go-ipfs 0.12.0. This release switches the storage of IPLD blocks to be keyed by multihash instead of CID.

As usual, this release includes important fixes, some of which may be critical for security. Unless the fix addresses a bug being exploited in the wild, the fix will not be called out in the release notes. Please make sure to update ASAP. See our release process for details.

🛠 BREAKING CHANGES

• ipfs refs local will now list all blocks as if they were raw CIDv1 instead of with whatever CID version and IPLD codecs they were stored with. All other functionality should remain the same.

Note: This change also effects ipfs-update so if you use that tool to mange your go-ipfs installation then grab ipfs-update v1.8.0 from dist.

Keep reading to learn more details.

🔦 Highlights

There is only one change since 0.11:

Blockstore migration from full CID to Multihash keys

We are switching the default low level datastore to be keyed only by the Multihash part of the CID, and deduplicate some blocks in the process. The blockstore will become codec-agnostic.

Rationale

The blockstore/datastore layers are not concerned with data interpretation, only with storage of binary blocks and verification that the Multihash they are addressed with (which comes from the CID), matches the block. In fact, different CIDs, with different codecs prefixes, may be carrying the same multihash, and referencing the same block. Carrying the CID abstraction so low on the stack means potentially fetching and storing the same blocks multiple times just because they are referenced by different CIDs. Prior to this change, a CIDv1 with a dag-cbor codec and a CIDv1 with a raw codec, both containing the same multihash, would result in two identical blocks stored. A CIDv0 and CIDv1 both being the same dag-pb block would also result in two copies.

How migration works

In order to perform the switch, and start referencing all blocks by their multihash, a migration will occur on update. This migration will take the repository version from 11 (current) to 12.

One thing to note is that any content addressed CIDv0 (all the hashes that start with Qm..., the current default in go-ipfs), does not need any migration, as CIDv0 are raw multihashes already. This means the migration will be very lightweight for the majority of users.

The migration process will take care of re-keying any CIDv1 block so that it is only addressed by its multihash. Large nodes with lots of CIDv1-addressed content will need to go through a heavier process as the migration happens. This is how the migration works:

1. Phase 1: The migration script will perform a pass for every block in the datastore and will add all CIDv1s found to a file named 11-to-12-cids.txt, in the go-ipfs configuration folder. Nothing is written in this first phase and it only serves to identify keys that will be migrated in phase 2.
2. Phase 2: The migration script will perform a second pass where every CIDv1 block will be read and re-written with its raw-multihash as key. There is 1 worker performing this task, although more can be configured. Every 100MiB-worth of blocks (this is configurable), each worker will trigger a datastore "sync" (to ensure all written data is flushed to disk) and delete the CIDv1-addressed blocks that were just renamed. This provides a good compromise between speed and resources needed to run the migration.

At every sync, the migration emits a log message showing how many blocks need to be rewritten and how far the process is.

FlatFS specific migration

For those using a single FlatFS datastore as their backing blockstore (i.e. the default behavior), the migration (but not reversion) will take advantage of the ability to easily move/rename the blocks to improve migration performance.

Unfortunately, other common datastores do not support renames which is what makes this FlatFS specific. If you are running a large custom datastore that supports renames you may want to consider running a fork of fs-repo-11-to-12 specific to your datastore.

If you want to disable this behavior, set the environment variable IPFS_FS_MIGRATION_11_TO_12_ENABLE_FLATFS_FASTPATH to false.

Migration configuration

For those who want to tune the migration more precisely for their setups, there are two environment variables to configure:

• IPFS_FS_MIGRATION_11_TO_12_NWORKERS : an integer describing the number of migration workers - defaults to 1
• IPFS_FS_MIGRATION_11_TO_12_SYNC_SIZE_BYTES : an integer describing the number of bytes after which migration workers will sync - defaults to 104857600 (i.e. 100MiB)

Migration caveats

Large repositories with very large numbers of CIDv1s should be mindful of the migration process:

• We recommend ensuring that IPFS runs with an appropriate (high) file-descriptor limit, particularly when Badger is use as datastore backend. Badger is known to open many tables when experiencing a high number of writes, which may trigger "too many files open" type of errors during the migrations. If this happens, the migration can be retried with a higher FD limit (see below).
• Migrations using the Badger datastore may not immediately reclaim the space freed by the deletion of migrated blocks, thus space requirements may grow considerably. A periodic Badger-GC is run every 2 minutes, which will reclaim space used by deleted and de-duplicated blocks. The last portion of the space will only be reclaimed after go-ipfs starts (the Badger-GC cycle will trigger after 15 minutes).
• While there is a revert process detailed below, we recommend keeping a backup of the repository, particularly for very large ones, in case an issue happens, so that the revert can happen immediately and cases of repository corruption due to crashes or unexpected circumstances are not catastrophic.

Migration interruptions and retries

If a problem occurs during the migration, it is be possible to simply re-start and retry it:

1. Phase 1 will never overwrite the 11-to-12-cids.txt file, but only append to it (so that a list of things we were supposed to have migrated during our first attempt is not lost - this is important for reverts, see below).
2. Phase 2 will proceed to continue re-keying blocks that were not re-keyed during previous attempts.

Migration reverts

It is also possible to revert the migration after it has succeeded, for example to go to a previous go-ipfs version (<=0.11), even after starting and using go-ipfs in the new version (>=0.12). The revert process works as follows:

1. The 11-to-12-cids.txt file is read, which has the list of all the CIDv1s that had to be rewritten for the migration.
2. A CIDv1-addressed block is written for every item on the list. This work is performed by 1 worker (configurable), syncing every 100MiB (configurable).
3. It is ensured that every CIDv1 pin, and every CIDv1 reference in MFS, are also written as CIDV1-addressed blocks, regardless of whether they were part of the original migration or were added later.

The revert process does not delete any blocks--it only makes sure that blocks that were accessible with CIDv1s before the migration are again keyed with CIDv1s. This may result in a datastore becoming twice as large (i.e. if all the blocks were CIDv1-addressed before the migration). This is however done this way to cover corner cases: user can add CIDv1s after migration, which may reference blocks that existed as CIDv0 before migration. The revert aims to ensure that no data becomes unavailable on downgrade.

While go-ipfs will auto-run the migration for you, it will not run the reversion. To do so you can download the latest migration binary or use ipfs-update.

Custom datastores

As with previous migrations if you work with custom datastores and want to leverage the migration you can run a fork of fs-repo-11-to-12 specific to your datastore. The repo includes instructions on building for different datastores.

For this migration, if your datastore has fast renames you may want to consider writing some code to leverage the particular efficiencies of your datastore similar to what was done for FlatFS.

Changelog

Full Changelog

• github.com/ipfs/go-ipfs:
  • Release v0.12.0
  • docs: v0.12.0 release notes
  • chore: bump migrations dist.ipfs.io CID to contain fs-repo-11-to-12 v1.0.2
  • feat: refactor Fetcher interface used for downloading migrations (#8728) (ipfs/go-ipfs#8728)
  • feat: log multifetcher errors
  • Release v0.12.0-rc1
  • chore: bump Go version to 1.16.12
  • feat: switch to raw multihashes for blocks (ipfs/go-ipfs#6816)
  • chore: add release template snippet for fetching artifact tarball
  • chore: bump Go version to 1.16.11
  • chore: add release steps for upgrading Go
  • Merge branch 'release'
  • fix(corehttp): adjust peer counting metrics (#8577) (ipfs/go-ipfs#8577)
  • chore: update version to v0.12.0-dev
• github.com/ipfs/go-filestore (v0.1.0 -> v1.1...

v0.12.0-rc1

Tracking Issue: #8344

v0.11.0

go-ipfs 0.11.0 Release

We're happy to announce go-ipfs 0.11.0. This release comes with improvements to the UnixFS Sharding and PubSub experiments as well as support for Circuit-Relay v2 which sets the network up for decentralized hole punching support.

As usual, this release includes important fixes, some of which may be critical for security. Unless the fix addresses a bug being exploited in the wild, the fix will not be called out in the release notes. Please make sure to update ASAP. See our release process for details.

🛠 BREAKING CHANGES

• UnixFS sharding is now automatic and enabled by default
  • HAMT-based sharding is applied to large directories (i.e. those that would serialize into block larger than ~256KiB)s. This means importing data via commands like ipfs add -r <directory> may result in different CIDs due to the different DAG representations.
  • Support for Experimental.ShardingEnabled is removed.
• go-ipfs can no longer act as a Circuit Relay v1
  • Node will refuse to start if Swarm.EnableRelayHop is set to true
  • If you depend on v1 relay service provider, see "Removal of v1 relay service" section for available migration options.
• HTTP RPC wire format for experimental commands at /api/v0/pubsub changed.
  • If you use js-ipfs-http-client or go-ipfs-http-client, just update to their latest version.
  • If you use something else, see "Multibase in PubSub" section below for migration details.

Keep reading to learn more details.

🔦 Highlights

🗃️ Automatic UnixFS sharding

Truly big directories can have so many items, that the root block with all of their names is too big to be exchanged with other peers. This was partially solved by HAMT-sharding, which was introduced a while ago as opt-in. The main downside of the implementation was that it was a global flag that sharded all imported directories (big and small).

This release solves that inconvenience by making UnixFS sharding smarter and applies it only to larger directories (i.e. directories that would be at least ~256KiB). This is now the default behavior in ipfs add and ipfs files commands, where UnixFS sharding works out-of-the-box.

🔁 Circuit Relay v2

This release adds support for the circuit relay v2 protocol based on the reference implementation from go-libp2p 0.16.

This is the cornerstone for maximizing p2p connections between IPFS peers. Every publicly dialable peer can now act as a limited relay v2, which can be used for hole punching and other decentralized signaling protocols.

Limited relay v2 configuration options

go-ipfs can now be configured to act as a RelayClient that uses other peers for autorelay functionality when behind a NAT, or provide a limited RelayService to other peers on the network.

Starting with go-ipfs v0.11 every publicly dialable go-ipfs (based on AutoNAT determination) will start a limited RelayService. RelayClient remains disabled by default for now, as we want the network to update and get enough v2 service providers first.

Note: the limited Circuit Relay v2 provided with this release only allows low-bandwidth protocols (identify, ping, holepunch) over transient connections. If you want to relay things like bitswap sessions, you need to set up a v1 relay by some other means. See details below.

Removal of unlimited v1 relay service provider

Switching to v2 of the relay spec means removal or deprecation of configuration keys that were specific to v1.

• Relay transport and client support circuit-relay v2:
  • Swarm.EnableAutoRelay was replaced by Swarm.RelayClient.Enable.
  • Swarm.DisableRelay is deprecated, relay transport can be now disabled globally (both client and service) by setting Swarm.Transports.Network.Relay to false
• Relay v1 service provider was replaced by v2:
  • Swarm.EnableRelayHop no longer starts an unlimited v1 relay. If you have it set to true the node will refuse to start and display an error message.
  • Existing users who choose to continue running a v1 relay should migrate their setups to relay v1 based on js-ipfs running in node, or the standalone libp2p-relay-daemon configured with RelayV1.Enabled set to true. Be mindful that v1 relays are unlimited, and one may want to set up some ACL based either on PeerIDs or Subnets.

🕳 Decentralized Hole Punching (DCUtR protocol client)

We are working towards enabling hole punching for NAT traversal when port forwarding is not possible.

go-libp2p 0.16 provides an implementation of the DCUtR (decentralized hole punching) protocol. It is hidden behind the Swarm.EnableHolePunching configuration flag.

When enabled, go-ipfs will coordinate with the counterparty using a relayed v2 connection, to upgrade to a direct connection through a NAT/firewall whenever possible.

This feature is disabled by default in this release, but we hope to enable it by default as soon the network updates to go-ipfs v0.11 and gains a healthy set of limited v2 relays.

💬 Multibase in PubSub HTTP RPC API

This release fixed some edge cases that were reported by users of the PubSub experiment, getting it closer to becoming a stable feature of go-ipfs. Some PubSub users will notice that the plaintext limitation is lifted: one can now use line breaks in messages published to non-ascii topic names, or even publish arbitrary bytes to arbitrary topics. It required a change to the wire format used when pubsub commands are executed over the HTTP RPC API at /api/v0/pubsub/*, and also modified the behavior of the ipfs pubsub pub command, which now is publishing only a single pubsub message with data read from a file or stdin.

PubSub client migration tips

If you use the HTTP RPC API with the go-ipfs-http-client library, make sure to update to the latest version. The next version of js-ipfs-http-client will use the new wire format as well, so you don't need to do anything.

If you use /api/v0/pubsub/* directly or maintain your own client library, you must adjust your HTTP client code. Byte fields and URL args are now encoded in base64url Multibase. Encode/decode bytes using the ipfs multibase --help commands, or use the multiformats libraries (js-multiformats, go-multibase).

Low level changes:

• topic passed as URL arg in requests to /api/v0/pubsub/* must be encoded in URL-safe multibase (base64url)
• data, from, seqno and topicIDs returned in JSON responses are now encoded in multibase
• Peer IDs returned in from now use the same default text representation from go-libp2p and peerid encoder/decoder from libp2p. This means the same text representation as in as in swarm peers, which makes it possible to compare them without decoding multibase.
• /api/v0/pubsub/pub no longer accepts data to be passed as URL, it has to be sent as multipart/form-data. This removes size limitations based on URL length, and enables regular HTTP clients to publish data to PubSub topics. For example, to publish some-file to topic named test-topic using vanilla curl, one would execute: curl -X POST -v -F "stdin=@some-file" 'http://127.0.0.1:5001/api/v0/pubsub/pub?arg=$(echo -n test-topic | ipfs multibase encode -b base64url)'
• ipfs pubsub pub on the command line no longer accepts variadic data arguments. Instead, it expects a single file input or stream of bytes from stdin. This ensures arbitrary stream of bytes can be published, removing limitation around messages that include \n or \r\n.

⚙️ New configuration flags

• Addresses.AppendAnnounce is an array of multiaddrs, similar to Addresses.Announce, except it does not override inferred swarm addresses, but appends custom ones to the list.
• Pubsub experiments can now be enabled via config, removing the need for CLI flag to be passed every time daemon starts:
  • Pubsub.Enabled enables the pubsub system.
  • Ipns.UsePubsub enables IPFS over pubsub experiment for publishing IPNS records in real time.

🔐 Support for DAG-JOSE IPLD codec

JOSE is a standard for signing and encrypting JSON objects. DAG-JOSE is an IPLD codec based on JO...

v0.11.0-rc2

Tracking Issue: #8343

v0.11.0-rc1

Tracking Issue: #8343

v0.10.0

go-ipfs v0.10.0 Release

We're happy to announce go-ipfs 0.10.0. This release brings some big changes to the IPLD internals of go-ipfs that make working with non-UnixFS DAGs easier than ever. There are also a variety of new commands and configuration options available.

As usual, this release includes important fixes, some of which may be critical for security. Unless the fix addresses a bug being exploited in the wild, the fix will not be called out in the release notes. Please make sure to update ASAP. See our release process for details.

🛠 TLDR: BREAKING CHANGES

• ipfs dag get
  • default output changed to dag-json
  • dag-pb (e.g. unixfs) field names changed - impacts userland code that works with dag-pb objects returned by dag get
  • no longer emits an additional new-line character at the end of the data output
• ipfs dag put
  • defaults changed to reduce ambiguity and surprises: input is now assumed to be dag-json, and data is serialized to dag-cbor at rest.
  • --format and --input-enc were removed and replaced with --store-codec and --input-codec
  • codec names now match the ones defined in the multicodec table
  • dag-pb (e.g. unixfs) field names changed - impacts userland code that works with dag-pb objects stored via dag put

Keep reading to learn more details.

🔦 Highlights

🌲 IPLD Levels Up

The handling of data serialization as well as many aspects of DAG traversal and pathing have been migrated from older libraries, including go-merkledag and go-ipld-format to the new go-ipld-prime library and its components. This allows us to use many of the newer tools afforded by go-ipld-prime, stricter and more uniform codec implementations, support for additional (pluggable) codecs, and some minor performance improvements.

This is significant refactor of a core component that touches many parts of IPFS, and does come with some breaking changes:

• IPLD plugins:
  • The PluginIPLD interface has been changed to utilize go-ipld-prime. There is a demonstration of the change in the bundled git plugin.
• The semantics of dag put and dag get change:
  • dag get now takes the output-codec option which accepts a multicodec name used to encode the output. By default this is dag-json, which is a strict and deterministic subset of JSON created by the IPLD team. Users may notice differences from the previously plain Go JSON output, particularly where bytes are concerned which are now encoded using a form similar to CIDs: {"/":{"bytes":"unpadded-base64-bytes"}} rather than the previously Go-specific plain padded base64 string. See the dag-json specification for an explanation of these forms.
  • dag get no longer prints an additional new-line character at the end of the encoded block output. This means that the output as presented by dag get are the exact bytes of the requested node. A round-trip of such bytes back in through dag put using the same codec should result in the same CID.
  • dag put uses the input-codec option to specify the multicodec name of the format data is being provided in, and the store-codec option to specify the multicodec name of the format the data should be stored in at rest. These formerly defaulted to json and cbor respectively. They now default to dag-json and dag-cbor respectively but may be changed to any supported codec (bundled or loaded via plugin) by its multicodec name.
  • The json and cbor multicodec names (as used by input-enc and format options) are now no longer aliases for dag-json and dag-cbor respectively. Instead, they now refer to their proper multicodec types. cbor refers to a plain CBOR format, which will not encode CIDs and does not have strict deterministic encoding rules. json is a plain JSON format, which also won't encode CIDs and will encode bytes in the Go-specific padded base64 string format rather than the dag-json method of byte encoding. See https://ipld.io/specs/codecs/ for more information on IPLD codecs.
  • protobuf is no longer used as the codec name for dag-pb
  • The codec name raw is used to mean Bytes in the IPLD Data Model
• UnixFS refactor. The dag-pb codec, which is used to encode UnixFS data for IPFS, is now represented through the dag API in a form that mirrors the protobuf schema used to define the binary format. This unifies the implementations and specification of dag-pb across the IPLD and IPFS stacks. Previously, additional layers of code for file and directory handling within IPFS between protobuf serialization and UnixFS obscured the protobuf representation. Much of this code has now been replaced and there are fewer layers of transformation. This means that interacting with dag-pb data via the dag API will use different forms:
  • Previously, using dag get on a dag-pb block would present the block serialized as JSON as {"data":"padded-base64-bytes","links":[{"Name":"foo","Size":100,"Cid":{"/":"Qm..."}},...]}.
  • Now, the dag-pb data with dag-json codec for output will be serialized using the data model from the dag-pb specification: {"Data":{"/":{"bytes":"unpadded-base64-bytes"}},"Links":[{"Name":"foo","Tsize":100,"Hash":{"/":"Qm..."}},...]}. Aside from the change in byte formatting, most field names have changed: data → Data, links → Links, Size → Tsize, Cid → Hash. Note that this output can be changed now using the output-codec option to specify an alternative codec.
  • Similarly, using dag put and a store-codec option of dag-pb now requires that the input conform to this dag-pb specified form. Previously, input using {"data":"...","links":[...]} was accepted, now it must be {"Data":"...","Links":[...]}.
  • Previously it was not possible to use paths to navigate to any of these properties of a dag-pb node, the only possible paths were named links, e.g. dag get QmFoo/NamedLink where NamedLink was one of the links whose name was NamedLink. This functionality remains the same, but by prefixing the path with /ipld/ we enter data model pathing semantics and can dag get /ipld/QmFoo/Links/0/Hash to navigate to links or /ipld/QmFoo/Data to simply retrieve the data section of the node, for example.
  • ℹ See the dag-pb specification for details on the codec and its data model representation.
  • ℹ See this detailed write-up for further background on these changes.

Ⓜ Multibase Command

go-ipfs now provides utility commands for working with multibase:

$ echo -n hello | ipfs multibase encode -b base16 > file-mbase16
$ cat file-mbase16
f68656c6c6f

$ ipfs multibase decode file-mbase16
hello

$ cat file-mbase16 | ipfs multibase decode
hello

$ ipfs multibase transcode -b base2 file-mbase16
00110100001100101011011000110110001101111

See ipfs multibase --help for more examples.

🔨 Bitswap now supports greater configurability

This release adds an Internal section to the configuration file that is designed to help advanced users optimize their setups without needing a custom binary. The Internal section is not guaranteed to be the same from release to release and may not be covered by migrations. If you use the Internal section you should be making sure to check the config documentation between releases for any changes.

🐚 Programmatic shell completions command

ipfs commands completion bash will generate a bash completion script for go-ipfs commands

📜 Profile collection command

Performance profiles can now be collected using ipfs diag profile. If you need to do some debugging or have an issue to submit the collected profiles are very useful to have around.

🍎 Mac OS notarized binaries

The go-ipfs and related migration binaries (for both Intel and Apple Sillicon) are now signed and notarized to make Mac OS installation easier.

👨‍👩‍👦 Improved MDNS

There is a completed implementation of the revised libp2p MDNS spec. This should result in better MDNS discovery and better local/offline operation as a result.

🚗 CAR import statistics

dag import command now supports --stats option which will include the number of imported blocks and their total size in the output.

🕸 Peering command

This release adds swarm peering command for easy management of the peering subsystem. Peer in the peering subsystem is maintained to be connected at all times, and gets reconnected on disconnect with a back-off.

See ipfs swarm peering --help for more details.

Changelog

Full Changelog

• github.com/ipfs/go-ipfs:
  • fuse: load unixfs adls as their dagpb substrates
  • enable the legacy mDNS implementation
  • test: add dag get --ouput-codec test
  • change ipfs dag get flag name from format to output-codec
  • test: check behavior of l...

v0.10.0-rc2

Tracking Issue: #8176

v0.10.0-rc1

Tracking Issue: #8176

v0.9.1

go-ipfs v0.9.1 Release

This is a small bug fix release resolving the following issues:

1. A regression where the empty CID bafkqaaa could not resolve on gateways #8230
2. A panic on OpenBSD #8211
3. High CPU usage with QUIC #8256
4. High memory usage with TCP #8219
5. Some pubsub issues (libp2p/go-libp2p-pubsub#427, libp2p/go-libp2p-pubsub#430)
6. Updated WebUI to v2.12.4
7. Fixed the snap deployment #8212

Changelog

Full Changelog

• github.com/ipfs/go-ipfs:
  • chore: update deps
  • feat: webui v2.12.4
  • test: gateway response for bafkqaaa
  • fix: downgrade mimetype dependency
  • update go-libp2p to v0.14.3
  • bump snap to build with Go 1.16
• github.com/libp2p/go-libp2p (v0.14.2 -> v0.14.3):
  • update go-tcp-transport to v0.2.3 and go-multiaddr to v0.3.3 (libp2p/go-libp2p#1121)
• github.com/libp2p/go-libp2p-pubsub (v0.4.1 -> v0.4.2):
  • release priority locks early when handling batches
  • don't respawn writer if we fail to open a stream; declare it a peer error
  • batch process dead peer notifications
  • use a priority lock instead of a semaphore
  • do the notification in a goroutine
  • emit new peer notification without holding the semaphore
  • use a semaphore for new peer notifications so that we don't block the event loop
  • don't accumulate pending goroutines from new connections
  • Make close concurrent safe
  • Fix close of closed channel
• github.com/libp2p/go-libp2p-quic-transport (v0.11.1 -> v0.11.2):
  • update quic-go to v0.21.2
• github.com/libp2p/go-tcp-transport (v0.2.2 -> v0.2.4):
  • collect metrics in a separate go routine (libp2p/go-tcp-transport#82)
  • fix: avoid logging "invalid argument" errors when setting keepalive (libp2p/go-tcp-transport#83)
  • Skip SetKeepAlivePeriod call on OpenBSD (libp2p/go-tcp-transport#80)
  • sync: update CI config files (#79) (libp2p/go-tcp-transport#79)
• github.com/lucas-clemente/quic-go (v0.21.1 -> v0.21.2):
  • update qtls to include the crypto/tls fix of Go 1.16.6 / 1.15.14
  • cancel the PTO timer when all Handshake packets are acknowledged
  • update to Go 1.17rc1
  • update Ginkgo to v1.16.4 and Gomega to v1.13.0 (lucas-clemente/quic-go#3139)
• github.com/multiformats/go-multiaddr (v0.3.2 -> v0.3.3):
  • guard against nil {Local,Remote}Addr() return values (multiformats/go-multiaddr#155)
  • sync: update CI config files (#154) (multiformats/go-multiaddr#154)

❤ Contributors

Contributor	Commits	Lines ±	Files Changed
vyzo	8	+205/-141	12
Marten Seemann	7	+127/-74	11
gammazero	2	+43/-5	3
Steven Allen	1	+13/-2	1
Adin Schmahmann	3	+13/-2	3
Marcin Rataj	2	+9/-1	2
Aaron Bieber	1	+6/-2	1