Every commit scored for change-risk against this repo's own history, so 'elevated' means elevated here rather than on some global curve.
Needs review
231 commits sit in this repo's top risk tercile, which is 33% of the 702scored. The cut is drawn against this codebase's own history rather than a global curve, so a quiet repo still fills its top band, and here it starts at 6.4 out of 10. What pushes a commit up is size and spread together: a large change confined to one area scores below a smaller one scattered across a dozen files.
Commit categories over time, read off the subject line. Fixes carry the accent because that is the series this chart exists to show.
Began other-led, now leaning feature.
Ranked by change-risk, highest first. Priority is a tercile of this repo's own distribution, so a quiet repo still fills its top band.
| # | Commit | Author | When | Lines | Review priority | Top driver |
|---|---|---|---|---|---|---|
| 1 | 341931abconvert line endings in json simple from CRLF to LF | Brian Campbell | 11y ago | +2.5K -2.5K | 100thElevated | more lines added than baseline |
| 2 | 493f40a0add of initial source files that had previously been living w/out source control *shudder* | Brian Campbell | 14y ago | +3.5K -0 | 100thElevated | more lines added than baseline |
| 3 | 5d91a2d7Pulling the json-simple source code directly in (changing the package). Little uneasy about it. But it hasn’t changed much in years and jose4j only needs pretty basic JSON processing. This lets me remove one more dependency and avoid any potential dependency conflicts. It also allows me to make changes to the JSON processing in the future like not escaping forward slashes. There’s some risk in this but moving to a new/different processor in the future isn’t really made particularly more difficul | Brian Campbell | 12y ago | +2.5K -9 | 100thElevated | more lines added than baseline |
| 4 | 4360fa83pretty big change, which allows for the caller of various JOSE and JWT functionality to specify a particular Java Cryptography Architecture provider by name for various cryptographic operations as well as a SecureRandom source of randomness. | Brian Campbell | 10y ago | +1.5K -210 | 99thElevated | more lines added than baseline |
| 5 | 25f5a855pull over the (slightly modified to deal w/ dependencies) unit tests for base64 over from commons codec v1.9 too, which will be nice to have should I ever need to meddle with the implementation | Brian Campbell | 12y ago | +1.4K -1 | 99thElevated | more lines added than baseline |
| 6 | 75c3ff54Apache License, Version 2.0 | Brian Campbell | 14y ago | +1.1K -3 | 99thElevated | more lines added than baseline |
| 7 | 2c39b4c7more Copyright/License headers | Brian Campbell | 11y ago | +740 -0 | 99thElevated | more lines added than baseline |
| 8 | d157df18beginning work on more legitimate direct support for JWT starting with a JwtClaimsSet object for more easily dealing with the JSON claims conveyed by a JWT | Brian Campbell | 11y ago | +935 -0 | 99thElevated | more lines added than baseline |
| 9 | d8c0d516copied Base64 and BaseNCodec (modified slightly to remove/replace dependencies) from version 1.9 of the Apache Commons Codec project into org.jose4j.org.apache.commons.codec.binary. I'm a little uneasy about doing this but it has some benefits in that enables jose4j to have one less dependency and also ensures jose4j has a consistent Base64 interface and implementation regardless of where/how it's deployed. | Brian Campbell | 12y ago | +1.3K -7 | 99thElevated | more lines added than baseline |
| 10 | 00b7c8a3initial support for the Elliptic Curve Digital Signature Algorithms in JWS | Brian Campbell | 13y ago | +699 -295 | 99thElevated | more lines added than baseline |
| 11 | 12a88d60JwtConsumer & Builder can now more easily be used in a two phased validation/processing approach where first the JTW is parsed and additional policy can be looked up from the content (like issuer and associated verification key resolver) to do a second processing and validation on the JWT context obtained from the first processing. This can be helpful, for example, if you don’t know the issuer from other context and need to crack the JWT open to figure it out. | Brian Campbell | 11y ago | +540 -166 | 98thElevated | more lines added than baseline |
| 12 | e75cebe4initial work on VerificationJwkSelector, which attempts to chose the best/right JWK for signature verification of a JWS | Brian Campbell | 11y ago | +651 -0 | 98thElevated | more lines added than baseline |
| 13 | 8cc4c749JWT checking of exp, nbf and iat claims via new NumericDateClaimsValidator in JwtConsumerBuilder and also replace IntDate with NumericDate in JWT stuff reflecting the name change in the spec a while ago | Brian Campbell | 11y ago | +456 -127 | 98thElevated | more lines added than baseline |
| 14 | 22305eb4initial support for the PBES2 Key Encryption algorithms PBES2-HS256+A128KW, PBES2-HS384+A192KW and PBES2-HS512+A256KW | Brian Campbell | 12y ago | +689 -17 | 98thElevated | more lines added than baseline |
| 15 | cca6bc9aadded hooks for valuation of keys (type, size, etc) on JWS and implemented a lot of them (mostly on verify) | Brian Campbell | 13y ago | +369 -59 | 98thElevated | more lines added than baseline |
| 16 | 03bf93d5a very simple little HTTP API for doing GETs only. This is intended to help facilitate retrieving JWKS content from HTTPS endpoints, which thanks largely to OpenID Connect should be a common use case and I’d like to have good support for it in this project. | Brian Campbell | 11y ago | +377 -0 | 98thElevated | more lines added than baseline |
| 17 | caf9efbaadd a PkixJsonWebKey to support the PKIX JWK Key Type for X509 certs via an x5c element per http://tools.ietf.org/html/draft-miller-jose-pkix-key (with tests from there and from OpenID Connect where it's being duplicated until hopefully draft-miller-jose-pkix-key becomes a WG document) | Brian Campbell | 13y ago | +374 -51 | 98thElevated | more lines added than baseline |
| 18 | 4c01d630some example stuff for connect pkix key type via jwk | Brian Campbell | 13y ago | +406 -337 | 98thElevated | more lines added than baseline |
| 19 | b8372653JwtConsumer[Builder] now can be told to relax validation of the verification or deception key, which will more easily allow for things like verification of JWTs signed with a 1024 bit RSA key (i.e. what Google is doing right now) or an HMAC key that is not the full 256 bits. | Brian Campbell | 11y ago | +345 -1 | 97thElevated | more lines added than baseline |
| 20 | b5599e5cintroduce a JwksDecryptionKeyResolver that, using DecryptionJwkSelector, will chose a key management key for decryption from a given list of JWSs using the content of the JWE header (mainly kid and x5t etc) | Brian Campbell | 11y ago | +292 -3 | 97thElevated | more lines added than baseline |
| 21 | 39cee2eaa new X509 verification key resolver that will look at x5t/x5t#S256 headers and select from a provided list of certs based on the thumb/fingerprint in the JWS | Brian Campbell | 11y ago | +332 -0 | 97thElevated | more lines added than baseline |
| 22 | 2e25cc11add Copyright/License header to some files | Brian Campbell | 11y ago | +256 -1 | 97thElevated | more lines added than baseline |
| 23 | c590037ainitial work on a JWT consumer API for (hopefully easily) parsing and validating JWTs | Brian Campbell | 11y ago | +315 -0 | 97thElevated | more lines added than baseline |
| 24 | cd42cabfmore work on verifying some of the cookbook examples in unit test - added 4.2 RSA-OAEP, 4.3 PBES2-AES-KeyWrap with AES-CBC-HMAC-SHA2 and 4.4 ECDH-ES and AES-KeyWrap | Brian Campbell | 12y ago | +310 -45 | 97thElevated | more lines added than baseline |
| 25 | 1465fa02an initial implementation of PBKDF2 from RFC 2898, which can use any HMAC SHA as the PRF (Java only has SHA1 currently). Tests from the vectors in RFC 6070 as well as some tests that compare to the java SecretKeyFactory implementation. | Brian Campbell | 12y ago | +288 -0 | 97thElevated | more lines added than baseline |
| 26 | 24ae7064add x5c support to JWK | Brian Campbell | 13y ago | +272 -30 | 97thElevated | more lines added than baseline |
| 27 | be24bbd2first pass at javadoc for JwtConsumerBuilder | Brian Campbell | 10y ago | +278 -4 | 96thElevated | more lines added than baseline |
| 28 | b4b791daintroduce a DecryptionJwkSelector | Brian Campbell | 11y ago | +263 -23 | 96thElevated | more lines added than baseline |
| 29 | e98b154dadd HttpsJsonWebKeySet which can retrieve and cache JWKs from a JWKS HTTP(s) endpoint | Brian Campbell | 11y ago | +281 -0 | 96thElevated | more lines added than baseline |
| 30 | 812d7917do a little more work to disambiguate on alg and crv in VerificationJwkSelector when the initial filtering leaves more than one JWK | Brian Campbell | 11y ago | +330 -5 | 96thElevated | more lines added than baseline |
| 31 | 27dd2d94working on impl of A128CBC-HS256 while starting to work out the class layout for JWE | Brian Campbell | 13y ago | +314 -118 | 96thElevated | more lines added than baseline |
| 32 | 5129246eintroduce the underpinnings of JWT claims validation to JwtConsumer along with Audience checking as the first implementation | Brian Campbell | 11y ago | +219 -3 | 95thElevated | more lines added than baseline |
| 33 | 553adfd1add validate[Encryption/Decryption]Key to KeyManagementAlgorithm and do implementations for AES algos to start checking that the given key is appropriate and provide some meaningful message when its not | Brian Campbell | 13y ago | +245 -6 | 95thElevated | more lines added than baseline |
| 34 | 711e14f4add support for the ECDH-ES+AxxxKW algorithms by just composing the ECDH-ES and the AxxxKW ones with a little glue code. + some round trip unit tests. but it'd be nice to get some kind of 3rd party interop test on these at some point... | Brian Campbell | 13y ago | +220 -6 | 95thElevated | more lines added than baseline |
| 35 | 252048acadding support for the AES Key Wrap algorithms. Introduced WrappingKeyManagementAlgorithm that AES and RSA KeyManagementAlgorithm extend from as the RSA and AES key wrapping/encryption/transport do pretty much the same thing with the cipher just using different keys and algorithm names. Also added tests from the example in JWE -14 appendix A.3 | Brian Campbell | 13y ago | +230 -75 | 95thElevated | more lines added than baseline |
| 36 | 6c25d9c4update licenses headers | Brian Campbell | 13y ago | +319 -79 | 95thElevated | more lines added than baseline |
| 37 | 84640b68introduce support for private keys in JWK (EC & RSA but not the RSA CRT parts yet) | Brian Campbell | 13y ago | +220 -2 | 95thElevated | more lines added than baseline |
| 38 | c6f590c3update Copyright headers | Brian Campbell | 10y ago | +212 -197 | 94thElevated | more lines added than baseline |
| 39 | 151c069aaddress #44 by providing a generic callback to JwtConsumer to customize each JWS/JWE, which will allow the usage of new and/or esoteric JWS/JWE features such as setting the known critical headers without having to have specific support for them at JwtConsumer[Builder] layer. | Brian Campbell | 10y ago | +205 -4 | 94thElevated | more lines added than baseline |
| 40 | 65c52d89create an HttpsJwksVerificationKeyResolver that basically does (or helps do) what is described in http://openid.net/specs/openid-connect-core-1_0.html#RotateSigKeys from the verifier/consumer perspective | Brian Campbell | 11y ago | +230 -0 | 94thElevated | more lines added than baseline |
| 41 | 19fbf7d6add algorithm constraints to JwtConsumer(+ builder), which are needed to allow processing of an Unsecured Jwt (JWS with alg=none) but also should have utility elsewhere | Brian Campbell | 11y ago | +217 -6 | 94thElevated | more lines added than baseline |
| 42 | c3454812begin working though the examples in the JOSE Cookbook (currently at draft -01) via unit test - RSA v1.5 and HMAC SHA2 looking good but ECDSA not so much. checking in just to get a snapshot in the history before doing further investigation | Brian Campbell | 12y ago | +238 -0 | 94thElevated | more lines added than baseline |
| 43 | 9270d952first cut at a ECDH + KDF KeyManagementAlgorithm (just ECDH-ES now, still need to do the ECDH-ES+AxxxKW ones - and why no GCM key wrap variants anyway? oh well). My results don't match http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-14#appendix-D but were the same that Edmund Jay got http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20130805/003869.html so I'm going with it for now. This change touched a number of things including having to make headers more than just | Brian Campbell | 13y ago | +280 -35 | 94thElevated | more lines added than baseline |
| 44 | 2cece85bApache License, Version 2.0 | Brian Campbell | 14y ago | +202 -0 | 94thElevated | more lines added than baseline |
| 45 | 560904c9give up on unchecked exceptions and introduce a new checked JoseException to replace most of the IllegalSomethingExceptions | Brian Campbell | 14y ago | +197 -131 | 94thElevated | more lines added than baseline |
| 46 | 459ea84caddressing #43 with support for the crit header | Brian Campbell | 10y ago | +256 -0 | 93thElevated | more lines added than baseline |
| 47 | 2fea31d1initial add of the AES GCM content encryption algorithms. The Sun/Oracle provider in Java 7 doesn’t support GCM. Only as of v1.50 does the Bouncy Castle support GCM via the standard JCE AEAD interfaces, which means I can add GCM support without having to use specific Bouncy Castle APIs (which I really didn’t want to do). So now I’m adding it but just using JCE API. The Bouncy Castle provider (or one that supports GCM via standard JCE AEAD interfaces) needs to be available for GCM to work, and t | Brian Campbell | 12y ago | +211 -138 | 93thElevated | more lines added than baseline |
| 48 | 719b060badd the RSA-PSS signature algorithms (PS256, PS384 & PS512 alg values for JWS) and test the one RSA-PSS example from the JOSE Cookbook. However, the Java JCA provider doesn’t support RSA-PSS so bring in the Bouncy Castle provider just in test scope and do some hacky stuff to register it and PS384 before verifying the cookbook example and then unregister them both. | Brian Campbell | 12y ago | +240 -53 | 93thElevated | more lines added than baseline |
| 49 | f8104fcaused sandbox to generate examples for http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20131104/004310.html and presumptuously added a unit test for it. also examples for OWASP Vancouver talk http://www.slideshare.net/briandavidcampbell/owasp-vancouver | Brian Campbell | 12y ago | +189 -2 | 93thElevated | more lines added than baseline |
| 50 | 9c2ed2f5add some more negative tests around symmetric key sizes | Brian Campbell | 13y ago | +233 -96 | 93thElevated | more lines added than baseline |
Two views of the same model: where the cuts fall, and what commit shape lands you above them.
Every scored commit, binned on the raw 0 to 10 score rather than the percentile. Percentile ranks are uniform by construction, so that axis has no shape to draw. The dashed lines are the tercile cuts behind each row's priority pill.
The 200 most recent commits, on their own recency sample rather than the feed above: that defaults to risk-sorted, so reusing it would plot only the top tercile and call it the spread. Big and scattered is what the model penalises. Click a dot to open it.
pvliesdonk/jose4j has 718 commits in its history from 7 contributors, the first of them Oct 1, 2012. No file in the repository changed in the last 90 days. Every commit is scored for change risk from its size, spread and the history of the files it touches.
