This branch will adapt the speedrfmodel to a dtree.treemodel and use dtree.treemodel's tojava methods.

Using this branch, we will create a dtree.compressedTree every time we create a singlenoderf.tree and append it to the speedrfmodel.

The output pojo passes the 7 tests: R/tests/testdir_javapredict/runit_SRF_*

There was a bug that occurred when the number of training observations was not divisible by the number of internal CV folds (as specified in the cvControl argument of h2o.ensemble). This has been fixed.

This PR also includes a few edits to the documentation.

Regression functionality is now working in h2o.ensemble in the h2oEnsemble package. For regression, I suggest using metalearner = "SL.nnls" using the SL.nnls function provided in ./R/ensemle/SuperLearner_wrappers.R

The new R/ensemble folder contains the h2oEnsemble R package and a few related scripts. The package contains functionality to create ensemble models using h2o algorithms as base learners.

Current docs have no requirements needed for building h2o. These requirements are noted in the document to help developers setup environment before several trying and getting error.

The link to the group on Google Groups does not work. It should be https://groups.google.com/forum/#!forum/h2ostream instead of https://groups.google.com/forum/?!forum/h2ostream.

Dear H2O team,

I found using your h2o.predict() method returns a data frame of prediction results with probability in each class. I think this new method will be handy when you only want to see a list of prediction results. Let me know if you have any questions or suggestions.

Thanks, Yuan

... offer entropy and gini splitting criteria, it may be nice to offer twoing as well.

Reference: Breiman, L. Some Properties of Splitting Criteria, Statistics Department, University of California, Berkeley. 1992.

Added some very basic jUnit tests for the twoing computation.

This is a tiny change but since we wanted it I figured I would add it. Next would be to get the response and pull out the list of variables with importance.

Somehow the commit shows a lot of whitespace addition/removals, sorry about that.

I added the Python requirements.txt file with the Sphinx-doc module necessary to build documentation. Use the file with pip command:

pip install -r requirements.txt [--user]

Fixes make build error:

make[2]: Entering directory `/home/vmlaker/work/git-h2o/h2o-docs' sphinx-build -b html -d build/doctrees source build/html Making output directory... Running Sphinx v1.1.3

Extension error: Could not import extension sphinxcontrib.fulltoc (exception: No module named fulltoc) make[2]: *** [html] Error 1 make[2]: Leaving directory /home/vmlaker/work/git-h2o/h2o-docs' make[1]: *** [dw_2] Error 2 make[1]: Leaving directory/home/vmlaker/work/git-h2o' make: *** [nightly_build_stuff] Error 2

Security Vulnerability Fix

This pull request fixes a partial-path traversal vulnerability due to an insufficient path traversal guard.

Even if you deem, as the maintainer of this project, this is not necessarily fixing a security vulnerability, it is still a valid security hardening.

Preamble

Impact

This issue allows a malicious actor to potentially break out of the expected directory. The impact is limited to sibling directories. For example, userControlled.getCanonicalPath().startsWith("/usr/out") will allow an attacker to access a directory with a name like /usr/outnot.

Why?

To demonstrate this vulnerability, consider "/usr/outnot".startsWith("/usr/out"). The check is bypassed although /outnot is not under the /out directory. It's important to understand that the terminating slash may be removed when using various String representations of the File object. For example, on Linux, println(new File("/var")) will print /var, but println(new File("/var", "/") will print /var/; however, println(new File("/var", "/").getCanonicalPath()) will print /var.

The Fix

Comparing paths with the java.nio.files.Path#startsWith will adequately protect againts this vulnerability.

For example: file.getCanonicalFile().toPath().startsWith(BASE_DIRECTORY) or file.getCanonicalFile().toPath().startsWith(BASE_DIRECTORY_FILE.getCanonicalFile().toPath())

Other Examples

• CVE-2022-31159 - aws/aws-sdk-java
• CVE-2022-23457 - ESAPI/esapi-java-legacy

:arrow_right: Vulnerability Disclosure :arrow_left:

:wave: Vulnerability disclosure is a super important part of the vulnerability handling process and should not be skipped! This may be completely new to you, and that's okay, I'm here to assist!

First question, do we need to perform vulnerability disclosure? It depends!

1. Is the vulnerable code only in tests or example code? No disclosure required!
2. Is the vulnerable code in code shipped to your end users? Vulnerability disclosure is probably required!

For partial path traversal, consider if user-supplied input could ever flow to this logic. If user supplied input could reach this conditional, it's insufficient and, as such, most likely a vulnerability.

Vulnerability Disclosure How-To

You have a few options options to perform vulnerability disclosure. However, I'd like to suggest the following 2 options:

1. Request a CVE number from GitHub by creating a repository-level GitHub Security Advisory. This has the advantage that, if you provide sufficient information, GitHub will automatically generate Dependabot alerts for your downstream consumers, resolving this vulnerability more quickly.
2. Reach out to the team at Snyk to assist with CVE issuance. They can be reached at the Snyk's Disclosure Email. Note: Please include JLLeitschuh Disclosure in the subject of your email so it is not missed.

Detecting this and Future Vulnerabilities

You can automatically detect future vulnerabilities like this by enabling the free (for open-source) GitHub Action.

I'm not an employee of GitHub, I'm simply an open-source security researcher.

Source

This contribution was automatically generated with an OpenRewrite refactoring recipe, which was lovingly hand crafted to bring this security fix to your repository.

The source code that generated this PR can be found here: PartialPathTraversalVulnerability

Why didn't you disclose privately (ie. coordinated disclosure)?

This PR was automatically generated, in-bulk, and sent to this project as well as many others, all at the same time.

This is technically what is called a "Full Disclosure" in vulnerability disclosure, and I agree it's less than ideal. If GitHub offered a way to create private pull requests to submit pull requests, I'd leverage it, but that infrastructure, sadly, doesn't exist yet.

The problem is that as an open source software security researcher, I (exactly like open source maintainers), I only have so much time in a day. I'm able to find vulnerabilities impacting hundreds, or sometimes thousands of open source projects with tools like GitHub Code Search and CodeQL. The problem is that my knowledge of vulnerabilities doesn't scale very well.

Individualized vulnerability disclosure takes time and care. It's a long and tedious process, and I have a significant amount of experience with it (I have over 50 CVEs to my name). Even tracking down the reporting channel (email, Jira, ect..) can take time and isn't automatable. Unfortunately, when facing prblems of this scale, individual reporting doesn't work well either.

Additionally, if I just spam out emails or issues, I'll just overwhelm already over taxed maintainers, I don't want to do this either.

By creating a pull request, I am aiming to provide maintainers something highly actionable to actually fix the identified vulnerability; a pull request.

There's a larger discussion on this topic that can be found here: https://github.com/JLLeitschuh/security-research/discussions/12

Opting-Out

If you'd like to opt-out of future automated security vulnerability fixes like this, please consider adding a file called .github/GH-ROBOTS.txt to your repository with the line:

User-agent: JLLeitschuh/security-research
Disallow: *

This bot will respect the ROBOTS.txt format for future contributions.

Alternatively, if this project is no longer actively maintained, consider archiving the repository.

CLA Requirements

This section is only relevant if your project requires contributors to sign a Contributor License Agreement (CLA) for external contributions.

It is unlikely that I'll be able to directly sign CLAs. However, all contributed commits are already automatically signed-off.

The meaning of a signoff depends on the project, but it typically certifies that committer has the rights to submit this work under the same license and agrees to a Developer Certificate of Origin (see https://developercertificate.org/ for more information).

- Git Commit Signoff documentation

If signing your organization's CLA is a strict-requirement for merging this contribution, please feel free to close this PR.

Sponsorship & Support

This contribution is sponsored by HUMAN Security Inc. and the new Dan Kaminsky Fellowship, a fellowship created to celebrate Dan's memory and legacy by funding open-source work that makes the world a better (and more secure) place.

This PR was generated by Moderne, a free-for-open source SaaS offering that uses format-preserving AST transformations to fix bugs, standardize code style, apply best practices, migrate library versions, and fix common security vulnerabilities at scale.

Tracking

All PR's generated as part of this fix are tracked here: https://github.com/JLLeitschuh/security-research/issues/13

Snyk has created this PR to fix one or more vulnerable packages in the `npm` dependencies of this project.

Changes included in this PR

• Changes to the following files to upgrade the vulnerable dependencies to a fixed version:
  • client/package.json

Vulnerabilities that will be fixed

With an upgrade:

Severity | Issue | Breaking Change | Exploit Maturity :-------------------------:|:-------------------------|:-------------------------|:------------------------- | Prototype Pollution
SNYK-JS-LODASH-567746 | Yes | Proof of Concept

Check the changes in this PR to ensure they won't cause issues with your project.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.

For more information: 🧐 View latest project report

🛠 Adjust project settings

📚 Read more about Snyk's upgrade and patch logic

Snyk has created this PR to upgrade istanbul from 0.2.16 to 0.4.5.

:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

• The recommended version is 28 versions ahead of your current version.
• The recommended version was released 4 years ago, on 2016-08-21.

The recommended version fixes:

Severity | Issue | Exploit Maturity :-------------------------:|:-------------------------|:------------------------- | Prototype Pollution
SNYK-JS-HANDLEBARS-534988 | No Known Exploit | Arbitrary Code Execution
SNYK-JS-HANDLEBARS-534478 | No Known Exploit | Prototype Pollution
SNYK-JS-HANDLEBARS-469063 | No Known Exploit | Prototype Pollution
SNYK-JS-HANDLEBARS-173692 | No Known Exploit | Cross-site Scripting (XSS)
npm:handlebars:20151207 | No Known Exploit | Prototype Pollution
SNYK-JS-HANDLEBARS-567742 | Proof of Concept

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.

For more information:

🧐 View latest project report

🛠 Adjust upgrade PR settings

🔕 Ignore this dependency or unsubscribe from future upgrade PRs

Snyk has created this PR to upgrade stylus from 0.43.1 to 0.54.7.

:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

• The recommended version is 37 versions ahead of your current version.
• The recommended version was released 10 months ago, on 2019-08-21.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.

For more information:

🧐 View latest project report

🛠 Adjust upgrade PR settings

🔕 Ignore this dependency or unsubscribe from future upgrade PRs

Snyk has created this PR to upgrade uglify-js from 2.4.24 to 2.8.29.

• The recommended version is 42 versions ahead of your current version.
• The recommended version was released 3 years ago, on 2017-06-14.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.

For more information:

🧐 View latest project report

🛠 Adjust upgrade PR settings

🔕 Ignore this dependency or unsubscribe from future upgrade PRs

Snyk has created this PR to upgrade coffeelint from 1.1.0 to 1.16.2.

• The recommended version is 42 versions ahead of your current version.
• The recommended version was released 2 years ago, on 2018-02-17.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.

For more information:

🧐 View latest project report

🛠 Adjust upgrade PR settings

🔕 Ignore this dependency or unsubscribe from future upgrade PRs