HackerOne Code
Visit HackerOne.comLog In
  • Introduction to HackerOne Code for On-Premise Integrations
  • Create User Account & Organization
  • Installing PullRequest Proxy
  • Configuring your Proxy to Connect to the PullRequest Server
  • Configure Posting User
    • Configure GitHub Posting User
    • Configure Bitbucket Posting User
    • Configure GitLab Posting User
    • Configure Azure DevOps Posting User
  • Configuring SSL
  • Start the PullRequest Proxy
  • Verify Data on HackerOne Code
  • Configure Webhooks
    • Configure GitHub Webhooks
    • Configure Bitbucket Webhooks
    • Configure GitLab Webhooks
    • Configure Azure DevOps Webhooks
  • Next Steps
    • Project Visibility in the HackerOne Code Dashboard
  • Manually Requesting Validation With Posting User
  • Upgrading PullRequest Proxy
  • PullRequest Proxy Dataflow Diagram
Powered by GitBook
On this page
  • Server Provisioning
  • Configuring the firewall
  • Server install
  • Install necessary packages
  • Create service user
  • Installing the proxy
  • Configuring an HTTP proxy

Installing PullRequest Proxy

When your organization has been created, you should receive a link via email (or other specified delivery) containing the HackerOne's PullRequest Proxy as a compressed package tarball.

PreviousCreate User Account & OrganizationNextConfiguring your Proxy to Connect to the PullRequest Server

Last updated 27 days ago

Server Provisioning

These instructions assume that the PullRequest Proxy will run in a cloud environment, and as such, the proxy itself will be running on its own virtual instance. What this section will go over is not only the recommended starting point for instance provisioning but also why it's recommended. First, the recommended specifications are as follows:

  • 2 vCPUs

  • 16 GB of memory

  • 200 GB of disk space

If the below "Server Install" instructions are followed, PullRequest Proxy stores all of its files in the /home/pullrequest/pullrequest_proxy/ directory. This directory will store the service executables for various installed versions of the proxy and as the runtime data, as well.

As the PullRequest Proxy requires access to the source code repository of your source provider, a copy of each repository will be stored locally. This will take up the most storage space of everything else, so it's important to configure the drive with that in mind.

As for the CPU and memory recommendations, the PullRequest Proxy will be mostly running the git utility and calling out to your source code provider via APIs, so it's not really expected to need much in this area. If you see increased usage here, you can increase the power of the instance.

Configuring the firewall

The PullRequest Proxy will only contact the following FQDNs:

https://app.pullrequest.com
https://content.pullrequest.com

The only one that's required for the proxy to minimally operate is https://app.pullrequest.com.

The https://content.pullrequest.com domain is only required if enabling auto-upgrade. Read more in the next section.

In order for the PullRequest Proxy to be able to access source code provider APIs, the proxy instance itself needs to have access to your source code provider instances either via http (port 80), https (port 443), or both.

If you are configuring webhooks from your source code provider to the proxy, then the provider instances need to be able to access the proxy instance by either port 5012 if using http and 8443 if using https. More on configuring SSL can be found here:

Configuring SSL

More on configuring webhooks can be found here:

Configure Webhooks

Server install

The instructions below outline how to install the PullRequest Proxy on a fresh server. The assumed flavor of Linux is Amazon Linux 2, but you can go ahead and modify the instructions to apply to your flavor of Linux. The commands themselves assume you're running as the root user.

Install necessary packages

The PullRequest Proxy doesn't have many dependencies as it is distributed as an executable binary. However, it does require that the git utility is installed.

yum install -y git

Create service user

Best practices dictate that each service should have its own user running it. Let's go ahead and create a PullRequest user. Below, I'm creating the pullrequest user and locking the account to prevent logins as the user.

useradd pullrequest
usermod -L pullrequest

Installing the proxy

Now, it's time to assume the role of the pullrequest user for this portion of the installation process.

su pullrequest

The following commands will be run as the pullrequest user.

cd $HOME
curl <proxy_url> --output - | tar zxvf -
cd pullrequest_proxy

We'll stay logged in as the pullrequest user for the next few steps so that the proxy can now be configured. Go ahead and open the .env file in this directory in your favorite text editor.

vim .env

Configuring an HTTP proxy

As the PullRequest Proxy uses the Golang standard library for communicating with external domains, the standard UNIX environment variables (http_proxy, HTTP_PROXY, https_proxy, HTTPS_PROXY, no_proxy, and NO_PROXY) can be configured in the .env file. Information about these can be found here:

https://www.cyberciti.biz/faq/linux-unix-set-proxy-environment-variable/
https://about.gitlab.com/blog/2021/01/27/we-need-to-talk-no-proxy/
Auto-Upgrade