An implementation of JOSE standards (JWE, JWS, JWT) in Go
This repository is DEPRECATED.
It will be placed in an archived state on February 27th, 2023.
Development of Go JOSE has continued in a new organization:
https://github.com/go-jose/go-jose
We strongly encourage users of square/go-jose to migrate to v3 of
go-jose/go-jose. No support, security fixes or updates will be delivered to
the v1/v2 branches in the Square repository.
![dependabot-preview[bot] avatar](https://avatars.githubusercontent.com/in/2141?v=4 "dependabot-preview[bot]")
Improve test coverage for the jwt sub-package in the v2 branch.
See https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#page-11
I'm working on implementing a JOSE backend for the Vault Project hashicorp/vault#1986
Running into issues with this library not supporting setting all the various headers that are supported by JWS vs JWE and JWT.
As pointed out at https://www.ietf.org/mail-archive/web/json/current/msg03763.html, Go's JSON parser is case-insensitive, which can lead to differences in interpretation between go-jose and libraries in other languages.
One possible workaround, mentioned in that thread, is to parse into a map[string]string, where the key names will be based on exact match.
The JsonWebSignature.Verify method currently accepts a interface{} as a parameter. This makes it not immediately apparent what types are expected. For example, there doesn't seem to be any indication that symmetricMac is created with a byte slice instead of a string unless you read the code. This could be fixed with an update to the docs, however this doesn't fit Go idea of "if it compiles, it will run as expected".
By changing to key-specific methods, this will reduce any confusion. One possible configuration could be:
JsonWebSignature.VerifyRSA(*rsa.PublicKey)JsonWebSignature.VerifyECDSA(*ecdsa.PublicKey)JsonWebSignature.VerifyMAC([]byte)JsonWebSignature.VerifyWebKey(*JSONWebKey)Alternatively, the creation of the payloadVerifier could be exposed as a function and then called by the user. Eg:
verifier, err := jose.NewRSAVerifier(key)
// handle err
jws := jose.ParseSigned(input)
payload, err := jws.Verify(verifier)
This way, everything is strongly typed from beginning to end, but the Verify method can accept any type of key as long as it's wrapped in a verifier.
I've implemented support for deserializing JWT claims and am wondering if go-jose would benefit from adding it. What's your thoughts?
See RFC -- https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-32#section-5
While the typ header is optional it is good practice when creating JWT tokens to set typ to JWT (see https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-32#section-3.1)
I got a panic when I created a HS256 signer with a JsonWebKey,
sr, err := jose.NewSigner(jose.HS256, &jose.JsonWebKey{
Key: key,
KeyID: "k0",
})
sr.Sign([]byte("hello")
and the panic was,
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x0 pc=0x46ecd0]
goroutine 1 [running]:
panic(0x5f1ec0, 0xc82000e150)
/opt/go/src/runtime/panic.go:464 +0x3e6
github.com/square/go-jose.makeJWSRecipient(0x62f448, 0x5, 0x6014a0, 0xc820010300, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
/home/b6g/git/src/github.com/square/go-jose/signing.go:131 +0x450
github.com/square/go-jose.(*genericSigner).AddRecipient(0xc820012780, 0x62f448, 0x5, 0x6014a0, 0xc820010300, 0x0, 0x0)
/home/b6g/git/src/github.com/square/go-jose/signing.go:109 +0x69
github.com/square/go-jose.NewSigner(0x62f448, 0x5, 0x6014a0, 0xc820010300, 0x0, 0x0, 0x0, 0x0)
/home/b6g/git/src/github.com/square/go-jose/signing.go:70 +0x167
main.sign(0xc82000a310, 0x1, 0x1)
The problem is makeSymmetricSigner does not allocate the publicKey field, yet makeJWSRecipient assigns the KeyID of the signingKey to recipient.publicKey.KeyID.
I could be wrong, but I think the spec allows setting "kid" when HS256 is used.
I could not find a good fix for this problem. If we new publicKey in makeSymmetricSigner, genericSigner.Sign will fail with json marshal error. This is because ctx.embedJwk is true and protected.Jwk will be set, but the Key field of the JsonWebKey is nil. I could work around this by calling SetEmbedJwk(false), but it does not sound correct to me.
Thanks,
Support the ed25519 signing method https://ed25519.cr.yp.to/
There is an x/crypto package at https://godoc.org/golang.org/x/crypto/ed25519
Happy to contribute if needed.
Currently the "jwt" package does not expose the jose.Header fields of the JSONWebToken. This means you can't match on keyIDs to determine which key pair signed the token (and verify appropriately).
I propose adding a "Signatures" field to the JSONWebToken to mirror the JSONWebSignature.
Builder panics when you use a custom claim struct.
package main
import (
"crypto/rand"
"crypto/rsa"
"log"
"gopkg.in/square/go-jose.v2"
"gopkg.in/square/go-jose.v2/jwt"
)
type claims struct {
Subject string `json:"sub"`
}
func main() {
priv, err := rsa.GenerateKey(rand.Reader, 2048)
if err != nil {
log.Fatalf("generate: %v", err)
}
signingKey := jose.SigningKey{Algorithm: jose.RS256, Key: priv}
signer, err := jose.NewSigner(signingKey, nil)
if err != nil {
log.Fatalf("generate: %v", err)
}
token, err := jwt.Signed(signer).Claims(claims{"foo"}).CompactSerialize()
if err != nil {
log.Fatalf("creating jwt: %v", err)
}
log.Println(token)
}Running this program results in.
$ go run main.go
panic: reflect: call of reflect.Value.IsNil on struct Value
goroutine 1 [running]:
panic(0x51c940, 0xc420196e20)
/usr/local/go/src/runtime/panic.go:500 +0x1a1
reflect.Value.IsNil(0x5216a0, 0xc42007c4a0, 0x99, 0xc42007c4a0)
/usr/local/go/src/reflect/value.go:977 +0xf9
gopkg.in/square/go-jose.v2/jwt.publicClaims(0x5216a0, 0xc42007c4a0, 0x0, 0x18, 0x0)
/home/eric/src/gopkg.in/square/go-jose.v2/jwt/json.go:103 +0x70
gopkg.in/square/go-jose.v2/jwt.marshalClaims(0x5216a0, 0xc42007c4a0, 0x8, 0x10, 0xc42007c4a0, 0x0, 0x5dec40)
/home/eric/src/gopkg.in/square/go-jose.v2/jwt/json.go:125 +0x96
gopkg.in/square/go-jose.v2/jwt.(*Builder).Claims(0xc420078320, 0x5216a0, 0xc42007c4a0, 0x5216a0)
/home/eric/src/gopkg.in/square/go-jose.v2/jwt/builder.go:79 +0x6e
main.main()
/home/eric/p/go/jose/main.go:26 +0x176
exit status 2
https://github.com/square/go-jose/blob/master/jws.go#L106
func (parsed *rawJsonWebSignature) sanitized() (*JsonWebSignature, error) {
if parsed.Payload == nil {
return nil, ErrUnprotectedNonce
}
I think this was incorrectly changed from its old value fmt.Errorf("square/go-jose: missing payload in JWS message"). @bifurcation
The current "supply a key to verify with" model for verification is almost always a bad fit.
If a JWS object contains a "jwk" header, then it already has enough information for a verifier to be able to check the signature. In this case, it should not be necessary to supply a public key to a verifier constructor.
If a JWS object does not contain a "jwk" header, then the verifier should be identifying the key for verification based on other header fields, e.g., "kid". In this case, a set of keys with attributes would be an appropriate input to a verifier factory, instead of an individual key.
It might be useful simply to add a Verify() and/or Verify([]KeyType) methods to JwsObject. For example:
https://github.com/bifurcation/gose/blob/master/jws.go#L211
While investigating a malformed jwks file, I found it necessary to know which field go-jose thought was missing from the JSON file. This is not such a important thing except for a specific instance like mine, so I thought I'd just file this run by this change as an issue first instead of PR.
diff --git a/jwk.go b/jwk.go
index 8512be3..73b99b3 100644
--- a/jwk.go
+++ b/jwk.go
@@ -187,9 +187,28 @@ func fromEcPublicKey(pub *ecdsa.PublicKey) (*rawJsonWebKey, error) {
return key, nil
}
+var (
+ errInvalidRSAPrivateKeyMissingN = fmt.Errorf("square/go-jose: invalid RSA private key, missing values (%s)", "N")
+ errInvalidRSAPrivateKeyMissingE = fmt.Errorf("square/go-jose: invalid RSA private key, missing values (%s)", "E")
+ errInvalidRSAPrivateKeyMissingD = fmt.Errorf("square/go-jose: invalid RSA private key, missing values (%s)", "D")
+ errInvalidRSAPrivateKeyMissingP = fmt.Errorf("square/go-jose: invalid RSA private key, missing values (%s)", "P")
+ errInvalidRSAPrivateKeyMissingQ = fmt.Errorf("square/go-jose: invalid RSA private key, missing values (%s)", "Q")
+)
+
func (key rawJsonWebKey) rsaPrivateKey() (*rsa.PrivateKey, error) {
- if key.N == nil || key.E == nil || key.D == nil || key.P == nil || key.Q == nil {
- return nil, fmt.Errorf("square/go-jose: invalid RSA private key, missing values")
+ // lestrrat: these assersions are unpacked so that error messages are
+ // reported better
+ switch {
+ case key.N == nil:
+ return nil, errInvalidRSAPrivateKeyMissingN
+ case key.E == nil:
+ return nil, errInvalidRSAPrivateKeyMissingE
+ case key.D == nil:
+ return nil, errInvalidRSAPrivateKeyMissingD
...skipping...
+var (
+ errInvalidRSAPrivateKeyMissingN = fmt.Errorf("square/go-jose: invalid RSA private key, missing values (%s)", "N")
+ errInvalidRSAPrivateKeyMissingE = fmt.Errorf("square/go-jose: invalid RSA private key, missing values (%s)", "E")
+ errInvalidRSAPrivateKeyMissingD = fmt.Errorf("square/go-jose: invalid RSA private key, missing values (%s)", "D")
+ errInvalidRSAPrivateKeyMissingP = fmt.Errorf("square/go-jose: invalid RSA private key, missing values (%s)", "P")
+ errInvalidRSAPrivateKeyMissingQ = fmt.Errorf("square/go-jose: invalid RSA private key, missing values (%s)", "Q")
+)
+
func (key rawJsonWebKey) rsaPrivateKey() (*rsa.PrivateKey, error) {
- if key.N == nil || key.E == nil || key.D == nil || key.P == nil || key.Q == nil {
- return nil, fmt.Errorf("square/go-jose: invalid RSA private key, missing values")
+ // lestrrat: these assersions are unpacked so that error messages are
+ // reported better
+ switch {
+ case key.N == nil:
+ return nil, errInvalidRSAPrivateKeyMissingN
+ case key.E == nil:
+ return nil, errInvalidRSAPrivateKeyMissingE
+ case key.D == nil:
+ return nil, errInvalidRSAPrivateKeyMissingD
+ case key.P == nil:
+ return nil, errInvalidRSAPrivateKeyMissingP
+ case key.Q == nil:
+ return nil, errInvalidRSAPrivateKeyMissingQ
}
rv := &rsa.PrivateKey{
https://github.com/square/go-jose/blob/master/jwk_test.go#L497
Working on adding ECDSA support to golang.org/x/crypto/acme but I need a test for ECDSA thumbprints. I copied it from here but I wanted to know where this library got it from.
Would love to clean up the interface for a go-jose.v2 release. Ideas welcome!
By my reading of the code, it looks like the unprotected header field is not supported in Flattened JWS JSON Serialization. I'd like to add support: We are using it in https://github.com/letsencrypt/boulder to indicate which key was used to sign a message, and we'd like to port Boulder to use go-jose. Any objections?
Thanks,
Jacob
I have a situation where information included in an incoming payload is needed to know which key to use to verify the signature on a request, and cannot figure out how to achieve this with the current API. Would there be a downside to exposing the JsonWebSignature's payload field in some fashion that does not yet require knowing the key needed for verification? I am looking to do something like:
json.Unmarshal(jwo.Payload(), &req)
database.FindId(req.SubmitterId, &submitter)
jwo.Verify(submitter.SigningKey)
Thank you for your consideration.
Usecase: embedding JWK's in configuration files. See the following workaround:
type jwk struct {
jose.JsonWebKey
}
func (j *jwk) UnmarshalText(text []byte) error {
var k = new(jose.JsonWebKey)
if err := k.UnmarshalJSON(text); err != nil {
return err
}
j.JsonWebKey = *k
return nil
}
If I use signer.Sign() which by default includes the public key in the jwk header how can I use this to verify? Verify() expects a key, but I want to use the key thats already in the token.
Expose header values to e.g. retrieve a JWK embedded in a JWS header.
JOSE has a flattened JSON syntax that is more efficient for single-signer JWS / single-recipient JWE objects. Basically, all of the elements of the single signatures/recipients object are included at the top level. It would be nice to have a SerializeFlattened() method on JweObject/JwsObject that rendered to this serialization.
For example:
https://github.com/bifurcation/gose/blob/master/jws.go#L29
"JwsObject" -> "JsonWebSignature"
"JweObject" -> "JsonWebEncryption"
And "JsonWebKey" once that's added. It's mostly an aesthetic issue, but it does improve readability not having to distinguish "s" from "e" to tell the two apart. I concede that it works better for JWS and JWK than JWE, since the nouns are more suitable.
Use base64.RawURLEncoding instead of our own helper functions. Breaks support for older Go versions, so maybe wait a bit or do this in v2 only.
It would be helpful for this library to have support for processing JWK-formatted keys independent of JWS / JWE. For example:
https://github.com/bifurcation/gose/blob/master/jwk.go
As a possible enhancement, it would be nice to have support for doing decryption/signing on HSMs via PKCS11. Possibly with some sort of wrapper around https://github.com/miekg/pkcs11.
Version 1.0.4 fails to build as a Debian package due to now importing github.com/square/go-jose/json instead of previously gopkg.in/square/go-jose.v1/json. Could you revert the import path to the latter?
Are you interested in supporting registered claims in this project? Or should I create a separate repository implementing (at least a subset of those) on top of go-jose?
I'd like to support (at least) exp and nbf.
This package is somewhat picky about always using *jose.JSONWebKey values instead of non-pointer values. I find myself messing this up a lot, particularly when using JSONWebKeySet[0], which holds concrete values.
Largely I'm surprised when this code:
jwk := jose.JSONWebKey{
Key: myRSAKey,
KeyID: "foobar",
}
options := jose.SigningKey{Algorithm: jose.RS258, Key: jwk}
signer, err := jose.NewSigner(options, nil)Returns the following error.
square/go-jose: unsupported key type/format
This is because the codebase requires explicitly using a *JSONWebKey type instead of a non-pointer value.[1]
func makeJWSRecipient(alg SignatureAlgorithm, signingKey interface{}) (recipientSigInfo, error) {
switch signingKey := signingKey.(type) {
// ...
case *JSONWebKey:
recipient, err := makeJWSRecipient(alg, signingKey.Key)
if err != nil {
return recipientSigInfo{}, err
}
recipient.publicKey.KeyID = signingKey.KeyID
return recipient, nil
default:
return recipientSigInfo{}, ErrUnsupportedKeyType
}
}Verify() also has similar logic.
I think this is an issue for JSONWebKey types instead of other key types because there's no explicit constructor method (e.g. no NewJSONWebKey()). This means I have to explicitly initialize the type myself and end up running into this problem a lot.
Would it be reasonable to add another case statement (probably with a helper method to avoid the repetition)?
func makeJWSRecipient(alg SignatureAlgorithm, signingKey interface{}) (recipientSigInfo, error) {
switch signingKey := signingKey.(type) {
// ...
case *JSONWebKey:
recipient, err := makeJWSRecipient(alg, signingKey.Key)
if err != nil {
return recipientSigInfo{}, err
}
recipient.publicKey.KeyID = signingKey.KeyID
return recipient, nil
case JSONWebKey:
recipient, err := makeJWSRecipient(alg, signingKey.Key)
if err != nil {
return recipientSigInfo{}, err
}
recipient.publicKey.KeyID = signingKey.KeyID
return recipient, nil
default:
return recipientSigInfo{}, ErrUnsupportedKeyType
}
}
cc @csstaub
[0] https://godoc.org/gopkg.in/square/go-jose.v2#JSONWebKeySet
[1]
Line 133 in 8c5257b
Please consider assigning version numbers and tagging releases. Tags/releases
are quite useful for downstream package maintainers (in Debian and other distributions) to export source tarballs, automatically track new releases and to declare dependencies between packages. Read more in the Debian Upstream Guide.
Thank you.
See also
Importing this package from the gopkg import requires downloading the github repo as well. Not a bug, but it seems odd to having the versioned import path downloading the latest from github for the sub repos.
$ go get -v gopkg.in/square/go-jose.v1
Fetching https://gopkg.in/square/go-jose.v1?go-get=1
Parsing meta tags from https://gopkg.in/square/go-jose.v1?go-get=1 (status code 200)
get "gopkg.in/square/go-jose.v1": found meta tag main.metaImport{Prefix:"gopkg.in/square/go-jose.v1", VCS:"git", RepoRoot:"https://gopkg.in/square/go-jose.v1"} at https://gopkg.in/square/go-jose.v1?go-get=1
gopkg.in/square/go-jose.v1 (download)
github.com/square/go-jose (download)
github.com/square/go-jose/json
gopkg.in/square/go-jose.v1
The JWA spec says:
The "n" (modulus) parameter contains the modulus value for the RSA public key. It is represented as a Base64urlUInt-encoded value.
However, Base64URL-encoded "n" parameter cannot be unmarshalled into JSONWebKey in go-jose.
Here is what I'm trying to do:
var d jose.JSONWebKeySet
if err := json.Unmarshal(body, &d); err != nil {
return err
}When the "n" parameter in the json body is Base64URL encoded instead of Base64 encoded, I get the error illegal base64 data at input byte 343. I think this is because encoding/json package expects a Base64-encoded string when decoding to []byte.
Not sure if I'm missing something?
This can be solved by changing the type of N in rawJSONWebKey to string. If I'm right, let me know, I'll gladly submit a PR.
I have seen that for some of the JWK-related libraries out there the "use" key in the JWK is required to find the correct key to use for sign verification and what not.
For example, JWK like:
{ keys: [ { "kty": "RSA", ... other elements } ] }
Fail, but this works
{ keys: [ { "use": "sig", "kty": "RSA", ... other elements } ] }
Now, for the stuff I'm doing, I want to generate the JWK file from the RSA private key on the fly. So I do something like the following:
type MyJWK struct {
*jose.JsonWebKey
Use string
}
json.Marshal(MyJWK{ Use: "sig", JsonWebKey: &jose.JsonWebKey{...} })
and for serialization/deserialization, I'm jumping through hoops, which is doable, but it sure would be nice if jose.JsonWebKey just did it for me. Thoughts?
The jose-util CLI can already decode/dump JWE/JWS for debugging, maybe we should add some JWT debugging commands. Could be useful.
I want to access JWS payload before it gets verified.
Use Case:
I am building an Open ID Connect clients which accepts ID Tokens (i.e. JWTs signed by JWS) issued by multiple issuers. In this client, parse a JWS payload at first, then recognize the issuer by iss claim of the payload and retrieve JWKs via Open ID Connect Discovery flow, finally verify the JWS using retrieved JWKs.
I looked for a go-jose's API that exports an unverified JWS payload but could not find. Do you have any plans to support this use case?
The JWE spec supports more than just the two fields allowed currently in go-jose (alg and enc).
You can also specify a kid which is really important when using symmetric encryption like AES with JWE.
I'm attempting something like so:
alg := jose.KeyAlgorithm("dir")
enc := jose.ContentEncryption("A256GCM")
encrypter, err := jose.NewEncrypter(alg, enc, resp.Plaintext)
if err != nil {
log.Fatalf(err.Error())
}
obj, err := encrypter.Encrypt([]byte(contents))
obj.Header.KeyID = "XXXXXX"but when I attempt to base64 decode the header (first part), I still only see alg and enc.
I'm proposing either changing the Encrypter interface to support new funcs for adding kid specifically or a more generic one to allow setting headers that are unrelated to the encryption and key methods being used.
I can maybe make a PR on this but I need to know which way you'd rather go first.
Thanks!
We (letsencrypt/boulder) requested the std_json tag to ensure we could have a smooth switchover to the safe JSON code. We've now made that transition and the std_json tag can be removed. Thanks for being so accomodating!
The link for the docs is a little confusing. Maybe include a direct link in the main README.md?
https://godoc.org/gopkg.in/square/go-jose.v2
I usually do a ctrl+f doc to find the GoDoc. That returns two mentions of "The Godoc reference" without a link.
Assuming I'm doing this all using the blessed path. I've included a snippet at the bottom to demonstrate.
Relevant output produced:
serialized to eyJhbGciOiJIUzUxMiJ9.eyJudW1iZXIiOjFlKzA2fQ.oFRp6CQOyNEicaiXDZASuGZpAX00fWnCoMRd89ueIFqo2t48WUo4C3Ld0EkrSViLYk5FxoxmyxXRJaq6BYKWuA
parsing signed
parsing claims
json: cannot unmarshal number 1e+06 into Go value of type int64
If you base64 decode the 2nd component of the compact JWT you'll see "number": 1e+06.
I suspect the culprit is here: https://github.com/square/go-jose/blob/v2/jwt/builder.go#L132 - the Marshal/Unmarshal loses the type information that would otherwise cause go's marshaler to encode Number as an integer.
package main
import (
"fmt"
jose "gopkg.in/square/go-jose.v2"
jwt "gopkg.in/square/go-jose.v2/jwt"
)
const SecretKey = "WoW"
type Claims struct {
Number int64 `json:"number"`
}
func main() {
fmt.Println("building signer")
signer, err := jose.NewSigner(jose.SigningKey{Algorithm: jose.HS512, Key: []byte(SecretKey)}, nil)
if err != nil {
fmt.Println(err)
return
}
fmt.Println("building builder")
token := jwt.Signed(signer)
token = token.Claims(Claims{Number: 1000000})
fmt.Println("serializing")
enc, err := token.CompactSerialize()
if err != nil {
fmt.Println(err)
return
}
fmt.Printf("serialized to %s\n", enc)
fmt.Println("parsing signed")
tok, err := jwt.ParseSigned(enc)
if err != nil {
fmt.Println(err)
return
}
fmt.Println("parsing claims")
claims := Claims{}
if err := tok.Claims([]byte(SecretKey), &claims); err != nil {
fmt.Println(err)
return
}
fmt.Printf("%#v\n", claims)
}
I believe there is an issue regarding exponent ("e") encoding in JWK.
In jwk_test.go the TestMarshalNonPointer JWK encoding test looks strange to me :
keyJson := []byte(`{
"e": "AQAB",
"kty": "RSA",
"n": "vd7rZIoTLEe-z1_8G1FcXSw9CQFEJgV4g9V277sER7yx5Qjz_Pkf2YVth6wwwFJEmzc0hoKY-MMYFNwBE4hQHw"
}`)
[ ... ]
expected := "{\"Key\":{\"kty\":\"RSA\",\"n\":\"vd7rZIoTLEe-z1_8G1FcXSw9CQFEJgV4g9V277sER7yx5Qjz_Pkf2YVth6wwwFJEmzc0hoKY-MMYFNwBE4hQHw\",\"e\":\"AAEAAQ\"}}"Why isn't "e" encoded as "AQAB" as in input ?
as per JWA RFC7518 e should be encoded in Base64urlUInt
AQAB represent 0x010001 => 65537
AAEAAQ represent 0x01000100 => 16777472
Is it possible to use x5c parameters with go-jose? I want to marshall a RSA private key along a x509 certificate (for HTTP over TLS).
The utils LoadPublicKey and LoadPrivateKey functions are listed in godoc as part of the library, but these are in the main package of jose-util and can't be accessed. Is there a reason the utils.go isn't outside of main and accessible as library calls?
The test suite of commit 7465d2b fails on armhf (hard-float ABI armv7) with the following error:
https://tests.reproducible-builds.org/rb-pkg/unstable/armhf/golang-github-square-go-jose.html
go test -v github.com/square/go-jose github.com/square/go-jose/cipher
=== RUN TestVectorsRSA
--- PASS: TestVectorsRSA (0.27s)
=== RUN TestInvalidAlgorithmsRSA
--- PASS: TestInvalidAlgorithmsRSA (0.00s)
=== RUN TestPKCSKeyGeneratorFailure
--- PASS: TestPKCSKeyGeneratorFailure (0.00s)
=== RUN TestInvalidAlgorithmsEC
--- PASS: TestInvalidAlgorithmsEC (0.00s)
=== RUN TestInvalidECKeyGen
--- PASS: TestInvalidECKeyGen (0.09s)
=== RUN TestInvalidECDecrypt
--- PASS: TestInvalidECDecrypt (0.00s)
=== RUN TestDecryptWithIncorrectSize
--- PASS: TestDecryptWithIncorrectSize (51.80s)
=== RUN TestPKCSDecryptNeverFails
--- PASS: TestPKCSDecryptNeverFails (19.83s)
=== RUN TestInvalidEllipticCurve
--- PASS: TestInvalidEllipticCurve (0.00s)
=== RUN TestRoundtripsJWE
--- PASS: TestRoundtripsJWE (199.33s)
=== RUN TestRoundtripsJWECorrupted
SIGQUIT: quit
PC=0x6ce28 m=0
goroutine 0 [idle]:
runtime.futex(0x38a0cc, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1dee4, 0x0, 0x0, 0x0, ...)
/usr/lib/go/src/runtime/sys_linux_arm.s:246 +0x1c
runtime.futexsleep(0x38a0cc, 0x0, 0xffffffff, 0xffffffff)
/usr/lib/go/src/runtime/os1_linux.go:40 +0x68
runtime.notesleep(0x38a0cc)
/usr/lib/go/src/runtime/lock_futex.go:145 +0xa4
runtime.stopm()
/usr/lib/go/src/runtime/proc.go:1535 +0x100
runtime.findrunnable(0x1051c000, 0x0)
/usr/lib/go/src/runtime/proc.go:1973 +0x7c8
runtime.schedule()
/usr/lib/go/src/runtime/proc.go:2072 +0x26c
runtime.goschedImpl(0x160911e0)
/usr/lib/go/src/runtime/proc.go:2152 +0x140
runtime.gopreempt_m(0x160911e0)
/usr/lib/go/src/runtime/proc.go:2167 +0x30
runtime.newstack()
/usr/lib/go/src/runtime/stack.go:932 +0xa38
runtime.morestack()
/usr/lib/go/src/runtime/asm_arm.s:309 +0x4c
goroutine 1 [chan receive, 4 minutes]:
testing.RunTests(0x2c37bc, 0x3885a8, 0x4d, 0x4d, 0xb4c54001)
/usr/lib/go/src/testing/testing.go:583 +0x62c
testing.(*M).Run(0x10539f7c, 0x1088ab70)
/usr/lib/go/src/testing/testing.go:515 +0x8c
main.main()
github.com/square/go-jose/_test/_testmain.go:526 +0x118
goroutine 17 [syscall, 9 minutes, locked to thread]:
runtime.goexit()
/usr/lib/go/src/runtime/asm_arm.s:990 +0x4
goroutine 15 [runnable]:
math/big.(*Int).Mod(0x160db508, 0x160db508, 0x1088e240, 0x160db508)
/usr/lib/go/src/math/big/int.go:252
crypto/elliptic.(*CurveParams).addJacobian(0x1088d2e0, 0x1096bb50, 0x1096bb60, 0x160db5b8, 0x1739d4d0, 0x1739d4c0, 0x1739d4e0, 0x1739d460, 0x1739d470, 0x1739d480)
/usr/lib/go/src/crypto/elliptic/elliptic.go:132 +0x244
crypto/elliptic.(*CurveParams).ScalarMult(0x1088d2e0, 0x1096bb50, 0x1096bb60, 0x1739a690, 0x30, 0x30, 0x4, 0x4)
/usr/lib/go/src/crypto/elliptic/elliptic.go:259 +0x170
github.com/square/go-jose/cipher.DeriveECDHES(0x27bf80, 0xe, 0x160db78c, 0x0, 0x0, 0x160db78c, 0x0, 0x0, 0x15a83ee0, 0x1088d6a0, ...)
/build/golang-github-square-go-jose-0.0~git20160304.0.7465d2b/obj-arm-linux-gnueabihf/src/github.com/square/go-jose/cipher/ecdh_es.go:36 +0x7a0
github.com/square/go-jose.ecKeyGenerator.genKey(0x10, 0x27bf80, 0xe, 0x1088d6a0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
/build/golang-github-square-go-jose-0.0~git20160304.0.7465d2b/obj-arm-linux-gnueabihf/src/github.com/square/go-jose/asymmetric.go:351 +0x15c
github.com/square/go-jose.ecEncrypterVerifier.encryptKey(0x1088d6a0, 0x15a83ea0, 0x18, 0x18, 0x27bf80, 0xe, 0x0, 0x0, 0x0, 0x0, ...)
/build/golang-github-square-go-jose-0.0~git20160304.0.7465d2b/obj-arm-linux-gnueabihf/src/github.com/square/go-jose/asymmetric.go:318 +0x218
github.com/square/go-jose.(*ecEncrypterVerifier).encryptKey(0x10526a40, 0x15a83ea0, 0x18, 0x18, 0x27bf80, 0xe, 0x0, 0x0, 0x0, 0x0, ...)
<autogenerated>:16 +0xd8
github.com/square/go-jose.(*genericEncrypter).EncryptWithAuthData(0x15aad740, 0x15a83e80, 0x1a, 0x20, 0x0, 0x0, 0x0, 0x15aad740, 0x0, 0x0)
/build/golang-github-square-go-jose-0.0~git20160304.0.7465d2b/obj-arm-linux-gnueabihf/src/github.com/square/go-jose/crypter.go:254 +0x340
github.com/square/go-jose.RoundtripJWE(0x27bf80, 0xe, 0x264748, 0x7, 0x263ca0, 0x3, 0x2c36dc, 0x160dbd98, 0x0, 0x0, ...)
/build/golang-github-square-go-jose-0.0~git20160304.0.7465d2b/obj-arm-linux-gnueabihf/src/github.com/square/go-jose/crypter_test.go:46 +0x1c4
github.com/square/go-jose.TestRoundtripsJWECorrupted(0x16f85e60)
/build/golang-github-square-go-jose-0.0~git20160304.0.7465d2b/obj-arm-linux-gnueabihf/src/github.com/square/go-jose/crypter_test.go:176 +0x6b0
testing.tRunner(0x16f85e60, 0x388620)
/usr/lib/go/src/testing/testing.go:473 +0xa8
created by testing.RunTests
/usr/lib/go/src/testing/testing.go:582 +0x600
trap 0x6
error 0x0
oldmask 0x0
r0 0x38a0cc
r1 0x0
r2 0x0
r3 0x0
r4 0x0
r5 0x0
r6 0x7f27b
r7 0xf0
r8 0x1051aa00
r9 0x0
r10 0x389e58
fp 0x389dcc
ip 0x1051b6f4
sp 0xbefab184
lr 0x3a790
pc 0x6ce28
cpsr 0xa0070010
fault 0x0
*** Test killed with quit: ran too long (10m0s).
FAIL github.com/square/go-jose 600.153s
there have been a few additions since the last release and it would be great to see them in a new patch/minor version.
Hey I'm working out some issues with the go-oidc verification method, I noticed that https://github.com/square/go-jose/blob/master/jws.go#L30 is an array of signatures. I can't seem to find any documentation on when a JWT would have multiple signatures. Is it safe to assume a single value here? Thanks
According to this blog post there is a critical vulnerability in this library. The blog post is 3 days old and mentions go-jose, but there does not seem to be any mention of this issue in the changelog or in the PRs. Is this a thing and if so, which version introduced a fix?
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.