CBOR RFC 7049 (Go/Golang) - safe & fast with standard API + toarray & keyasint, CBOR tags, float64/32/16, fuzz tested.

Overview

CBOR Library - Slideshow and Latest Docs.

CBOR library in Go

fxamacker/cbor is a CBOR encoder & decoder in Go. It has a standard API, CBOR tags, options for duplicate map keys, float64→32→16, toarray, keyasint, etc. Each release passes 375+ tests and 250+ million execs fuzzing.

CBOR (RFC 7049) is a binary data format inspired by JSON and MessagePack. CBOR is an Internet Standard by IETF used in W3C WebAuthn, COSE (RFC 8152), CWT (RFC 8392 CBOR Web Token), and more.

Go Report Card

fxamacker/cbor is secure. It rejects malformed CBOR data, can detect duplicate map keys, and more.

alt text

For more info, see RFC 7049 Section 8 (Security Considerations).


fxamacker/cbor is easy. It provides standard API and interfaces.

Standard API. Function signatures identical to encoding/json include:
Marshal, Unmarshal, NewEncoder, NewDecoder, (*Encoder).Encode, and (*Decoder).Decode.

Standard Interfaces. Custom encoding and decoding is handled by implementing:
BinaryMarshaler, BinaryUnmarshaler, Marshaler, and Unmarshaler.

It's also designed to simplify concurrency and allow fast parallelism. CBOR options can be used without creating unintended runtime side-effects.


fxamacker/cbor saves time. It has killer features like toarray and keyasint struct tags.


alt text


fxamacker/cbor is a full-featured CBOR encoder and decoder.

alt text


fxamacker/cbor can produce smaller programs that are faster and use less memory.

Click to expand:

CBOR Program Size Comparison

fxamacker/cbor can produce smaller programs.

alt text

CBOR Speed Comparison

fxamacker/cbor can be faster for CBOR data such as CBOR Web Tokens.

alt text

CBOR Memory Comparison

fxamacker/cbor can use less memory for CBOR data such as CBOR Web Tokens.

alt text

Benchmarks used example data from RFC 8392 Appendix A.1 and default options for CBOR libraries.


InstallationSystem RequirementsQuick Start Guide


Why this CBOR library? It doesn't crash and it has well-balanced qualities: small, fast, safe and easy. It also has a standard API, CBOR tags (built-in and user-defined), float64→32→16, and duplicate map key options.

  • Standard API. Codec functions with signatures identical to encoding/json include:
    Marshal, Unmarshal, NewEncoder, NewDecoder, (*Encoder).Encode, and (*Decoder).Decode.

  • Customizable. Standard interfaces are provided to allow user-implemented encoding or decoding:
    BinaryMarshaler, BinaryUnmarshaler, Marshaler, and Unmarshaler.

  • Small apps. Same programs are 4-9 MB smaller by switching to this library. No code gen and the only imported pkg is x448/float16 which is maintained by the same team as this library.

  • Small data. The toarray, keyasint, and omitempty struct tags shrink size of Go structs encoded to CBOR. Integers encode to smallest form that fits. Floats can shrink from float64 -> float32 -> float16 if values fit.

  • Fast. v1.3 became faster than a well-known library that uses unsafe optimizations and code gen. Faster libraries will always exist, but speed is only one factor. This library doesn't use unsafe optimizations or code gen.

  • Safe and reliable. It prevents crashes on malicious CBOR data by using extensive tests, coverage-guided fuzzing, data validation, and avoiding Go's unsafe pkg. Decoder settings include: MaxNestedLevels, MaxArrayElements, MaxMapPairs, and IndefLength.

  • Easy and saves time. Simple (no param) functions return preset EncOptions so you don't have to know the differences between Canonical CBOR and CTAP2 Canonical CBOR to use those standards.

💡 Struct tags are a Go language feature. CBOR tags relate to a CBOR data type (major type 6).

Struct tags for CBOR and JSON like `cbor:"name,omitempty"` and `json:"name,omitempty"` are supported so you can leverage your existing code. If both cbor: and json: tags exist then it will use cbor:.

New struct tags like keyasint and toarray make compact CBOR data such as COSE, CWT, and SenML easier to use.

Quick StartStatusDesign GoalsFeaturesStandardsAPIOptionsUsageFuzzingLicense

Installation

Using Go modules is recommended.

Use "/v2" when using go get.

$ GO111MODULE=on go get github.com/fxamacker/cbor/v2

Also use "/v2" when importing.

import (
	"github.com/fxamacker/cbor/v2" // imports as package "cbor"
)

If Go modules aren't used, delete or modify example_test.go to change the import
from "github.com/fxamacker/cbor/v2" to "github.com/fxamacker/cbor"

System Requirements

Using Go modules is recommended but not required.

  • Go 1.12 (or newer).
  • amd64, arm64, ppc64le and s390x. Other architectures may also work but they are not tested as frequently.

If Go modules feature isn't used, please see Installation about deleting or modifying example_test.go.

Quick Start

🛡️ Use Go's io.LimitReader to limit size when decoding very large or indefinite size data.

Import using "/v2" like this: import "github.com/fxamacker/cbor/v2", and
it will import version 2.x as package "cbor" (when using Go modules).

Functions with identical signatures to encoding/json include:
Marshal, Unmarshal, NewEncoder, NewDecoder, (*Encoder).Encode, (*Decoder).Decode.

Default Mode

If default options are acceptable, package level functions can be used for encoding and decoding.

b, err := cbor.Marshal(v)        // encode v to []byte b

err := cbor.Unmarshal(b, &v)     // decode []byte b to v

encoder := cbor.NewEncoder(w)    // create encoder with io.Writer w

decoder := cbor.NewDecoder(r)    // create decoder with io.Reader r

Modes

If you need to use options or CBOR tags, then you'll want to create a mode.

"Mode" means defined way of encoding or decoding -- it links the standard API to your CBOR options and CBOR tags. This way, you don't pass around options and the API remains identical to encoding/json.

EncMode and DecMode are interfaces created from EncOptions or DecOptions structs.
For example, em, err := cbor.EncOptions{...}.EncMode() or em, err := cbor.CanonicalEncOptions().EncMode().

EncMode and DecMode use immutable options so their behavior won't accidentally change at runtime. Modes are reusable, safe for concurrent use, and allow fast parallelism.

Creating and Using Encoding Modes

💡 Avoid using init(). For best performance, reuse EncMode and DecMode after creating them.

Most apps will probably create one EncMode and DecMode before init(). There's no limit and each can use different options.

// Create EncOptions using either struct literal or a function.
opts := cbor.CanonicalEncOptions()

// If needed, modify opts. For example: opts.Time = cbor.TimeUnix

// Create reusable EncMode interface with immutable options, safe for concurrent use.
em, err := opts.EncMode()   

// Use EncMode like encoding/json, with same function signatures.
b, err := em.Marshal(v)      // encode v to []byte b

encoder := em.NewEncoder(w)  // create encoder with io.Writer w
err := encoder.Encode(v)     // encode v to io.Writer w

Both em.Marshal(v) and encoder.Encode(v) use encoding options specified during creation of encoding mode em.

Creating Modes With CBOR Tags

A TagSet is used to specify CBOR tags.

em, err := opts.EncMode()                  // no tags
em, err := opts.EncModeWithTags(ts)        // immutable tags
em, err := opts.EncModeWithSharedTags(ts)  // mutable shared tags

TagSet and all modes using it are safe for concurrent use. Equivalent API is available for DecMode.

Predefined Encoding Options

func CanonicalEncOptions() EncOptions {}            // settings for RFC 7049 Canonical CBOR
func CTAP2EncOptions() EncOptions {}                // settings for FIDO2 CTAP2 Canonical CBOR
func CoreDetEncOptions() EncOptions {}              // settings from a draft RFC (subject to change)
func PreferredUnsortedEncOptions() EncOptions {}    // settings from a draft RFC (subject to change)

The empty curly braces prevent a syntax highlighting bug on GitHub, please ignore them.

Struct Tags (keyasint, toarray, omitempty)

The keyasint, toarray, and omitempty struct tags make it easy to use compact CBOR message formats. Internet standards often use CBOR arrays and CBOR maps with int keys to save space.

The following sections provide more info:


Quick StartStatusDesign GoalsFeaturesStandardsAPIOptionsUsageFuzzingLicense

Current Status

Latest version is v2.x, which has:

  • Stable API – Six codec function signatures will never change. No breaking API changes for other funcs in same major version. And these two functions are subject to change until the draft RFC is approved by IETF (est. in 2020):
    • CoreDetEncOptions() is subject to change because it uses draft standard.
    • PreferredUnsortedEncOptions() is subject to change because it uses draft standard.
  • Passed all tests – v2.x passed all 375+ tests on amd64, arm64, ppc64le and s390x with linux.
  • Passed fuzzing – v2.2 passed 459+ million execs in coverage-guided fuzzing on Feb 24 (release date)
    and 3.2+ billion execs on March 7, 2020.

Why v2.x?:

v1 required breaking API changes to support new features like CBOR tags, detection of duplicate map keys, and having more functions with identical signatures to encoding/json.

v2.1 is roughly 26% faster and uses 57% fewer allocs than v1.x when decoding COSE and CWT using default options.

Recent Activity:

  • Release v2.1 (Feb. 17, 2020)

    • CBOR tags (major type 6) for encoding and decoding.
    • Decoding options for duplicate map key detection: DupMapKeyQuiet (default) and DupMapKeyEnforcedAPF
    • Decoding optimizations. Structs using keyasint tag (like COSE and CWT) is
      24-28% faster and 53-61% fewer allocs than both v1.5 and v2.0.1.
  • Release v2.2 (Feb. 24, 2020)

    • CBOR BSTR <--> Go byte array (byte slices were already supported)
    • Add more encoding and decoding options (MaxNestedLevels, MaxArrayElements, MaxMapKeyPairs, TagsMd, etc.)
    • Fix potential error when decoding shorter CBOR indef length array to Go array (slice wasn't affected). This bug affects all prior versions of 1.x and 2.x. It was found by a recently updated fxamacker/cbor-fuzz.

Quick StartStatusDesign GoalsFeaturesStandardsAPIOptionsUsageFuzzingLicense

Design Goals

This library is designed to be a generic CBOR encoder and decoder. It was initially created for a WebAuthn (FIDO2) server library, because existing CBOR libraries (in Go) didn't meet certain criteria in 2019.

This library is designed to be:

  • Easy – API is like encoding/json plus keyasint and toarray struct tags.
  • Small – Programs in cisco/senml are 4 MB smaller by switching to this library. In extreme cases programs can be smaller by 9+ MB. No code gen and the only imported pkg is x448/float16 which is maintained by the same team.
  • Safe and reliable – No unsafe pkg, coverage >95%, coverage-guided fuzzing, and data validation to avoid crashes on malformed or malicious data. Decoder settings include: MaxNestedLevels, MaxArrayElements, MaxMapPairs, and IndefLength.

Avoiding unsafe package has benefits. The unsafe package warns:

Packages that import unsafe may be non-portable and are not protected by the Go 1 compatibility guidelines.

All releases prioritize reliability to avoid crashes on decoding malformed CBOR data. See Fuzzing and Coverage.

Competing factors are balanced:

  • Speed vs safety vs size – to keep size small, avoid code generation. For safety, validate data and avoid Go's unsafe pkg. For speed, use safe optimizations such as caching struct metadata. This library is faster than a well-known library that uses unsafe and code gen.
  • Standards compliance vs size – Supports CBOR RFC 7049 with minor limitations. To limit bloat, CBOR tags are supported but not all tags are built-in. The API allows users to add tags that aren't built-in. The API also allows custom encoding and decoding of user-defined Go types.

Click to expand topic:

Supported CBOR Features (Highlights)

alt text

v2.0 API Design

v2.0 decoupled options from CBOR encoding & decoding functions:

  • More encoding/decoding function signatures are identical to encoding/json.
  • More function signatures can remain stable forever.
  • More flexibility for evolving internal data types, optimizations, and concurrency.
  • Features like CBOR tags can be added without more breaking API changes.
  • Options to handle duplicate map keys can be added without more breaking API changes.

Features not in Go's standard library are usually not added. However, the toarray struct tag in ugorji/go was too useful to ignore. It was added in v1.3 when a project mentioned they were using it with CBOR to save disk space.


Quick StartStatusDesign GoalsFeaturesStandardsAPIOptionsUsageFuzzingLicense

Features

Standard API

Many function signatures are identical to encoding/json, including:
Marshal, Unmarshal, NewEncoder, NewDecoder, (*Encoder).Encode, (*Decoder).Decode.

RawMessage can be used to delay CBOR decoding or precompute CBOR encoding, like encoding/json.

Standard interfaces allow user-defined types to have custom CBOR encoding and decoding. They include:
BinaryMarshaler, BinaryUnmarshaler, Marshaler, and Unmarshaler.

Marshaler and Unmarshaler interfaces are satisfied by MarshalCBOR and UnmarshalCBOR functions using same params and return types as Go's MarshalJSON and UnmarshalJSON.

Struct Tags

Support "cbor" and "json" keys in Go's struct tags. If both are specified for the same field, then "cbor" is used.

  • a different field name can be specified, like encoding/json.
  • omitempty omits (ignores) field if value is empty, like encoding/json.
  • - always omits (ignores) field, like encoding/json.
  • keyasint treats fields as elements of CBOR maps with specified int key.
  • toarray treats fields as elements of CBOR arrays.

See Struct Tags for more info.

CBOR Tags (New in v2.1)

There are three broad categories of CBOR tags:

  • Default built-in CBOR tags currently include tag numbers 0 and 1 (Time). Additional default built-in tags in future releases may include tag numbers 2 and 3 (Bignum).

  • Optional built-in CBOR tags may be provided in the future via build flags or optional package(s) to help reduce bloat.

  • User-defined CBOR tags are easy by using TagSet to associate tag numbers to user-defined Go types.

Preferred Serialization

Preferred serialization encodes integers and floating-point values using the fewest bytes possible.

  • Integers are always encoded using the fewest bytes possible.
  • Floating-point values can optionally encode from float64->float32->float16 when values fit.

Compact Data Size

The combination of preferred serialization and struct tags (toarray, keyasint, omitempty) allows very compact data size.

Predefined Encoding Options

Easy-to-use functions (no params) return preset EncOptions struct:
CanonicalEncOptions, CTAP2EncOptions, CoreDetEncOptions, PreferredUnsortedEncOptions

Encoding Options

Integers always encode to the shortest form that preserves value. By default, time values are encoded without tags.

Encoding of other data types and map key sort order are determined by encoder options.

alt text

See Options section for details about each setting.

Decoding Options

alt text

See Options section for details about each setting.

Additional Features

  • Decoder always checks for invalid UTF-8 string errors.
  • Decoder always decodes in-place to slices, maps, and structs.
  • Decoder tries case-sensitive first and falls back to case-insensitive field name match when decoding to structs.
  • Both encoder and decoder support indefinite length CBOR data ("streaming").
  • Both encoder and decoder correctly handles nil slice, map, pointer, and interface values.

Quick StartStatusDesign GoalsFeaturesStandardsAPIOptionsUsageFuzzingLicense

Standards

This library is a full-featured generic CBOR (RFC 7049) encoder and decoder. Notable CBOR features include:

alt text

See the Features section for list of Encoding Options and Decoding Options.

Known limitations are noted in the Limitations section.

Go nil values for slices, maps, pointers, etc. are encoded as CBOR null. Empty slices, maps, etc. are encoded as empty CBOR arrays and maps.

Decoder checks for all required well-formedness errors, including all "subkinds" of syntax errors and too little data.

After well-formedness is verified, basic validity errors are handled as follows:

  • Invalid UTF-8 string: Decoder always checks and returns invalid UTF-8 string error.
  • Duplicate keys in a map: Decoder has options to ignore or enforce rejection of duplicate map keys.

When decoding well-formed CBOR arrays and maps, decoder saves the first error it encounters and continues with the next item. Options to handle this differently may be added in the future.

By default, decoder treats time values of floating-point NaN and Infinity as if they are CBOR Null or CBOR Undefined.

See Options section for detailed settings or Features section for a summary of options.

Click to expand topic:

Duplicate Map Keys

This library provides options for fast detection and rejection of duplicate map keys based on applying a Go-specific data model to CBOR's extended generic data model in order to determine duplicate vs distinct map keys. Detection relies on whether the CBOR map key would be a duplicate "key" when decoded and applied to the user-provided Go map or struct.

DupMapKeyQuiet turns off detection of duplicate map keys. It tries to use a "keep fastest" method by choosing either "keep first" or "keep last" depending on the Go data type.

DupMapKeyEnforcedAPF enforces detection and rejection of duplidate map keys. Decoding stops immediately and returns DupMapKeyError when the first duplicate key is detected. The error includes the duplicate map key and the index number.

APF suffix means "Allow Partial Fill" so the destination map or struct can contain some decoded values at the time of error. It is the caller's responsibility to respond to the DupMapKeyError by discarding the partially filled result if that's required by their protocol.

Tag Validity

This library checks tag validity for built-in tags (currently tag numbers 0 and 1):

  • Inadmissible type for tag content
  • Inadmissible value for tag content

Unknown tag data items (not tag number 0 or 1) are handled in two ways:

  • When decoding into an empty interface, unknown tag data item will be decoded into cbor.Tag data type, which contains tag number and tag content. The tag content will be decoded into the default Go data type for the CBOR data type.
  • When decoding into other Go types, unknown tag data item is decoded into the specified Go type. If Go type is registered with a tag number, the tag number can optionally be verified.

Decoder also has an option to forbid tag data items (treat any tag data item as error) which is specified by protocols such as CTAP2 Canonical CBOR.

For more information, see decoding options and tag options.

Limitations

If any of these limitations prevent you from using this library, please open an issue along with a link to your project.

  • CBOR Undefined (0xf7) value decodes to Go's nil value. CBOR Null (0xf6) more closely matches Go's nil.
  • CBOR map keys with data types not supported by Go for map keys are ignored and an error is returned after continuing to decode remaining items.
  • When using io.Reader interface to read very large or indefinite length CBOR data, Go's io.LimitReader should be used to limit size.

Quick StartStatusDesign GoalsFeaturesStandardsAPIOptionsUsageFuzzingLicense

API

Many function signatures are identical to Go's encoding/json, such as:
Marshal, Unmarshal, NewEncoder, NewDecoder, (*Encoder).Encode, and (*Decoder).Decode.

Interfaces identical or comparable to Go's encoding, encoding/json, or encoding/gob include:
Marshaler, Unmarshaler, BinaryMarshaler, and BinaryUnmarshaler.

Like encoding/json, RawMessage can be used to delay CBOR decoding or precompute CBOR encoding.

"Mode" in this API means defined way of encoding or decoding -- it links the standard API to CBOR options and CBOR tags.

EncMode and DecMode are interfaces created from EncOptions or DecOptions structs.
For example, em, err := cbor.EncOptions{...}.EncMode() or em, err := cbor.CanonicalEncOptions().EncMode().

EncMode and DecMode use immutable options so their behavior won't accidentally change at runtime. Modes are intended to be reused and are safe for concurrent use.

API for Default Mode

If default options are acceptable, then you don't need to create EncMode or DecMode.

Marshal(v interface{}) ([]byte, error)
NewEncoder(w io.Writer) *Encoder

Unmarshal(data []byte, v interface{}) error
NewDecoder(r io.Reader) *Decoder

API for Creating & Using Encoding Modes

// EncMode interface uses immutable options and is safe for concurrent use.
type EncMode interface {
	Marshal(v interface{}) ([]byte, error)
	NewEncoder(w io.Writer) *Encoder
	EncOptions() EncOptions  // returns copy of options
}

// EncOptions specifies encoding options.
type EncOptions struct {
...
}

// EncMode returns an EncMode interface created from EncOptions.
func (opts EncOptions) EncMode() (EncMode, error) {}

// EncModeWithTags returns EncMode with options and tags that are both immutable. 
func (opts EncOptions) EncModeWithTags(tags TagSet) (EncMode, error) {}

// EncModeWithSharedTags returns EncMode with immutable options and mutable shared tags. 
func (opts EncOptions) EncModeWithSharedTags(tags TagSet) (EncMode, error) {}

The empty curly braces prevent a syntax highlighting bug, please ignore them.

API for Predefined Encoding Options

func CanonicalEncOptions() EncOptions {}            // settings for RFC 7049 Canonical CBOR
func CTAP2EncOptions() EncOptions {}                // settings for FIDO2 CTAP2 Canonical CBOR
func CoreDetEncOptions() EncOptions {}              // settings from a draft RFC (subject to change)
func PreferredUnsortedEncOptions() EncOptions {}    // settings from a draft RFC (subject to change)

API for Creating & Using Decoding Modes

// DecMode interface uses immutable options and is safe for concurrent use.
type DecMode interface {
	Unmarshal(data []byte, v interface{}) error
	NewDecoder(r io.Reader) *Decoder
	DecOptions() DecOptions  // returns copy of options
}

// DecOptions specifies decoding options.
type DecOptions struct {
...
}

// DecMode returns a DecMode interface created from DecOptions.
func (opts DecOptions) DecMode() (DecMode, error) {}

// DecModeWithTags returns DecMode with options and tags that are both immutable. 
func (opts DecOptions) DecModeWithTags(tags TagSet) (DecMode, error) {}

// DecModeWithSharedTags returns DecMode with immutable options and mutable shared tags. 
func (opts DecOptions) DecModeWithSharedTags(tags TagSet) (DecMode, error) {}

The empty curly braces prevent a syntax highlighting bug, please ignore them.

API for Using CBOR Tags

TagSet can be used to associate user-defined Go type(s) to tag number(s). It's also used to create EncMode or DecMode. For example, em := EncOptions{...}.EncModeWithTags(ts) or em := EncOptions{...}.EncModeWithSharedTags(ts). This allows every standard API exported by em (like Marshal and NewEncoder) to use the specified tags automatically.

Tag and RawTag can be used to encode/decode a tag number with a Go value, but TagSet is generally recommended.

type TagSet interface {
    // Add adds given tag number(s), content type, and tag options to TagSet.
    Add(opts TagOptions, contentType reflect.Type, num uint64, nestedNum ...uint64) error

    // Remove removes given tag content type from TagSet.
    Remove(contentType reflect.Type)    
}

Tag and RawTag types can also be used to encode/decode tag number with Go value.

type Tag struct {
    Number  uint64
    Content interface{}
}

type RawTag struct {
    Number  uint64
    Content RawMessage
}

See API docs (godoc.org) for more details and more functions. See Usage section for usage and code examples.


Quick StartStatusDesign GoalsFeaturesStandardsAPIOptionsUsageFuzzingLicense

Options

Struct tags, decoding options, and encoding options.

Struct Tags

This library supports both "cbor" and "json" key for some (not all) struct tags. If "cbor" and "json" keys are both present for the same field, then "cbor" key will be used.

Key Format Str Scope Description
cbor or json "myName" field Name of field to use such as "myName", etc. like encoding/json.
cbor or json ",omitempty" field Omit (ignore) this field if value is empty, like encoding/json.
cbor or json "-" field Omit (ignore) this field always, like encoding/json.
cbor ",keyasint" field Treat field as an element of CBOR map with specified int as key.
cbor ",toarray" struct Treat each field as an element of CBOR array. This automatically disables "omitempty" and "keyasint" for all fields in the struct.

The "keyasint" struct tag requires an integer key to be specified:

type myStruct struct {
    MyField     int64    `cbor:-1,keyasint,omitempty`
    OurField    string   `cbor:0,keyasint,omitempty`
    FooField    Foo      `cbor:5,keyasint,omitempty`
    BarField    Bar      `cbor:hello,omitempty`
    ...
}

The "toarray" struct tag requires a special field "_" (underscore) to indicate "toarray" applies to the entire struct:

type myStruct struct {
    _           struct{}    `cbor:",toarray"`
    MyField     int64
    OurField    string
    ...
}

Click to expand:

Example Using CBOR Web Tokens

alt text

Decoding Options

DecOptions.TimeTag Description
DecTagIgnored (default) Tag numbers are ignored (if present) for time values.
DecTagOptional Tag numbers are only checked for validity if present for time values.
DecTagRequired Tag numbers must be provided for time values except for CBOR Null and CBOR Undefined.

The following CBOR time values are decoded as Go's "zero time instant":

  • CBOR Null
  • CBOR Undefined
  • CBOR floating-point NaN
  • CBOR floating-point Infinity

Go's time package provides IsZero function, which reports whether t represents "zero time instant"
(January 1, year 1, 00:00:00 UTC).


DecOptions.DupMapKey Description
DupMapKeyQuiet (default) turns off detection of duplicate map keys. It uses a "keep fastest" method by choosing either "keep first" or "keep last" depending on the Go data type.
DupMapKeyEnforcedAPF enforces detection and rejection of duplidate map keys. Decoding stops immediately and returns DupMapKeyError when the first duplicate key is detected. The error includes the duplicate map key and the index number.

DupMapKeyEnforcedAPF uses "Allow Partial Fill" so the destination map or struct can contain some decoded values at the time of error. Users can respond to the DupMapKeyError by discarding the partially filled result if that's required by their protocol.


DecOptions.IndefLength Description
IndefLengthAllowed (default) allow indefinite length data
IndefLengthForbidden forbid indefinite length data

DecOptions.TagsMd Description
TagsAllowed (default) allow CBOR tags (major type 6)
TagsForbidden forbid CBOR tags (major type 6)

DecOptions.MaxNestedLevels Description
32 (default) allowed setting is [4, 256]

DecOptions.MaxArrayElements Description
131072 (default) allowed setting is [16, 2147483647]

DecOptions.MaxMapPairs Description
131072 (default) allowed setting is [16, 2147483647]

Encoding Options

Integers always encode to the shortest form that preserves value. Encoding of other data types and map key sort order are determined by encoding options.

These functions are provided to create and return a modifiable EncOptions struct with predefined settings.

Predefined EncOptions Description
CanonicalEncOptions() Canonical CBOR (RFC 7049 Section 3.9).
CTAP2EncOptions() CTAP2 Canonical CBOR (FIDO2 CTAP2).
PreferredUnsortedEncOptions() Unsorted, encode float64->float32->float16 when values fit, NaN values encoded as float16 0x7e00.
CoreDetEncOptions() PreferredUnsortedEncOptions() + map keys are sorted bytewise lexicographic.

🌱 CoreDetEncOptions() and PreferredUnsortedEncOptions() are subject to change until the draft RFC they used is approved by IETF.


EncOptions.Sort Description
SortNone (default) No sorting for map keys.
SortLengthFirst Length-first map key ordering.
SortBytewiseLexical Bytewise lexicographic map key ordering
SortCanonical (alias) Same as SortLengthFirst (RFC 7049 Section 3.9)
SortCTAP2 (alias) Same as SortBytewiseLexical (CTAP2 Canonical CBOR).
SortCoreDeterministic (alias) Same as SortBytewiseLexical.

EncOptions.Time Description
TimeUnix (default) (seconds) Encode as integer.
TimeUnixMicro (microseconds) Encode as floating-point. ShortestFloat option determines size.
TimeUnixDynamic (seconds or microseconds) Encode as integer if time doesn't have fractional seconds, otherwise encode as floating-point rounded to microseconds.
TimeRFC3339 (seconds) Encode as RFC 3339 formatted string.
TimeRFC3339Nano (nanoseconds) Encode as RFC3339 formatted string.

EncOptions.TimeTag Description
EncTagNone (default) Tag number will not be encoded for time values.
EncTagRequired Tag number (0 or 1) will be encoded unless time value is undefined/zero-instant.

Undefined Time Values

By default, undefined (zero instant) time values will encode as CBOR Null without tag number for both EncTagNone and EncTagRequired. Although CBOR Undefined might be technically more correct for EncTagRequired, CBOR Undefined might not be supported by other generic decoders and it isn't supported by JSON.

Go's time package provides IsZero function, which reports whether t represents the zero time instant, January 1, year 1, 00:00:00 UTC.


Floating-Point Options

Encoder has 3 types of options for floating-point data: ShortestFloatMode, InfConvertMode, and NaNConvertMode.

EncOptions.ShortestFloat Description
ShortestFloatNone (default) No size conversion. Encode float32 and float64 to CBOR floating-point of same bit-size.
ShortestFloat16 Encode float64 -> float32 -> float16 (IEEE 754 binary16) when values fit.

Conversions for infinity and NaN use InfConvert and NaNConvert settings.

EncOptions.InfConvert Description
InfConvertFloat16 (default) Convert +- infinity to float16 since they always preserve value (recommended)
InfConvertNone Don't convert +- infinity to other representations -- used by CTAP2 Canonical CBOR

EncOptions.NaNConvert Description
NaNConvert7e00 (default) Encode to 0xf97e00 (CBOR float16 = 0x7e00) -- used by RFC 7049 Canonical CBOR.
NaNConvertNone Don't convert NaN to other representations -- used by CTAP2 Canonical CBOR.
NaNConvertQuiet Force quiet bit = 1 and use shortest form that preserves NaN payload.
NaNConvertPreserveSignal Convert to smallest form that preserves value (quit bit unmodified and NaN payload preserved).

EncOptions.IndefLength Description
IndefLengthAllowed (default) allow indefinite length data
IndefLengthForbidden forbid indefinite length data

EncOptions.TagsMd Description
TagsAllowed (default) allow CBOR tags (major type 6)
TagsForbidden forbid CBOR tags (major type 6)

Tag Options

TagOptions specifies how encoder and decoder handle tag number registered with TagSet.

TagOptions.DecTag Description
DecTagIgnored (default) Tag numbers are ignored (if present).
DecTagOptional Tag numbers are only checked for validity if present.
DecTagRequired Tag numbers must be provided except for CBOR Null and CBOR Undefined.

TagOptions.EncTag Description
EncTagNone (default) Tag number will not be encoded.
EncTagRequired Tag number will be encoded.

Quick StartStatusDesign GoalsFeaturesStandardsAPIOptionsUsageFuzzingLicense

Usage

🛡️ Use Go's io.LimitReader to limit size when decoding very large or indefinite size data.

Functions with identical signatures to encoding/json include:
Marshal, Unmarshal, NewEncoder, NewDecoder, (*Encoder).Encode, (*Decoder).Decode.

Default Mode

If default options are acceptable, package level functions can be used for encoding and decoding.

b, err := cbor.Marshal(v)        // encode v to []byte b

err := cbor.Unmarshal(b, &v)     // decode []byte b to v

encoder := cbor.NewEncoder(w)    // create encoder with io.Writer w

decoder := cbor.NewDecoder(r)    // create decoder with io.Reader r

Modes

If you need to use options or CBOR tags, then you'll want to create a mode.

"Mode" means defined way of encoding or decoding -- it links the standard API to your CBOR options and CBOR tags. This way, you don't pass around options and the API remains identical to encoding/json.

EncMode and DecMode are interfaces created from EncOptions or DecOptions structs.
For example, em, err := cbor.EncOptions{...}.EncMode() or em, err := cbor.CanonicalEncOptions().EncMode().

EncMode and DecMode use immutable options so their behavior won't accidentally change at runtime. Modes are reusable, safe for concurrent use, and allow fast parallelism.

Creating and Using Encoding Modes

EncMode is an interface (API) created from EncOptions struct. EncMode uses immutable options after being created and is safe for concurrent use. For best performance, EncMode should be reused.

// Create EncOptions using either struct literal or a function.
opts := cbor.CanonicalEncOptions()

// If needed, modify opts. For example: opts.Time = cbor.TimeUnix

// Create reusable EncMode interface with immutable options, safe for concurrent use.
em, err := opts.EncMode()   

// Use EncMode like encoding/json, with same function signatures.
b, err := em.Marshal(v)      // encode v to []byte b

encoder := em.NewEncoder(w)  // create encoder with io.Writer w
err := encoder.Encode(v)     // encode v to io.Writer w

Struct Tags (keyasint, toarray, omitempty)

The keyasint, toarray, and omitempty struct tags make it easy to use compact CBOR message formats. Internet standards often use CBOR arrays and CBOR maps with int keys to save space.


alt text


Decoding CWT (CBOR Web Token) using keyasint and toarray struct tags:

// Signed CWT is defined in RFC 8392
type signedCWT struct {
	_           struct{} `cbor:",toarray"`
	Protected   []byte
	Unprotected coseHeader
	Payload     []byte
	Signature   []byte
}

// Part of COSE header definition
type coseHeader struct {
	Alg int    `cbor:"1,keyasint,omitempty"`
	Kid []byte `cbor:"4,keyasint,omitempty"`
	IV  []byte `cbor:"5,keyasint,omitempty"`
}

// data is []byte containing signed CWT

var v signedCWT
if err := cbor.Unmarshal(data, &v); err != nil {
	return err
}

Encoding CWT (CBOR Web Token) using keyasint and toarray struct tags:

// Use signedCWT struct defined in "Decoding CWT" example.

var v signedCWT
...
if data, err := cbor.Marshal(v); err != nil {
	return err
}

Encoding and Decoding CWT (CBOR Web Token) with CBOR Tags

// Use signedCWT struct defined in "Decoding CWT" example.

// Create TagSet (safe for concurrency).
tags := cbor.NewTagSet()
// Register tag COSE_Sign1 18 with signedCWT type.
tags.Add(	
	cbor.TagOptions{EncTag: cbor.EncTagRequired, DecTag: cbor.DecTagRequired}, 
	reflect.TypeOf(signedCWT{}), 
	18)

// Create DecMode with immutable tags.
dm, _ := cbor.DecOptions{}.DecModeWithTags(tags)

// Unmarshal to signedCWT with tag support.
var v signedCWT
if err := dm.Unmarshal(data, &v); err != nil {
	return err
}

// Create EncMode with immutable tags.
em, _ := cbor.EncOptions{}.EncModeWithTags(tags)

// Marshal signedCWT with tag number.
if data, err := cbor.Marshal(v); err != nil {
	return err
}

For more examples, see examples_test.go.


Quick StartStatusDesign GoalsFeaturesStandardsAPIOptionsUsageFuzzingLicense

Comparisons

Comparisons are between this newer library and a well-known library that had 1,000+ stars before this library was created. Default build settings for each library were used for all comparisons.

This library is safer. Small malicious CBOR messages are rejected quickly before they exhaust system resources.

alt text

This library is smaller. Programs like senmlCat can be 4 MB smaller by switching to this library. Programs using more complex CBOR data types can be 9.2 MB smaller.

alt text

This library is faster for encoding and decoding CBOR Web Token (CWT). However, speed is only one factor and it can vary depending on data types and sizes. Unlike the other library, this one doesn't use Go's unsafe package or code gen.

alt text

This library uses less memory for encoding and decoding CBOR Web Token (CWT) using test data from RFC 8392 A.1.

alt text

Doing your own comparisons is highly recommended. Use your most common message sizes and data types.


Quick StartStatusDesign GoalsFeaturesStandardsAPIOptionsUsageFuzzingLicense

Benchmarks

Go structs are faster than maps with string keys:

  • decoding into struct is >28% faster than decoding into map.
  • encoding struct is >35% faster than encoding map.

Go structs with keyasint struct tag are faster than maps with integer keys:

  • decoding into struct is >28% faster than decoding into map.
  • encoding struct is >34% faster than encoding map.

Go structs with toarray struct tag are faster than slice:

  • decoding into struct is >15% faster than decoding into slice.
  • encoding struct is >12% faster than encoding slice.

Doing your own benchmarks is highly recommended. Use your most common message sizes and data types.

See Benchmarks for fxamacker/cbor.

Fuzzing and Code Coverage

Over 375 tests must pass on 4 architectures before tagging a release. They include all RFC 7049 examples, bugs found by fuzzing, maliciously crafted CBOR data, and over 87 tests with malformed data.

Code coverage must not fall below 95% when tagging a release. Code coverage is 98.6% (go test -cover) for cbor v2.2 which is among the highest for libraries (in Go) of this type.

Coverage-guided fuzzing must pass 250+ million execs before tagging a release. Fuzzing uses fxamacker/cbor-fuzz. Default corpus has:

Over 1,100 files (corpus) are used for fuzzing because it includes fuzz-generated corpus.

To prevent excessive delays, fuzzing is not restarted for a release if changes are limited to docs and comments.


Quick StartStatusDesign GoalsFeaturesStandardsAPIOptionsUsageFuzzingLicense

Versions and API Changes

This project uses Semantic Versioning, so the API is always backwards compatible unless the major version number changes.

These functions have signatures identical to encoding/json and they will likely never change even after major new releases:
Marshal, Unmarshal, NewEncoder, NewDecoder, (*Encoder).Encode, and (*Decoder).Decode.

Newly added API documented as "subject to change" are excluded from SemVer.

Newly added API in the master branch that has never been release tagged are excluded from SemVer.

Code of Conduct

This project has adopted the Contributor Covenant Code of Conduct. Contact [email protected] with any questions or comments.

Contributing

Please refer to How to Contribute.

Security Policy

Security fixes are provided for the latest released version of fxamacker/cbor.

For the full text of the Security Policy, see SECURITY.md.

Disclaimers

Phrases like "no crashes", "doesn't crash", and "is secure" mean there are no known crash bugs in the latest version based on results of unit tests and coverage-guided fuzzing. They don't imply the software is 100% bug-free or 100% invulnerable to all known and unknown attacks.

Please read the license for additional disclaimers and terms.

Special Thanks

Making this library better

  • Stefan Tatschner for using this library in sep, being the 1st to discover my CBOR library, requesting time.Time in issue #1, and submitting this library in a PR to cbor.io on Aug 12, 2019.
  • Yawning Angel for using this library to oasis-core, and requesting BinaryMarshaler in issue #5.
  • Jernej Kos for requesting RawMessage in issue #11 and offering feedback on v2.1 API for CBOR tags.
  • ZenGround0 for using this library in go-filecoin, filing "toarray" bug in issue #129, and requesting
    CBOR BSTR <--> Go array in #133.
  • Keith Randall for fixing Go bugs and providing workarounds so we don't have to wait for new versions of Go.

Help clarifying CBOR RFC 7049 or 7049bis

  • Carsten Bormann for RFC 7049 (CBOR), adding this library to cbor.io, his fast confirmation to my RFC 7049 errata, approving my pull request to 7049bis, and his patience when I misread a line in 7049bis.
  • Laurence Lundblade for his help on the IETF mailing list for 7049bis and for pointing out on a CBORbis issue that CBOR Undefined might be problematic translating to JSON.
  • Jeffrey Yasskin for his help on the IETF mailing list for 7049bis.

Words of encouragement and support

  • Jakob Borg for his words of encouragement about this library at Go Forum. This is especially appreciated in the early stages when there's a lot of rough edges.

License

Copyright © 2019-present Faye Amacker.

fxamacker/cbor is licensed under the MIT License. See LICENSE for the full license text.


Quick StartStatusDesign GoalsFeaturesStandardsAPIOptionsUsageFuzzingLicense

Issues
  • docs: Fix go.dev and README compatibility

    docs: Fix go.dev and README compatibility

    UPDATE: v2.2 was released a few minutes before midnight on Feb 24, 2020 with only some (less than half) of the README.md markdown tables replaced by SVG tables. go.dev has rendering bugs and doesn't provide a "refresh" button so it was frustrating on Saturday having to wait until Sunday to see if changes look OK. And then waiting for go.dev again on Sunday night.


    All 10-12 tables in README.md are still not rendering properly on go.dev.

    @x448 We should fix this ASAP so v2.2 can be tagged as soon as fuzzing hits required execs.

    Here's a separate repo so we don't have to release tag this project each time README is updated to see if it worked.

    GitHub: https://github.com/fxamacker/godev

    go.dev: https://pkg.go.dev/github.com/fxamacker/godev?tab=overview

    Issue on golang/go for go.dev: https://github.com/golang/go/issues/37284 Issue on golang/go for go.dev: https://github.com/golang/go/issues/37394

    opened by fxamacker 10
  • CBOR security comparisons should include newer malformed CBOR data that cause

    CBOR security comparisons should include newer malformed CBOR data that cause "fatal error: runtime: out of memory"

    CBOR security comparison table only compares fxamacker/cbor to ugorji/go 1.1.7 -- update it to compare with all released versions of ugorji/go using newer malformed CBOR data.

    The old comparison uses two malformed CBOR samples found in September 2019 (https://github.com/oasislabs/oasis-core/issues/2153) that affects ugorji/go 1.1.6 & 1.1.7 but not all of the older versions.

    Newly discovered malformed CBOR samples of tiny size (smaller than "hello world") is confirmed to cause fatal error: runtime: out of memory in these versions of ugorji/go (with only 1 decode attempt required):

    • :fire: ugorji/go 42bc974 (Aug 12, 2019 -- latest commit)
    • :fire: ugorji/go 1.1.7 (Jul 2, 2019 -- latest release)
    • :fire: ugorji/go 1.1.6 (Jul 2, 2019 -- same release date as 1.1.7)
    • :fire: ugorji/go 1.1.5-pre (May 28, 2019)
    • :fire: ugorji/go 1.1.4 (Apr 8, 2019)
    • :question: ugorji/go 1.1.3 (not found on GitHub)
    • :fire: ugorji/go 1.1.2 (Jan 26, 2019)
    • :fire: ugorji/go 1.1.1 (Apr 9, 2018)
    • :fire: ugorji/go 1.1 (Jan 21, 2018 -- first non-beta release)

    Separately, an unrelated project claims to have encountered fatal: morestack on g0 with malformed CBOR when decoded with ugorji (presumably 1.1.4) but I've not confirmed that one yet.

    @fxamacker I'll submit PR updating the comparisons using the new CBOR samples you found and confirmed. Thanks for discovering these, running tests on each version to confirm and making sure fxamacker/cbor properly rejects these new CBOR samples.

    opened by x448 8
  • Who uses fxamacker/cbor v2.2+?

    Who uses fxamacker/cbor v2.2+?

    fxamacker/cbor 2.2 was released on Feb 24, 2020.

    On March 7, 2020, coverage-guided fuzzing passed 3.2 billion execs for fxamacker/cbor 2.2. Projects using older versions are encouraged to upgrade.

    Please ask if you need help upgrading from 1.x to 2.x.


    The 1st two sizable projects are: oasislabs/oasis-core and smartcontractkit/chainlink.

    image

    opened by x448 7
  • Feedback wanted for upcoming v2.1 CBOR tags API

    Feedback wanted for upcoming v2.1 CBOR tags API

    UPDATED (Feb. 5, 2020 10:51 PM CST): added new functions DecModeWithSharedTags and EncModeWithSharedTags in "API Related to CBOR Tags"

    :new: A shared TagSet can be used as a tag registry and any EncMode created with it using EncModeWithSharedTags will automatically use updated tags.


    I'd like to release v2.1 with support for CBOR tags (major type 6) around Feb 9, 2020.

    Your feedback/questions would be appreciated. Please feel free to point out anything I missed.

    Terms used:

    • tag = tag number + tag content.
    • TagSet = Go interface representing a collection of registered tag number + Go type + tag options.

    :point_right: There's no reduction in functionality related to how tag content is encoded or decoded between v1.5 and v2.1. Underlying floats will use their options, BinaryMarshaler and etc. are still supported.

    :point_right: EncMode and DecMode are interfaces created from EncOptions and optionally TagSet. During mode creation, EncOptions and TagSet are copied into private immutable representations.

    EncMode and DecMode are meant to be reused, free from side-effects (changes to TagSet, etc.), and fast/safe for concurrency.

    There's no global tag registry but TagSet can be reused to create multiple EncMode and DecMode interfaces.

    v2.0 - Six Codec Funcs that Will Never Change + SemVer for Other Funcs

    After v2.0, these six codec funcs will never change their signatures and are same as encoding/json:
    Marshal, Unmarshal, NewEncoder, NewDecoder, encoder.Encode, encoder.Decode

    Funcs other than the above six comply with SemVer 2.0 unless marked as "subject to change".

    Functions marked "subject to change" are:

    • CoreDetEncOptions() -- uses draft RFC not yet approved by IETF (est. "later 2020")
    • PreferredUnsortedEncOptions() -- uses draft RFC not yet approved by IETF (est. "later 2020")
    v2.0 - API of EncMode interface

    EncMode interface can be created from EncOptions struct:

    // EncMode interface uses immutable options and is safe for concurrent use.
    type EncMode interface {
        Marshal(v interface{}) ([]byte, error)
        NewEncoder(w io.Writer) *Encoder
        EncOptions() EncOptions  // returns copy of options
    }
    
    v2.0 - Usage of EncMode interface and EncOptions struct

    // Create EncOptions using either struct literal or a function.
    opts := cbor.CanonicalEncOptions()
    
    // If needed, modify encoding options
    opts.Time = cbor.TimeUnix
    
    // Create reusable EncMode interface with immutable options, safe for concurrent use.
    em, err := opts.EncMode()   
    
    // Use EncMode like encoding/json, with same function signatures.
    b, err := em.Marshal(v)
    // or
    encoder := em.NewEncoder(w)
    err := encoder.Encode(v)
    

    If default options are acceptable, then EncMode or DecMode don't need to be created. Package-level codec funcs have same func signatures.

    @x448 updated API and Usage some more after 2.0 release.

    v2.1 - API Related to CBOR Tags

    type Tag struct {
        Number  uint64
        Content interface{}
    }
    
    type RawTag struct {
        Number  uint64
        Content RawMessage
    }
    
    type TagOptions struct {
        DecTag DecTagMode // DecTagIgnored, DecTagOptional, DecTagRequired 
        EncTag EncTagMode // EncTagIgnored, EncTagRequired
    }
    
    type TagSet interface {
        Add(opts TagOptions, tagContentType reflect.Type, tagNum uint64, nestedTagNum ...uint64) error
        Remove(tagContentType reflect.Type)
        ...
    }
    
    func NewTagSet() TagSet 
    
    // DecModeWithTags creates DecMode having immutable copy of TagSet
    func (opts DecOptions) DecModeWithTags(tags TagSet) (DecMode, error) 
    
    // DecModeWithSharedTags creates DecMode having a shared TagSet
    // Changes to TagSet will automatically be used by DecMode
    func (opts DecOptions) DecModeWithSharedTags(tags TagSet) (DecMode, error) 
    
    // EncModeWithTags creates EncMode with given tags
    func (opts EncOptions) EncModeWithTags(tags TagSet) (EncMode, error) 
    
    // EncModeWithSharedTags creates EncMode having a shared TagSet
    // Changes to TagSet will automatically be used by EncMode
    func (opts EncOptions) EncModeWithSharedTags(tags TagSet) (EncMode, error) 
    
    v2.1 - How to register user-defined Go type with tag number

    // User defined type can be on array, float64, int64, map, slice, struct, and etc.
    type MyFloat float64
    
    // Create TagSet.
    tags := NewTagSet()
    
    // Register MyFloat type with tag number 123
    tags.Add(
        TagOptions{DecTag: DecTagRequired, EncTag: EncTagRequired},
        reflect.TypeOf(MyFloat(0.0)), 
        123)
    
    // Create EncMode interface
    em, err := EncOptions{ShortestFloat: cbor.ShortestFloat16}.EncModeWithTags(tags)
    
    // Encode MyFloat value. It'll be tagged 123 and encode using shortest float.
    myFloatBytes, err := em.Marshal(MyFloat(4.56))
    
    // Create DecMode interface
    dm, err := DecOptions{}.DecModeWithTags(tags)
    
    // Decode MyFloat value
    var f MyFloat
    err = dm.Unmarshal(myFloatBytes, &f)
    
    // Modifying TagSet won't affect already-created EncMode or DecMode.
    // This is done to reduce side-effects and simplify concurrency.
    

    Encoder will write tag number 123 and decoder will verify tag number matches what was registered for MyFloat. TagOptions can be set to modify this.

    v2.1 - How to encode Go value with tag number

    This is a one-time encoding for a tag number and tag content. It can be used for encoding tag number with values (not types). For example int64 can't be registered (not user-defined type) so this can be used on an int64 value.

    Use Tag to encode tag number and interface{}.

    taggedFloat := Tag{Number: 123, Content: float64(4.56)}
    b, err := cbor.Marshal(taggedFloat)
    

    Use RawTag to encode tag number and cbor.RawMessage.

    rawMessage := cbor.RawMessage([]byte{131, 2, 3, 4})
    taggedRawMessage := RawTag{Number: 123: Content: rawMessage}
    b, err := cbor.Marshal(taggedRawMessage)
    
    v2.1 - How to extract tag number from CBOR tag

    Use Tag to extract tag number and decode tag content to interface{}

    var tag Tag
    err := cbor.Unmarshal(b, &tag)
    

    Use RawTag to extract tag number and decode tag content to cbor.RawMessage

    var rawTag RawTag
    err := cbor.Unmarshal(b, &rawTag)
    

    Thanks @x448 for v2.0 & v2.1 API ideas. cc @kostko @ZenGround0

    opened by fxamacker 7
  • Support Go byte arrays <--> CBOR byte string (major type 2)

    Support Go byte arrays <--> CBOR byte string (major type 2)

    This is a minor request for something that would be mildly helpful if it is not too much trouble. When attempting to encode a 32 byte array I find that it is unsupported: unsupported type for encoding: [32]uint8.

    Not much trouble in using a wrapper type with Binary marshaling but flagging that this would be useful.

    enhancement 
    opened by ZenGround0 7
  • Release v2.1 (Feb 17, 2020) CBOR Tags and Duplicate Map Key Options

    Release v2.1 (Feb 17, 2020) CBOR Tags and Duplicate Map Key Options

    UPDATED (Feb. 17, 17:00 CST)

    It's all done except release notes and tagging!

    Progress:

    • [x] #44 - Add support for CBOR tags (major type 6)
    • [x] #147 - Decode "keyasint" structs faster and with less memory
    • [x] #125 - Add encoding option to tag or not tag time values
    • [x] #47 - Improve decoding speed (optimizations already identified during v1)
    • [x] Cleanup and fix reported lint issues for #44, #47, #125, #147 changes
    • [x] Basic optimization for CBOR tags feature, more can be done in later releases
    • [x] Decided to combine v2.1 and v2.2 to reduce overhead (fuzzing, docs, benchmarks, charts, etc.)
    • [x] Decided (Un)MarshalerWithMode isn't needed in v2.1.
    • [x] Get feedback on proposed v2.1 API and decide what features to add/modify/remove. See #136.
      • [x] Will add EncModeWithSharedTags (there will be 3 funcs to create EncMode, see table below)
      • [x] Will make sure EncMode, DecMode, and TagSet can be initialized before init()
    • [x] #151 - Implement default encoding for uninitialized time.Time values when tag-required option is specified.

    The above has been pushed to tip. The remaining items will be in a new PR.

    • [x] #122 - Add decoding options for duplicate map keys
    • [x] Cleanup and fix reported lint issues for #122 changes
    • [x] Begin fuzzing for release tag (it won't be restarted for changes limited to docs or tests)
    • [x] Update README.md and benchmarks

    There will be three ways to create EncMode (all are reusable and concurrency safe interface.)

    |Function (returns EncMode) | Encoding Mode | |---------------------------------------------------|------------------------------------------------------------------------------| |EncOptions{...}.EncMode() | immutable options, no tags |:new: EncOptions{...}.EncModeWithTags(ts) | both options & tags are immutable |:new: EncOptions{...}.EncModeWithSharedTags(ts) | immutable options & mutable shared tags |

    To minimize bloat, only tags 0 and 1 (datetime) are going to be part of the default build. The API provides a way for users to register and handle other CBOR tags for user-defined Go types.

    In future releases, additional tags may be provided by the library in a modular way (possibly build flags or optional packages).

    opened by x448 7
  • bug: Can't unmarshal in structure that contains interface field

    bug: Can't unmarshal in structure that contains interface field

    What version of fxamacker/cbor are you using?

    v2.2.0

    Does this issue reproduce with the latest release?

    Yes

    What OS and CPU architecture are you using (go env)?

    go env Output
    $ go env
    GO111MODULE=""
    GOARCH="amd64"
    GOBIN=""
    GOCACHE="/home/yaroslav/.cache/go-build"
    GOENV="/home/yaroslav/.config/go/env"
    GOEXE=""
    GOFLAGS=""
    GOHOSTARCH="amd64"
    GOHOSTOS="linux"
    GOINSECURE=""
    GONOPROXY=""
    GONOSUMDB=""
    GOOS="linux"
    GOPATH="/home/yaroslav/go"
    GOPRIVATE=""
    GOPROXY="https://proxy.golang.org,direct"
    GOROOT="/usr/local/go"
    GOSUMDB="sum.golang.org"
    GOTMPDIR=""
    GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
    GCCGO="gccgo"
    AR="ar"
    CC="gcc"
    CXX="g++"
    CGO_ENABLED="1"
    GOMOD=""
    CGO_CFLAGS="-g -O2"
    CGO_CPPFLAGS=""
    CGO_CXXFLAGS="-g -O2"
    CGO_FFLAGS="-g -O2"
    CGO_LDFLAGS="-g -O2"
    PKG_CONFIG="pkg-config"
    GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build217708215=/tmp/go-build -gno-record-gcc-switches"
    

    What did you do?

    https://play.golang.org/p/JnZ6HLQyFXC

    I tried to unmarshal CBOR into struct that contains interface field. That field initialized with zero value of specific type, so it should be clear for unmarshaler how to unmarshal it. A similar code for encoding/json package works well, but cbor.Unmarshal returns error cbor: cannot unmarshal map into Go struct field main.Outer.2 of type main.TestInterface

    What did you expect to see?

    Unmarshaled data without errors

    What did you see instead?

    Error cbor: cannot unmarshal map into Go struct field main.Outer.2 of type main.TestInterface

    bug 
    opened by yar-resh 6
  • bug: Can't Unmarshal(b, v) if b is CBOR null (0xF6) or CBOR undefined (0xF7) and v is of type **time.Time

    bug: Can't Unmarshal(b, v) if b is CBOR null (0xF6) or CBOR undefined (0xF7) and v is of type **time.Time

    What version of fxamacker/cbor are you using?

    2.2.0

    Does this issue reproduce with the latest release?

    Yes

    What OS and CPU architecture are you using (go env)?

    go env Output
    $ go env
    

    GO111MODULE="" GOARCH="amd64" GOBIN="" GOCACHE="/home/zakaria/.cache/go-build" GOENV="/home/zakaria/.config/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/home/zakaria/go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/usr/local/go" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64" GCCGO="gccgo" AR="ar" CC="gcc" CXX="g++" CGO_ENABLED="1" GOMOD="" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build661418315=/tmp/go-build -gno-record-gcc-switches"

    What did you do?

    https://play.golang.org/p/h4ws0o5srvA

    What did you expect to see?

    I need to store nil time cause I need to store stop time, when stop time is nil that's mean the program is still running.

    What did you see instead?

    panic

    bug has workaround 
    opened by bangzek 6
  • Replace example CBOR program in size comparison chart

    Replace example CBOR program in size comparison chart

    Program size comparison should use existing 3rd-party program(s), instead of one you wrote for solely for comparison.

    If you want, I'll give it a shot and post result(s) here. I'll find IoT and security related projects because they value size, safety and reliability.

    Let me know.

    docs 
    opened by x448 6
  • feature: increase 256 limit for MaxNestedLevels to allow decoding data with larger nesting levels

    feature: increase 256 limit for MaxNestedLevels to allow decoding data with larger nesting levels

    What version of fxamacker/cbor are you using?

    v.2.4.0

    Does this issue reproduce with the latest release?

    Yes

    I have a data structure encoded with serde_cbor from Rust. It's a sparse tree-like object that is a known, but large depth (about 600 levels). I completely understand the rationale behind MaxNestedLevels, and the default being 32 seems sane to me. But why, if I am going out of my way to pick a higher maximum in my decoding options, am I limited to 256 as the max? It means I can't decode this known-good, signed data structure. What was the original rationale behind this particular number for the limit?

    It's also a limit that is seemingly not common in other cbor libraries which can prevent interoperability. Can we remove/increase this maximum and instead put a sentence in the documentation about why you may want to think twice before setting it to a large number?

    What did you expect to see?

    No limit on MaxNestedLevels unless there was a technological limitation or other hard-limit reason for it

    What did you see instead?

    A limit that, for me, is inconveniently low.

    opened by immesys 5
  • feature: add decoding option to specify the go type to use when decoding CBOR maps into `interface{}`

    feature: add decoding option to specify the go type to use when decoding CBOR maps into `interface{}`

    When decoding CBOR to generic interface{}, CBOR maps are decoded as map[interface{}]interface{} go types. Offer a decoding option to change the go map type, e.g. to map[string]interface{}.

    Is your feature request related to a problem? Please describe. I have a server application that communicates with clients through a REST API with JSON data structures. Internally it stores those data structures encoded in CBOR for improved compactness and coding efficiency. In addition, the data structures may be manipulated server-side by plugins that expect the same data types, independent of whether the data was received through the API (unmarshaled JSON) or from server-side storage (unmarshaled CBOR).

    I would like to replace ugorji/cbor with this library, but am running into problems with maps, since they are decoded to map[interface{}]interface{} instead of map[string]interface{} as provided by the json decoder.

    Describe the solution you'd like Add a decoding option MapType that specifies the go map type to use when decoding CBOR maps to interface{}.

    	// MapType specifies the go type to use during schema-less decoding of a CBOR map. 
    	// Defaults to map[interface{}]interface{}.
    	MapType reflect.Type
    

    ugorji/cbor offers this option.

    Describe alternatives you've considered Run a post-unmarshal process that converts the maps. This is slow and ugly.

    Additional context Code snippet that shows the problem: https://go.dev/play/p/84XvSau-7Yt

    An alternative implementation of this feature was previously submitted in pull request #229, but refused because it didn't follow contributor guidelines.

    enhancement 
    opened by lukseven 5
  • Check following extraneous data (#359)

    Check following extraneous data (#359)

    Signed-off-by: Yan Qing [email protected]

    Description

    PR Was Proposed and Welcomed in Currently Open Issue

    • [x] This PR was proposed and welcomed by maintainer(s) in issue #359
    • [x] Closes or Updates Issue #359

    Checklist (for code PR only, ignore for docs PR)

    • [x] Include unit tests that cover the new code
    • [x] Pass all unit tests
    • [x] Pass all 18 ci linters (golint, gosec, staticcheck, etc.)
    • [x] Sign each commit with your real name and email.
      Last line of each commit message should be in this format:
      Signed-off-by: Firstname Lastname [email protected]
    • [x] Certify the Developer's Certificate of Origin 1.1 (see next section).

    Certify the Developer's Certificate of Origin 1.1

    • [x] By marking this item as completed, I certify the Developer Certificate of Origin 1.1.
    Developer Certificate of Origin
    Version 1.1
    
    Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
    660 York Street, Suite 102,
    San Francisco, CA 94110 USA
    
    Everyone is permitted to copy and distribute verbatim copies of this
    license document, but changing it is not allowed.
    
    Developer's Certificate of Origin 1.1
    
    By making a contribution to this project, I certify that:
    
    (a) The contribution was created in whole or in part by me and I
        have the right to submit it under the open source license
        indicated in the file; or
    
    (b) The contribution is based upon previous work that, to the best
        of my knowledge, is covered under an appropriate open source
        license and I have the right under that license to submit that
        work with modifications, whether created in whole or in part
        by me, under the same open source license (unless I am
        permitted to submit under a different license), as indicated
        in the file; or
    
    (c) The contribution was provided directly to me by some other
        person who certified (a), (b) or (c) and I have not modified
        it.
    
    (d) I understand and agree that this project and the contribution
        are public and that a record of the contribution (including all
        personal information I submit with it, including my sign-off) is
        maintained indefinitely and may be redistributed consistent with
        this project or the open source license(s) involved.
    
    opened by zensh 0
  • bug: Unmarshal and Valid should check following extraneous data

    bug: Unmarshal and Valid should check following extraneous data

    What version of fxamacker/cbor are you using?

    v2.4.0

    Does this issue reproduce with the latest release?

    Yes

    What OS and CPU architecture are you using (go env)?

    MacOS, m1

    go env Output
    $ go env
    

    What did you do?

    data := []byte{0, 1, 2, 3}
    err := cbor.Valid(data) // should return a error
    
    var val interface{}
    err = cbor.Unmarshal(data, &val) // should return a error
    

    What did you expect to see?

    What did you see instead?

    enhancement 
    opened by zensh 2
  • Add Fortanix, Tailscale, and National Cybersecurity Agency of France (govt) to notable users

    Add Fortanix, Tailscale, and National Cybersecurity Agency of France (govt) to notable users

    Update list of notable users of fxamacker/cbor:

    • [ ] @fxamacker - mention these in the README text.
    • [ ] @x448 - please add these to the animated banner of notable users. Also, maybe change ContainerSSH link to libcontainerssh instead of auditlog in the banner. :pray:
    docs 
    opened by fxamacker 0
  • Add list of security assessments/audits

    Add list of security assessments/audits

    Microsoft Corporation had NCC Group produce a security assessment (PDF) which includes portions of fxamacker/cbor.

    image

    Please let me know (or post here) if you're authorized to share other security assessments that have this library in its scope.

    docs 
    opened by fxamacker 0
  • add option to enforce nil container marshaling as empty containers

    add option to enforce nil container marshaling as empty containers

    Description

    PR for Issue #351

    PR Was Proposed and Welcomed in Currently Open Issue

    • [ ] This PR was proposed and welcomed by maintainer(s) in issue #351
    • [x] Closes or Updates Issue #351

    Checklist (for code PR only, ignore for docs PR)

    • [x] Include unit tests that cover the new code
    • [x] Pass all unit tests
    • [x] Pass all 18 ci linters (golint, gosec, staticcheck, etc.)
    • [x] Sign each commit with your real name and email.
      Last line of each commit message should be in this format:
      Signed-off-by: Firstname Lastname [email protected]
    • [x] Certify the Developer's Certificate of Origin 1.1 (see next section).

    Certify the Developer's Certificate of Origin 1.1

    • [x] By marking this item as completed, I certify the Developer Certificate of Origin 1.1.
    Developer Certificate of Origin
    Version 1.1
    
    Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
    660 York Street, Suite 102,
    San Francisco, CA 94110 USA
    
    Everyone is permitted to copy and distribute verbatim copies of this
    license document, but changing it is not allowed.
    
    Developer's Certificate of Origin 1.1
    
    By making a contribution to this project, I certify that:
    
    (a) The contribution was created in whole or in part by me and I
        have the right to submit it under the open source license
        indicated in the file; or
    
    (b) The contribution is based upon previous work that, to the best
        of my knowledge, is covered under an appropriate open source
        license and I have the right under that license to submit that
        work with modifications, whether created in whole or in part
        by me, under the same open source license (unless I am
        permitted to submit under a different license), as indicated
        in the file; or
    
    (c) The contribution was provided directly to me by some other
        person who certified (a), (b) or (c) and I have not modified
        it.
    
    (d) I understand and agree that this project and the contribution
        are public and that a record of the contribution (including all
        personal information I submit with it, including my sign-off) is
        maintained indefinitely and may be redistributed consistent with
        this project or the open source license(s) involved.
    
    opened by dedefer 0
  • feature: Encode nil map/slice with cbor empty map/list tag

    feature: Encode nil map/slice with cbor empty map/list tag

    Is your feature request related to a problem? Please describe. I use cbor as a serialization format for rpc between services written in different languages. So when i try to send some structure like

    type Example struct {
      Data map[string]string `cbor:"data"`
    }
    

    I always need to initialize Data explicitly Example{Data: map[string]string{}} because Example{} is serialized to {"data":null}.

    So I need to describe this dto in python like

    class Example:
      data: Optional[dict[str, str]]
    

    despite the fact that this field is required.

    Describe the solution you'd like I think it would be nice to have encoding option to enforce encoder use empty list/map cbor type for nil slice/map.

    opened by dedefer 4
Releases(v2.4.0)
  • v2.4.0(Jan 4, 2022)

    This release adds two user-requested features to the decoder. It passed 3+ billion execs fuzzing before being tagged.

    What's Changed

    • Add option to specify default Go map type when decoding CBOR map into interface{} by @fxamacker in https://github.com/fxamacker/cbor/pull/316
    • Add support for decoding registered CBOR tag to interface type by @fxamacker in https://github.com/fxamacker/cbor/pull/308
    • Update CBOR docs for v2.4.0 by @x448 in https://github.com/fxamacker/cbor/pull/318

    Special Thanks

    • @lukseven for opening issue #303 and proposing a solution
    • @Gui-Yom for issue #301

    Full Changelog: https://github.com/fxamacker/cbor/compare/v2.3.1...v2.4.0

    Source code(tar.gz)
    Source code(zip)
  • v2.3.1(Dec 28, 2021)

    IMPORTANT:

    • This release fixes an important typo in README and omission in CONTRIBUTING.
    • No changes to code outside _test.go files.
    • Changes to non-test files are limited to comments.
    • Next release (v2.4.0) started fuzz testing and is expected to be tagged within 1-2 weeks.

    Changes to v2.3.1 include:

    • Fix typo in docs (example code snippet) that can cause bugs. Thanks @herrjemand!
    • Update CONTRIBUTING to mention signing requirements. Thanks @lukseven and @x448!
    • Update README. Thanks @x448 and @rumpelsepp!
    • Update ci.yml to use Go 1.17.x. Thanks @x448!
    • Add Revive as a lint checker.
    • Cleanup lint messages in _test.go files
    • Cleanup lint messages in non-test files if the changes are limited to comments (no actual coding changes).

    Full Changelog: https://github.com/fxamacker/cbor/compare/v2.3.0...v2.3.1

    Source code(tar.gz)
    Source code(zip)
  • v2.3.0(May 30, 2021)

    Upgrading is recommended: v2.3.0 has bug fixes, is faster, and passed 1+ billion execs fuzzing.

    ⭐ Features and Improvements

    • Add built-in support for big.Int (#209)
    • Add support for tag 55799 self-describing CBOR (#227)
    • Export valid function (#248)
    • Increase user-configurable CBOR limit for MaxArrayElements and MaxMapPairs (#207)
    • Add decoding option to be more strict than encoding/json: fail on CBOR map if destination struct field is not found (#178)
    • Add option for decoding CBOR pos and neg integer to interface{} to not distinguish between uint and int (#216)

    🚀 Performance

    fxamacker/cbor 2.3.0 is faster than 2.2.0 by up to 14% (using CWT and COSE example data from RFCs).

    name                                 old time/op    new time/op    delta
    DecodeCWTClaims-4                      1.34µs ± 0%    1.25µs ± 0%   -6.90%  (p=0.000 n=10+9)
    DecodeCOSE/128-Bit_Symmetric_Key-4     1.01µs ± 0%    0.86µs ± 0%  -14.02%  (p=0.000 n=9+9)
    DecodeCOSE/256-Bit_Symmetric_Key-4     1.02µs ± 0%    0.88µs ± 0%  -13.60%  (p=0.000 n=9+10)
    DecodeCOSE/ECDSA_P256_256-Bit_Key-4    1.69µs ± 0%    1.45µs ± 0%  -14.14%  (p=0.000 n=10+10)
    DecodeWebAuthn-4                       1.46µs ± 0%    1.32µs ± 0%   -9.65%  (p=0.000 n=10+10)
    EncodeCWTClaims-4                       766ns ± 0%     780ns ± 0%   +1.87%  (p=0.000 n=10+10)
    EncodeCOSE/128-Bit_Symmetric_Key-4      910ns ± 0%     908ns ± 0%     ~     (p=0.059 n=9+10)
    EncodeCOSE/256-Bit_Symmetric_Key-4      912ns ± 0%     912ns ± 0%     ~     (p=0.909 n=10+10)
    EncodeCOSE/ECDSA_P256_256-Bit_Key-4    1.13µs ± 1%    1.14µs ± 0%   +0.61%  (p=0.001 n=9+10)
    EncodeWebAuthn-4                        794ns ± 2%     823ns ± 1%   +3.69%  (p=0.000 n=9+10)
    
    fxamacker/cbor 2.3.0 vs ugorji/go 1.2.6

    fxamacker/cbor 2.3.0 (not using unsafe) is faster than ugorji/go 1.2.6 (using unsafe).

    name                                 old time/op    new time/op    delta
    DecodeCWTClaims-4                      2.06µs ± 1%    1.25µs ± 0%  -39.57%  (p=0.000 n=10+9)
    DecodeCOSE/128-Bit_Symmetric_Key-4     1.47µs ± 1%    0.86µs ± 0%  -41.25%  (p=0.000 n=9+9)
    DecodeCOSE/256-Bit_Symmetric_Key-4     1.50µs ± 2%    0.88µs ± 0%  -41.63%  (p=0.000 n=10+10)
    DecodeCOSE/ECDSA_P256_256-Bit_Key-4    2.22µs ± 2%    1.45µs ± 0%  -34.65%  (p=0.000 n=10+10)
    DecodeWebAuthn-4                       1.55µs ± 0%    1.32µs ± 0%  -14.97%  (p=0.000 n=9+10)
    EncodeCWTClaims-4                      1.46µs ± 0%    0.78µs ± 0%  -46.52%  (p=0.000 n=10+10)
    EncodeCOSE/128-Bit_Symmetric_Key-4     1.79µs ± 1%    0.91µs ± 0%  -49.38%  (p=0.000 n=9+10)
    EncodeCOSE/256-Bit_Symmetric_Key-4     1.79µs ± 1%    0.91µs ± 0%  -49.15%  (p=0.000 n=10+10)
    EncodeCOSE/ECDSA_P256_256-Bit_Key-4    2.09µs ± 1%    1.14µs ± 0%  -45.41%  (p=0.000 n=10+10)
    EncodeWebAuthn-4                        981ns ± 0%     823ns ± 1%  -16.05%  (p=0.000 n=10+10)
    
    name                                 old alloc/op   new alloc/op   delta
    DecodeCWTClaims-4                        760B ± 0%      176B ± 0%  -76.84%  (p=0.000 n=10+10)
    DecodeCOSE/128-Bit_Symmetric_Key-4       800B ± 0%      240B ± 0%  -70.00%  (p=0.000 n=10+10)
    DecodeCOSE/256-Bit_Symmetric_Key-4       816B ± 0%      256B ± 0%  -68.63%  (p=0.000 n=10+10)
    DecodeCOSE/ECDSA_P256_256-Bit_Key-4      913B ± 0%      352B ± 0%  -61.45%  (p=0.000 n=10+10)
    DecodeWebAuthn-4                       1.56kB ± 0%    0.99kB ± 0%  -36.41%  (p=0.000 n=10+10)
    EncodeCWTClaims-4                      1.36kB ± 0%    0.18kB ± 0%  -87.06%  (p=0.000 n=10+10)
    EncodeCOSE/128-Bit_Symmetric_Key-4     1.97kB ± 0%    0.22kB ± 0%  -88.62%  (p=0.000 n=10+10)
    EncodeCOSE/256-Bit_Symmetric_Key-4     1.97kB ± 0%    0.24kB ± 0%  -87.80%  (p=0.000 n=10+10)
    EncodeCOSE/ECDSA_P256_256-Bit_Key-4    1.97kB ± 0%    0.32kB ± 0%  -83.74%  (p=0.000 n=10+10)
    EncodeWebAuthn-4                       1.31kB ± 0%    1.09kB ± 0%  -17.07%  (p=0.000 n=10+10)
    
    name                                 old allocs/op  new allocs/op  delta
    DecodeCWTClaims-4                        6.00 ± 0%      6.00 ± 0%     ~     (all equal)
    DecodeCOSE/128-Bit_Symmetric_Key-4       4.00 ± 0%      4.00 ± 0%     ~     (all equal)
    DecodeCOSE/256-Bit_Symmetric_Key-4       4.00 ± 0%      4.00 ± 0%     ~     (all equal)
    DecodeCOSE/ECDSA_P256_256-Bit_Key-4      7.00 ± 0%      7.00 ± 0%     ~     (all equal)
    DecodeWebAuthn-4                         5.00 ± 0%      5.00 ± 0%     ~     (all equal)
    EncodeCWTClaims-4                        4.00 ± 0%      2.00 ± 0%  -50.00%  (p=0.000 n=10+10)
    EncodeCOSE/128-Bit_Symmetric_Key-4       6.00 ± 0%      2.00 ± 0%  -66.67%  (p=0.000 n=10+10)
    EncodeCOSE/256-Bit_Symmetric_Key-4       6.00 ± 0%      2.00 ± 0%  -66.67%  (p=0.000 n=10+10)
    EncodeCOSE/ECDSA_P256_256-Bit_Key-4      6.00 ± 0%      2.00 ± 0%  -66.67%  (p=0.000 n=10+10)
    EncodeWebAuthn-4                         4.00 ± 0%      2.00 ± 0%  -50.00%  (p=0.000 n=10+10)
    

    Benchmarks used Go 1.15.12 on linux_amd64. Benchmark results are data dependent so run them using your own data.

    🐞 Bug Fixes

    • Allow decoding to struct field of interface type (#260, #275)
    • Decoding registered tag to empty interface should return object of registered type (#223)
    • Fix: encoding cbor.RawTag with empty content returns malformed CBOR data (#258)
    • Fix: encoding uninitialized cbor.(Raw)Tag returns malformed CBOR data (#256)
    • Decoding CBOR null to time.Time should have no effect (#254)
    • Fix: decoding CBOR null to cbor.Tag shouldn't return any error (#252)
    • Properly handle empty values for custom types (#232)
    • Decoding should ignore CBOR tag number 55799 when it is a prefix (#228)
    • Validate CBOR tag content type if tag number is 0 or 1, even when TimeTag = DecTagIgnored (#221)
    • Registering tag (TagSet.Add) with already registered tag number should be rejected (#218)
    • DecOptions.ExtraReturnErrors field should be typed #240

    📖 Docs

    • Make README more friendly to dark themes (#269)
    • Private member struct tag (json:"-" and cbor:"-") are supported but not documented (#201)
    • TagOptions struct is missing from README.md (#199)
    • Fix go.dev and README compatibility (#173)
    • Replace CBOR "draft RFC" with CBOR "RFC 8949" because it was approved by IETF (#265)

    🏗️ Chores

    • Audit library for any missing attribution for code snippets from sources other than Go's stdlib (#237)
    • Audit library for any missing attribution for code snippets from Go's stdlib (encoding/json) (#233)
    • Create pull request template for code contributions (#197)
    • CI: Use safer-golangci-lint.yml GitHub Action Workflow contributed by @x448
    • CI: Bump golangci-lint to 1.40.1
    • CI: Use CodeQL analysis

    🧪 Tests and Fuzzing

    • Code coverage remains above 98%.
    • Coverage-guided fuzzing reached 1+ billion execs ~2 days after v2.3.0 release.

    👍 Special Thanks

    • Special thanks to @kostko, @turbolent, @x448, @yawning and others for reporting bugs, providing feedback, and more.

    ⛈️ Winter Storm Uri Displaced Me (still at a hotel 3+ months later)

    • As of May 30, I'm still displaced due to Winter Storm Uri started causing damage on February 16. Fire sprinklers started leaking, pipes shattered in the ceilings, and water outage lasted 2+ weeks.
    Source code(tar.gz)
    Source code(zip)
  • v2.2.0(Feb 25, 2020)

    IMPORTANT: This release fixes a bug that affects all prior versions (1.x and 2.x). Please update if you use Go arrays instead of slices with CBOR indef length arrays. Bug was detected by newer fxamacker/cbor-fuzz.

    v2.2 is a small release and is the most reliable version currently available.

    Changes include:

    • Feat: Support decoding CBOR byte string (major type 2) to Go byte array. (commit 52db071). Thanks @ZenGround0 for requesting this feature.
    • Feat: Add more decoding options (MaxNestedLevels, MaxArrayElements, MaxMapKeyPairs, IndefLength, TagsMd.) (commit cb23445)
    • Feat: Add more encoding options (IndefLength, TagsMd.) (commit cb23445)
    • Fix: Fix potential error when decoding shorter CBOR indef length array to Go array (slice wasn't affected). This bug affects all prior versions of 1.x and 2.x. (commit c7f2cc7)
    • Docs: Replace README.md markdown tables with SVG tables to work around go.dev bugs. Less than half were replaced to avoid delaying this release. Thanks @x448 for working on this!

    v2.2 passed 473+ million execs of coverage-guided fuzzing on Feb 24, 2020. UPDATE: v2.2 passed 3.2+ billion execs of coverage-guided fuzzing on Mar 7, 2020.

    Source code(tar.gz)
    Source code(zip)
  • v2.1.0(Feb 17, 2020)

    This release focused on three items:

    • CBOR tags (major type 6) for encoding and decoding
    • Duplicate map key detection options for decoding
    • Faster decoding with less memory use (to help offset overhead of new features)

    Decoding got faster and memory use dropped more than expected, especially for 'keyasint' structs.

    Here's how this library compares to another one using default options and test data from RFC 8392 A.1. | | fxamacker/cbor 2.1 |ugorji/go 1.1.7 | |-------------------|-----------------------------|----------------------------------| |Encode CWT claims | 457 ns/op, 176 B/op, 2 allocs/op | 995 ns/op, 1424 B/op, 4 allocs/op |Decode CWT claims | 796 ns/op, 176 B/op, 6 allocs/op | 1105 ns/op, 568 B/op, 6 allocs/op

    Changes include:

    • [x] #44 - Add support for CBOR tags (major type 6) with API for built-in and user-defined tags
    • [x] #122 - Add decoding options for duplicate map keys
    • [x] #147 - Decode "keyasint" structs 26% faster and with 57% fewer allocs (COSE, CWT, etc.)
    • [x] #125 - Add encoding option to tag or not tag time values
    • [x] #47 - Improve decoding speed (optimizations already identified during v1)
    • [x] Basic optimization for CBOR tags feature, more can be done in later releases
    • [x] #151 - Implement default encoding for uninitialized time.Time values when tag-required option is specified.
    • [x] Update README.md and benchmarks

    There will be three ways to create EncMode (and similar API for DecMode):

    |Function (returns EncMode) | Encoding Mode | |---------------------------------------------------|------------------------------------------------------------------------------| |EncOptions{...}.EncMode() | immutable options, no tags |:new: EncOptions{...}.EncModeWithTags(ts) | both options & tags are immutable |:new: EncOptions{...}.EncModeWithSharedTags(ts) | immutable options & mutable shared tags |

    To minimize bloat, only tags 0 and 1 (datetime) are going to be part of the default build. The API provides a way for users to register and handle other CBOR tags for user-defined Go types.

    In future releases, additional tags may be provided by the library in a modular way (possibly build flags or optional packages).

    Special Thanks

    @x448 for helping with v2.1 API, docs, and providing the general idea for DupMapKeyEnforcedAPF.
    @kostko for providing feedback on the draft v2.1 API for CBOR tags.
    @laurencelundblade for providing feedback to @x448 regarding CBOR Null & Undef interop with JSON.
    @ZenGround0 for using this library in go-filecoin and requesting a useful feature that'll be in v2.2.

    v2.1 fuzzing passed 380+ million execs before release, and passed 2.1+ billion execs on Feb 21, 2020.

    Source code(tar.gz)
    Source code(zip)
  • v1.5.1(Feb 10, 2020)

    This release is outdated. Upgrading to v2.0.1 or newer is recommended.

    Changes include:

    • Backport v2.0 fix to v1.5 (sanitize decoded NaN and Infinity time values.) See issue #141.
    • Add more unit tests for floating-point data.

    Fuzzing passed 500+ million execs on Feb 9, 2020.

    Source code(tar.gz)
    Source code(zip)
  • v2.0.1(Feb 6, 2020)

    Changes include:

    • Fix: API bug introduced in v2.0.0 with (Un)Marshaler and (Un)MarshalerWithMode interface mixup
    • Fix: Reject CBOR non-array data for structs decorated with "toarray"

    More at #129 and #137.

    Special thanks to ZenGround0 for reporting issues.

    v2.0.1 passed 300+ million execs fuzzing at time of release. v2.0.1 passed 2+ billion execs fuzzing on Feb 9, 2020.

    Source code(tar.gz)
    Source code(zip)
  • v2.0.0(Feb 3, 2020)

    Changes in v2.0:

    • Improved API.
    • Faster performance.
    • Reduced memory usage.
    • Improved code quality using around 20 linters.
    • Replaced EncOptions.TimeRFC3339 bool with TimeMode (5 settings).
    • Decode NaN and Infinity time values to Go's "zero time" value.
    • Removed deprecated v1 options and Valid() function.
    • Many improvements to README.md.

    Why 2.0?

    v2 decoupled options from encoding/decoding functions so that:

    • new features like CBOR tags can be added without breaking API changes.
    • more encoding/decoding function signatures are identical to encoding/json.
    • more function signatures can remain stable forever even as CBOR options & tags evolve.

    Roadmap

    • v2.1 (Feb. 9, 2020) support for CBOR tags (major type 6) and some decoder optimizations.
    • v2.2 (Feb. 2020) options for handling duplicate map keys.

    CBOR Tags (major type 6) was moved to milestone v2.1. and is over 50% done.

    Status

    v2.0 passed 1+ billion execs in coverage-guided fuzzing before release. This is the most well-tested and most reliable release of this library. Upgrading is highly recommended.

    Improved API

    More function signatures match encoding/json. These will never change their parameters or return types: Marshal, Unmarshal, NewEncoder, NewDecoder, encoder.Encode, decoder.Decode.

    "Mode" in this API means definite way of encoding or decoding.

    EncMode and DecMode are interfaces created from EncOptions or DecOptions structs.

    EncMode and DecMode use immutable options so their behavior won't accidentally change at runtime. Modes are intended to be reused and are safe for concurrent use.

    // Create EncOptions, using either struct literal or a function.
    opts := cbor.CanonicalEncOptions()
    
    // If needed, modify options -- e.g. how time values should be encoded.
    opts.Time = cbor.TimeUnix
    
    // Create reusable EncMode interface with immutable options, safe for concurrent use.
    em, err := opts.EncMode()   
    
    // Use EncMode like encoding/json, with same function signatures.
    b, err := em.Marshal(v)
    // or
    encoder := em.NewEncoder(w)
    err := encoder.Encode(v)
    

    Package Level Functions

    These package level functions use default options without CBOR tags. Their API matches encoding/json. EncMode and DecMode also provide these functions with same signatures.

    b, err := cbor.Marshal(v)
    err := cbor.Unmarshal(b, &v)
    encoder := cbor.NewEncoder(w)
    decoder := cbor.NewDecoder(r)
    

    EncOptions.Time

    Replaced EncOptions.TimeRFC3339 bool with TimeMode:

    • TimeUnix // secs, encodes to CBOR integer using fewest bytes
    • TimeUnixMicro // μs, encodes to CBOR float with subsecs in fractional part
    • TimeUnixDynamic // secs or μs, encodes to either int or float depending on empty subsecs
    • TimeRFC3339 // secs, encodes to string
    • TimeRFC3339Nano // ns, encodes to string with trailing zeros removed
    Source code(tar.gz)
    Source code(zip)
  • v1.5.0(Jan 13, 2020)

    This release adds encoding options while maintaining backward compatibility.

    With EncOptions.ShortestFloat = ShortestFloat16, floating-point values (including subnormals) encode float64 -> float32 -> float16 when values can round-trip. This is optimized by avoiding the round-trip test except for a subset of subnormal input values and using a faster test for other values.

    Conversions for infinity and NaN use InfConvert and NaNConvert settings.

    New functions like CanonicalEncOptions(), CTAP2EncOptions(), etc. return predefined EncOptions that can be modified to create custom configurations.

    Changes include:

    • Use x448/float16 (same team as this library) because all 4+ billion possible conversions are tested.
    • Feature: Add funcs that return predefined EncOptions (commit b7b5733, e203b29)
      • CanonicalEncOptions() -- Canonical CBOR (RFC 7049)
      • CTAP2EncOptions() -- CTAP2 Canonical CBOR
      • CoreDetEncOptions() -- Core Deterministic Encoding (draft RFC, subject to change)
      • PreferredUnsortedEncOptions() - Preferred unsorted serialization (draft RFC, subject to change)
    • Feature: Add ShortestFloat option for encoding (commit 29e78ee)
      • ShortestFloatNone (default)
      • ShortestFloat16
    • Feature: Add NanConvertMode for encoding (commit 16c573c)
      • NaNConvertNone
      • NanConvert7e00
      • NanConvertQuiet
      • NaNConvertPreserveSignal
    • Feature: Add InfConvertMode for encoding (commit 16c573c)
      • InfConvertNone
      • InfConvertFloat16
    • Refactor and improve quality of code, docs, and tests

    UPDATE: Fuzzing passed 4.75+ billion execs with Go 1.12 on Jan. 22, 2020.
    Fuzzing passed 2.88+ billion execs with Go 1.13 on Jan. 31, 2020 (slower machine).

    Source code(tar.gz)
    Source code(zip)
  • v1.4.0(Dec 25, 2019)

    Release v1.4.0 (Dec 25, 2019)

    Changes include:

    • Feature: Deprecate bool encoding options and add int SortMode (commit 3b78ee0)
    • Reliability: Use float16 to float32 conversion func that had all 65536 results verified to be correct (commit 48850b2)
    • Fix: Fix decoding of float16 subnormal numbers (commit 48850b2)

    Fuzzing passed 532+ million execs with Go 1.12 at the time of release.
    Fuzzing passed 4+ billion execs with Go 1.13 about 17-18 days after release.

    Source code(tar.gz)
    Source code(zip)
  • v1.3.4(Dec 19, 2019)

    Release v1.3.4 (Dec 18, 2019)

    v1.3.1 to v.1.3.4 benefited from extensive code review and refactoring.

    Changes include:

    • Fix: Limit nested levels to 32 for arrays, maps, tags to prevent stack exhaustion exploits (commit 3aa4328)
    • Fix: Fix error when decoding to not-nil interface (commit d26d3cd)
    • Misc: Refactor to improve readability and maintainability (commit d2d6a95)

    Fuzzing reached 370+ million execs with Go 1.12 at the time of release.

    Update: On Dec. 25, 2019, fuzzing passed 2+ billion execs with Go 1.13.

    corpus: 1092 (46h8m ago), crashers: 0, restarts: 1/10000, execs: 2028736632 (3194/sec), cover: 2006, uptime: 176h27m
    
    Source code(tar.gz)
    Source code(zip)
  • v1.3.3(Dec 10, 2019)

    Release v1.3.3 (Dec 9, 2019)

    Changes include:

    • Fix: Fix panic when encoding new type with float32 as its underlying type (commit bb1c06a)
    • Fix: Change CBOR string validation error from SemanticError to SyntaxError (commit acaec05)
    • Fix: Reject CBOR indefinite length byte/text string with tagged chunks (commit 28e2c0b)
    • Fix: Reject CBOR indefinite length text string with invalid UTF-8 chunks (commit 9f1f677)
    • Misc: Add unit tests based on latest 7049bis and remove tests made redundant by this (commit ac1c292)

    Fuzzing reached 276+ million execs at the time of release.

    UPDATE: It continued fuzzing and reached 2.79+ billion execs about 8 days after release.

    workers: 2, corpus: 1074 (44h26m ago), crashers: 0, restarts: 1/10000, execs: 2796329664 (3386/sec), cover: 2011, uptime: 229h25m
    
    Source code(tar.gz)
    Source code(zip)
  • v1.3.2(Nov 27, 2019)

    Release v1.3.2 (Nov 27, 2019)

    This release checks for additional issues while decoding well-formed CBOR messages.

    Changes include:

    • Skip CBOR array/map elements on incompatible Go type
    • Check if CBOR type can be used as Go map key when map key type is interface{}

    A separate project, cbor-fuzz was updated to use new fxamacker/cbor features it had missed. Cover is noticably higher (better) during fuzzing.

    UPDATE: Fuzzing reached 4.2+ billion execs on Dec 3, 2019. Corpus is temporarily low (as shown here) for v1.3.2, but it's already 1000+ after combining Go 1.12 + Go 1.13 fuzzing corpus folders after this run.

    2019/12/03 15:37:19 workers: 2, corpus: 602 (12h17m ago), crashers: 0, restarts: 1/10000, execs: 4226276531 (7203/sec), cover: 2000, uptime: 162h59m
    
    Source code(tar.gz)
    Source code(zip)
  • v1.3.1(Nov 24, 2019)

    Release v1.3.1 (Nov 24, 2019)

    Issue #46 resulted in filing an errata to RFC 7049 (CBOR) after the same mistake was found in both 7049 and Wikipedia. RFC 7049 author (cabo) confirmed within an hour directly in #46 which was super nice of him.

    I'll let fuzzing continue for 1-10 days, due in part to issue #46 and initial valid fuzzing corpus. Maybe it'll generate fewer corpus files this time to reach a good stopping point.

    Most users of v1.3.0 won't notice any practical difference from these bugfixes. They involve data validation rules and an obscure difference in sorting rule for canonical encoding.

    Changes include:

    • Fix: Relax decoding restriction on CBOR int to Go float (commit 71ea0c5)
    • Fix: Separate CTAP2 and RFC 7049 canonical encoding (commit 7164aa3)
    • Fix: Reject indefinite-length byte/text string if chunks are indefinite-length (commit a4adae8)
    • Fix: Reject CBOR primitive 2-byte simple value < 32 (commit aa44241)

    This release passed 877k+ executions (19 hours, and still running) of coverage-guided fuzzing using fxamacker/cbor-fuzz.

    workers: 2, corpus: 403 (48s ago), crashers: 0, restarts: 1/10000, execs: 877930249 (12405/sec), cover: 1501, uptime: 19h39m
    
    Source code(tar.gz)
    Source code(zip)
  • v1.3.0(Nov 21, 2019)

    New struct tags "keyasint" and "toarray" make it easy to use Go structs with CBOR maps and arrays. Using COSE, CWT, SenML, etc. is more natural with less programming effort.

    Encoding and decoding speed is faster than prior releases due to safe optimizations. Encoding speed and structs got the biggest speedups.

    Benchmark comparisons are hard in v1.3 because older releases lack "keyasint" and "toarray". Some of the biggest speedups are from no longer having to use Go maps with COSE, CWT, SenML, etc.

    Specific changes include:

    • Feature: Encode/Decode CBOR map with integer keys to Go struct with "keyasint" struct tag (commit 3cbdc26)
    • Feature: Encode/Decode CBOR array to Go struct with "toarray" struct tag (commit 07c8226)
    • Fix: Skip embedded struct pointed to by nil pointer during encoding (commit 593ee34)
    • Speed: Improve decoding speed (commit 726c423, 23d2052)
    • Speed: Improve encoding speed (commit 8ea465d, d85552b, 90423eb, 05e6b7c)
    • Misc: Refactor (commit ca1f6f1, be23d57, 1e745c3)
    • Misc: Add examples and benchmarks (commit 61d7682, 2964577, 6c17db7)

    This release passed 2+ billion executions (72 hours) of coverage-guided fuzzing using fxamacker/cbor-fuzz v0.7.0:

    workers: 2, corpus: 719 (72h27m ago), crashers: 0, restarts: 1/10000, execs: 2275843330 (8725/sec), cover: 1492, uptime: 72h27m
    
    Source code(tar.gz)
    Source code(zip)
  • v1.2.0(Nov 5, 2019)

    Changes include:

    • Feature: Add RawMessage, Marshaler, and Unmarshaler (commit 1a2918702e980f0776663d11290dfe40e20a8c08)
    • Speed: Improve decoding into struct speed by +23% (commit 9ff43a1d5d7c0f17829546218632897ecef7a993)
    • Fix: Return error on decoding unsupported CBOR neg int (commit 47055e770d43a9920be073d7f62c47b72011ed8c)
    • Misc: Add benchmarks using COSE and WebAuthn data (commit 22732d743c17ebb631411c45d3ea3b9a7fff2d7f)
    • Misc: Add more tests, including malicious CBOR data (credit: oasislabs/oasis-core)
    • Misc: Update README.md

    This release passed 42 hours of fuzzing with fxamacker/cbor-fuzz v0.7.0.

    Source code(tar.gz)
    Source code(zip)
  • v1.1.2(Oct 23, 2019)

    Prevent an inappropriate use of BinaryUnmarshaler.

    Specifically, don't allow CBOR byte string (major type 2) as input to Go's Time.UnmarshalBinary.

    Time values should only be encoded/decoded using these CBOR data types: pos or neg integer, float, and text string. For more info, see RFC 7049 section 2.4.1.

    For details, see commit 34ffc3a3fd37df109c2ea1887de5ec8848a11fd8.

    This release passed 24+ hours of fuzzing with fxamacker/cbor-fuzz v0.6.0.

    Source code(tar.gz)
    Source code(zip)
  • v1.1.1(Oct 18, 2019)

  • v1.1.0(Oct 8, 2019)

    Add support for encoding.BinaryMarshaler and encoding.BinaryUnmarshaler interfaces.

    • Encoder encodes value implementing encoding.BinaryMarshaler as CBOR byte string.
    • Decoder decodes CBOR byte string into a value implementing encoding.BinaryUnmarshaler.

    For details, see commit 602ddc7 closing Issue #5.

    Source code(tar.gz)
    Source code(zip)
  • v1.0.1(Oct 8, 2019)

  • v1.0.0(Sep 29, 2019)

  • v0.5.0(Sep 15, 2019)

    Refactored and improved test coverage to 97%:

    • Removed unused type InvalidValueError.
    • Refactored and removed unreachable code (redundant error/bounds checking).
    • Added tests for edge cases.
    • Reduced compiled library size.
    Source code(tar.gz)
    Source code(zip)
  • v0.4.0(Sep 11, 2019)

  • v0.3.0(Sep 3, 2019)

    Add encoding and decoding support for time.Time.

    • Encode time.Time values as RFC 3339 formatted text strings when EncOptions.TimeRFC3339 is true; otherwise, encode time.Time values as Unix time.
    • Decode RFC 3339 formatted text strings, or numerical representation of Unix time into time.Time.
    Source code(tar.gz)
    Source code(zip)
  • v0.2.0(Sep 1, 2019)

  • v0.1.1(Sep 1, 2019)

    cbor will only support Go 1.12 and newer. This allows cbor to use new API in reflect package for performance gain.

    This release includes bug fixes, performance improvements, and documentation updates, detailed below.

    Changelog:

    • Fix decoding nil into struct field of type pointer (commit 420e2c0)
    • Fix encoding byte array as CBOR byte string (commit a4fface)
    • Improve map encoding performance and memory allocation (commit 224b632)
    Source code(tar.gz)
    Source code(zip)
Owner
Faye Amacker
Faye Amacker
A standard way to wrap a proto message

Welcome to Pletter ?? A standard way to wrap a proto message Pletter was born with a single mission: To standardize wrapping protocol buffer messages.

Lykon 18 May 17, 2022
csvutil provides fast and idiomatic mapping between CSV and Go (golang) values.

csvutil Package csvutil provides fast and idiomatic mapping between CSV and Go (golang) values. This package does not provide a CSV parser itself, it

Jacek Szwec 736 Aug 5, 2022
Fast implementation of base58 encoding on golang.

Fast Implementation of Base58 encoding Fast implementation of base58 encoding in Go. Base algorithm is adapted from https://github.com/trezor/trezor-c

Denis Subbotin 123 Jul 7, 2022
Asn.1 BER and DER encoding library for golang.

WARNING This repo has been archived! NO further developement will be made in the foreseen future. asn1 -- import "github.com/PromonLogicalis/asn1" Pac

Logicalis 50 Apr 8, 2022
auto-generate capnproto schema from your golang source files. Depends on go-capnproto-1.0 at https://github.com/glycerine/go-capnproto

bambam: auto-generate capnproto schema from your golang source files. Adding capnproto serialization to an existing Go project used to mean writing a

Jason E. Aten, Ph.D. 64 Jan 29, 2022
Golang binary decoder for mapping data into the structure

binstruct Golang binary decoder to structure Install go get -u github.com/ghostiam/binstruct Examples ZIP decoder PNG decoder Use For struct From file

Vladislav Fursov 56 Jul 18, 2022
Fixed width file parser (encoder/decoder) in GO (golang)

Fixed width file parser (encoder/decoder) for GO (golang) This library is using to parse fixed-width table data like: Name Address

Oleg Lobanov 20 Mar 4, 2022
msgpack.org[Go] MessagePack encoding for Golang

MessagePack encoding for Golang ❤️ Uptrace.dev - All-in-one tool to optimize performance and monitor errors & logs Join Discord to ask questions. Docu

Vladimir Mihailenco 1.8k Aug 1, 2022
Encode and decode Go (golang) struct types via protocol buffers.

protostructure protostructure is a Go library for encoding and decoding a struct type over the wire. This library is useful when you want to send arbi

Mitchell Hashimoto 171 Mar 24, 2022
golang struct 或其他对象向 []byte 的序列化或反序列化

bytecodec 字节流编解码 这个库实现 struct 或其他对象向 []byte 的序列化或反序列化 可以帮助你在编写 tcp 服务,或者需要操作字节流时,简化数据的组包、解包 这个库的组织逻辑 copy 借鉴了标准库 encoding/json ?? 安装 使用 go get 安装最新版本

null 7 Jun 30, 2022
Dynamically Generates Ysoserial's Payload by Golang

Gososerial 介绍 ysoserial是java反序列化安全方面著名的工具 无需java环境,无需下载ysoserial.jar文件 输入命令直接获得payload,方便编写安全工具 目前已支持CC1-CC7,K1-K4和CB1链 Introduce Ysoserial is a well-

4ra1n 43 Jul 10, 2022
A k-mer serialization package for Golang

.uniq v5 This package provides k-mer serialization methods for the package kmers, TaxIds of k-mers are optionally saved, while there's no frequency in

Wei Shen 6 Jun 16, 2022
Some Golang types based on builtin. Implements interfaces Value / Scan and MarshalJSON / UnmarshalJSON for simple working with database NULL-values and Base64 encoding / decoding.

gotypes Some simple types based on builtin Golang types that implement interfaces for working with DB (Scan / Value) and JSON (Marshal / Unmarshal). N

null 0 Feb 12, 2022
gogoprotobuf is a fork of golang/protobuf with extra code generation features.

GoGo Protobuf looking for new ownership Protocol Buffers for Go with Gadgets gogoprotobuf is a fork of golang/protobuf with extra code generation feat

null 0 Nov 26, 2021
generic sort for slices in golang

slices generic sort for slices in golang basic API func BinarySearch[E constraints.Ordered](list []E, x E) int func IsSorted[E constraints.Ordered](li

阮坤良 15 Jul 26, 2022
Bitbank-trezor - Bitbank trezor with golang

Bitbank - Trezor (c) 2022 Bernd Fix [email protected] >Y< bitbank-trezor is fre

Bernd Fix 0 Jan 27, 2022
Herbert Fischer 197 Jun 10, 2022
A go implementation of the STUN client (RFC 3489 and RFC 5389)

go-stun go-stun is a STUN (RFC 3489, 5389) client implementation in golang (a.k.a. UDP hole punching). RFC 3489: STUN - Simple Traversal of User Datag

Cong Ding 510 Aug 5, 2022
AWS Tags Updater - Sync tags with all resources via sheet 🐏🐏

AWS Tags Updater - Sync tags with all resources via sheet ????

PePoDev 1 Mar 22, 2022
Go concurrent-safe, goroutine-safe, thread-safe queue

goconcurrentqueue - Concurrent safe queues The package goconcurrentqueue offers a public interface Queue with methods for a queue. It comes with multi

Enrique Bris 199 Jul 19, 2022
Implements the XDR standard as specified in RFC 4506 in pure Go (Golang)

go-xdr [] (https://travis-ci.org/davecgh/go-xdr) [![Coverage Status] (https://coveralls.io/repos/davecgh/go-xdr/badge.png?branch=master)] (https://cov

Dave Collins 97 Jul 12, 2022
idiomatic codec and rpc lib for msgpack, cbor, json, etc. msgpack.org[Go]

go-codec This repository contains the go-codec library, the codecgen tool and benchmarks for comparing against other libraries. This is a High Perform

Ugorji Nwoke 1.7k Aug 6, 2022
Hsuan-Fuzz: REST API Fuzzing by Coverage Level Guided Blackbox Testing

Hsuan-Fuzz: REST API Fuzzing by Coverage Level Guided Blackbox Testing Architecture Usage package main import ( restAPI "github.com/iasthc/hsuan-

Chung-Hsuan Tsai 21 Jul 13, 2022
Lightweight, fast and dependency-free Cron expression parser (due checker) for Golang (tested on v1.13 and above)

adhocore/gronx gronx is Golang cron expression parser ported from adhocore/cron-expr. Zero dependency. Very fast because it bails early in case a segm

Jitendra Adhikari 207 Jul 25, 2022
A fast, well-tested and widely used WebSocket implementation for Go.

Gorilla WebSocket Gorilla WebSocket is a Go implementation of the WebSocket protocol. Documentation API Reference Chat example Command example Client

Gorilla Web Toolkit 17.7k Jul 29, 2022
A Golang REST API to handle users and posts for a simple instagram backend. Uses MongoDB as the database. Tested using golang-testing and Postman.

A Golang REST API to handle users and posts for a simple instagram backend. Uses MongoDB as the database. Tested using golang-testing and Postman.

Nitin Narayanan 1 Oct 10, 2021
Fuzz testing for go.

gofuzz gofuzz is a library for populating go objects with random values. This is useful for testing: Do your project's objects really serialize/unseri

Google 1.3k Jul 27, 2022
Fuzz Go defer/panic/recover

deferfuzz deferfuzz is a fuzzer for Go defer/panic/recover. Caveat: I wrote this in a couple hours, and I'm more of a compiler engineer than a fuzzer

Matthew Dempsky 26 Mar 3, 2022
tfuzz is a command-line tool to fuzz some layer 7 OSI protocols with a template file

tfuzz tfuzz is a command-line tool to fuzz some layer 7 OSI protocols with a template file download the linux binary executable (or you can compile fr

Noob0x 3 Sep 29, 2021