Add safe Jackson deserializers to prevent a DoS attack

Jackson uses BigDecimal for deserialization of java.time instants and durations. The problem is that if the users sets a very big number in the scientific notation (like 1e1000000000), it takes forever to convert BigDecimal to BigInteger, and then to convert it to a long value. An example of the stack trace:
@Test(timeout = 2000)
public void parseBigDecimal(){
    new BigDecimal("1e1000000000").longValue();
}

org.junit.runners.model.TestTimedOutException: test timed out after 2000 milliseconds
	at java.math.BigInteger.squareToomCook3(BigInteger.java:2074)
	at java.math.BigInteger.square(BigInteger.java:1899)
	at java.math.BigInteger.squareToomCook3(BigInteger.java:2053)
	at java.math.BigInteger.square(BigInteger.java:1899)
	at java.math.BigInteger.squareToomCook3(BigInteger.java:2051)
	at java.math.BigInteger.square(BigInteger.java:1899)
	at java.math.BigInteger.squareToomCook3(BigInteger.java:2049)
	at java.math.BigInteger.square(BigInteger.java:1899)
	at java.math.BigInteger.squareToomCook3(BigInteger.java:2049)
	at java.math.BigInteger.square(BigInteger.java:1899)
	at java.math.BigInteger.squareToomCook3(BigInteger.java:2055)
	at java.math.BigInteger.square(BigInteger.java:1899)
	at java.math.BigInteger.squareToomCook3(BigInteger.java:2049)
	at java.math.BigInteger.square(BigInteger.java:1899)
	at java.math.BigInteger.pow(BigInteger.java:2306)
	at java.math.BigDecimal.bigTenToThe(BigDecimal.java:3543)
	at java.math.BigDecimal.bigMultiplyPowerTen(BigDecimal.java:3676)
	at java.math.BigDecimal.setScale(BigDecimal.java:2445)
	at java.math.BigDecimal.toBigInteger(BigDecimal.java:3025)

A fix would be to reject big decimal values outside of the Instant and Duration ranges.
See:
[1] https://github.com/FasterXML/jackson-databind/issues/2141
[2] https://reddit.com/r/java/comments/9jyv58/lowbandwidth_dos_vulnerability_in_jacksons/

@dropwizard/committers Please review

@nickbabcock Please PTAL

Before merging, is this only slated for the 1.3.x branch? Or what's the plan?

Before merging, is this only slated for the 1.3.x branch? Or what's the plan?
It's for the 1.3 and 1.2 branches. I've released Dropwizard 1.3.6 and 1.2.9 with this patch to Maven Central.

@arteam is this not an issue in Jackson 2.9.6 which is what 2.0.0 is currently using in master?

It is. I will cherry-pick the patch to master.

@arteam I don't think 1.3.6 was released fully.  dropwizard-parent 1.3.6 in particular seems to be missing from https://repo.maven.apache.org/maven2/io/dropwizard/dropwizard-parent/

Looks like the upload was broken. I will redeploy the parent POM.

Hey guys looks like you're already aware but 1.3.6 fails to install properly:
[ERROR] Failed to execute goal on project api: Could not resolve dependencies for project com.sanctionco.thunder:api:jar:2.0.1-SNAPSHOT: Failed to collect dependencies at io.dropwizard:dropwizard-testing:jar:1.3.6: Failed to read artifact descriptor for io.dropwizard:dropwizard-testing:jar:1.3.6: Could not transfer artifact io.dropwizard:dropwizard-parent:pom:1.3.6 from/to sonatype-apache (https://repository.apache.org/releases/): Connect to repository.apache.org:443 [repository.apache.org/<IP_ADDRESS>] failed: Connection timed out (Connection timed out) -> [Help 1]

Ok, I've managed to manually deploy the 1.3.6 parent pom, should be in Maven Central in an hour. I wish releases to the Sonatype OSS repo were atomic.

Thanks @arteam, is it possible to redeploy the whole tag to ensure any other modules weren’t missed?

I don't think so, I believe you it's possible to redeploy only missed artifacts. Dropwizard once had an issue with several broken artifacts in the Central repo, so we had to create an issue with Sonatype. It turned out some caches got corrupted, they manually busted them. Hopefully, this time it won't be so bad.

Looks like it's there: https://repo.maven.apache.org/maven2/io/dropwizard/dropwizard-parent/1.3.6/

Installing 1.3.6 is working for me now - thanks!

Jackson 2.9.8 now provides a native fix for the issue (cf. https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.9.8, https://github.com/FasterXML/jackson-modules-java8/issues), so you might want to revert these changes in Dropwizard and save yourself the need to maintain it.

@bentmann Thank you for the heads up! I will follow up with an update the official fix.


add eye book icons

Ref #4047
Adding the icons for certain work types and the See in all seeing 👁 .

@davidpmccormick I'll wait for you to merge the prettier branch.
Also - this is a fork from #4047 - are we happy with that?


Link to download weights is broken

I tried to download the model weights from the provided link and got the following error: The requested URL /smilelab/xuma/ContextCluster/coc-updates/tiny/ was not found on this server. I hope you'll be able to fix this issue soon.
Thanks

Hi,thanks for letting me know. Currently, our lab's website has been shutted down. We have contacted with the manager, hope it will be fixed soon. Please let me know if it is still not working after one week, thanks!

@HussainAlasmawi Got it. Okay, let me retry the models. It may take some time. Once done, I will later you know. If want a particular checkpoint, please let me know and I can train it for you first.

I need the three models  Tiny, Small, & Medium. Hope it does not take that long.
Thanks,

@ma-xu would like to know how long it will take to get the models.

@HussainAlasmawi  I will check tmr. I think Tony and small are done.

@HussainAlasmawi
Just checked, the tiny and tiny_plain are done, achieves  73.2% and 73.8% top-1 accuracy, which is higher than reported (71.9 and 72.0).  I upload the checkpoints and logs in the google drive link:
https://drive.google.com/drive/folders/13MHhDnITaqcsKiSGeUZPeJ-VpfQkH_9F?usp=sharing
Once small and mid are finished, I will uploade to the link and ping you.
Thanks for your patience, please let me know if you have any questions.

@HussainAlasmawi Hi, I also uploaded the small model, which achieves 78.1, 0.3 higher than reported.
Sry that the training cost too much time since my nodes are limited and preemptible. I will update medium once finshed.

@HussainAlasmawi Updated all checkpoints and the README file, thanks for your kind reminder.


Update app copy

:tada: This PR is included in version 1.28.10-dev.2 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.29.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Adds correct response to 'technical assessment` + serves a random Meshuggah video from Youtube.

Thanks for the PR!
However, there's an inside joke behind the technical assessment answer and I would prefer to leave that one alone. Can you strip out those changes and just have the new command in this PR?
Thanks!

Thanks!

Whoops. Had to revert this. There are some show stopping errors going on. See inline comments. :-D


"Edit This Page" links on the doc is linking to wrong places

They should be linked to https://github.com/kubernetes-incubator/kube-aws/tree/master/docs/* rather tha https://github.com/kube-aws/docs/tree/master/*

@c-knowles I suggest that the link url would better be under edit/ rather than tree/(alias of blob) so that a link url becomes:
https://github.com/kubernetes-incubator/kube-aws/edit/master/docs/README.md
which will allow the user to immediately start editing the page for contribution.
I suppose the user may expect this behavior from the text "Edit This Page".

/lgtm
@mumoshu one thing to consider is the only people who get an edit page is those with write access. I'd like it if we enabled branch protection on master to avoid direct editing without PR. Anyone without access will be greeted by the You need to fork this repository to propose changes message and a button to fork so that seems fine. But then not sure if it directs them back to the document in question later.

Codecov Report

Merging #861 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #861   +/-   ##
=======================================
  Coverage   34.49%   34.49%
=======================================
  Files          57       57
  Lines        3902     3902
=======================================
  Hits         1346     1346
  Misses       2398     2398
  Partials      158      158

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5c1eb60...101fdbe. Read the comment docs.

Thanks!
I've enabled branch protection with push restriction on master.


Adding architecture support dynamically

It would be very useful to employ BARF's REIL analysis tools for architectures not supported in BARF without modifying its core but rather through a defined API that allows to add support for an architecture (information, disassembler, REIL translator) in a dynamic fashion. In this way, BARF would be used as a library inside another project.
An example of this use case is the Hexag00n project (that works with the Hexagon architecture, currently not supported in BARF), where BARF's REIL analysis tools would be very useful. Hexag00n already has its own disassembler (for the Hexagon architecture) and REIL translator, porting these to the BARF core is not a trivial task, nor it is desirable: BARF and Hexag00n should be able to work together while avoiding as much coupling as possible.
In this scenario Hexag00n will use BARF as a library facilitating the Hexagon architecture support to BARF in a dynamic fashion, without modifying BARF's source code, e.g., forcing BARF to import Hexag00n disassembler (and thus generating a circular dependency). An API has to be defined in BARF to be able to import that architecture support, for this purpose the load_architecture method has been added to the BARF core. This method is employed in an Hexag00n's example script which will be used as a first step to precisely define what has to be provided to BARF to generate REIL code (from an Hexagon binary) through the BARF framework.
For now, what has been characterized as architecture support are 3 base classes:

ArchitectureInformation: contains the basic definitions of an architecture like its size, registers, etc.
Disassembler: encapsulates the architecture disassembler.
Translator: encapsulates the architecture to REIL translator.

For each architecture supported, new classes have to be derived from these ones, containing all the necessary information for BARF to generate an equivalent REIL code and proceed to its analysis. Up to now these derived classes are part of the BARF core (like x86 and ARM architectures). With this new functionality, the objective is, through a defined API, being able to provide architecture support on the fly while using BARF as a library (imported in the working project).

The list of BARF's supported architectures is static and can't be modified by the load_architecture method.
When BARF opens a binary ELF file, the _get_arch_elf function is called to figure out the machine type from the ELF header. As the Hexagon architecture is not registered it raises an exception (Machine not supported).