New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jackson Deserializer security vulnerability via default typing (CVE-2017-7525) #1599

Closed
ayound opened this Issue Apr 11, 2017 · 57 comments

Comments

Projects
None yet
@ayound

ayound commented Apr 11, 2017

I have send email to info@fasterxml.com

@ayound ayound closed this Apr 11, 2017

@ayound ayound reopened this Apr 11, 2017

@ayound ayound changed the title from Jackson Deserializer vulnerability, can execute any code or command to Jackson Deserializer security vulnerability Apr 11, 2017

@cowtowncoder

This comment has been minimized.

Show comment
Hide comment
@cowtowncoder

cowtowncoder Apr 13, 2017

Member

I have received this and am investigating possible patch. Problem is quite specific, but some aspects are more general.

Member

cowtowncoder commented Apr 13, 2017

I have received this and am investigating possible patch. Problem is quite specific, but some aspects are more general.

cowtowncoder added a commit that referenced this issue Apr 13, 2017

Fix #1599 for 2.8.9
Merge branch '2.7' into 2.8

@cowtowncoder cowtowncoder added this to the 2.8.9 milestone Apr 13, 2017

@cowtowncoder

This comment has been minimized.

Show comment
Hide comment
@cowtowncoder

cowtowncoder Apr 13, 2017

Member

Fixed in 2.7, 2.8 and master (to the best of my knowledge): will be in 2.8.9 and 2.7.9.1, as well as 2.9.0.pr3.

Member

cowtowncoder commented Apr 13, 2017

Fixed in 2.7, 2.8 and master (to the best of my knowledge): will be in 2.8.9 and 2.7.9.1, as well as 2.9.0.pr3.

@Viyond

This comment has been minimized.

Show comment
Hide comment
@Viyond

Viyond commented Apr 17, 2017

nice~

@ayound

This comment has been minimized.

Show comment
Hide comment
@ayound

ayound Apr 17, 2017

when do you want to release 2.7.10,2.8.9 and 2.9.0.pr3?

ayound commented Apr 17, 2017

when do you want to release 2.7.10,2.8.9 and 2.9.0.pr3?

@JoyChou93

This comment has been minimized.

Show comment
Hide comment
@JoyChou93

JoyChou93 Apr 17, 2017

when do you want to release 2.7.10,2.8.9 and 2.9.0.pr3?

JoyChou93 commented Apr 17, 2017

when do you want to release 2.7.10,2.8.9 and 2.9.0.pr3?

@OneSourceCat

This comment has been minimized.

Show comment
Hide comment
@OneSourceCat

OneSourceCat Apr 17, 2017

I don't think blacklist is a good mechanism to prevent this issue, because there are other Java Deserialized Gadgets or ClassLoaders can arise this problem including com.sun.org.apache.xalan which is in your list.

OneSourceCat commented Apr 17, 2017

I don't think blacklist is a good mechanism to prevent this issue, because there are other Java Deserialized Gadgets or ClassLoaders can arise this problem including com.sun.org.apache.xalan which is in your list.

@ayound

This comment has been minimized.

Show comment
Hide comment
@ayound

ayound Apr 17, 2017

I suggest you to use black list like this

"^bsh[.].", "^com[.]google[.]inject[.].", "^com[.]mchange[.]v2[.]c3p0[.].", "^com[.]sun[.]jndi[.].", "^com[.]sun[.]corba[.].", "^com[.]sun[.]javafx[.].", "^com[.]sun[.]org[.]apache[.]regex[.]internal[.].", "^java[.]awt[.].", "^java[.]rmi[.].", "^javax[.]management[.].", "^javax[.]naming[.].", "^javax[.]script[.].", "^javax[.]swing[.].", "^org[.]apache[.]commons[.]beanutils[.].", "^org[.]apache[.]commons[.]collections[.]functors[.].", "^org[.]apache[.]myfaces[.].", "^org[.]apache[.]wicket[.].", ".org[.]apache[.]xalan.", "^org[.]codehaus[.]groovy[.]runtime[.].", "^org[.]hibernate[.].", "^org[.]python[.].", "^org[.]springframework..", "^sun[.]rmi[.].", "^javax[.]imageio[.].*", "^java[.]util[.]ServiceLoader$", "^java[.]net[.]URLClassLoader$”

ayound commented Apr 17, 2017

I suggest you to use black list like this

"^bsh[.].", "^com[.]google[.]inject[.].", "^com[.]mchange[.]v2[.]c3p0[.].", "^com[.]sun[.]jndi[.].", "^com[.]sun[.]corba[.].", "^com[.]sun[.]javafx[.].", "^com[.]sun[.]org[.]apache[.]regex[.]internal[.].", "^java[.]awt[.].", "^java[.]rmi[.].", "^javax[.]management[.].", "^javax[.]naming[.].", "^javax[.]script[.].", "^javax[.]swing[.].", "^org[.]apache[.]commons[.]beanutils[.].", "^org[.]apache[.]commons[.]collections[.]functors[.].", "^org[.]apache[.]myfaces[.].", "^org[.]apache[.]wicket[.].", ".org[.]apache[.]xalan.", "^org[.]codehaus[.]groovy[.]runtime[.].", "^org[.]hibernate[.].", "^org[.]python[.].", "^org[.]springframework..", "^sun[.]rmi[.].", "^javax[.]imageio[.].*", "^java[.]util[.]ServiceLoader$", "^java[.]net[.]URLClassLoader$”

@channingwen

This comment has been minimized.

Show comment
Hide comment
@channingwen

channingwen Apr 17, 2017

hello, everybody, I wait for new version, where can I get the version release 2.7.10,2.8.9 and 2.9.0.pr3?

channingwen commented Apr 17, 2017

hello, everybody, I wait for new version, where can I get the version release 2.7.10,2.8.9 and 2.9.0.pr3?

@maluguos

This comment has been minimized.

Show comment
Hide comment
@maluguos

maluguos Apr 17, 2017

@cowtowncoder
When 2.8.9 will be released? I can't find it in mvn repo or git release...

maluguos commented Apr 17, 2017

@cowtowncoder
When 2.8.9 will be released? I can't find it in mvn repo or git release...

@taisenki

This comment has been minimized.

Show comment
Hide comment
@taisenki

taisenki Apr 18, 2017

When 2.8.9 will be released? I wait for new version...

taisenki commented Apr 18, 2017

When 2.8.9 will be released? I wait for new version...

@cowtowncoder

This comment has been minimized.

Show comment
Hide comment
@cowtowncoder

cowtowncoder Apr 18, 2017

Member

@maluguos I do not release new version for every single bug fix. Have a look at release schedule:

https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.7

New version is unlikely to be released within next couple of weeks. Same goes for 2.8.9.
If a new version is needed sooner, you will need to use a local snapshot build.

Member

cowtowncoder commented Apr 18, 2017

@maluguos I do not release new version for every single bug fix. Have a look at release schedule:

https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.7

New version is unlikely to be released within next couple of weeks. Same goes for 2.8.9.
If a new version is needed sooner, you will need to use a local snapshot build.

@kuaike

This comment has been minimized.

Show comment
Hide comment
@kuaike

kuaike Apr 18, 2017

waiting for version 2.8.9 release...

kuaike commented Apr 18, 2017

waiting for version 2.8.9 release...

@cowtowncoder

This comment has been minimized.

Show comment
Hide comment
@cowtowncoder

cowtowncoder Apr 18, 2017

Member

@ayound I appreciate the list, but to be honest I think that restriction within core databind need to be focused on demonstratable security concerns. There are many types that could potentially be problematic, but I would hesitate to include very wide limits on, say, org. springframework, since there are utility types that may well be already in use by some users.
For 2.8 I did include a few types as per:

https://github.com/kantega/notsoserial

so I am not against extending the list, but at this point prefer keeping static blacklist to minimum.

Member

cowtowncoder commented Apr 18, 2017

@ayound I appreciate the list, but to be honest I think that restriction within core databind need to be focused on demonstratable security concerns. There are many types that could potentially be problematic, but I would hesitate to include very wide limits on, say, org. springframework, since there are utility types that may well be already in use by some users.
For 2.8 I did include a few types as per:

https://github.com/kantega/notsoserial

so I am not against extending the list, but at this point prefer keeping static blacklist to minimum.

@cowtowncoder

This comment has been minimized.

Show comment
Hide comment
@cowtowncoder

cowtowncoder Apr 18, 2017

Member

Everyone: I did do mvn deploy for 2.8 branches, so snapshots via Sonatype snapshot repository (for 2.8.9-SNAPSHOT) should have initial protection for vulnerabilities indicated.

Perhaps more importantly, I just pushed micro-patch 2.7.9.1 of jackson-databind: it should be available soon via Maven Central. I decided to do this because it is not clear whether there will be more 2.7 full releases (and if so, when), and due to criticality of this fix it seemed better to release micro-patch at this point.

As to 2.8: set of fixes is rather short, still:

https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.8.9

so I'll think of whether I should similarly release 2.8.8.1 as full release may take time (although there will certainly still be 2.8.9 as 2.9 is not yet released).

If anyone feels urgency wrt 2.8 please let me know.

Member

cowtowncoder commented Apr 18, 2017

Everyone: I did do mvn deploy for 2.8 branches, so snapshots via Sonatype snapshot repository (for 2.8.9-SNAPSHOT) should have initial protection for vulnerabilities indicated.

Perhaps more importantly, I just pushed micro-patch 2.7.9.1 of jackson-databind: it should be available soon via Maven Central. I decided to do this because it is not clear whether there will be more 2.7 full releases (and if so, when), and due to criticality of this fix it seemed better to release micro-patch at this point.

As to 2.8: set of fixes is rather short, still:

https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.8.9

so I'll think of whether I should similarly release 2.8.8.1 as full release may take time (although there will certainly still be 2.8.9 as 2.9 is not yet released).

If anyone feels urgency wrt 2.8 please let me know.

@logan2013

This comment has been minimized.

Show comment
Hide comment
@logan2013

logan2013 Apr 18, 2017

Everyone: Any impact on version 2.1.0?

thank you in advanced

logan2013 commented Apr 18, 2017

Everyone: Any impact on version 2.1.0?

thank you in advanced

@cowtowncoder

This comment has been minimized.

Show comment
Hide comment
@cowtowncoder

cowtowncoder Apr 18, 2017

Member

@logan2013 Yes, if (and only if):

  1. Object model is using either "default typing", or @JsonTypeInfo with nominal base type of java.lang.Object (or one of small number of tag-on "tag" types like java.io.Serializable and perhaps java.util.Comparable)
  2. JSON content comes from untrusted source, that is, someone can craft specific JSON message.

If so, there is at least one reproduction of an issue.

Now: as to versions prior to 2.7: I have a plan to implement a new Jackson module which can be used with ALL 2.x versions, including 2.1.0. This may take bit more time, but would be more useful than handling within jackson-databind.

I hope this helps.

Member

cowtowncoder commented Apr 18, 2017

@logan2013 Yes, if (and only if):

  1. Object model is using either "default typing", or @JsonTypeInfo with nominal base type of java.lang.Object (or one of small number of tag-on "tag" types like java.io.Serializable and perhaps java.util.Comparable)
  2. JSON content comes from untrusted source, that is, someone can craft specific JSON message.

If so, there is at least one reproduction of an issue.

Now: as to versions prior to 2.7: I have a plan to implement a new Jackson module which can be used with ALL 2.x versions, including 2.1.0. This may take bit more time, but would be more useful than handling within jackson-databind.

I hope this helps.

@alexchenfeiyu

This comment has been minimized.

Show comment
Hide comment
@alexchenfeiyu

alexchenfeiyu Apr 19, 2017

@cowtowncoder Hello, our product used 2.8.1, we need to solve the problem urgently.How can we do? We hope your help!
Thank you in advance

alexchenfeiyu commented Apr 19, 2017

@cowtowncoder Hello, our product used 2.8.1, we need to solve the problem urgently.How can we do? We hope your help!
Thank you in advance

@ycrxun

This comment has been minimized.

Show comment
Hide comment
@ycrxun

ycrxun Apr 19, 2017

Everyone: Any impact on version 1.x?
thank you in advanced

ycrxun commented Apr 19, 2017

Everyone: Any impact on version 1.x?
thank you in advanced

@paulwong888

This comment has been minimized.

Show comment
Hide comment
@paulwong888

paulwong888 Apr 19, 2017

@cowtowncoder any impact on jackson 2.7.5 + JDK 1.7 and above?

paulwong888 commented Apr 19, 2017

@cowtowncoder any impact on jackson 2.7.5 + JDK 1.7 and above?

@cowtowncoder

This comment has been minimized.

Show comment
Hide comment
@cowtowncoder

cowtowncoder Apr 19, 2017

Member

@alexchenfeiyu Do you know the vulnerability and that it affects you? I appreciate your general concern, but the vulnerability is quite specific and does not apply to majority of users.
Anyway: I will go ahead now and release 2.8.8.1: it will be available within couple of hours.

@ycrxun In theory yes, versions 1.5 and above.

@paulwong888 As per above, not very specific to Jackson version: but you may want to use jackson-databind 2.7.9.1 since it's the first one to have the fix.
However: it is possible JDK version matters; might not work on later JDK versions -- but I don't have specific knowledge that it would be prevent by particular version. Using latest JDK from given line could be safer (depends on embedded version of XSL engine JDK bundles).

As to vulnerability, this only applies to polymorphic type handling via default typing (or especially annotated @JsonTypeInfo on java.lang.Object type property) -- and obviously JSON crafted by untrusted third party.

Member

cowtowncoder commented Apr 19, 2017

@alexchenfeiyu Do you know the vulnerability and that it affects you? I appreciate your general concern, but the vulnerability is quite specific and does not apply to majority of users.
Anyway: I will go ahead now and release 2.8.8.1: it will be available within couple of hours.

@ycrxun In theory yes, versions 1.5 and above.

@paulwong888 As per above, not very specific to Jackson version: but you may want to use jackson-databind 2.7.9.1 since it's the first one to have the fix.
However: it is possible JDK version matters; might not work on later JDK versions -- but I don't have specific knowledge that it would be prevent by particular version. Using latest JDK from given line could be safer (depends on embedded version of XSL engine JDK bundles).

As to vulnerability, this only applies to polymorphic type handling via default typing (or especially annotated @JsonTypeInfo on java.lang.Object type property) -- and obviously JSON crafted by untrusted third party.

@shellb0y

This comment has been minimized.

Show comment
Hide comment
@shellb0y

shellb0y Apr 20, 2017

@cowtowncoder I did not find the 2.8.8.1 url ,please provide this url, thank you!

shellb0y commented Apr 20, 2017

@cowtowncoder I did not find the 2.8.8.1 url ,please provide this url, thank you!

@cowtowncoder cowtowncoder added the CVE label Dec 12, 2017

@cowtowncoder cowtowncoder changed the title from Jackson Deserializer security vulnerability to Jackson Deserializer security vulnerability via default typing Dec 12, 2017

cmark added a commit to b2ihealthcare/snow-owl that referenced this issue Dec 12, 2017

[tp] bump jackson to 2.8.10
Fixes the following security issue:
FasterXML/jackson-databind#1599
FasterXML/jackson-databind#1837

Also include other jackson libraries in the target platform instead of
embedding them via Bundle-ClassPath.
@lukaszlenart

This comment has been minimized.

Show comment
Hide comment
@lukaszlenart

lukaszlenart Dec 20, 2017

Do I get it right that the default typing isn't enabled by default?

lukaszlenart commented Dec 20, 2017

Do I get it right that the default typing isn't enabled by default?

@cowtowncoder

This comment has been minimized.

Show comment
Hide comment
@cowtowncoder

cowtowncoder Dec 20, 2017

Member

@lukaszlenart Absolutely, it is not the default for Jackson. It is possible that some frameworks could enable it, but I really hope they do not -- I do not think it is a setting that makes sense as the baseline, both for security reasons and for basic ergonomics. To me at least it is quite specific setting that one might want to use when replacing JDK serialization, for internal storage, checkpointing or such usage.
But never for public (REST) endpoints.

Member

cowtowncoder commented Dec 20, 2017

@lukaszlenart Absolutely, it is not the default for Jackson. It is possible that some frameworks could enable it, but I really hope they do not -- I do not think it is a setting that makes sense as the baseline, both for security reasons and for basic ergonomics. To me at least it is quite specific setting that one might want to use when replacing JDK serialization, for internal storage, checkpointing or such usage.
But never for public (REST) endpoints.

@cowtowncoder

This comment has been minimized.

Show comment
Hide comment
@cowtowncoder

cowtowncoder Dec 20, 2017

Member

Note: there will soon be 2.8.11 as well, to address further work at #1855.

Member

cowtowncoder commented Dec 20, 2017

Note: there will soon be 2.8.11 as well, to address further work at #1855.

@cowtowncoder cowtowncoder changed the title from Jackson Deserializer security vulnerability via default typing to Jackson Deserializer security vulnerability via default typing (CVE-2017-7525) Dec 21, 2017

@lukaszlenart

This comment has been minimized.

Show comment
Hide comment
@lukaszlenart

lukaszlenart Dec 21, 2017

@cowtowncoder thank you for the explanation, I was struggling with this question for some time and cannot find a clear answer :)

lukaszlenart commented Dec 21, 2017

@cowtowncoder thank you for the explanation, I was struggling with this question for some time and cannot find a clear answer :)

@lukaszlenart

This comment has been minimized.

Show comment
Hide comment
@lukaszlenart

lukaszlenart Dec 21, 2017

One more question because this isn't clear to me: using @JsonTypeInfo anywhere in an app enables default typing, is that true?

lukaszlenart commented Dec 21, 2017

One more question because this isn't clear to me: using @JsonTypeInfo anywhere in an app enables default typing, is that true?

@cowtowncoder

This comment has been minimized.

Show comment
Hide comment
@cowtowncoder

cowtowncoder Dec 21, 2017

Member

@lukaszlenart No. You can think of it as reverse: enabling default typing is about same as adding @JsonTypeInfo either on all classes, or on all properties.

So adding @JsonTypeInfo only enables polymorphic typing for either:

  1. Properties of type X (when added to declaration of class X)
  2. Specific property annotated.

and even then it will only allow subtypes of the property. So vulnerability would only apply property like:

@JsonTypeInfo(....)
public Object value;

where any type is accepted as a subtype. But would not apply, for example, for:

@JsonTypeInfo(....)
public MyBaseType value;

where only real subtypes are accepted, ever.

You can still override handling, too, to disable polymorphic handling for specific type (Class) or property, by using @JsonTypeInfo(include = As.NONE) (or something similar, I forget exact setting).

Member

cowtowncoder commented Dec 21, 2017

@lukaszlenart No. You can think of it as reverse: enabling default typing is about same as adding @JsonTypeInfo either on all classes, or on all properties.

So adding @JsonTypeInfo only enables polymorphic typing for either:

  1. Properties of type X (when added to declaration of class X)
  2. Specific property annotated.

and even then it will only allow subtypes of the property. So vulnerability would only apply property like:

@JsonTypeInfo(....)
public Object value;

where any type is accepted as a subtype. But would not apply, for example, for:

@JsonTypeInfo(....)
public MyBaseType value;

where only real subtypes are accepted, ever.

You can still override handling, too, to disable polymorphic handling for specific type (Class) or property, by using @JsonTypeInfo(include = As.NONE) (or something similar, I forget exact setting).

@lukaszlenart

This comment has been minimized.

Show comment
Hide comment
@lukaszlenart

lukaszlenart Dec 22, 2017

Nice, thank you :)

lukaszlenart commented Dec 22, 2017

Nice, thank you :)

@fv3386

This comment has been minimized.

Show comment
Hide comment
@fv3386

fv3386 Dec 25, 2017

I use jackson-databind 2.9.3 which depends on jackson-annotations 2.9.0, will this cause problems? Do I need to upgrade all jackson related jars to 2.9.3?

fv3386 commented Dec 25, 2017

I use jackson-databind 2.9.3 which depends on jackson-annotations 2.9.0, will this cause problems? Do I need to upgrade all jackson related jars to 2.9.3?

@cowtowncoder

This comment has been minimized.

Show comment
Hide comment
@cowtowncoder

cowtowncoder Dec 26, 2017

Member

@fasterxml-travis No: jackson-annotations is quite special in that it only declares annotation types, and as a general rule there should be no differences at all between all 2.9.x versions (and same for all 2.x minor patches). In Jackson 3.x we will only have 3.0, 3.1 and so on, to remove this one source of confusion.

So: 2.9.0 is fine; 2.9.3 is also fine. They do not have code differences (*)

(*) For sake of completeness: there happens to be one actual packaging difference: 2.9.1 and above have Java 9 module declaration compiled in. Otherwise patches are identical.

Member

cowtowncoder commented Dec 26, 2017

@fasterxml-travis No: jackson-annotations is quite special in that it only declares annotation types, and as a general rule there should be no differences at all between all 2.9.x versions (and same for all 2.x minor patches). In Jackson 3.x we will only have 3.0, 3.1 and so on, to remove this one source of confusion.

So: 2.9.0 is fine; 2.9.3 is also fine. They do not have code differences (*)

(*) For sake of completeness: there happens to be one actual packaging difference: 2.9.1 and above have Java 9 module declaration compiled in. Otherwise patches are identical.

@ksuresh8

This comment has been minimized.

Show comment
Hide comment
@ksuresh8

ksuresh8 Feb 1, 2018

does this vulnerability affect jackson-databind v2.3.3?

ksuresh8 commented Feb 1, 2018

does this vulnerability affect jackson-databind v2.3.3?

@cowtowncoder

This comment has been minimized.

Show comment
Hide comment
@cowtowncoder

cowtowncoder Feb 1, 2018

Member

@ksuresh8 yes. All 2.x versions not specifically included as having the fix will have it.

Member

cowtowncoder commented Feb 1, 2018

@ksuresh8 yes. All 2.x versions not specifically included as having the fix will have it.

@swankjesse

This comment has been minimized.

Show comment
Hide comment
@swankjesse

swankjesse Feb 14, 2018

Contributor

Have you considered disabling this feature when the target field’s type is java.lang.Object, Comparable, etc.? That would quickly cut down the attack surface.

Contributor

swankjesse commented Feb 14, 2018

Have you considered disabling this feature when the target field’s type is java.lang.Object, Comparable, etc.? That would quickly cut down the attack surface.

@cowtowncoder

This comment has been minimized.

Show comment
Hide comment
@cowtowncoder

cowtowncoder Feb 14, 2018

Member

@swankjesse Unfortunately ability to use that base type is a big use case (equivalent of JDK serialization, with all the warts), so those can not really be blocked without breaking some of existing usage. Especially since library can not really determine if content is trusted or might come from untrusted source.

But I think adding a MapperFeature that would add such limits is indeed something that might make sense -- and making that feature enabled by default for 3.0.

That is the loose plan anyway, so that although it will be possible to allow unsafe (potentially unsafe) usage it should require bit more work. As things are one has to enable default typing (or unsafe base type for @JsonTypeInfo), but it is not obvious that there are security considerations.

There is also some related discussion on #1866 as well as at:

FasterXML/jackson3-dev#21

although I may not have added an issue for MapperFeature to perhaps add in 2.9 (which is against SemVer, but 2.9 is likely the last 2.x version so... may be lesser evil. Unless I'll change my mind and do 2.10 yet)

Member

cowtowncoder commented Feb 14, 2018

@swankjesse Unfortunately ability to use that base type is a big use case (equivalent of JDK serialization, with all the warts), so those can not really be blocked without breaking some of existing usage. Especially since library can not really determine if content is trusted or might come from untrusted source.

But I think adding a MapperFeature that would add such limits is indeed something that might make sense -- and making that feature enabled by default for 3.0.

That is the loose plan anyway, so that although it will be possible to allow unsafe (potentially unsafe) usage it should require bit more work. As things are one has to enable default typing (or unsafe base type for @JsonTypeInfo), but it is not obvious that there are security considerations.

There is also some related discussion on #1866 as well as at:

FasterXML/jackson3-dev#21

although I may not have added an issue for MapperFeature to perhaps add in 2.9 (which is against SemVer, but 2.9 is likely the last 2.x version so... may be lesser evil. Unless I'll change my mind and do 2.10 yet)

komamitsu added a commit to msgpack/msgpack-java that referenced this issue Feb 20, 2018

Update jackson-databind 2.7.9.1
to address FasterXML/jackson-databind#1599

With 2.8.10, it degrades the serialization performance of
jackson-dataformat-msgpack down to 62%.
@cowtowncoder

This comment has been minimized.

Show comment
Hide comment
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment