Coder Social home page Coder Social logo

getsentry / relay Goto Github PK

View Code? Open in Web Editor NEW
294.0 54.0 81.0 222.66 MB

Sentry event forwarding and ingestion service.

Home Page: https://docs.sentry.io/product/relay/

License: Other

Rust 87.69% Makefile 0.14% C 0.34% Python 10.92% Shell 0.27% Dockerfile 0.04% Lua 0.21% Jsonnet 0.32% HTML 0.06% CSS 0.01%
tag-production

relay's Introduction

Sentry

Official Sentry Relay

CI GitHub Release PyPI

Relay

The Sentry Relay is a service that pushes some functionality from the Sentry SDKs as well as the Sentry server into a proxy process.

Documentation

License

Like Sentry, Relay is licensed under the FSL. See the LICENSE.md file and this blog post for more information.

Development

To build Relay, we require the latest stable Rust. The crate is split into a workspace with multiple features, so when running building or running tests always make sure to pass the --all and --all-features flags. The processing feature additionally requires a C compiler and CMake.

To install the development environment, librdkafka must be installed and on the path. On macOS, we require to install it with brew install librdkafka, as the installation script uses brew --prefix to determine the correct location.

We use VSCode for development. This repository contains settings files configuring code style, linters, and useful features. When opening the project for the first time, make sure to install the Recommended Extensions, as they will allow editor assist during coding.

The root of the repository contains a Makefile with useful commands for development:

  • make check: Runs code formatting checks and linters. This is useful before opening a pull request.
  • make test: Runs unit tests, integration tests and Python package tests (see below for more information).
  • make all: Runs all checks and tests. This runs most of the tasks that are also performed in CI.
  • make clean: Removes all build artifacts, the virtualenv and cached files.

For more available make targets, please, run make help.

Integration tests require Redis and Kafka running in their default configuration. The most convenient way to get all required services is via sentry devservices, which requires an up-to-date Sentry development environment.

Building and Running

The easiest way to rebuild and run Relay for development is using cargo. Depending on the configuration, you may need to have a local instance of Sentry running.

# Initialize Relay for the first time
cargo run --all-features -- config init

# Rebuild and run with all features
cargo run --all-features -- run

The standard build commands are also available as make targets. Note that release builds still generate debug information.

# Build without optimizations in debug mode.
make build

# Build with release optimizations and debug information.
make release

For quickly verifying that Relay compiles after making some changes, you can also use cargo check:

cargo check --all --all-features

Features

By default, Relay compiles without processing mode. This is the configuration used for Relays operating as proxys. There are two optional features:

  • processing: Enables event processing and ingestion functionality. This allows to enable processing in config. When enabled, Relay will produce events into a Kafka topic instead of forwarding to the configured upstream. Also, it will perform full event normalization, filtering, and rate limiting.

  • crash-handler: Allows native crash reporting for segfaults and out-of-memory situations when internal error reporting to Sentry is enabled.

To enable a feature, pass it to the cargo invocation. For example, to run tests across all workspace crates with the processing feature enabled, run:

cargo run --features=processing

Tests

The test suite comprises unit tests, an integration test suite and a separate test suite for the Python package. Unit tests are implemented as part of the Rust crates and can be run via:

# Tests for default features
make test-rust

# Run Rust tests for all features
make test-rust-all

The integration test suite requires python. By default, the integration test suite will create a virtualenv, build the Relay binary with processing enabled, and run a set of integration tests:

# Make sure that kafka and redis are running
sentry devservices up kafka redis

# Create a new virtualenv, build Relay and run integration tests
make test-integration

# Build and run a single test manually
make build
.venv/bin/pytest tests/integration -k <test_name>

Snapshot tests

We use insta for snapshot testing. It will run as part of the make test command to validate schema/protocol changes. To install the insta tool for reviewing snapshots run:

cargo install cargo-insta

After that you'll be able to review and automatically update snapshot files by running:

cargo insta review

Make sure to run the command if you've made any changes to the event schema/protocol. For more information see https://insta.rs/docs/.

Linting

We use rustfmt and clippy from the latest stable channel for code formatting and linting. To make sure that these tools are set up correctly and running with the right configuration, use the following make targets:

# Format the entire codebase
make format

# Run clippy on the entire codebase
make lint

Python and C-ABI

Potentially, new functionality also needs to be added to the Python package. This first requires to expose new functions in the C ABI. For this, refer to the Relay C-ABI readme.

We highly recommend to develop and test the python package in a virtual environment. Once the ABI has been updated and tested, ensure the virtualenv is active and install the package, which builds the native library. There are two ways to install this:

# Install the release build, recommended:
pip install --editable ./py

# Install the debug build, faster installation but much slower runtime:
RELAY_DEBUG=1 pip install --editable ./py

For testing, we use ubiquitous pytest. Again, ensure that your virtualenv is active and the latest version of the native library has been installed. Then, run:

# Create a new virtualenv, install the release build and run tests
make test-python

# Run a single test manually
.venv/bin/pytest py/tests -k <test_name>

Usage with Sentry

To develop Relay with an existing Sentry devserver, self-hosted Sentry installation, or Sentry SaaS, configure the upstream to the URL of the Sentry server in .relay/config.yml in the project root directory. For example, in local development set relay.upstream to http://localhost:8000/.

To test processing mode with a local development Sentry, use this configuration:

relay:
  # Point to your Sentry devserver URL:
  upstream: http://localhost:8000/
  # Listen to a port other than 3000:
  port: 3001
logging:
  # Enable full logging and backtraces:
  level: trace
  enable_backtraces: true
limits:
  # Speed up shutdown on ^C
  shutdown_timeout: 0
processing:
  # Enable processing mode with store normalization and post data to Kafka:
  enabled: true
  kafka_config:
    - { name: "bootstrap.servers", value: "127.0.0.1:9092" }
    - { name: "message.max.bytes", value: 2097176 }
  redis: "redis://127.0.0.1"

Note that the Sentry devserver also starts a Relay in processing mode on port 3000 with similar configuration. That Relay does not interfere with your development build. To ensure SDKs send to your development instance, update the port in the DSN:

http://<key>@localhost:3001/<id>

Release Management

We use GitHub actions to release new versions. There are two separate projects to publish:

Instructions for changelogs

For changes exposed to the Python package, add an entry to py/CHANGELOG.md. This includes, but is not limited to, event normalization, PII scrubbing, and the protocol. For changes to the Relay server, please add an entry to CHANGELOG.md under the following heading:

  1. Features: for new user-visible functionality.
  2. Bug Fixes: for user-visible bug fixes.
  3. Internal: for features and bug fixes in internal operation, especially processing mode.

To the changelog entry, please add a link to this PR (consider a more descriptive message):

- ${getCleanTitle()}. (${PR_LINK})

If none of the above apply, you can opt out by adding #skip-changelog to the PR description.

relay's People

Contributors

abhiprasad avatar asottile-sentry avatar byk avatar chadwhitacre avatar cmanallen avatar dashed avatar dav1dde avatar dependabot-preview[bot] avatar edwardgou-sentry avatar evanpurkhiser avatar getsentry-bot avatar iambriccardo avatar ianwoodard avatar iker-barriocanal avatar jan-auer avatar jjbayer avatar joshferge avatar mattgauntseo-sentry avatar mitsuhiko avatar narsaynorath avatar olksdr avatar phacops avatar raduw avatar shruthilayaj avatar swatinem avatar tbs1996 avatar tonyo avatar untitaker avatar viglia avatar zylphrex avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

relay's Issues

Config init via docker not possible

Hi. I think I'm an early adopter but I really need to use the relay.

The installation instruction are really scarce and the only possibility to run was to use the provided docker image.

The problematic thing is generating the initial config using the docker command:

docker run -v $(pwd)/configs/:/etc/semaphore/ us.gcr.io/sentryio/semaphore config init --config /etc/semaphore

There is a rich console interaction in place and everything hangs or is refreshed without the possibility to exit or abort

semaphore

I ended up logging into the container directly. Running the command in there and copying out the config outside.

Requirement to have a license key to download GeoLite2-City.mmdb

A successful run of make test requires a file GeoLite2-City.mmdb. This file is downloaded through a make target that requires the GEOIP_LICENSE environment variable set.

Failure to set the env var to a proper value creates an empty GeoLite2-City.mmdb file which satisfies the build in the next run of make test.

The tests depend on a non-empty file, though, and fail.

As a side-effect, PRs from external contributors cannot build successfully in Travis, e.g. https://travis-ci.com/github/getsentry/relay/jobs/299613662

$ make -e test-rust-all
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    20  100    20    0     0     83      0 --:--:-- --:--:-- --:--:--    83
gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now
Makefile:206: recipe for target 'GeoLite2-City.mmdb' failed

Investigate and reconsider this dependency, perhaps replacing with something more easily available and with an open source license.

TransactionsProcessor modifies event timestamps by default

TransactionsProcessor modifies event timestamps by default as part of a "clock drift detection" feature.

Disabling it requires setting a value on the now field. None of this is documented.

The behavior is surprising, and makes constructing tests and generally using TransactionsProcessor unnecessarily hard, requiring deep knowledge on the implementation details.

Unable to secure the onpremise install

Environment

Dev

How do you use Sentry?
Sentry SaaS (sentry.io) or self-hosted/on-premise (which version?)
On-premise 21.3.0

Which SDK and version?
e.g: JavaScript 5.11.1, .NET 1.2.0
N/A

Steps to Reproduce

  1. We are working to deploy Sentry 21.3.0 to our kubernetes infrastructure, and in the process of inspecting the deployment in pre-production, we found a number of default usernames and passwords, and a general lack of encryption between various components.
  2. We began attempting to configure these items and for the most part, we were successful in getting Bitnami Kafka and Zookeeper working together with our own internal usernames and passwords, but ran into an issue trying to get Sentry Relay to connect, because it doesn't have SASL enabled in its built-in librdkafka library as per the logs in the logs section below

Our config.yml is a ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: sentry-relay
data:
  config.yml: |-
    relay:
      mode: proxy
      upstream: "http://sentry-web:9000/"
      host: 0.0.0.0
      port: 3000

    processing:
      enabled: true

      kafka_config:
        - name: "bootstrap.servers"
          value: sentry-kafka:9092
        - name: "message.max.bytes"
          value: 50000000  # 50MB or bust
        - name: "security.protocol"
          value: sasl_plaintext
        - name: "sasl.mechanisms"
          value: SCRAM-SHA-512
        - name: "sasl.username"
          value: sentry-relay-kafka-username-from-akvs
        - name: "sasl.password"
          value: sentry-relay-kafka-password-from-akvs
      redis: "redis://:relay-redis-password-from-akvs@sentry-sentry-redis-master:6379"

Expected Result

Sentry Relay would start up and authenticate with Kafka using SCRAM-SHA-512 over SASL authentication

Actual Result

$ kubectl logs sentry-relay-container-id
2021-04-05T21:22:22Z [relay::setup] INFO: launching relay from config folder /work/.relay
2021-04-05T21:22:22Z [relay::setup] INFO:   relay mode: proxy
2021-04-05T21:22:22Z [relay::setup] INFO:   relay id: ee535ced-1f98-4c8a-862a-97d100b2e8f5
2021-04-05T21:22:22Z [relay::setup] INFO:   public key: _CT1kPyAxe6rq9Vw7KPkCdRofEkHEenqdd8OOhA-L6Q
2021-04-05T21:22:22Z [relay::setup] INFO:   log level: INFO
2021-04-05T21:22:22Z [relay_log::utils] ERROR: could not initialize kafka producer
  caused by: Client creation error: No provider for SASL mechanism SCRAM-SHA-512: recompile librdkafka with libsasl2 or openssl support. Current build options: PLAIN
bash-4.1$ 

authentication encountered error: upstream request returned error 403 Forbidden caused by: Relay is not allowed to register

Environment

I using sentry on-premise 21.3.17 e5ca7e behind nginx reverse proxy with simple proxy_pass configuration

  location ~ ^/api/[1-9]\d*/store/ {
    proxy_pass http://127.0.0.1:9000;
    proxy_set_header   Host              $host;
    proxy_set_header   X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_set_header   X-Forwarded-Proto $scheme;
    proxy_redirect     off;
    keepalive_timeout 0;
  }

  location / {
    proxy_pass http://127.0.0.1:9000/;
    proxy_set_header   Host              $host;
    proxy_set_header   X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_set_header   X-Forwarded-Proto $scheme;
    proxy_redirect     off;
    keepalive_timeout 0;
  }

And trying to setup relay on different server.

# docker-compose exec  web sentry --version
sentry, version 21.3.1 (7e5ca7ed5581)
$ docker run --rm -it -v $(pwd)/config/:/work/.relay/ -p 3000:3000 getsentry/relay -V
relay 21.3.1

Steps to Reproduce

  1. According to manual from page https://docs.sentry.io/product/relay/getting-started/
    1.I generate init config: docker run --rm -it -v $(pwd)/config/:/work/.relay/ getsentry/relay config init
  2. I update new config with my upstream:
---
relay:
  mode: managed
  upstream: "https://sentry.mydomain.com/"
  host: 0.0.0.0
  port: 3000
  tls_port: ~
  tls_identity_path: ~
  tls_identity_password: ~
  1. I created new relay key in my sentry with public key from file $(pwd)/config/credentials.json
  2. And starting... docker run --rm -it -v $(pwd)/config/:/work/.relay/ -p 3000:3000 getsentry/relay run
    and then
    I received error "authentication encountered error: upstream request returned error 403 Forbidden
    caused by: Relay is not allowed to register"

Expected Result

I expecting working relay

Actual Result

I reveived 403 when starting relay

 INFO  relay::setup > launching relay from config folder /home/broken/projects/gitlab/premium/sentry-relay/./config/
 INFO  relay::setup >   relay mode: managed
 INFO  relay::setup >   relay id: c41bb894-f395-43fa-bdbe-b83be183cbc0
 INFO  relay::setup >   public key: JnlcaXo17cI25aSJNTQTUHR4xkz2Jh0kzn6TO7DzfgA
 INFO  relay::setup >   log level: INFO
 INFO  relay_server::actors::events > starting 12 event processing workers
 INFO  relay_server::service        > spawning http server
 INFO  relay_server::service        >   listening on: http://0.0.0.0:3000/
 INFO  actix_net::server::server    > Starting 12 workers
 INFO  actix_net::server::server    > Starting server on 0.0.0.0:3000
 INFO  relay_server::actors::controller > relay server starting
 INFO  relay_server::actors::connector  > metered connector started
 INFO  relay_server::actors::events     > event manager started
 INFO  relay_server::actors::project_local > project local cache started
 INFO  relay_server::actors::project_upstream > project upstream cache started
 INFO  relay_server::actors::project_cache    > project cache started
 INFO  relay_server::actors::relays           > key cache started
 WARN  actix::actors::resolver                > Can not create system dns resolver: io error
 INFO  relay_server::actors::upstream         > upstream relay started
 INFO  relay_server::actors::upstream         > registering with upstream (https://sentry.mydomain.com/)
 ERROR relay_server::actors::upstream         > authentication encountered error: upstream request returned error 403 Forbidden
  caused by: Relay is not allowed to register
 INFO  relay_server::actors::upstream         > registering with upstream (https://sentry.mydomain.com/)
 ERROR relay_server::actors::upstream         > authentication encountered error: upstream request returned error 403 Forbidden
  caused by: Relay is not allowed to register
 INFO  relay_server::actors::upstream         > registering with upstream (https://sentry.mydomain.com/)
 ERROR relay_server::actors::upstream         > authentication encountered error: upstream request returned error 403 Forbidden
  caused by: Relay is not allowed to register
 INFO  relay_server::actors::upstream         > registering with upstream (https://sentry.mydomain.com/)
 ERROR relay_server::actors::upstream         > authentication encountered error: upstream request returned error 403 Forbidden
  caused by: Relay is not allowed to register
 INFO  relay_server::actors::upstream         > registering with upstream (https://sentry.mydomain.com/)
 ERROR relay_server::actors::upstream         > authentication encountered error: upstream request returned error 403 Forbidden
  caused by: Relay is not allowed to register
 INFO  relay_server::actors::upstream         > registering with upstream (https://sentry.mydomain.com/)
 ERROR relay_server::actors::upstream         > authentication encountered error: upstream request returned error 403 Forbidden
  caused by: Relay is not allowed to register
 INFO  relay_server::actors::upstream         > registering with upstream (https://sentry.mydomain.com/)
 ERROR relay_server::actors::upstream         > authentication encountered error: upstream request returned error 403 Forbidden
  caused by: Relay is not allowed to register

Also I check this with binary from page https://github.com/getsentry/relay/releases/tag/21.3.1 and have same error.

How to resolve this problem?

Missing context on `invalid digit found in string`

When relay is deployed in a Kubernetes cluster and there is a Kubernetes service called relay, an environment variable called RELAY_PORT is automatically added to the runtime environment. The value is in the form of tcp://10.16.0.48:3000 and is causing an error that is not giving much context to help tracking down the error:

error: invalid config value (field port)
  caused by: invalid digit found in string

If possible, could the error printed include the environment variable name or the value that is causing the parse error?

Steps to reproduce:

docker run --rm -v $(pwd)/relay/:/work/.relay/ -e RELAY_PORT=tcp://10.16.0.48:3000 getsentry/relay:20.7.1 config show

Fragile clock drift correction

From #526 (comment)

@jan-auer wrote:

@untitaker clock drift correction looks extremely fragile. It should use a timestamp of when the event was received, not when the processor runs (now). Since we can have arbitrary delays inside Relay due to project config fetching, this can massively skew the clock -- more than what's expected from usual clock skew. This means, the TransactionsProcessor should always receive sent_at and also received_at instead of now.

Also, doing clock drift correction with the end timestamp probably does more harm than it helps. We cannot assume that the transaction is sent immediately after it's complete (especially if we want to start batching up in the SDK).

SENTRY_USE_X_FORWARDED_FOR not working

Important Details

How are you running Sentry?

On-Premise w/ Docker, version 20.11.1

Description

When a CSP report comes in, Sentry uses the IP of the Docker host (reverse proxy) as the client IP. It ignores the X-Forwarded-For header.

Obviously honoring the X-Forwarded-For header is dangerous and must be enabled only when a reverse proxy is used. (But with the Sentry On-premise Docker installation almost always a reverse proxy is used.) It is unclear from the docs how it should be enabled.

I tried setting SENTRY_USE_X_FORWARDED_FOR in .env and it shows up in Admin->Environment:

image

But still, events are reported with the IP of the Docker host:

image

Steps to Reproduce

  1. Install Sentry
  2. Configure a reverse proxy of your choice on the docker host, forwarding requests to the docker container
  3. Receive a CSP report (or an event from a Javascript client)

What you expected to happen

To see the IP address of the browser, not of the reverse proxy.

Possible Solution

I'm not sure why it is not working. I added another config option SENTRY_SOME_OTHER_OPTION to .env and it does not show up in Admin->Environment, so I am sure that I spelled SENTRY_USE_X_FORWARDED_FOR correctly and that the value actually reaches Sentry. The problem is just that it gets ignored apparently.

Seeking alpha testers: Data Scrubbing enhancements

We have created a prototype of a revamped server-side data scrubbing solution which also includes additional functionalities like:

  • Ability to define custom regular expressions to match on sensitive data
  • More fine-grained tuning on which parts of an event to scrub
  • Partial removal or hashing of sensitive data instead of just deletion

At this time, we are ready to start an Alpha for these features on SaaS (sentry.io) and would like to invite you to try out the early prototype and share your feedback. This is an invite-only program and would be a great opportunity to learn more about the features and how they can help you.

What is currently implemented

If you participate in this program, you will, for now, just see an additional textbox in your projects' settings that allows you to configure additional data scrubbing using a fairly low-level configuration language in JSON.

Screenshot 2020-01-28 at 09 38 34

Those rules apply in addition to the already known data scrubbing settings. It's not possible to accidentally stop stripping something that was stripped before, but it's possible to accidentally remove too much data from events.

For a first look at this language, please take a look at https://getsentry.github.io/relay/pii-config/ and more importantly the subpages linked from there. This should give you a rough overview of how flexible the final feature will be. There is a playground at https://getsentry.github.io/piinguin/ where you can try out these settings on individual event payloads and see the results.

How do I get in?

Email me at [email protected] for further steps. We have a Slack workspace for discussion, and would prefer most interaction to happen there. Communication via GitHub issues or via email is also fine for now though.

Fails to install from pypi

Description

When insalling semaphore from pip I get the following error:

Building wheels for collected packages: symbolic, semaphore
  Building wheel for symbolic (setup.py) ... error
  ERROR: Complete output from command /www/sentry/bin/python2 -u -c 'import setuptools, tokenize;__file__='"'"'/tmp/pip-install-UHxQ89/symbolic/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' bdist_wheel -d /tmp/pip-wheel-ooHfBf --python-tag cp27:
  ERROR: running `cargo build --release` (release target)
  running bdist_wheel
  running build
  running build_py
  creating build/lib.linux-armv7l-2.7
  creating build/lib.linux-armv7l-2.7/symbolic
  copying symbolic/debuginfo.py -> build/lib.linux-armv7l-2.7/symbolic
  copying symbolic/exceptions.py -> build/lib.linux-armv7l-2.7/symbolic
  copying symbolic/symcache.py -> build/lib.linux-armv7l-2.7/symbolic
  copying symbolic/sourcemap.py -> build/lib.linux-armv7l-2.7/symbolic
  copying symbolic/minidump.py -> build/lib.linux-armv7l-2.7/symbolic
  copying symbolic/demangle.py -> build/lib.linux-armv7l-2.7/symbolic
  copying symbolic/unreal.py -> build/lib.linux-armv7l-2.7/symbolic
  copying symbolic/__init__.py -> build/lib.linux-armv7l-2.7/symbolic
  copying symbolic/proguard.py -> build/lib.linux-armv7l-2.7/symbolic
  copying symbolic/common.py -> build/lib.linux-armv7l-2.7/symbolic
  copying symbolic/_compat.py -> build/lib.linux-armv7l-2.7/symbolic
  copying symbolic/utils.py -> build/lib.linux-armv7l-2.7/symbolic
  error: [Errno 2] No such file or directory
  ----------------------------------------
  ERROR: Failed building wheel for symbolic
  Running setup.py clean for symbolic
  Building wheel for semaphore (setup.py) ... error
  ERROR: Complete output from command /www/sentry/bin/python2 -u -c 'import setuptools, tokenize;__file__='"'"'/tmp/pip-install-UHxQ89/semaphore/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' bdist_wheel -d /tmp/pip-wheel-d9JJB1 --python-tag cp27:
  ERROR: running bdist_wheel
  running build
  running build_py
  creating build/lib.linux-armv7l-2.7
  creating build/lib.linux-armv7l-2.7/semaphore
  copying semaphore/exceptions.py -> build/lib.linux-armv7l-2.7/semaphore
  copying semaphore/processing.py -> build/lib.linux-armv7l-2.7/semaphore
  copying semaphore/__init__.py -> build/lib.linux-armv7l-2.7/semaphore
  copying semaphore/_compat.py -> build/lib.linux-armv7l-2.7/semaphore
  copying semaphore/utils.py -> build/lib.linux-armv7l-2.7/semaphore
  copying semaphore/auth.py -> build/lib.linux-armv7l-2.7/semaphore
  error: [Errno 2] No such file or directory
  ----------------------------------------
  ERROR: Failed building wheel for semaphore
  Running setup.py clean for semaphore
Failed to build symbolic semaphore

This happens on a "Linux 4.9.93-mainline-rev1 #1 SMP Tue Apr 10 09:42:40 UTC 2018 armv7l armv7l armv7l GNU/Linux"

Release version with an unescaped string.

Important Details

How are you running Sentry?

Saas (sentry.io)

Description

error when trying to open a release. also, when trying to delete via the API, it gives the answer that it was not found

image

Steps to Reproduce

  1. create a new release
  2. then you need to set the release version, for example, I have problems with this name "\n> [email protected] release:version\n> echo "dev-19be1b7e-dirty"\n\ndev-19be1b7e-dirty" (forgot to escape the symbol in the bash script)

Good items to include here include:

vendor.f93d44c7de6da4a40abf.js:2 GET https://sentry.io/api/0/organizations/somename/sessions/?project=123456&query=release%3A%22%5Cn%3E+rfrontend%400.1.0+release%3Aversion%5Cn%3E+echo+%22dev-19be1b7e-dirty%22%5Cn%5Cndev-19be1b7e-dirty%22&field=sum(session)&statsPeriod=90d&interval=1d 400 (Bad Request)

{"detail":"Invalid query field: \"message\""}

Issue installing semaphore in FreeBSD via pip

% rustc --version
rustc 1.27.0
% cargo --version
cargo 1.27.0
% uname -a
FreeBSD svrsentry 11.1-RELEASE-p1 FreeBSD 11.1-RELEASE-p1 #0: Wed Aug 9 11:55:48 UTC 2017 [email protected]:/usr/obj/usr/src/sys/GENERIC amd64
% clang --version
FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0)
Target: x86_64-unknown-freebsd11.1
Thread model: posix
InstalledDir: /usr/bin

(env) sentry@svrsentry:~ pip install semaphore
Collecting semaphore
  Using cached https://files.pythonhosted.org/packages/7f/93/af09573ec5f447a44973aee3c26cfe1b7a4c658c00262ae73b8c879c013e/semaphore-0.1.3.zip
Collecting milksnake>=0.1.2 (from semaphore)
  Using cached https://files.pythonhosted.org/packages/27/be/e10e73f857ac98ef43587fa8db37a3ef6de56e728037a7b9728de26711c7/milksnake-0.1.5-py2.py3-none-any.whl
Collecting cffi>=1.6.0 (from milksnake>=0.1.2->semaphore)
Collecting pycparser (from cffi>=1.6.0->milksnake>=0.1.2->semaphore)
Building wheels for collected packages: semaphore
  Running setup.py bdist_wheel for semaphore ... error
  Complete output from command /usr/home/sentry/env/bin/python2.7 -u -c "import setuptools, tokenize;__file__='/tmp/pip-install-4V7LQm/semaphore/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" bdist_wheel -d /tmp/pip-wheel-kpyk9r --python-tag cp27:
  running bdist_wheel
  
     Compiling rust_sodium-sys v0.9.0
  error: failed to run custom build command for `rust_sodium-sys v0.9.0`
  process didn't exit successfully: `/tmp/tmp3O6IHb/rustsrc/cabi/target/release/build/rust_sodium-sys-ff5bb2f53604e571/build-script-build` (exit code: 101)
  --- stdout
  cargo:rerun-if-env-changed=RUST_SODIUM_LIB_DIR
  cargo:rerun-if-env-changed=RUST_SODIUM_USE_PKG_CONFIG
  cargo:rerun-if-env-changed=RUST_SODIUM_SHARED
  OPT_LEVEL = Some("3")
  TARGET = Some("x86_64-unknown-freebsd")
  HOST = Some("x86_64-unknown-freebsd")
  TARGET = Some("x86_64-unknown-freebsd")
  TARGET = Some("x86_64-unknown-freebsd")
  HOST = Some("x86_64-unknown-freebsd")
  CC_x86_64-unknown-freebsd = None
  CC_x86_64_unknown_freebsd = None
  HOST_CC = None
  CC = None
  HOST = Some("x86_64-unknown-freebsd")
  TARGET = Some("x86_64-unknown-freebsd")
  HOST = Some("x86_64-unknown-freebsd")
  CFLAGS_x86_64-unknown-freebsd = None
  CFLAGS_x86_64_unknown_freebsd = None
  HOST_CFLAGS = None
  CFLAGS = None
  DEBUG = Some("true")
  cargo:rerun-if-env-changed=RUST_SODIUM_DISABLE_PIE
  
  --- stderr
  thread 'main' panicked at '
  "make" "check" "-j8"
  checking build system type... x86_64-unknown-freebsd11.1
  checking host system type... x86_64-unknown-freebsd

  checking for x86_64-unknown-freebsd-strip... no
  checking for strip... strip
  checking for a thread-safe mkdir -p... build-aux/install-sh -c -d

  checking for suffix of executables...
  checking whether we are cross compiling... no
  checking for suffix of object files... o
 
  checking whether Clang needs flag to prevent "argument unused" warning when linking with -pthread... no
  checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
  checking whether more special flags are required for pthreads... no
  
  checking how to associate runtime and link libraries... printf %s\n
  checking for x86_64-unknown-freebsd-ar... no
  checking for ar... ar
  checking for archiver @FILE support... no
  checking for x86_64-unknown-freebsd-strip... strip
  checking for x86_64-unknown-freebsd-ranlib... no
  checking for ranlib... ranlib
  checking command to parse nm output from cc object... ok
  checking for sysroot... no
  checking for a working dd... /bin/dd
  checking how to truncate binary pipes... /bin/dd bs=4096 count=1
  checking for x86_64-unknown-freebsd-mt... no
  checking for mt... mt
  checking if mt is a manifest tool... no
  checking for dlfcn.h... yes
  checking for objdir... .libs
  checking if cc supports -fno-rtti -fno-exceptions... yes
  checking for cc option to produce PIC... -fPIC -DPIC
  checking if cc PIC flag -fPIC -DPIC works... yes
  checking if cc static flag -static works... no
  checking if cc supports -c -o file.o... yes
  checking if cc supports -c -o file.o... (cached) yes
  checking whether the cc linker (/usr/bin/ld) supports shared libraries... yes
  checking dynamic linker characteristics... freebsd ld.so
  checking how to hardcode library paths into programs... immediate
  checking whether stripping libraries is possible... no
  checking if libtool supports shared libraries... yes
  checking whether to build shared libraries... no
  checking whether to build static libraries... yes
  checking for x86_64-unknown-freebsd-ar... ar
  checking whether C compiler accepts -mmmx... yes
  checking for MMX instructions set... yes
  checking whether C compiler accepts -mmmx... (cached) yes
  checking whether C compiler accepts -msse2... yes
  checking for SSE2 instructions set... yes
  checking whether C compiler accepts -msse2... (cached) yes
  checking whether C compiler accepts -msse3... yes
  checking for SSE3 instructions set... yes
  checking whether C compiler accepts -msse3... (cached) yes
  checking whether C compiler accepts -mssse3... yes
  checking for SSSE3 instructions set... yes
  checking whether C compiler accepts -mssse3... (cached) yes
  checking whether C compiler accepts -msse4.1... yes
  checking for SSE4.1 instructions set... yes
  checking whether C compiler accepts -msse4.1... (cached) yes
  checking whether C compiler accepts -mavx... yes
  checking for AVX instructions set... yes
  checking whether C compiler accepts -mavx... (cached) yes
  checking whether C compiler accepts -mavx2... yes
  checking for AVX2 instructions set... yes
  checking whether C compiler accepts -mavx2... (cached) yes
  checking if _mm256_broadcastsi128_si256 is correctly defined... yes
  checking whether C compiler accepts -mavx512f... yes
  checking for AVX512F instructions set... yes
  checking whether C compiler accepts -mavx512f... (cached) yes
  checking whether C compiler accepts -maes... yes
  checking whether C compiler accepts -mpclmul... yes
  checking for AESNI instructions set and PCLMULQDQ... yes
  checking whether C compiler accepts -maes... (cached) yes
  checking whether C compiler accepts -mpclmul... (cached) yes
  checking whether C compiler accepts -mrdrnd... yes
  checking for RDRAND... yes
  checking whether C compiler accepts -mrdrnd... (cached) yes
  checking sys/mman.h usability... yes
  checking sys/mman.h presence... yes
  checking for sys/mman.h... yes
  checking intrin.h usability... no
  checking intrin.h presence... no
  checking for intrin.h... no
  checking if _xgetbv() is available... no
  checking for inline... inline
  checking whether byte ordering is bigendian... (cached) no
  checking whether __STDC_LIMIT_MACROS is required... no
  checking whether we can use x86_64 asm code... yes
  checking whether we can assemble AVX opcodes... yes
  checking for 128-bit arithmetic... yes
  checking for cpuid instruction... yes
  checking if the .private_extern asm directive is supported... no
  checking if the .hidden asm directive is supported... yes
  checking if weak symbols are supported... yes
  checking if data alignment is required... no
  checking if atomic operations are supported... yes
  checking for size_t... yes
  checking for working alloca.h... no
  checking for alloca... yes
  checking for arc4random... yes
  checking for arc4random_buf... yes
  checking for mmap... yes
  checking for mlock... yes
  checking for madvise... yes
  checking for mprotect... yes
  checking for memset_s... yes
  checking for explicit_bzero... yes
  checking for nanosleep... yes
  checking for posix_memalign... yes
  checking for getpid... yes
  checking if gcc/ld supports -Wl,--output-def... not needed, shared libraries are disabled
  checking that generated files are newer than configure... done
  configure: creating ./config.status
  config.status: creating Makefile
  config.status: creating builds/Makefile
  config.status: creating contrib/Makefile
  config.status: creating dist-build/Makefile
  config.status: creating libsodium.pc
  config.status: creating libsodium-uninstalled.pc
  config.status: creating msvc-scripts/Makefile
  config.status: creating src/Makefile
  config.status: creating src/libsodium/Makefile
  config.status: creating src/libsodium/include/Makefile
  config.status: creating src/libsodium/include/sodium/version.h
  config.status: creating test/default/Makefile
  config.status: creating test/Makefile
  config.status: executing depfiles commands
  config.status: executing libtool commands
  
  --- crypto_auth/hmacsha256/libsodium_la-auth_hmacsha256.lo ---
  libtool: compile:  cc -DPACKAGE_NAME=\"libsodium\" -DPACKAGE_TARNAME=\"libsodium\" -DPACKAGE_VERSION=\"1.0.16\" "-DPACKAGE_STRING=\"libsodium 1.0.16\"" -DPACKAGE_BUGREPORT=\"https://github.com/jedisct1/libsodium/issues\" -DPACKAGE_URL=\"https://github.com/jedisct1/libsodium\" -DPACKAGE=\"libsodium\" -DVERSION=\"1.0.16\" -DHAVE_PTHREAD_PRIO_INHERIT=1 -DHAVE_PTHREAD=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -D__EXTENSIONS__=1 -D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DHAVE_C_VARARRAYS=1 -DHAVE_CATCHABLE_SEGV=1 -DHAVE_CATCHABLE_ABRT=1 -DTLS=_Thread_local -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_MMINTRIN_H=1 -DHAVE_EMMINTRIN_H=1 -DHAVE_PMMINTRIN_H=1 -DHAVE_TMMINTRIN_H=1 -DHAVE_SMMINTRIN_H=1 -DHAVE_AVXINTRIN_H=1 -DHAVE_AVX2INTRIN_H=1 -DHAVE_AVX512FINTRIN_H=1 -DHAVE_WMMINTRIN_H=1 -DHAVE_RDRAND=1 -DHAVE_SYS_MMAN_H=1 -DNATIVE_LITTLE_ENDIAN=1 -DHAVE_AMD64_ASM=1 -DHAVE_AVX_ASM=1 -DHAVE_TI_MODE=1 -DHAVE_CPUID=1 -DASM_HIDE_SYMBOL=.hidden -DHAVE_WEAK_SYMBOLS=1 -DCPU_UNALIGNED_ACCESS=1 -DHAVE_ATOMIC_OPS=1 -DHAVE_ALLOCA=1 -DHAVE_ARC4RANDOM=1 -DHAVE_ARC4RANDOM_BUF=1 -DHAVE_MMAP=1 -DHAVE_MLOCK=1 -DHAVE_MADVISE=1 -DHAVE_MPROTECT=1 -DHAVE_MEMSET_S=1 -DHAVE_EXPLICIT_BZERO=1 -DHAVE_NANOSLEEP=1 -DHAVE_POSIX_MEMALIGN=1 -DHAVE_GETPID=1 -DCONFIGURED=1 -I. -I./include/sodium -I./include/sodium -D_FORTIFY_SOURCE=2 -O2 -pthread -fvisibility=hidden -fPIC -fno-strict-aliasing -fno-strict-overflow -fstack-protector -MT crypto_auth/hmacsha256/libsodium_la-auth_hmacsha256.lo -MD -MP -MF crypto_auth/hmacsha256/.deps/libsodium_la-auth_hmacsha256.Tpo -c crypto_auth/hmacsha256/auth_hmacsha256.c -fPIE -o crypto_auth/hmacsha256/libsodium_la-auth_hmacsha256.o
  --- crypto_box/libsodium_la-crypto_box_easy.lo ---
  libtool: compile:  cc -DPACKAGE_NAME=\"libsodium\" -DPACKAGE_TARNAME=\"libsodium\" -DPACKAGE_VERSION=\"1.0.16\" "-DPACKAGE_STRING=\"libsodium 1.0.16\"" -DPACKAGE_BUGREPORT=\"https://github.com/jedisct1/libsodium/issues\" -DPACKAGE_URL=\"https://github.com/jedisct1/libsodium\" -DPACKAGE=\"libsodium\" -DVERSION=\"1.0.16\" -DHAVE_PTHREAD_PRIO_INHERIT=1 -DHAVE_PTHREAD=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -D__EXTENSIONS__=1 -D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DHAVE_C_VARARRAYS=1 -DHAVE_CATCHABLE_SEGV=1 -DHAVE_CATCHABLE_ABRT=1 -DTLS=_Thread_local -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_MMINTRIN_H=1 -DHAVE_EMMINTRIN_H=1 -DHAVE_PMMINTRIN_H=1 -DHAVE_TMMINTRIN_H=1 -DHAVE_SMMINTRIN_H=1 -DHAVE_AVXINTRIN_H=1 -DHAVE_AVX2INTRIN_H=1 -DHAVE_AVX512FINTRIN_H=1 -DHAVE_WMMINTRIN_H=1 -DHAVE_RDRAND=1 -DHAVE_SYS_MMAN_H=1 -DNATIVE_LI--- crypto_box/libsodium_la-crypto_box.lo ---
  libtool: compile:  cc -DPACKAGE_NAME=\"libsodium\" -DPACKAGE_TARNAME=\"libsodium\" -DPACKAGE_VERSION=\"1.0.16\" "-DPACKAGE_STRING=\"libsodium 1.0.16\"" -DPACKAGE_BUGREPORT=\"https://github.com/jedisct1/libsodium/issues\" -DPACKAGE_URL=\"https://github.com/jedisct1/libsodium\" -DPACKAGE=\"libsodium\" -DVERSION=\"1.0.16\" -DHAVE_PTHREAD_PRIO_INHERIT=1 -DHAVE_PTHREAD=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -D__EXTENSIONS__=1 -D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DHAVE_C_VARARRAYS=1 -DHAVE_CATCHABLE_SEGV=1 -DHAVE_CATCHABLE_ABRT=1 -DTLS=_Thread_local -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_MMINTRIN_H=1 -DHAVE_EMMINTRIN_H=1 -DHAVE_PMMINTRIN_H=1 -DHAVE_TMMINTRIN_H=1 -DHAVE_SMMINTRIN_H=1 -DHAVE_AVXINTRIN_H=1 -DHAVE_AVX2INTRIN_H=1 -DHAVE_AVX512FINTRIN_H=1 -DHAVE_WMMINTRIN_H=1 -DHAVE_RDRAND=1 -DHAVE_SYS_MMAN_H=1 -DNATIVE_LITTLE_ENDIAN=1 -DHAVE_AMD64_ASM=1 -DHAVE_AVX_ASM=1 -DHAVE_TI_MODE=1 -DHAVE_CPUID=1 -DASM_HIDE_SYMBOL=.hidden -DHAVE_WEAK_SYMBOLS=1 -DCPU_UNALIGNED_ACCESS=1 -DHAVE_ATOMIC_OPS=1 -DHAVE_ALLOCA=1 -DHAVE_ARC4RANDOM=1 -DHAVE_ARC4RANDOM_BUF=1 -DHAVE_MMAP=1 -DHAVE_MLOCK=1 -DHAVE_MADVISE=1 -DHAVE_MPROTECT=1 -DHAVE_MEMSET_S=1 -DHAVE_EXPLICIT_BZERO=1 -DHAVE_NANOSLEEP=1 -DHAVE_POSIX_MEMALIGN=1 -DHAVE_GETPID=1 -DCONFIGURED=1 -I. -I./include/sodium -I./include/sodium -D_FORTIFY_SOURCE=2 -O2 -pthread -fvisibility=hidden -fPIC -fno-strict-aliasing -fno-strict-overflow -fstack-protector -MT crypto_box/libsodium_la-crypto_box.lo -MD -MP -MF crypto_box/.deps/libsodium_la-crypto_box.Tpo -c crypto_box/crypto_box.c -fPIE -o crypto_box/libsodium_la-crypto_box.o
  --- crypto_box/libsodium_la-crypto_box_easy.lo ---
  TTLE_ENDIAN=1 -DHAVE_AMD64_ASM=1 -DHAVE_AVX_ASM=1 -DHAVE_TI_MODE=1 -DHAVE_CPUID=1 -DASM_HIDE_SYMBOL=.hidden -DHAVE_WEAK_SYMBOLS=1 -DCPU_UNALIGNED_ACCESS=1 -DHAVE_ATOMIC_OPS=1 -DHAVE_ALLOCA=1 -DHAVE_ARC4RANDOM=1 -DHAVE_ARC4RANDOM_BUF=1 -DHAVE_MMAP=1 -DHAVE_MLOCK=1 -DHAVE_MADVISE=1 -DHAVE_MPROTECT=1 -DHAVE_MEMSET_S=1 -DHAVE_EXPLICIT_BZERO=1 -DHAVE_NANOSLEEP=1 -DHAVE_POSIX_MEMALIGN=1 -DHAVE_GETPID=1 -DCONFIGURED=1 -I. -I./include/sodium -I./include/sodium -D_FORTIFY_SOURCE=2 -O2 -pthread -fvisibility=hidden -fPIC -fno-strict-aliasing -fno-strict-overflow -fstack-protector -MT crypto_box/libsodium_la-crypto_box_easy.lo -MD -MP -MF crypto_box/.deps/libsodium_la-crypto_box_easy.Tpo -c crypto_box/crypto_box_easy.c -fPIE -o crypto_box/libsodium_la-crypto_box_easy.o
  --- crypto_auth/libsodium_la-crypto_auth.lo ---
  libtool: compile:  cc -DPACKAGE_NAME=\"libsodium\" -DPACKAGE_TARNAME=\"libsodium\" -DPACKAGE_VERSION=\"1.0.16\" "-DPACKAGE_STRING=\"libsodium 1.0.16\"" -DPACKAGE_BUGREPORT=\"https://github.com/jedisct1/libsodium/issues\" -DPACKAGE_URL=\"https://github.com/jedisct1/libsodium\" -DPACKAGE=\"libsodium\" -DVERSION=\"1.0.16\" -DHAVE_PTHREAD_PRIO_INHERIT=1 -DHAVE_PTHREAD=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -D__EXTENSIONS__=1 -D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DHAVE_C_VARARRAYS=1 -DHAVE_CATCHABLE_SEGV=1 -DHAVE_CATCHABLE_ABRT=1 -DTLS=_Thread_local -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_MMINTRIN_H=1 -DHAVE_EMMINTRIN_H=1 -DHAVE_PMMINTRIN_H=1 -DHAVE_TMMINTRIN_H=1 -DHAVE_SMMINTRIN_H=1 -DHAVE_AVXINTRIN_H=1 -DHAVE_AVX2INTRIN_H=1 -DHAVE_AVX512FINTRIN_H=1 -DHAVE_WMMINTRIN_H=1 -DHAVE_RDRAND=1 -DHAVE_SYS_MMAN_H=1 -DNATIVE_LITTLE_ENDIAN=1 -DHAVE_AMD64_ASM=1 -DHAVE_AVX_ASM=1 -DHAVE_TI_MODE=1 -DHAVE_CPUID=1 -DASM_HIDE_SYMBOL=.hidden -DHAVE_WEAK_SYMBOLS=1 -DCPU_UNALIGNED_ACCESS=1 -DHAVE_ATOMIC_OPS=1 -DHAVE_ALLOCA=1 -DHAVE_ARC4RANDOM=1 -DHAVE_ARC4RANDOM_BUF=1 -DHAVE_MMAP=1 -DHAVE_MLOCK=1 -DHAVE_MADVISE=1 -DHAVE_MPROTECT=1 -DHAVE_MEMSET_S=1 -DHAVE_EXPLICIT_BZERO=1 -DHAVE_NANOSLEEP=1 -DHAVE_POSIX_MEMALIGN=1 -DHAVE_GETPID=1 -DCONFIGURED=1 -I. -I./include/sodium -I./include/sodium -D_FORTIFY_SOURCE=2 -O2 -pthread -fvisibility=hidden -fPIC -fno-strict-aliasing -fno-strict-overflow -fstack-protector -MT crypto_auth/libsodium_la-crypto_auth.lo -MD -MP -MF crypto_auth/.deps/libsodium_la-crypto_auth.Tpo -c crypto_auth/crypto_auth.c -fPIE -o crypto_auth/libsodium_la-crypto_auth.o
  --- crypto_auth/hmacsha512256/libsodium_la-auth_hmacsha512256.lo ---
  libtool: compile:  cc -DPACKAGE_NAME=\"libsodium\" -DPACKAGE_TARNAME=\"libsodium\" -DPACKAGE_VERSION=\"1.0.16\" "-DPACKAGE_STRING=\"libsodium 1.0.16\"" -DPACKAGE_BUGREPORT=\"https://github.com/jedisct1/libsodium/issues\" -DPACKAGE_URL=\"https://github.com/jedisct1/libsodium\" -DPACKAGE=\"libsodium\" -DVERSION=\"1.0.16\" -DHAVE_PTHREAD_PRIO_INHERIT=1 -DHAVE_PTHREAD=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -D__EXTENSIONS__=1 -D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DHAVE_C_VARARRAYS=1 -DHAVE_CATCHABLE_SEGV=1 -DHAVE_CATCHABLE_ABRT=1 -DTLS=_Thread_local -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_MMINTRIN_H=1 -DHAVE_EMMINTRIN_H=1 -DHAVE_PMMINTRIN_H=1 -DHAVE_TMMINTRIN_H=1 -DHAVE_SMMINTRIN_H=1 -DHAVE_AVXINTRIN_H=1 -DHAVE_AVX2INTRIN_H=1 -DHAVE_AVX512FINTRIN_H=1 -DHAVE_WMMINTRIN_H=1 -DHAVE_RDRAND=1 -DHAVE_SYS_MMAN_H=1 -DNATIVE_LITTLE_ENDIAN=1 -DHAVE_AMD64_ASM=1 -DHAVE_AVX_ASM=1 -DHAVE_TI_MODE=1 -DHAVE_CPUID=1 -DASM_HIDE_SYMBOL=.hidden -DHAVE_WEAK_SYMBOLS=1 -DCPU_UNALIGNED_ACCESS=1 -DHAVE_ATOMIC_OPS=1 -DHAVE_ALLOCA=1 -DHAVE_ARC4RANDOM=1 -DHAVE_ARC4RANDOM_BUF=1 -DHAVE_MMAP=1 -DHAVE_MLOCK=1 -DHAVE_MADVISE=1 -DHAVE_MPROTECT=1 -DHAVE_MEMSET_S=1 -DHAVE_EXPLICIT_BZERO=1 -DHAVE_NANOSLEEP=1 -DHAVE_POSIX_MEMALIGN=1 -DHAVE_GETPID=1 -DCONFIGURED=1 -I. -I./include/sodium -I./include/sodium -D_FORTIFY_SOURCE=2 -O2 -pthread -fvisibility=hidden -fPIC -fno-strict-aliasing -fno-strict-overflow -fstack-protector -MT crypto_auth/hmacsha512256/libsodium_la-auth_hmacsha512256.lo -MD -MP -MF crypto_auth/hmacsha512256/.deps/libsodium_la-auth_hmacsha512256.Tpo -c crypto_auth/hmacsha512256/auth_hmacsha512256.c -fPIE -o crypto_auth/hmacsha512256/libsodium_la-auth_hmacsha512256.o
  --- crypto_auth/libsodium_la-crypto_auth.lo ---
  mv -f crypto_auth/.deps/libsodium_la-crypto_auth.Tpo crypto_auth/.deps/libsodium_la-crypto_auth.Plo
  --- crypto_box/libsodium_la-crypto_box_seal.lo ---
  --- crypto_box/libsodium_la-crypto_box.lo ---
  mv -f crypto_box/.deps/libsodium_la-crypto_box.Tpo crypto_box/.deps/libsodium_la-crypto_box.Plo
  --- crypto_box/libsodium_la-crypto_box_seal.lo ---
  /bin/sh ../../libtool  --tag=CC   --mode=compile cc -DPACKAGE_NAME=\"libsodium\" -DPACKAGE_TARNAME=\"libsodium\" -DPACKAGE_VERSION=\"1.0.16\" -DPACKAGE_STRING=\"libsodium\ 1.0.16\" -DPACKAGE_BUGREPORT=\"https://github.com/jedisct1/libsodium/issues\" -DPACKAGE_URL=\"https://github.com/jedisct1/libsodium\" -DPACKAGE=\"libsodium\" -DVERSION=\"1.0.16\" -DHAVE_PTHREAD_PRIO_INHERIT=1 -DHAVE_PTHREAD=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -D__EXTENSIONS__=1 -D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DHAVE_C_VARARRAYS=1 -DHAVE_CATCHABLE_SEGV=1 -DHAVE_CATCHABLE_ABRT=1 -DTLS=_Thread_local -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_MMINTRIN_H=1 -DHAVE_EMMINTRIN_H=1 -DHAVE_PMMINTRIN_H=1 -DHAVE_TMMINTRIN_H=1 -DHAVE_SMMINTRIN_H=1 -DHAVE_AVXINTRIN_H=1 -DHAVE_AVX2INTRIN_H=1 -DHAVE_AVX512FINTRIN_H=1 -DHAVE_WMMINTRIN_H=1 -DHAVE_RDRAND=1 -DHAVE_SYS_MMAN_H=1 -DNATIVE_LITTLE_ENDIAN=1 -DHAVE_AMD64_ASM=1 -DHAVE_AVX_ASM=1 -DHAVE_TI_MODE=1 -DHAVE_CPUID=1 -DASM_HIDE_SYMBOL=.hidden -DHAVE_WEAK_SYMBOLS=1 -DCPU_UNALIGNED_ACCESS=1 -DHAVE_ATOMIC_OPS=1 -DHAVE_ALLOCA=1 -DHAVE_ARC4RANDOM=1 -DHAVE_ARC4RANDOM_BUF=1 -DHAVE_MMAP=1 -DHAVE_MLOCK=1 -DHAVE_MADVISE=1 -DHAVE_MPROTECT=1 -DHAVE_MEMSET_S=1 -DHAVE_EXPLICIT_BZERO=1 -DHAVE_NANOSLEEP=1 -DHAVE_POSIX_MEMALIGN=1 -DHAVE_GETPID=1 -DCONFIGURED=1 -I.    -I./include/sodium  -I./include/sodium -D_FORTIFY_SOURCE=2  -O2 -pthread -fvisibility=hidden -fPIC -fPIE -fno-strict-aliasing -fno-strict-overflow -fstack-protector -MT crypto_box/libsodium_la-crypto_box_seal.lo -MD -MP -MF crypto_box/.deps/libsodium_la-crypto_box_seal.Tpo -c -o crypto_box/libsodium_la-crypto_box_seal.lo `test -f 'crypto_box/crypto_box_seal.c' || echo './'`crypto_box/crypto_box_seal.c
  --- crypto_box/curve25519xsalsa20poly1305/libsodium_la-box_curve25519xsalsa20poly1305.lo ---
  /bin/sh ../../libtool  --tag=CC   --mode=compile cc -DPACKAGE_NAME=\"libsodium\" -DPACKAGE_TARNAME=\"libsodium\" -DPACKAGE_VERSION=\"1.0.16\" -DPACKAGE_STRING=\"libsodium\ 1.0.16\" -DPACKAGE_BUGREPORT=\"https://github.com/jedisct1/libsodium/issues\" -DPACKAGE_URL=\"https://github.com/jedisct1/libsodium\" -DPACKAGE=\"libsodium\" -DVERSION=\"1.0.16\" -DHAVE_PTHREAD_PRIO_INHERIT=1 -DHAVE_PTHREAD=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -D__EXTENSIONS__=1 -D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DHAVE_C_VARARRAYS=1 -DHAVE_CATCHABLE_SEGV=1 -DHAVE_CATCHABLE_ABRT=1 -DTLS=_Thread_local -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_MMINTRIN_H=1 -DHAVE_EMMINTRIN_H=1 -DHAVE_PMMINTRIN_H=1 -DHAVE_TMMINTRIN_H=1 -DHAVE_SMMINTRIN_H=1 -DHAVE_AVXINTRIN_H=1 -DHAVE_AVX2INTRIN_H=1 -DHAVE_AVX512FINTRIN_H=1 -DHAVE_WMMINTRIN_H=1 -DHAVE_RDRAND=1 -DHAVE_SYS_MMAN_H=1 -DNATIVE_LITTLE_ENDIAN=1 -DHAVE_AMD64_ASM=1 -DHAVE_AVX_ASM=1 -DHAVE_TI_MODE=1 -DHAVE_CPUID=1 -DASM_HIDE_SYMBOL=.hidden -DHAVE_WEAK_SYMBOLS=1 -DCPU_UNALIGNED_ACCESS=1 -DHAVE_ATOMIC_OPS=1 -DHAVE_ALLOCA=1 -DHAVE_ARC4RANDOM=1 -DHAVE_ARC4RANDOM_BUF=1 -DHAVE_MMAP=1 -DHAVE_MLOCK=1 -DHAVE_MADVISE=1 -DHAVE_MPROTECT=1 -DHAVE_MEMSET_S=1 -DHAVE_EXPLICIT_BZERO=1 -DHAVE_NANOSLEEP=1 -DHAVE_POSIX_MEMALIGN=1 -DHAVE_GETPID=1 -DCONFIGURED=1 -I.    -I./include/sodium  -I./include/sodium -D_FORTIFY_SOURCE=2  -O2 -pthread -fvisibility=hidden -fPIC -fPIE -fno-strict-aliasing -fno-strict-overflow -fstack-protector -MT crypto_box/curve25519xsalsa20poly1305/libsodium_la-box_curve25519xsalsa20poly1305.lo -MD -MP -MF crypto_box/curve25519xsalsa20poly1305/.deps/libsodium_la-box_curve25519xsalsa20poly1305.Tpo -c -o crypto_box/curve25519xsalsa20poly1305/libsodium_la-box_curve25519xsalsa20poly1305.lo `test -f 'crypto_box/curve25519xsalsa20poly1305/box_curve25519xsalsa20poly1305.c' || echo './'`crypto_box/curve25519xsalsa20poly1305/box_curve25519xsalsa20poly1305.c
  --- crypto_aead/xchacha20poly1305/sodium/libsodium_la-aead_xchacha20poly1305.lo ---
  mv -f crypto_aead/xchacha20poly1305/sodium/.deps/libsodium_la-aead_xchacha20poly1305.Tpo crypto_aead/xchacha20poly1305/sodium/.deps/libsodium_la-aead_xchacha20poly1305.Plo
  --- crypto_box/libsodium_la-crypto_box_easy.lo ---
  mv -f crypto_box/.deps/libsodium_la-crypto_box_easy.Tpo crypto_box/.deps/libsodium_la-crypto_box_easy.Plo
  --- crypto_core/ed25519/ref10/libsodium_la-ed25519_ref10.lo ---
  --- crypto_auth/hmacsha512256/libsodium_la-auth_hmacsha512256.lo ---
  mv -f crypto_auth/hmacsha512256/.deps/libsodium_la-auth_hmacsha512256.Tpo crypto_auth/hmacsha512256/.deps/libsodium_la-auth_hmacsha512256.Plo
  --- crypto_core/hchacha20/libsodium_la-core_hchacha20.lo ---
  --- crypto_core/ed25519/ref10/libsodium_la-ed25519_ref10.lo ---
  /bin/sh ../../libtool  --tag=CC   --mode=compile cc -DPACKAGE_NAME=\"libsodium\" -DPACKAGE_TARNAME=\"libsodium\" -DPACKAGE_VERSION=\"1.0.16\" -DPACKAGE_STRING=\"libsodium\ 1.0.16\" -DPACKAGE_BUGREPORT=\"https://github.com/jedisct1/libsodium/issues\" -DPACKAGE_URL=\"https://github.com/jedisct1/libsodium\" -DPACKAGE=\"libsodium\" -DVERSION=\"1.0.16\" -DHAVE_PTHREAD_PRIO_INHERIT=1 -DHAVE_PTHREAD=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -D__EXTENSIONS__=1 -D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DHAVE_C_VARARRAYS=1 -DHAVE_CATCHABLE_SEGV=1 -DHAVE_CATCHABLE_ABRT=1 -DTLS=_Thread_local -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_MMINTRIN_H=1 -DHAVE_EMMINTRIN_H=1 -DHAVE_PMMINTRIN_H=1 -DHAVE_TMMINTRIN_H=1 -DHAVE_SMMINTRIN_H=1 -DHAVE_AVXINTRIN_H=1 -DHAVE_AVX2INTRIN_H=1 -DHAVE_AVX512FINTRIN_H=1 -DHAVE_WMMINTRIN_H=1 -DHAVE_RDRAND=1 -DHAVE_SYS_MMAN_H=1 -DNATIVE_LITTLE_ENDIAN=1 -DHAVE_AMD64_ASM=1 -DHAVE_AVX_ASM=1 -DHAVE_TI_MODE=1 -DHAVE_CPUID=1 -DASM_HIDE_SYMBOL=.hidden -DHAVE_WEAK_SYMBOLS=1 -DCPU_UNALIGNED_ACCESS=1 -DHAVE_ATOMIC_OPS=1 -DHAVE_ALLOCA=1 -DHAVE_ARC4RANDOM=1 -DHAVE_ARC4RANDOM_BUF=1 -DHAVE_MMAP=1 -DHAVE_MLOCK=1 -DHAVE_MADVISE=1 -DHAVE_MPROTECT=1 -DHAVE_MEMSET_S=1 -DHAVE_EXPLICIT_BZERO=1 -DHAVE_NANOSLEEP=1 -DHAVE_POSIX_MEMALIGN=1 -DHAVE_GETPID=1 -DCONFIGURED=1 -I.    -I./include/sodium  -I./include/sodium -D_FORTIFY_SOURCE=2  -O2 -pthread -fvisibility=hidden -fPIC -fPIE -fno-strict-aliasing -fno-strict-overflow -fstack-protector -MT crypto_core/ed25519/ref10/libsodium_la-ed25519_ref10.lo -MD -MP -MF crypto_core/ed25519/ref10/.deps/libsodium_la-ed25519_ref10.Tpo -c -o crypto_core/ed25519/ref10/libsodium_la-ed25519_ref10.lo `test -f 'crypto_core/ed25519/ref10/ed25519_ref10.c' || echo './'`crypto_core/ed25519/ref10/ed25519_ref10.c
  --- crypto_core/hsalsa20/ref2/libsodium_la-core_hsalsa20_ref2.lo ---
  --- crypto_core/hchacha20/libsodium_la-core_hchacha20.lo ---
  /bin/sh ../../libtool  --tag=CC   --mode=compile cc -DPACKAGE_NAME=\"libsodium\" -DPACKAGE_TARNAME=\"libsodium\" -DPACKAGE_VERSION=\"1.0.16\" -DPACKAGE_STRING=\"libsodium\ 1.0.16\" -DPACKAGE_BUGREPORT=\"https://github.com/jedisct1/libsodium/issues\" -DPACKAGE_URL=\"https://github.com/jedisct1/libsodium\" -DPACKAGE=\"libsodium\" -DVERSION=\"1.0.16\" -DHAVE_PTHREAD_PRIO_INHERIT=1 -DHAVE_PTHREAD=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -D__EXTENSIONS__=1 -D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DHAVE_C_VARARRAYS=1 -DHAVE_CATCHABLE_SEGV=1 -DHAVE_CATCHABLE_ABRT=1 -DTLS=_Thread_local -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_MMINTRIN_H=1 -DHAVE_EMMINTRIN_H=1 -DHAVE_PMMINTRIN_H=1 -DHAVE_TMMINTRIN_H=1 -DHAVE_SMMINTRIN_H=1 -DHAVE_AVXINTRIN_H=1 -DHAVE_AVX2INTRIN_H=1 -DHAVE_AVX512FINTRIN_H=1 -DHAVE_WMMINTRIN_H=1 -DHAVE_RDRAND=1 -DHAVE_SYS_MMAN_H=1 -DNATIVE_LITTLE_ENDIAN=1 -DHAVE_AMD64_ASM=1 -DHAVE_AVX_ASM=1 -DHAVE_TI_MODE=1 -DHAVE_CPUID=1 -DASM_HIDE_SYMBOL=.hidden -DHAVE_WEAK_SYMBOLS=1 -DCPU_UNALIGNED_ACCESS=1 -DHAVE_ATOMIC_OPS=1 -DHAVE_ALLOCA=1 -DHAVE_ARC4RANDOM=1 -DHAVE_ARC4RANDOM_BUF=1 -DHAVE_MMAP=1 -DHAVE_MLOCK=1 -DHAVE_MADVISE=1 -DHAVE_MPROTECT=1 -DHAVE_MEMSET_S=1 -DHAVE_EXPLICIT_BZERO=1 -DHAVE_NANOSLEEP=1 -DHAVE_POSIX_MEMALIGN=1 -DHAVE_GETPID=1 -DCONFIGURED=1 -I.    -I./include/sodium  -I./include/sodium -D_FORTIFY_SOURCE=2  -O2 -pthread -fvisibility=hidden -fPIC -fPIE -fno-strict-aliasing -fno-strict-overflow -fstack-protector -MT crypto_core/hchacha20/libsodium_la-core_hchacha20.lo -MD -MP -MF crypto_core/hchacha20/.deps/libsodium_la-core_hchacha20.Tpo -c -o crypto_core/hchacha20/libsodium_la-core_hchacha20.lo `test -f 'crypto_core/hchacha20/core_hchacha20.c' || echo './'`crypto_core/hchacha20/core_hchacha20.c
  --- crypto_core/hsalsa20/ref2/libsodium_la-core_hsalsa20_ref2.lo ---
  /bin/sh ../../libtool  --tag=CC   --mode=compile cc -DPACKAGE_NAME=\"libsodium\" -DPACKAGE_TARNAME=\"libsodium\" -DPACKAGE_VERSION=\"1.0.16\" -DPACKAGE_STRING=\"libsodium\ 1.0.16\" -DPACKAGE_BUGREPORT=\"https://github.com/jedisct1/libsodium/issues\" -DPACKAGE_URL=\"https://github.com/jedisct1/libsodium\" -DPACKAGE=\"libsodium\" -DVERSION=\"1.0.16\" -DHAVE_PTHREAD_PRIO_INHERIT=1 -DHAVE_PTHREAD=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -D__EXTENSIONS__=1 -D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DHAVE_C_VARARRAYS=1 -DHAVE_CATCHABLE_SEGV=1 -DHAVE_CATCHABLE_ABRT=1 -DTLS=_Thread_local -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_MMINTRIN_H=1 -DHAVE_EMMINTRIN_H=1 -DHAVE_PMMINTRIN_H=1 -DHAVE_TMMINTRIN_H=1 -DHAVE_SMMINTRIN_H=1 -DHAVE_AVXINTRIN_H=1 -DHAVE_AVX2INTRIN_H=1 -DHAVE_AVX512FINTRIN_H=1 -DHAVE_WMMINTRIN_H=1 -DHAVE_RDRAND=1 -DHAVE_SYS_MMAN_H=1 -DNATIVE_LITTLE_ENDIAN=1 -DHAVE_AMD64_ASM=1 -DHAVE_AVX_ASM=1 -DHAVE_TI_MODE=1 -DHAVE_CPUID=1 -DASM_HIDE_SYMBOL=.hidden -DHAVE_WEAK_SYMBOLS=1 -DCPU_UNALIGNED_ACCESS=1 -DHAVE_ATOMIC_OPS=1 -DHAVE_ALLOCA=1 -DHAVE_ARC4RANDOM=1 -DHAVE_ARC4RANDOM_BUF=1 -DHAVE_MMAP=1 -DHAVE_MLOCK=1 -DHAVE_MADVISE=1 -DHAVE_MPROTECT=1 -DHAVE_MEMSET_S=1 -DHAVE_EXPLICIT_BZERO=1 -DHAVE_NANOSLEEP=1 -DHAVE_POSIX_MEMALIGN=1 -DHAVE_GETPID=1 -DCONFIGURED=1 -I.    -I./include/sodium  -I./include/sodium -D_FORTIFY_SOURCE=2  -O2 -pthread -fvisibility=hidden -fPIC -fPIE -fno-strict-aliasing -fno-strict-overflow -fstack-protector -MT crypto_core/hsalsa20/ref2/libsodium_la-core_hsalsa20_ref2.lo -MD -MP -MF crypto_core/hsalsa20/ref2/.deps/libsodium_la-core_hsalsa20_ref2.Tpo -c -o crypto_core/hsalsa20/ref2/libsodium_la-core_hsalsa20_ref2.lo `test -f 'crypto_core/hsalsa20/ref2/core_hsalsa20_ref2.c' || echo './'`crypto_core/hsalsa20/ref2/core_hsalsa20_ref2.c
  --- crypto_auth/hmacsha512/libsodium_la-auth_hmacsha512.lo ---
  mv -f crypto_auth/hmacsha512/.deps/libsodium_la-auth_hmacsha512.Tpo crypto_auth/hmacsha512/.deps/libsodium_la-auth_hmacsha512.Plo
  --- crypto_core/hsalsa20/libsodium_la-core_hsalsa20.lo ---
  --- crypto_auth/hmacsha256/libsodium_la-auth_hmacsha256.lo ---
  mv -f crypto_auth/hmacsha256/.deps/libsodium_la-auth_hmacsha256.Tpo crypto_auth/hmacsha256/.deps/libsodium_la-auth_hmacsha256.Plo
  --- crypto_core/salsa/ref/libsodium_la-core_salsa_ref.lo ---

  /bin/sh ../../libtool  --tag=CC    --mode=link cc  -O2 -pthread -fvisibility=hidden -fPIC -fPIE -fno-strict-aliasing -fno-strict-overflow -fstack-protector   -pie -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -o secretbox secretbox.o ../../src/libsodium/libsodium.la
  --- secretbox7 ---
  /bin/sh ../../libtool  --tag=CC    --mode=link cc  -O2 -pthread -fvisibility=hidden -fPIC -fPIE -fno-strict-aliasing -fno-strict-overflow -fstack-protector   -pie -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -o secretbox7 secretbox7.o ../../src/libsodium/libsodium.la
  --- secretbox8 ---
  /bin/sh ../../libtool  --tag=CC    --mode=link cc  -O2 -pthread -fvisibility=hidden -fPIC -fPIE -fno-strict-aliasing -fno-strict-overflow -fstack-protector   -pie -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -o secretbox8 secretbox8.o ../../src/libsodium/libsodium.la
  --- randombytes ---
  libtool: link: cc -O2 -pthread -fvisibility=hidden -fPIC -fPIE -fno-strict-aliasing -fno-strict-overflow -fstack-protector -pie -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,-z -Wl,noexecstack -o randombytes randombytes.o  ../../src/libsodium/.libs/libsodium.a -pthread
  /usr/bin/ld: ../../src/libsodium/.libs/libsodium.a(librdrand_la-randombytes_salsa20_random.o): relocation R_X86_64_TPOFF32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
  ../../src/libsodium/.libs/libsodium.a: could not read symbols: Bad value
  cc: error: linker command failed with exit code 1 (use -v to see invocation)
  --- secretbox_easy ---
  --- randombytes ---
  *** [randombytes] Error code 1
  
  make[3]: stopped in /tmp/tmp3O6IHb/rustsrc/cabi/target/release/build/rust_sodium-sys-4ebf664e5b18d7f2/out/source/libsodium-1.0.16/test/default
  --- secretbox_easy ---
  /bin/sh ../../libtool  --tag=CC    --mode=link cc  -O2 -pthread -fvisibility=hidden -fPIC -fPIE -fno-strict-aliasing -fno-strict-overflow -fstack-protector   -pie -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -o secretbox_easy secretbox_easy.o ../../src/libsodium/libsodium.la
  --- pwhash_argon2i ---
  libtool: link: cc -O2 -pthread -fvisibility=hidden -fPIC -fPIE -fno-strict-aliasing -fno-strict-overflow -fstack-protector -pie -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,-z -Wl,noexecstack -o pwhash_argon2i pwhash_argon2i.o  ../../src/libsodium/.libs/libsodium.a -pthread
  --- pwhash_argon2id ---
  libtool: link: cc -O2 -pthread -fvisibility=hidden -fPIC -fPIE -fno-strict-aliasing -fno-strict-overflow -fstack-protector -pie -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,-z -Wl,noexecstack -o pwhash_argon2id pwhash_argon2id.o  ../../src/libsodium/.libs/libsodium.a -pthread
  --- secretbox2 ---
  libtool: link: cc -O2 -pthread -fvisibility=hidden -fPIC -fPIE -fno-strict-aliasing -fno-strict-overflow -fstack-protector -pie -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,-z -Wl,noexecstack -o secretbox2 secretbox2.o  ../../src/libsodium/.libs/libsodium.a -pthread
  --- secretbox ---
  libtool: link: cc -O2 -pthread -fvisibility=hidden -fPIC -fPIE -fno-strict-aliasing -fno-strict-overflow -fstack-protector -pie -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,-z -Wl,noexecstack -o secretbox secretbox.o  ../../src/libsodium/.libs/libsodium.a -pthread
  --- secretbox7 ---
  libtool: link: cc -O2 -pthread -fvisibility=hidden -fPIC -fPIE -fno-strict-aliasing -fno-strict-overflow -fstack-protector -pie -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,-z -Wl,noexecstack -o secretbox7 secretbox7.o  ../../src/libsodium/.libs/libsodium.a -pthread
  --- secretbox8 ---
  libtool: link: cc -O2 -pthread -fvisibility=hidden -fPIC -fPIE -fno-strict-aliasing -fno-strict-overflow -fstack-protector -pie -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,-z -Wl,noexecstack -o secretbox8 secretbox8.o  ../../src/libsodium/.libs/libsodium.a -pthread
  --- secretbox_easy ---
  libtool: link: cc -O2 -pthread -fvisibility=hidden -fPIC -fPIE -fno-strict-aliasing -fno-strict-overflow -fstack-protector -pie -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,-z -Wl,noexecstack -o secretbox_easy secretbox_easy.o  ../../src/libsodium/.libs/libsodium.a -pthread
  1 error
  
  make[3]: stopped in /tmp/tmp3O6IHb/rustsrc/cabi/target/release/build/rust_sodium-sys-4ebf664e5b18d7f2/out/source/libsodium-1.0.16/test/default
  *** [check-am] Error code 2
  
  make[2]: stopped in /tmp/tmp3O6IHb/rustsrc/cabi/target/release/build/rust_sodium-sys-4ebf664e5b18d7f2/out/source/libsodium-1.0.16/test/default
  1 error
  
  make[2]: stopped in /tmp/tmp3O6IHb/rustsrc/cabi/target/release/build/rust_sodium-sys-4ebf664e5b18d7f2/out/source/libsodium-1.0.16/test/default
  *** [check-recursive] Error code 1
  
  make[1]: stopped in /tmp/tmp3O6IHb/rustsrc/cabi/target/release/build/rust_sodium-sys-4ebf664e5b18d7f2/out/source/libsodium-1.0.16/test
  1 error
  
  make[1]: stopped in /tmp/tmp3O6IHb/rustsrc/cabi/target/release/build/rust_sodium-sys-4ebf664e5b18d7f2/out/source/libsodium-1.0.16/test
  *** [check-recursive] Error code 1
  
  make: stopped in /tmp/tmp3O6IHb/rustsrc/cabi/target/release/build/rust_sodium-sys-4ebf664e5b18d7f2/out/source/libsodium-1.0.16
  
  make: stopped in /tmp/tmp3O6IHb/rustsrc/cabi/target/release/build/rust_sodium-sys-4ebf664e5b18d7f2/out/source/libsodium-1.0.16
  
  1 error
  
  ', /home/sentry/.cargo/registry/src/github.com-1ecc6299db9ec823/rust_sodium-sys-0.9.0/build.rs:405:9
  stack backtrace:
     0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
     1: std::sys_common::backtrace::print
     2: std::panicking::default_hook::{{closure}}
     3: std::panicking::default_hook
     4: std::panicking::rust_panic_with_hook
     5: std::panicking::begin_panic_fmt
     6: build_script_build::get_libsodium
               at /home/sentry/.cargo/registry/src/github.com-1ecc6299db9ec823/rust_sodium-sys-0.9.0/build.rs:405
     7: build_script_build::main
               at /home/sentry/.cargo/registry/src/github.com-1ecc6299db9ec823/rust_sodium-sys-0.9.0/build.rs:70
     8: std::rt::lang_start::{{closure}}
     9: std::panicking::try::do_call
    10: __rust_maybe_catch_panic
               at libpanic_unwind/lib.rs:105
    11: std::rt::lang_start_internal
    12: main
    13: _start
    14: <unknown>
  
  
  ----------------------------------------
  Failed building wheel for semaphore
  Running setup.py clean for semaphore
Failed to build semaphore
Installing collected packages: pycparser, cffi, milksnake, semaphore
  Running setup.py install for semaphore ... error
    Complete output from command /usr/home/sentry/env/bin/python2.7 -u -c "import setuptools, tokenize;__file__='/tmp/pip-install-4V7LQm/semaphore/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record /tmp/pip-record-hmYZ7X/install-record.txt --single-version-externally-managed --compile --install-headers /usr/home/sentry/env/include/site/python2.7/semaphore:


       Compiling rust_sodium-sys v0.9.0
    error: failed to run custom build command for `rust_sodium-sys v0.9.0`
    process didn't exit successfully: `/tmp/tmpglZQJX/rustsrc/cabi/target/release/build/rust_sodium-sys-ff5bb2f53604e571/build-script-build` (exit code: 101)
    --- stdout
    cargo:rerun-if-env-changed=RUST_SODIUM_LIB_DIR
    cargo:rerun-if-env-changed=RUST_SODIUM_USE_PKG_CONFIG
    cargo:rerun-if-env-changed=RUST_SODIUM_SHARED
    OPT_LEVEL = Some("3")
    TARGET = Some("x86_64-unknown-freebsd")
    HOST = Some("x86_64-unknown-freebsd")
    TARGET = Some("x86_64-unknown-freebsd")
    TARGET = Some("x86_64-unknown-freebsd")
    HOST = Some("x86_64-unknown-freebsd")
    CC_x86_64-unknown-freebsd = None
    CC_x86_64_unknown_freebsd = None
    HOST_CC = None
    CC = None
    HOST = Some("x86_64-unknown-freebsd")
    TARGET = Some("x86_64-unknown-freebsd")
    HOST = Some("x86_64-unknown-freebsd")
    CFLAGS_x86_64-unknown-freebsd = None
    CFLAGS_x86_64_unknown_freebsd = None
    HOST_CFLAGS = None
    CFLAGS = None
    DEBUG = Some("true")
    cargo:rerun-if-env-changed=RUST_SODIUM_DISABLE_PIE
    
    --- stderr
    thread 'main' panicked at '

    --- randombytes ---
    libtool: link: cc -O2 -pthread -fvisibility=hidden -fPIC -fPIE -fno-strict-aliasing -fno-strict-overflow -fstack-protector -pie -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,-z -Wl,noexecstack -o randombytes randombytes.o  ../../src/libsodium/.libs/libsodium.a -pthread
    /usr/bin/ld: ../../src/libsodium/.libs/libsodium.a(librdrand_la-randombytes_salsa20_random.o): relocation R_X86_64_TPOFF32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
    ../../src/libsodium/.libs/libsodium.a: could not read symbols: Bad value
    cc: error: linker command failed with exit code 1 (use -v to see invocation)
    *** [randombytes] Error code 1
    
    make[3]: stopped in /tmp/tmpglZQJX/rustsrc/cabi/target/release/build/rust_sodium-sys-4ebf664e5b18d7f2/out/source/libsodium-1.0.16/test/default
    --- pwhash_argon2i ---
    libtool: link: cc -O2 -pthread -fvisibility=hidden -fPIC -fPIE -fno-strict-aliasing -fno-strict-overflow -fstack-protector -pie -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,-z -Wl,noexecstack -o pwhash_argon2i pwhash_argon2i.o  ../../src/libsodium/.libs/libsodium.a -pthread
    --- secretbox2 ---
    libtool: link: cc -O2 -pthread -fvisibility=hidden -fPIC -fPIE -fno-strict-aliasing -fno-strict-overflow -fstack-protector -pie -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,-z -Wl,noexecstack -o secretbox2 secretbox2.o  ../../src/libsodium/.libs/libsodium.a -pthread
    --- secretbox7 ---
    libtool: link: cc -O2 -pthread -fvisibility=hidden -fPIC -fPIE -fno-strict-aliasing -fno-strict-overflow -fstack-protector -pie -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,-z -Wl,noexecstack -o secretbox7 secretbox7.o  ../../src/libsodium/.libs/libsodium.a -pthread
    --- secretbox8 ---
    libtool: link: cc -O2 -pthread -fvisibility=hidden -fPIC -fPIE -fno-strict-aliasing -fno-strict-overflow -fstack-protector -pie -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,-z -Wl,noexecstack -o secretbox8 secretbox8.o  ../../src/libsodium/.libs/libsodium.a -pthread
    --- secretbox ---
    libtool: link: cc -O2 -pthread -fvisibility=hidden -fPIC -fPIE -fno-strict-aliasing -fno-strict-overflow -fstack-protector -pie -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,-z -Wl,noexecstack -o secretbox secretbox.o  ../../src/libsodium/.libs/libsodium.a -pthread
    --- pwhash_argon2id ---
    libtool: link: cc -O2 -pthread -fvisibility=hidden -fPIC -fPIE -fno-strict-aliasing -fno-strict-overflow -fstack-protector -pie -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,-z -Wl,noexecstack -o pwhash_argon2id pwhash_argon2id.o  ../../src/libsodium/.libs/libsodium.a -pthread
    --- secretbox_easy2 ---
    libtool: link: cc -O2 -pthread -fvisibility=hidden -fPIC -fPIE -fno-strict-aliasing -fno-strict-overflow -fstack-protector -pie -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,-z -Wl,noexecstack -o secretbox_easy2 secretbox_easy2.o  ../../src/libsodium/.libs/libsodium.a -pthread
    1 error
    
    make[3]: stopped in /tmp/tmpglZQJX/rustsrc/cabi/target/release/build/rust_sodium-sys-4ebf664e5b18d7f2/out/source/libsodium-1.0.16/test/default
    *** [check-am] Error code 2
    
    make[2]: stopped in /tmp/tmpglZQJX/rustsrc/cabi/target/release/build/rust_sodium-sys-4ebf664e5b18d7f2/out/source/libsodium-1.0.16/test/default
    1 error
    
    make[2]: stopped in /tmp/tmpglZQJX/rustsrc/cabi/target/release/build/rust_sodium-sys-4ebf664e5b18d7f2/out/source/libsodium-1.0.16/test/default
    *** [check-recursive] Error code 1
    
    make[1]: stopped in /tmp/tmpglZQJX/rustsrc/cabi/target/release/build/rust_sodium-sys-4ebf664e5b18d7f2/out/source/libsodium-1.0.16/test
    1 error
    
    make[1]: stopped in /tmp/tmpglZQJX/rustsrc/cabi/target/release/build/rust_sodium-sys-4ebf664e5b18d7f2/out/source/libsodium-1.0.16/test
    *** [check-recursive] Error code 1
    
    make: stopped in /tmp/tmpglZQJX/rustsrc/cabi/target/release/build/rust_sodium-sys-4ebf664e5b18d7f2/out/source/libsodium-1.0.16
    
    make: stopped in /tmp/tmpglZQJX/rustsrc/cabi/target/release/build/rust_sodium-sys-4ebf664e5b18d7f2/out/source/libsodium-1.0.16
    
    1 error
    
    ', /home/sentry/.cargo/registry/src/github.com-1ecc6299db9ec823/rust_sodium-sys-0.9.0/build.rs:405:9
    stack backtrace:
       0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
       1: std::sys_common::backtrace::print
       2: std::panicking::default_hook::{{closure}}
       3: std::panicking::default_hook
       4: std::panicking::rust_panic_with_hook
       5: std::panicking::begin_panic_fmt
       6: build_script_build::get_libsodium
                 at /home/sentry/.cargo/registry/src/github.com-1ecc6299db9ec823/rust_sodium-sys-0.9.0/build.rs:405
       7: build_script_build::main
                 at /home/sentry/.cargo/registry/src/github.com-1ecc6299db9ec823/rust_sodium-sys-0.9.0/build.rs:70
       8: std::rt::lang_start::{{closure}}
       9: std::panicking::try::do_call
      10: __rust_maybe_catch_panic
                 at libpanic_unwind/lib.rs:105
      11: std::rt::lang_start_internal
      12: main
      13: _start
      14: <unknown>

Allow configuration through environment variables

I am currently setting up Sentry Relay in our Kubernetes cluster. Passing the configuration as a file works fine, but is relatively verbose.

kind: Deployment
spec:
  template:
    spec:
      containers:
        - name: relay
          image: getsentry/relay
          volumeMounts:
            - mountPath: /work/.relay
              name: relay
      volumes:
        - name: relay
          configMap:
            name: relay
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: relay
data:
  config.yml: |
    relay:
      mode: proxy

It would be nice if I could pass the configuration values as environment variables instead.

kind: Deployment
spec:
  template:
    spec:
      containers:
        - name: relay
          image: getsentry/relay
          env:
            - name: RELAY_MODE
              value: proxy

Such a configuration style is common practice among many other Docker images i have used.

Fix origin handling

We currently use a url to represent the origin. This is wrong as for a start a trailing slash is added but it also does not handle null etc.

Decide payload limits

Currently the system uses hardcode 512kb payload limits. Do we want to load this from the config or communicate from upstream?

Authenticating to sentry.io

In the README it says:

"At present Sentry requires the relays to be explicitly whitelisted by their public key. This is done through the SENTRY_RELAY_WHITELIST_PK config key which is a list of permitted public keys."

How does one register this public key with sentry.io, or otherwise authenticate the relay to that site?

Thanks.

InApp setting on frame ignored

Please mark the type framework used:

  • [ x] ASP.NET MVC
  • ASP.NET Web API (OWIN)
  • ASP.NET Core
  • WPF
  • WinForms
  • Xamarin
  • Other:

Please mark the type of the runtime used:

  • [ x] .NET Framework
  • Mono
  • .NET Core
  • Version:

Please mark the NuGet packages used:

  • [ x] Sentry
  • Sentry.Serilog
  • Sentry.NLog
  • Sentry.Log4Net
  • Sentry.Extensions.Logging
  • Sentry.AspNetCore

Please describe the the steps to reproduce the issue or link to a repository with a small reproducible code.

I'm sending event (CaptureEvent) with SentryException inside, with all its frames marked as InApp=true.
When I open this event in Sentry and check its raw JSON, I see that the frames are there but all are marked as "in_app":false (both on my frames and frames from System. namespace)

Is this behavior expected ? Does setting inApp = true modify Sentry application somehow, for example by rendering event data differently?

DNS error in relay connecting to web on startup

Version Information

Version: Sentry 21.4.0.dev0857295a

Steps to Reproduce

After an ordinary upgrade (./install.sh, which went totally fine) events stopped registering.

Logs

latest install logs: ls -1 sentry_install_log-*.txt | tail -1 | xargs cat:

Creating sentry_onpremise_web_run                                    ...
Creating sentry_onpremise_web_run                                    ... done
15:39:32 [INFO] sentry.plugins.github: apps-not-configured
* Unknown config option found: 'slack.legacy-app'
Operations to perform:
  Apply all migrations: admin, auth, contenttypes, jira_ac, nodestore, sentry, sessions, sites, social_auth
Running migrations:
  No migrations to apply.
Creating missing DSNs
Correcting Group.num_comments counter

โ–ถ Migrating file storage ...

โ–ถ Generating Relay credentials ...
../relay/config.yml already exists, skipped creation.

โ–ถ Setting up GeoIP integration ...
Setting up IP address geolocation ...
IP address geolocation database already exists.
IP address geolocation is configured for updates.
Updating IP address geolocation database ...
--no-ansi option is deprecated and will be removed in future versions.
Creating sentry_onpremise_geoipupdate_run ...
Creating sentry_onpremise_geoipupdate_run ... done
Done updating IP address geolocation database.
Done setting up IP address geolocation.


-----------------------------------------------------------------

You're all done! Run the following command to get Sentry running:

  docker-compose up -d

-----------------------------------------------------------------

docker-compose logs have some records about the connection errors (web:9000) even though this container is running and web interface is totally accessible:

clickhouse_1                                | 2021.04.05 16:30:03.797072 [ 88 ] {} <Information> TCPHandler: Processed in 0.003 sec.
clickhouse_1                                | 2021.04.05 16:30:03.849351 [ 88 ] {} <Information> TCPHandler: Done processing connection.
relay_1                                     | 2021-04-05T16:30:06Z [relay_server::actors::upstream] WARN: Network outage, scheduling another check in 60s
redis_1                                     | 1:M 05 Apr 2021 16:30:08.062 * 100 changes in 300 seconds. Saving...
redis_1                                     | 1:M 05 Apr 2021 16:30:08.063 * Background saving started by pid 22
redis_1                                     | 22:C 05 Apr 2021 16:30:08.076 * DB saved on disk
redis_1                                     | 22:C 05 Apr 2021 16:30:08.077 * RDB: 6 MB of memory used by copy-on-write
redis_1                                     | 1:M 05 Apr 2021 16:30:08.164 * Background saving terminated with success
worker_1                                    | 16:30:22 [WARNING] sentry.tasks.release_registry: Release registry URL is not specified, skipping the task.
relay_1                                     | 2021-04-05T16:30:53Z [relay_server::actors::upstream] ERROR: authentication encountered error: could not send request to upstream
relay_1                                     |   caused by: error sending request for url (http://web:9000/api/0/relays/register/challenge/): error trying to connect: dns error: no record found for name: web. type: AAAA class: IN
relay_1                                     | 2021-04-05T16:31:06Z [relay_server::actors::upstream] WARN: Network outage, scheduling another check in 60s
relay_1                                     | 2021-04-05T16:31:14Z [relay_server::actors::events] ERROR: error processing event: event exceeded its configured lifetime
clickhouse_1                                | 2021.04.05 16:31:15.135779 [ 89 ] {aacb4d5f-b8e4-4386-bd5d-43e1f073290c} <Information> executeQuery: Read 1 rows, 88.00 B in 0.009 sec., 113 rows/sec., 9.79 KiB/sec.
clickhouse_1                                | 2021.04.05 16:31:15.136507 [ 89 ] {} <Information> HTTPHandler: Done processing query
snuba-outcomes-consumer_1                   | 2021-04-05 16:31:15,141 Completed processing <Batch: 1 message, open for 1.02 seconds>.
relay_1                                     | 2021-04-05T16:31:53Z [relay_server::actors::upstream] ERROR: authentication encountered error: could not send request to upstream
relay_1                                     |   caused by: error sending request for url (http://web:9000/api/0/relays/register/challenge/): error trying to connect: dns error: no record found for name: web. type: AAAA class: IN
relay_1                                     | 2021-04-05T16:32:06Z [relay_server::actors::upstream] WARN: Network outage, scheduling another check in 60s

All containers are run (docker-compose ps):

                           Name                                          Command               State              Ports
-----------------------------------------------------------------------------------------------------------------------------------
sentry_onpremise_clickhouse_1                                 /entrypoint.sh                   Up      8123/tcp, 9000/tcp, 9009/tcp
sentry_onpremise_cron_1                                       /etc/sentry/entrypoint.sh  ...   Up      9000/tcp
sentry_onpremise_ingest-consumer_1                            /etc/sentry/entrypoint.sh  ...   Up      9000/tcp
sentry_onpremise_kafka_1                                      /etc/confluent/docker/run        Up      9092/tcp
sentry_onpremise_memcached_1                                  docker-entrypoint.sh memcached   Up      11211/tcp
sentry_onpremise_nginx_1                                      nginx -g daemon off;             Up      0.0.0.0:9000->80/tcp
sentry_onpremise_post-process-forwarder_1                     /etc/sentry/entrypoint.sh  ...   Up      9000/tcp
sentry_onpremise_postgres_1                                   docker-entrypoint.sh postgres    Up      5432/tcp
sentry_onpremise_redis_1                                      docker-entrypoint.sh redis ...   Up      6379/tcp
sentry_onpremise_relay_1                                      /bin/bash /docker-entrypoi ...   Up      3000/tcp
sentry_onpremise_sentry-cleanup_1                             /entrypoint.sh 0 0 * * * g ...   Up      9000/tcp
sentry_onpremise_smtp_1                                       docker-entrypoint.sh exim  ...   Up      25/tcp
sentry_onpremise_snuba-api_1                                  ./docker_entrypoint.sh api       Up      1218/tcp
sentry_onpremise_snuba-cleanup_1                              /entrypoint.sh */5 * * * * ...   Up      1218/tcp
sentry_onpremise_snuba-consumer_1                             ./docker_entrypoint.sh con ...   Up      1218/tcp
sentry_onpremise_snuba-outcomes-consumer_1                    ./docker_entrypoint.sh con ...   Up      1218/tcp
sentry_onpremise_snuba-replacer_1                             ./docker_entrypoint.sh rep ...   Up      1218/tcp
sentry_onpremise_snuba-sessions-consumer_1                    ./docker_entrypoint.sh con ...   Up      1218/tcp
sentry_onpremise_snuba-subscription-consumer-events_1         ./docker_entrypoint.sh sub ...   Up      1218/tcp
sentry_onpremise_snuba-subscription-consumer-transactions_1   ./docker_entrypoint.sh sub ...   Up      1218/tcp
sentry_onpremise_snuba-transactions-consumer_1                ./docker_entrypoint.sh con ...   Up      1218/tcp
sentry_onpremise_subscription-consumer-events_1               /etc/sentry/entrypoint.sh  ...   Up      9000/tcp
sentry_onpremise_subscription-consumer-transactions_1         /etc/sentry/entrypoint.sh  ...   Up      9000/tcp
sentry_onpremise_symbolicator-cleanup_1                       /entrypoint.sh 55 23 * * * ...   Up      3021/tcp
sentry_onpremise_symbolicator_1                               /bin/bash /docker-entrypoi ...   Up      3021/tcp
sentry_onpremise_web_1                                        /etc/sentry/entrypoint.sh  ...   Up      9000/tcp
sentry_onpremise_worker_1                                     /etc/sentry/entrypoint.sh  ...   Up      9000/tcp
sentry_onpremise_zookeeper_1                                  /etc/confluent/docker/run        Up      2181/tcp, 2888/tcp, 3888/tcp

Peridocally crashed relay

Hello.

Relay was builded from tag 20.10.1 by cargo build --all-features and time to time crashing with strange repeatable error:

Nov 23 17:10:53 sentry4 relay[5184]: thread '<unnamed>' panicked at 'assertion failed: replacement_chunks.is_empty()', relay-general/src/pii/processor.rs:318:5
Nov 23 17:10:53 sentry4 relay[5184]: note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Nov 23 17:10:53 sentry4 relay[5184]: thread '<unnamed>' panicked at 'assertion failed: replacement_chunks.is_empty()', relay-general/src/pii/processor.rs:318:5
Nov 23 17:10:53 sentry4 relay[5184]: 2020-11-23T17:10:53Z [relay_server::actors::events] ERROR: error processing event: could not schedule project fetch
Nov 23 17:10:53 sentry4 relay[5184]:   caused by: Mailbox has closed
Nov 23 17:10:53 sentry4 relay[5184]: 2020-11-23T17:10:53Z [relay_server::actors::events] ERROR: error processing event: could not schedule project fetch
Nov 23 17:10:53 sentry4 relay[5184]:   caused by: Mailbox has closed
Nov 23 17:10:53 sentry4 relay[5184]: thread '<unnamed>' panicked at 'assertion failed: replacement_chunks.is_empty()', relay-general/src/pii/processor.rs:318:5
Nov 23 17:10:53 sentry4 relay[5184]: 2020-11-23T17:10:53Z [relay_server::actors::events] ERROR: error processing event: could not schedule project fetch
Nov 23 17:10:53 sentry4 relay[5184]:   caused by: Mailbox has closed
Nov 23 17:10:53 sentry4 relay[5184]: thread '<unnamed>' panicked at 'assertion failed: replacement_chunks.is_empty()', relay-general/src/pii/processor.rs:318:5
Nov 23 17:10:53 sentry4 relay[5184]: 2020-11-23T17:10:53Z [relay_server::actors::events] ERROR: error processing event: could not schedule project fetch
Nov 23 17:10:53 sentry4 relay[5184]:   caused by: Mailbox has closed
Nov 23 17:10:53 sentry4 relay[5184]: thread '<unnamed>' panicked at 'assertion failed: replacement_chunks.is_empty()', relay-general/src/pii/processor.rs:318:5
Nov 23 17:10:53 sentry4 relay[5184]: 2020-11-23T17:10:53Z [relay_server::actors::events] ERROR: error processing event: could not schedule project fetch
Nov 23 17:10:53 sentry4 relay[5184]:   caused by: Mailbox has closed
Nov 23 17:10:53 sentry4 relay[5184]: thread '<unnamed>' panicked at 'assertion failed: replacement_chunks.is_empty()', relay-general/src/pii/processor.rs:318:5
Nov 23 17:10:53 sentry4 relay[5184]: 2020-11-23T17:10:53Z [relay_server::actors::events] ERROR: error processing event: could not schedule project fetch
Nov 23 17:10:53 sentry4 relay[5184]:   caused by: Mailbox has closed
Nov 23 17:10:53 sentry4 relay[5184]: thread '<unnamed>' panicked at 'assertion failed: replacement_chunks.is_empty()', relay-general/src/pii/processor.rs:318:5
Nov 23 17:10:53 sentry4 relay[5184]: 2020-11-23T17:10:53Z [relay_server::actors::events] ERROR: error processing event: could not schedule project fetch
Nov 23 17:10:53 sentry4 relay[5184]:   caused by: Mailbox has closed

All services, like kafka and clickhouse seems working. After restart relay working near 5 hours and crashing again with same errors.

Service config:

relay:
        mode: managed
        upstream: http://127.0.0.1:9000
        host: 127.0.0.1
        port: 3000

proxy mode doesn't work in 0.5.2

The last version we're using successfully in production is semaphore 0.4.46.

This is my config:

---
relay:
  mode: proxy
  upstream: "https://sentry.abc.xyz"
  host: 127.0.0.1
  port: 3000
  tls_port: ~
  tls_identity_path: ~
  tls_identity_password: ~

The service starts without errors.

$ export SENTRY_DSN=http://[email protected]:3000/5
$ sentry-cli send-event -m "Hello from Sentry"
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

The event is never received. The service logs no errors. It doesn't exactly help sentry-cli send-event doesn't even complain when the service is shut down. Switching to the real DSN works as expected.

Any idea what's going on here? How can I provide more useful information?

FQDN for HTTPS upstream is not supported

Having

relay:
  upstream: https://sentry.io.

in config.yaml leads to the following error on startup:

 DEBUG relay_server::actors::upstream            > scheduling authentication retry in 1 seconds
 INFO  relay_server::actors::upstream            > registering with upstream (https://sentry.io./)
 ERROR relay_server::actors::upstream            > authentication encountered error: could not send request to upstream
  caused by: Failed to connect to host: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1269: (Hostname mismatch)
  caused by: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1269: (Hostname mismatch)
  caused by: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1269: (Hostname mismatch)
 DEBUG relay_server::actors::upstream            > scheduling authentication retry in 1 seconds

Removing the trailing dot fixes it.

Docker image semver tags

Hi,

I'm looking for a 0.4.x Relay image to test relay with an on-premise Sentry 10 install and I realized that there are no semver tags on your images (neither on the Docker hub nor on the GCP registry); just UUIDs...

How can I find a specific version?

ERROR: error fetching project states: could not send request to upstream

Relay: 20.8.0

[root@jsentry:src/relay]# git branch
* (HEAD detached at 20.8.0)
  master

Symptoms: Sentry stops streaming events. When examining the relay log, the following entries are found:

Sep 16 07:21:42 jsentry relay[54969]: 2020-09-16T04:21:42Z [relay_server::actors::project_upstream] ERROR: error fetching project states: could not send request to upstream
Sep 16 07:21:42 jsentry relay[54969]:   caused by: Server disconnected
Sep 16 07:21:42 jsentry syslogd: last message repeated 1 times

Fix: relay is restarted at this point, and Sentry continues to stream events.

In the same time relay just doesn't exit with error - for some reason it just stops processing events. From my point of view:

  1. logs give no ideas what "server" the relay talks about. It may be indeed that the error is in my software stack, not on the relay side, but from the lines above it's hard to guess what service should I take a look at, since sentry comprises gazillions of components. It it snuba/memcache/redis/confluent (what of it's components ?) ?
  2. does the "Server disconnected" message mean it's not the relay which eventually disconnected from something, but rather "something" got disconnected from the relay ? Anyway mentioning the actual service and/or the connect descriptor or at least socket address would be really nice.
  3. "it" (whatever it is) should either attempt to reconnect (which would be just cool) or exit, so the docker/swarm/k8s restarts it.

Expect-CT security reporting implementation does not comply with current revision of Expect-CT Extension for HTTP standard

Important Details

How are you running Sentry?

On-Premise with Docker, version 9.1.1.

Description

Lately we have created a project in our on-premise Sentry to collect Expect-CT violation reports. We have configured everything according to Security Policy Reporting and started testing the endpoint with Chrome's (86.0.4240.198) built-in test Expect-CT report tool, available under chrome://net-internals/#hsts. We have found multiple issues in the current implementation which completely precludes Sentry from reliable Expect-CT violation report collection.

In our Sentry instance security reporting is done in Sentry itself. However, the logic of security reporting has been completely removed from Sentry in version 20.7.0, specifically in this commit: getsentry/sentry@644dcc5, in favour of maintaining it in Relay, which introduced it in: #276. Unfortunately, it seems that the implementation has been done without paying attention to the detail, as the same issues present in Sentry's Python code now exist in Relay's Rust code. Therefore, I have decided to create an issue here, despite the fact that issues in my particular case come from Sentry rather than Relay.

Incompatibile request Content-Type

Currently security report endpoint filters out requests depending on the provided Content-Type. In case of Except-CT two content type values are accepted: "application/expect-ct-report" and "application/expect-ct-report+json". While this complies with the current Expect-CT Extension for HTTP revision or is even less strict, modern browsers tend to send charset along with the media type as the value of Content-Type header e.g. application/expect-ct-report+json; charset=utf-8, causing the request to be rejected with HTTP 400 Bad Request - Invalid Content-Type. Security report endpoint should match the media type of Content-Type request header value instead of matching the whole header.

CORS preflight request

Current Expect-CT Extension for HTTP revision states that:

The UA MAY perform other operations as part of sending the HTTP POST request, for example sending a CORS preflight as part of [FETCH].

Which in fact is the case in many browsers (including Chrome and it's test tool) since report is sent via XMLHttpRequest / Fetch API and unless report-uri is set to the same origin, it is treated as a cross-origin request, following same-origin policy. Since violation report has specific media type, as mentioned above, cross-origin resource sharing mandates browsers sending preflight request soliciting supported methods from the server with the HTTP OPTIONS request method, and then, upon "approval" from the server, sending the actual request. In our case Chrome e.g. is sending a preflight request with following CORS headers:

Access-Control-Request-Headers: content-type
Access-Control-Request-Method: POST

The proper handling of such preflight request should include response with allowed origins (would be great if they can be whitelisted in project settings), requested method, header and cacheing info, followed by the actual request sent by the browser. Unfortunately, in case of Sentry CORS preflight request was rejected with HTTP 405 Method Not Allowed and Allowed: POST response header.

Missing violation report properties

We have been able to work around the issues listed above using custom reverse proxy configuration in our on-premise setup. Nevertheless, testing the endpoint with Chrome's test tool and our deployment that used the endpoint as report-uri using Hardenize was still failing. Then we have found out that the report is rejected with HTTP 400 Bad Request due to additional fields present in request's JSON body, not compliant with Expect-CT JSON schema Sentry or Relay's ExpectCt protocol which is missing some properties, namely:

  • failure-mode (MANDATORY): the value indicates whether the Expect-CT report was triggered by an Expect-CT policy in enforce or report-only mode. The value is provided as a string. The UA MUST set this value to "enforce" if the Expect-CT metadata indicates an "enforce" configuration, and "report-only" otherwise.
  • scheme (OPTIONAL): the value is the scheme with which the UA made the original request that failed the CT compliance check. The value is provided as a string. This key is optional and is assumed to be "https" if not present.
  • test-report (OPTIONAL): the value is set to true if the report is being sent by a testing client to verify that the report server behave correctly. The value is provided as a boolean, and MUST be set to true if the report serves to test the server's behaviour and can be discarded.

Sending valid report containing any of these fields, especially failure-mode (the rest can be inferred) led to report being rejected with HTTP 400 Bad Request.

Violation report corner case handling

While this is not a problem per se current Expect-CT Extension for HTTP revision specifies how a report with a different top-level key should be handled (HTTP 501 Not Implemented) and how to treat report with test-report property set to true. This is something that can be addressed while adjusting the implementation to the above-mentioned requirements.

Steps to Reproduce

Chrome's test Expect-CT report tool

  1. Create and configure project in Sentry, get Security policy reporting endpoint url
  2. Go to chrome://net-internals/#hsts in any Chromium based browser
  3. Paste the url from point no. 1
  4. Click Send

Hardenize

  1. Create and configure project in Sentry, get Security policy reporting endpoint url
  2. Deploy a web service with Expect-CT header containing report-uri directive pointing at url from point no. 1
  3. Scan service from point no. 2 with Hardenize at https://www.hardenize.com
  4. Go to Expect CT section of the scan report and check the results

What you expected to happen

Both Chrome's test tool and Hardenize tests should be successful.

Possible Solution

This has been included in issues description.

Relay discards events when it is offline

Hey there, I did some experiment on the relay 20.7.2 and found something might be wrong.
I setup the relay in static mode and setup the project configuration file and localhost DSN according to the documentation.

Here are the steps of my experiments:

  1. Relay has Internet connection
  2. Trigger an error in client SDK
  3. Client SDK get 200 from relay
  4. Relay forwards the error to sentry.io (I can see the events in sentry.io dashboard)

But when I try:

  1. Relay disconnect to Internet
  2. Trigger an error in client SDK
  3. Client SDK gets 200 from relay
  4. Reconnect relay to Internet
  5. Canโ€™t see the error on sentry.io dashboard.

Feel like the Relay discards the events when it is offline. According to my understanding, shouldn't it be cached until the connection to sentry.io is back or the event reaches its expiration time?

My configs:

cat .relay/config.yml
---
relay:
  mode: static
  upstream: "https://sentry.io/"
  host: 127.0.0.1
  port: 9000
  tls_port: ~
  tls_identity_path: ~
  tls_identity_password: ~
cat .relay/projects/xxxx.json
{
  "slug": "client-2",
  "publicKeys": [
    {
      "publicKey": "xxxxxxxxxxxxxxxxxxxx",
      "isEnabled": true
    }
  ],
  "config": {
    "allowedDomains": ["*"]
  }
}

Add ability to filter on specific devices (or any tag)

The feature to quickly filter out legacy browsers is great, however, I have some other old devices that are causing fluke bugs and I'd like to filter them out. To my surprise, I couldn't find out anywhere how to filter out specific errors except by using ignoreErrors, which I think only compares the error message body.

I would like for example, to be able to ignore all errors with tag device:family and value Alcatel One Touch 7041X.

Is it possible to implement such manual error filters on inbound data that look at specific tags?

If this is too hard to implement, could you add Android 4 as a legacy device?

Can't connect to Kafka broker using SSL

I'm using the docker image getsentry/relay:20.11.1

I'm trying to connect to a Kafka broker using SSL (port 9094), but Relay is reporting that my config file is invalid.

logging:
  level: WARN
processing:
  enabled: true
  kafka_config:
  - name: bootstrap.servers
    value: 'kafka-b-2.sentry.:9094,kafka-b-1.sentry.:9094'
  - name: security.protocol
    value: ssl
  - name: message.max.bytes
    value: 50000000
relay:
  host: 0.0.0.0
  port: 3000
  upstream: http://web.sentry.:9000
# relay -V
relay 20.11.1
# relay run
 ERROR relay::cli > could not initialize kafka producer
  caused by: Client config error: Invalid value "ssl" for configuration property "security.protocol" security.protocol ssl

According to the rdkafka docs this should be a legal configuration property and value.

Rdkafka claims this is an issue with the wrapper library: confluentinc/librdkafka#1938 and rust-rdkafka states that you need to compile with the openssl library: fede1024/rust-rdkafka#174. Since I'm using the getsentry/relay official Docker image, this seems it would be an issue with this repository.

So far I've been able to get the Python components (Snuba and Sentry web) to run with SSL to Kafka, so this issue appears to be limited to Relay.

Specify all configuration values through environment variables

Follow up from #962.

As clarified by @RaduW in #962 (comment), some configuration values are available as environment variables, while others are not. That circumstance makes this configuration option a dead end: configuring a subset of values works fine, but once an unsupported option is required, one would have to rewrite their configuration completely.

In order to make the configuration both consistent and feature-complete, I propose to add the option to specify all configuration values available in the config file through environment variables. For ease of discovery, i propose to mirror the config path from the yaml options like this:

relay.mode -> RELAY_MODE
limits.max_attachment_size -> LIMITS_MAX_ATTACHMENT_SIZE

Allow extra JSON fields for ingestion into security report API

Summary

Extra fields in security reports are rejected by Sentry. This breaks compatibility with some libraries which are otherwise compatible with the security header API. There are workarounds but it would be nice for Sentry to accept extra data into the event. Also, please keep HPKP report support--it is useful for non-browser apps.

Motivation

While HPKP is being deprecated in browsers, best practice for mobile and desktop apps remains pinning TLS keys (as the code distribution model is not the web so isn't absurdly dangerous). One of the nicest libraries for doing this on Android and iOS is called TrustKit. It uses the HPKP report format and is compatible with Sentry security reports as long as we remove some extra fields TrustKit adds (we keep the information around by making them fake HTTP headers), because Sentry does not allow any fields it doesn't recognize in security reports. Is this restriction necessary? It seems overly draconian and that unrecognized fields could be allowed and become part of the event as unstructured data.

Additional Context

The extra TrustKit fields are:

  • app-bundle-id
  • app-version
  • app-vendor-id
  • app-platform
  • trustkit-version
  • enforce-pinning
  • validation-result

Building rdkafka on Windows fails

rdkafka can't be reliably built on Windows at the moment, because it tries to run ./configure as a build step and fails, not being able to find bash.
We should probably patch build.rs there to support MSVC.

Cannot build 21.1.0 using rustc 1.49.0

Important Details

How are you running Sentry?

On-premise. containerless, 21.1.0

OS: FreeBSD 12.1
Python:
Python 3.6.12 (default, Jan 24 2021, 14:59:42)
[GCC 4.2.1 Compatible FreeBSD Clang 8.0.1 (tags/RELEASE_801/final 366581)] on freebsd12

Rustc:
rustc 1.49.0

Description

Build crashes on python3.6 setup.py install stage:

   Compiling erased-serde v0.3.12
   Compiling serde_urlencoded v0.5.5
   Compiling sentry-release-parser v0.6.0
   Compiling globset v0.4.5
   Compiling minidump-common v0.2.0 (https://github.com/luser/rust-minidump?rev=4d95707b20bf15fb37de5f6d7ba7d7e0f8ab4afd#4d95707b)
   Compiling parking_lot_core v0.7.2
error[E0277]: the trait bound `[u16; 260]: TryFromCtx<'_, _>` is not satisfied
    --> /home/emz/.cargo/git/checkouts/rust-minidump-836c4af26fbfd1e5/4d95707/minidump-common/src/format.rs:1322:25
     |
1322 |           #[derive(Clone, Pread, SizeWith)]
     |                           ^^^^^ the trait `TryFromCtx<'_, _>` is not implemented for `[u16; 260]`
...
1331 | / multi_structs! {
1332 | |     /// Miscellaneous process information
1333 | |     ///
1334 | |     /// This struct matches the [Microsoft struct][msdn] of the same name.
...    |
1376 | |     }
1377 | | }
     | |_- in this macro invocation
     |
     = help: the following implementations were found:
               <&'a [u8] as TryFromCtx<'a, usize>>
     = note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `[u16; 40]: TryFromCtx<'_, _>` is not satisfied
    --> /home/emz/.cargo/git/checkouts/rust-minidump-836c4af26fbfd1e5/4d95707/minidump-common/src/format.rs:1322:25
     |
1322 |           #[derive(Clone, Pread, SizeWith)]
     |                           ^^^^^ the trait `TryFromCtx<'_, _>` is not implemented for `[u16; 40]`
...
1331 | / multi_structs! {
1332 | |     /// Miscellaneous process information
1333 | |     ///
1334 | |     /// This struct matches the [Microsoft struct][msdn] of the same name.
...    |
1376 | |     }
1377 | | }
     | |_- in this macro invocation
     |
     = help: the following implementations were found:
               <&'a [u8] as TryFromCtx<'a, usize>>
     = note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0599]: no function or associated item named `size_with` found for array `[u16; 260]` in the current scope
    --> /home/emz/.cargo/git/checkouts/rust-minidump-836c4af26fbfd1e5/4d95707/minidump-common/src/format.rs:1322:32
     |
1322 |           #[derive(Clone, Pread, SizeWith)]
     |                                  ^^^^^^^^ function or associated item not found in `[u16; 260]`
...
1331 | / multi_structs! {
1332 | |     /// Miscellaneous process information
1333 | |     ///
1334 | |     /// This struct matches the [Microsoft struct][msdn] of the same name.
...    |
1376 | |     }
1377 | | }
     | |_- in this macro invocation
     |
     = note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0599]: no function or associated item named `size_with` found for array `[u16; 40]` in the current scope
    --> /home/emz/.cargo/git/checkouts/rust-minidump-836c4af26fbfd1e5/4d95707/minidump-common/src/format.rs:1322:32
     |
1322 |           #[derive(Clone, Pread, SizeWith)]
     |                                  ^^^^^^^^ function or associated item not found in `[u16; 40]`
...
1331 | / multi_structs! {
1332 | |     /// Miscellaneous process information
1333 | |     ///
1334 | |     /// This struct matches the [Microsoft struct][msdn] of the same name.
...    |
1376 | |     }
1377 | | }
     | |_- in this macro invocation
     |
     = note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info)

error: aborting due to 4 previous errors

Some errors have detailed explanations: E0277, E0599.
For more information about an error, try `rustc --explain E0277`.
error: could not compile `minidump-common`

To learn more, run the command again with --verbose.
warning: build failed, waiting for other jobs to finish...
error: build failed
error: Setup script exited with 101

Possible Solution

Rollback to 20.8.0.

Upstreams disconnects after 1 min. Is this expected?

I've had an on-premises Sentry version 9 for several years. Two weeks ago I found the time to update to Sentry 20. I took a look at your onpremise configuration and I figure a way to deploy in our server.

I've noticed relay disconnects to the upstream web server each minute:

2020-12-07T21:57:07Z [relay_server::actors::upstream] INFO: registering with upstream (http://web.sentry.svc:9190/)
2020-12-07T21:57:07Z [relay_server::actors::upstream] ERROR: authentication encountered error: could not send request to upstream
  caused by: IO error: Connection reset by peer (os error 104)
  caused by: IO error: Connection reset by peer (os error 104)
  caused by: IO error: Connection reset by peer (os error 104)
  caused by: Connection reset by peer (os error 104)
2020-12-07T21:58:07Z [relay_server::actors::upstream] INFO: registering with upstream (http://web.sentry.svc:9190/)
2020-12-07T21:58:07Z [relay_server::actors::upstream] ERROR: authentication encountered error: could not send request to upstream
  caused by: IO error: Connection reset by peer (os error 104)
  caused by: IO error: Connection reset by peer (os error 104)
  caused by: IO error: Connection reset by peer (os error 104)
  caused by: Connection reset by peer (os error 104)
2020-12-07T21:59:07Z [relay_server::actors::upstream] INFO: registering with upstream (http://web.sentry.svc:9190/)
2020-12-07T21:59:07Z [relay_server::actors::upstream] ERROR: authentication encountered error: could not send request to upstream
  caused by: IO error: Connection reset by peer (os error 104)
  caused by: IO error: Connection reset by peer (os error 104)
  caused by: IO error: Connection reset by peer (os error 104)
  caused by: Connection reset by peer (os error 104)

I think this is caused by a Keep-Alive header somewhere. Can I increase it? Is there a more efficient protocol to connect relay to the upstream web?

Issue authenticating to on-premise instance

I have configured my on-premise instance to allow the relay public key, but am seeing this when attempting to run:

INFO semaphore_trove::auth > sending register challenge response
INFO semaphore_trove::types > changing auth state: RegisterRequestChallenge -> RegisterChallengeResponse
ERROR semaphore_trove::auth > failed to register relay with upstream: bad request (401 Unauthorized; Challenge expired)
INFO semaphore_trove::auth > scheduling authentication retry

The failure happens instantly.

Issue in building Semaphore for ARM64v8

Using Semaphore for sentry on arm64 architecture.

I have compiled semaphore source code and I get the below mentioned error:

   Compiling actix-web v0.6.14
   Compiling rust_sodium-sys v0.9.0
error: linking with `cc` failed: exit code: 1

  = note: /root/akhil/docker/P2.1/sentry/source/getsentry/semaphore/target/release/deps/libreqwest-b05c504e4ed0ed3b.rlib(reqwest-b05c504e4ed0ed3b.reqwest0-8226a1210ec8692065299e925a223007.rs.rcgu.o): In function `openssl::ssl::bio::state::hbda11b79d18404b0':
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/bio.rs:71: undefined reference to `BIO_get_data'
          /root/akhil/docker/P2.1/sentry/source/getsentry/semaphore/target/release/deps/libreqwest-b05c504e4ed0ed3b.rlib(reqwest-b05c504e4ed0ed3b.reqwest1-8226a1210ec8692065299e925a223007.rs.rcgu.o): In function `openssl::ssl::bio::new::h0aaf7d7006c29f9d':
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/bio.rs:44: undefined reference to `BIO_set_data'
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/bio.rs:45: undefined reference to `BIO_set_init'
          /root/akhil/docker/P2.1/sentry/source/getsentry/semaphore/target/release/deps/libreqwest-b05c504e4ed0ed3b.rlib(reqwest-b05c504e4ed0ed3b.reqwest1-8226a1210ec8692065299e925a223007.rs.rcgu.o): In function `openssl::ssl::bio::new::h9c5a491eee2b7c2e':
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/bio.rs:44: undefined reference to `BIO_set_data'
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/bio.rs:45: undefined reference to `BIO_set_init'
          /root/akhil/docker/P2.1/sentry/source/getsentry/semaphore/target/release/deps/libreqwest-b05c504e4ed0ed3b.rlib(reqwest-b05c504e4ed0ed3b.reqwest1-8226a1210ec8692065299e925a223007.rs.rcgu.o): In function `openssl::ssl::bio::state::hbda11b79d18404b0':
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/bio.rs:71: undefined reference to `BIO_get_data'
          /root/akhil/docker/P2.1/sentry/source/getsentry/semaphore/target/release/deps/libreqwest-b05c504e4ed0ed3b.rlib(reqwest-b05c504e4ed0ed3b.reqwest1-8226a1210ec8692065299e925a223007.rs.rcgu.o): In function `openssl::ssl::bio::state::hb20d3dc2490d5c09':
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/bio.rs:71: undefined reference to `BIO_get_data'
          /root/akhil/docker/P2.1/sentry/source/getsentry/semaphore/target/release/deps/libreqwest-b05c504e4ed0ed3b.rlib(reqwest-b05c504e4ed0ed3b.reqwest1-8226a1210ec8692065299e925a223007.rs.rcgu.o): In function `openssl::ssl::bio::state::hbda11b79d18404b0':
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/bio.rs:71: undefined reference to `BIO_get_data'
          /root/akhil/docker/P2.1/sentry/source/getsentry/semaphore/target/release/deps/libreqwest-b05c504e4ed0ed3b.rlib(reqwest-b05c504e4ed0ed3b.reqwest1-8226a1210ec8692065299e925a223007.rs.rcgu.o): In function `openssl::ssl::bio::state::hb20d3dc2490d5c09':
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/bio.rs:71: undefined reference to `BIO_get_data'
          /root/akhil/docker/P2.1/sentry/source/getsentry/semaphore/target/release/deps/libreqwest-b05c504e4ed0ed3b.rlib(reqwest-b05c504e4ed0ed3b.reqwest1-8226a1210ec8692065299e925a223007.rs.rcgu.o): In function `openssl::ssl::bio::state::hbda11b79d18404b0':
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/bio.rs:71: undefined reference to `BIO_get_data'
          /root/akhil/docker/P2.1/sentry/source/getsentry/semaphore/target/release/deps/libreqwest-b05c504e4ed0ed3b.rlib(reqwest-b05c504e4ed0ed3b.reqwest1-8226a1210ec8692065299e925a223007.rs.rcgu.o):/root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/bio.rs:71: more undefined references to `BIO_get_data' follow
          /root/akhil/docker/P2.1/sentry/source/getsentry/semaphore/target/release/deps/libreqwest-b05c504e4ed0ed3b.rlib(reqwest-b05c504e4ed0ed3b.reqwest1-8226a1210ec8692065299e925a223007.rs.rcgu.o): In function `openssl::ssl::bio::destroy::h880fcd29fa74580d':
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/bio.rs:171: undefined reference to `BIO_set_data'
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/bio.rs:172: undefined reference to `BIO_set_init'
          /root/akhil/docker/P2.1/sentry/source/getsentry/semaphore/target/release/deps/libreqwest-b05c504e4ed0ed3b.rlib(reqwest-b05c504e4ed0ed3b.reqwest1-8226a1210ec8692065299e925a223007.rs.rcgu.o): In function `openssl::ssl::bio::destroy::hb78208420b24f42b':
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/bio.rs:168: undefined reference to `BIO_get_data'
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/bio.rs:171: undefined reference to `BIO_set_data'
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/bio.rs:172: undefined reference to `BIO_set_init'
          /root/akhil/docker/P2.1/sentry/source/getsentry/semaphore/target/release/deps/libreqwest-b05c504e4ed0ed3b.rlib(reqwest-b05c504e4ed0ed3b.reqwest13-8226a1210ec8692065299e925a223007.rs.rcgu.o): In function `openssl::ssl::bio::compat::BIO_METHOD::new::ha0000e5e50cce4ca':
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/bio.rs:192: undefined reference to `BIO_meth_new'
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/bio.rs:195: undefined reference to `BIO_meth_set_write'
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/bio.rs:196: undefined reference to `BIO_meth_set_read'
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/bio.rs:197: undefined reference to `BIO_meth_set_puts'
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/bio.rs:198: undefined reference to `BIO_meth_set_ctrl'
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/bio.rs:199: undefined reference to `BIO_meth_set_create'
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/bio.rs:200: undefined reference to `BIO_meth_set_destroy'
          /root/akhil/docker/P2.1/sentry/source/getsentry/semaphore/target/release/deps/libreqwest-b05c504e4ed0ed3b.rlib(reqwest-b05c504e4ed0ed3b.reqwest13-8226a1210ec8692065299e925a223007.rs.rcgu.o): In function `openssl::ssl::bio::compat::BIO_METHOD::new::heba60411e2adf363':
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/bio.rs:192: undefined reference to `BIO_meth_new'
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/bio.rs:195: undefined reference to `BIO_meth_set_write'
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/bio.rs:196: undefined reference to `BIO_meth_set_read'
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/bio.rs:197: undefined reference to `BIO_meth_set_puts'
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/bio.rs:198: undefined reference to `BIO_meth_set_ctrl'
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/bio.rs:199: undefined reference to `BIO_meth_set_create'
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/bio.rs:200: undefined reference to `BIO_meth_set_destroy'
          /root/akhil/docker/P2.1/sentry/source/getsentry/semaphore/target/release/deps/libreqwest-b05c504e4ed0ed3b.rlib(reqwest-b05c504e4ed0ed3b.reqwest2-8226a1210ec8692065299e925a223007.rs.rcgu.o): In function `openssl::ssl::bio::state::hb20d3dc2490d5c09':
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/bio.rs:71: undefined reference to `BIO_get_data'
          /root/akhil/docker/P2.1/sentry/source/getsentry/semaphore/target/release/deps/libreqwest-b05c504e4ed0ed3b.rlib(reqwest-b05c504e4ed0ed3b.reqwest2-8226a1210ec8692065299e925a223007.rs.rcgu.o): In function `openssl::ssl::bio::state::hbda11b79d18404b0':
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/bio.rs:71: undefined reference to `BIO_get_data'
          /root/akhil/docker/P2.1/sentry/source/getsentry/semaphore/target/release/deps/libreqwest-b05c504e4ed0ed3b.rlib(reqwest-b05c504e4ed0ed3b.reqwest4-8226a1210ec8692065299e925a223007.rs.rcgu.o): In function `openssl::ssl::bio::state::hbda11b79d18404b0':
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/bio.rs:71: undefined reference to `BIO_get_data'
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/bio.rs:71: undefined reference to `BIO_get_data'
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/bio.rs:71: undefined reference to `BIO_get_data'
          /root/akhil/docker/P2.1/sentry/source/getsentry/semaphore/target/release/deps/libreqwest-b05c504e4ed0ed3b.rlib(reqwest-b05c504e4ed0ed3b.reqwest4-8226a1210ec8692065299e925a223007.rs.rcgu.o):/root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/bio.rs:71: more undefined references to `BIO_get_data' follow
          /root/akhil/docker/P2.1/sentry/source/getsentry/semaphore/target/release/deps/libopenssl-5a20bbe400ebbd32.rlib(openssl-5a20bbe400ebbd32.openssl0-fc5e1889476dc5e88449128f972d0910.rs.rcgu.o): In function `openssl::ssl::compat::tls_method::h732b00128d0b3cd7':
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/mod.rs:2473: undefined reference to `TLS_method'
          /root/akhil/docker/P2.1/sentry/source/getsentry/semaphore/target/release/deps/libopenssl-5a20bbe400ebbd32.rlib(openssl-5a20bbe400ebbd32.openssl0-fc5e1889476dc5e88449128f972d0910.rs.rcgu.o): In function `_$LT$openssl..ssl..SslContext$u20$as$u20$core..clone..Clone$GT$::clone::h3572e3cc8f2b9498':
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/mod.rs:1146: undefined reference to `SSL_CTX_up_ref'
          /root/akhil/docker/P2.1/sentry/source/getsentry/semaphore/target/release/deps/libopenssl-5a20bbe400ebbd32.rlib(openssl-5a20bbe400ebbd32.openssl3-fc5e1889476dc5e88449128f972d0910.rs.rcgu.o): In function `openssl::ssl::bio::create::hce7189a2bf8ba4ce':
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/bio.rs:156: undefined reference to `BIO_set_init'
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/bio.rs:158: undefined reference to `BIO_set_data'
          /root/akhil/docker/P2.1/sentry/source/getsentry/semaphore/target/release/deps/libopenssl-5a20bbe400ebbd32.rlib(openssl-5a20bbe400ebbd32.openssl3-fc5e1889476dc5e88449128f972d0910.rs.rcgu.o): In function `_$LT$openssl..ssl..bio..compat..BIO_METHOD$u20$as$u20$core..ops..drop..Drop$GT$::drop::ha700af2e75ca49f7':
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/bio.rs:213: undefined reference to `BIO_meth_free'
          /root/akhil/docker/P2.1/sentry/source/getsentry/semaphore/target/release/deps/libopenssl-5a20bbe400ebbd32.rlib(openssl-5a20bbe400ebbd32.openssl4-fc5e1889476dc5e88449128f972d0910.rs.rcgu.o): In function `openssl::ssl::SslContextBuilder::set_options::h2a0db6968b621a77':
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/ssl/mod.rs:904: undefined reference to `SSL_CTX_set_options'
          /root/akhil/docker/P2.1/sentry/source/getsentry/semaphore/target/release/deps/libopenssl-5a20bbe400ebbd32.rlib(openssl-5a20bbe400ebbd32.openssl4-fc5e1889476dc5e88449128f972d0910.rs.rcgu.o): In function `openssl::version::number::h0dd66467de6847ea':
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/src/version.rs:51: undefined reference to `OpenSSL_version_num'
          /root/akhil/docker/P2.1/sentry/source/getsentry/semaphore/target/release/deps/libopenssl_sys-367c358ce1b80630.rlib(openssl_sys-367c358ce1b80630.openssl_sys1-6ce8876ebfe6b5bfa953b5dd7be168a.rs.rcgu.o): In function `openssl_sys::openssl::v110::init::_$u7b$$u7b$closure$u7d$$u7d$::h2a9a27d7fc917b1e':
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-sys-0.9.33/src/openssl/v110.rs:83: undefined reference to `OPENSSL_init_ssl'
          /root/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-sys-0.9.33/src/openssl/v110.rs:83: undefined reference to `OPENSSL_init_ssl'
          /usr/bin/ld: /root/akhil/docker/P2.1/sentry/source/getsentry/semaphore/target/release/deps/libtokio_core-48c5ddb6fd9651c6.rlib(tokio_core-48c5ddb6fd9651c6.tokio_core8-91bc70d1e1d4919a8681d0997e6fda96.rs.rcgu.o)(.debug_info+0xe5): R_AARCH64_ABS64 used with TLS symbol _ZN10tokio_core7reactor12CURRENT_LOOP3FOO7__getit5__KEY17hc2432e342ce3f38cE
          /usr/bin/ld: /root/akhil/docker/P2.1/sentry/source/getsentry/semaphore/target/release/deps/libtokio-6e561a07f47dcf2d.rlib(tokio-6e561a07f47dcf2d.tokio15-c5f1849f041a33588a5ba832c161870e.rs.rcgu.o)(.debug_info+0x180): R_AARCH64_ABS64 used with TLS symbol _ZN5tokio8executor14current_thread7CURRENT7__getit5__KEY17hbe4963f89fc492cbE
          /usr/bin/ld: /root/akhil/docker/P2.1/sentry/source/getsentry/semaphore/target/release/deps/libtokio_timer-686b0412979aa2c2.rlib(tokio_timer-686b0412979aa2c2.tokio_timer15-363602c6b3b4fc2fee6fa89f8fcc97e.rs.rcgu.o)(.debug_info+0x1709): R_AARCH64_ABS64 used with TLS symbol _ZN11tokio_timer5timer6handle13CURRENT_TIMER7__getit5__KEY17h5a9d45a896989c1eE
          /usr/bin/ld: /root/akhil/docker/P2.1/sentry/source/getsentry/semaphore/target/release/deps/libtokio_timer-686b0412979aa2c2.rlib(tokio_timer-686b0412979aa2c2.tokio_timer15-363602c6b3b4fc2fee6fa89f8fcc97e.rs.rcgu.o)(.debug_info+0x1f61): R_AARCH64_ABS64 used with TLS symbol _ZN11tokio_timer5clock5clock5CLOCK7__getit5__KEY17hfb74ba7b35d307e5E
          /usr/bin/ld: /root/akhil/docker/P2.1/sentry/source/getsentry/semaphore/target/release/deps/libtokio_reactor-29df94c7f9c2329d.rlib(tokio_reactor-29df94c7f9c2329d.tokio_reactor0-e4bdb21a32741d34d5d655df0849f661.rs.rcgu.o)(.debug_info+0x61): R_AARCH64_ABS64 used with TLS symbol _ZN13tokio_reactor15CURRENT_REACTOR7__getit5__KEY17hf746cb0edd76d6ecE
          /usr/bin/ld: /root/akhil/docker/P2.1/sentry/source/getsentry/semaphore/target/release/deps/libtokio_threadpool-56805c5c437bb7a4.rlib(tokio_threadpool-56805c5c437bb7a4.tokio_threadpool0-cbf5f6497a5022c86c96535788b77a7d.rs.rcgu.o)(.debug_info+0x136): R_AARCH64_ABS64 used with TLS symbol _ZN16tokio_threadpool6worker14CURRENT_WORKER7__getit5__KEY17h12b26eb5c0c50bd7E
          /usr/bin/ld: /root/akhil/docker/P2.1/sentry/source/getsentry/semaphore/target/release/deps/libtokio_threadpool-56805c5c437bb7a4.rlib(tokio_threadpool-56805c5c437bb7a4.tokio_threadpool1-cbf5f6497a5022c86c96535788b77a7d.rs.rcgu.o)(.debug_info+0xe9): R_AARCH64_ABS64 used with TLS symbol _ZN16tokio_threadpool4pool4Pool10rand_usize14THREAD_RNG_KEY7__getit5__KEY17h9a1c18c82d20c480E
          /usr/bin/ld: /root/akhil/docker/P2.1/sentry/source/getsentry/semaphore/target/release/deps/libcrossbeam_epoch-11ff75e020ec649c.rlib(crossbeam_epoch-11ff75e020ec649c.crossbeam_epoch9-474807f860afed557668bc464922d861.rs.rcgu.o)(.debug_info+0x1f2): R_AARCH64_ABS64 used with TLS symbol _ZN15crossbeam_epoch7default6HANDLE7__getit5__KEY17h1b829b6bbb7060fdE
          /usr/bin/ld: /root/akhil/docker/P2.1/sentry/source/getsentry/semaphore/target/release/deps/libtokio_executor-68b057b04da6c57d.rlib(tokio_executor-68b057b04da6c57d.tokio_executor1-a11658ce7e77cf2172ef6eabd88c5d9d.rs.rcgu.o)(.debug_info+0x1a2e): R_AARCH64_ABS64 used with TLS symbol _ZN14tokio_executor4park19CURRENT_PARK_THREAD7__getit5__KEY17h1483744d681bd718E
          /usr/bin/ld: /root/akhil/docker/P2.1/sentry/source/getsentry/semaphore/target/release/deps/libtokio_executor-68b057b04da6c57d.rlib(tokio_executor-68b057b04da6c57d.tokio_executor13-a11658ce7e77cf2172ef6eabd88c5d9d.rs.rcgu.o)(.debug_info+0x4b): R_AARCH64_ABS64 used with TLS symbol _ZN14tokio_executor5enter7ENTERED7__getit5__KEY17ha2175dff02681b54E
          /usr/bin/ld: /root/akhil/docker/P2.1/sentry/source/getsentry/semaphore/target/release/deps/libtokio_executor-68b057b04da6c57d.rlib(tokio_executor-68b057b04da6c57d.tokio_executor14-a11658ce7e77cf2172ef6eabd88c5d9d.rs.rcgu.o)(.debug_info+0x5a3): R_AARCH64_ABS64 used with TLS symbol _ZN14tokio_executor6global8EXECUTOR7__getit5__KEY17hbafe94470e564e8cE
          /usr/bin/ld: /root/akhil/docker/P2.1/sentry/source/getsentry/semaphore/target/release/deps/libfutures-fa7d06cfcde58745.rlib(futures-fa7d06cfcde58745.futures1-cdab8173d348bbb039ae7e79765e65f.rs.rcgu.o)(.debug_info+0x6b): R_AARCH64_ABS64 used with TLS symbol _ZN7futures9task_impl3std12CURRENT_TASK7__getit5__KEY17hd9dae09453f7589fE
          /usr/bin/ld: /root/akhil/docker/P2.1/sentry/source/getsentry/semaphore/target/release/deps/libfutures-fa7d06cfcde58745.rlib(futures-fa7d06cfcde58745.futures1-cdab8173d348bbb039ae7e79765e65f.rs.rcgu.o)(.debug_info+0xcc): R_AARCH64_ABS64 used with TLS symbol _ZN7futures9task_impl3std21CURRENT_THREAD_NOTIFY7__getit5__KEY17had4c817af69c15d9E
          /usr/bin/ld: /root/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libstd-940fd77e0801f3c0.rlib(std-940fd77e0801f3c0.std11-321f92f8d7f958c4bcf109678299b1ca.rs.rcgu.o)(.debug_info+0x240f): R_AARCH64_ABS64 used with TLS symbol _ZN3std9panicking12LOCAL_STDERR7__getit5__KEY17hbb01bcd9172f3300E
          /usr/bin/ld: /root/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libstd-940fd77e0801f3c0.rlib(std-940fd77e0801f3c0.std11-321f92f8d7f958c4bcf109678299b1ca.rs.rcgu.o)(.debug_info+0x252b): R_AARCH64_ABS64 used with TLS symbol _ZN3std9panicking18update_panic_count11PANIC_COUNT7__getit5__KEY17hc4a80ec0fce233c1E
          /usr/bin/ld: /root/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libstd-940fd77e0801f3c0.rlib(std-940fd77e0801f3c0.std2-321f92f8d7f958c4bcf109678299b1ca.rs.rcgu.o)(.debug_info+0x60): R_AARCH64_ABS64 used with TLS symbol _ZN3std11collections4hash3map11RandomState3new4KEYS7__getit5__KEY17hfd3f05b7105903d1E
          /usr/bin/ld: /root/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libstd-940fd77e0801f3c0.rlib(std-940fd77e0801f3c0.std4-321f92f8d7f958c4bcf109678299b1ca.rs.rcgu.o)(.debug_info+0x340): R_AARCH64_ABS64 used with TLS symbol _ZN3std2io5stdio12LOCAL_STDOUT7__getit5__KEY17h72741308119425f3E
          /usr/bin/ld: /root/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libstd-940fd77e0801f3c0.rlib(std-940fd77e0801f3c0.std7-321f92f8d7f958c4bcf109678299b1ca.rs.rcgu.o)(.debug_info+0x108b): R_AARCH64_ABS64 used with TLS symbol _ZN3std10sys_common11thread_info11THREAD_INFO7__getit5__KEY17h312e03d88654214dE
          collect2: error: ld returned 1 exit status


error: Could not compile `rust_sodium-sys`.
warning: build failed, waiting for other jobs to finish...
error: build failed

Please guide, what is missing at my end to achieve sucessfull build.

Change DSN Api

The DSN type should not use url nomenclature but what we have for dsns:

Proposed changes:

  • Dsn::scheme -> return an enum Scheme with Http or Https.
  • Dsn::username -> Dsn::public_key
  • Dsn::password -> Dsn::secret_key
  • Dsn::path -> Dsn::project_id

Add metric reporting

We need basic metric reporting for the relay. So far this will only be for ops so it will be some operational metrics and not yet for driving the relay throughput.

Default PII config

I'd like to use semaphore in proxy mode. Thus I do not create a project.json file per project. Unfortunately, according to the documentation at least, the pii can only be set in the project.json file.

It would be nice if the global settings could be changed. In our case, we'd like to track the e-mail and ip addresses.

WDYT?

Thanks!

upstream request returned error 401 Unauthorized

This is probably a user issue, I just don't know enough about how semaphore works and the doc is a little sparse since it's not stable yet.

As I understand it, semaphore will not use any credentials when relaying to https://sentry.io and instead just use the public key in the DSN the same way the SDK does. Thus, I just used the default configuration.

semaphore config init

This creates a key pair but I have no clue what for. When I then try to run semaphore I get a 401 error:

authentication encountered error: upstream request returned error 401 Unauthorized

Full output
global filter: INFO true
 INFO  semaphore::setup > launching relay from config folder /Users/ilijatovilo/Downloads/semaphore-test/.semaphore
 INFO  semaphore::setup >   relay mode: managed
 INFO  semaphore::setup >   relay id: xyz
 INFO  semaphore::setup >   public key: xyz
 INFO  semaphore::setup >   log level: INFO
 INFO  semaphore_server::actors::events > starting 8 event processing workers
 INFO  semaphore_server::service        > spawning http server
 INFO  semaphore_server::service        >   listening on: http://127.0.0.1:3000/
 INFO  actix_net::server::server        > Starting 8 workers
 INFO  actix_net::server::server        > Starting server on 127.0.0.1:3000
 INFO  semaphore_server::actors::controller > relay server starting
 INFO  semaphore_server::actors::upstream   > upstream relay started
 INFO  semaphore_server::actors::upstream   > registering with upstream (https://sentry.io/)
 INFO  semaphore_server::actors::events     > event manager started
 INFO  semaphore_server::actors::keys       > key cache started
 INFO  semaphore_server::actors::project    > project cache started
 INFO  trust_dns_proto::xfer::dns_exchange  > sending message via: UDP(192.168.100.19:53)
 ERROR semaphore_server::actors::upstream   > authentication encountered error: upstream request returned error 401 Unauthorized
 INFO  semaphore_server::actors::upstream   > registering with upstream (https://sentry.io/)
 ERROR semaphore_server::actors::upstream   > authentication encountered error: upstream request returned error 401 Unauthorized
 INFO  semaphore_server::actors::upstream   > registering with upstream (https://sentry.io/)
 ERROR semaphore_server::actors::upstream   > authentication encountered error: upstream request returned error 401 Unauthorized
 INFO  semaphore_server::actors::upstream   > registering with upstream (https://sentry.io/)
 ERROR semaphore_server::actors::upstream   > authentication encountered error: upstream request returned error 401 Unauthorized
 INFO  semaphore_server::actors::upstream   > registering with upstream (https://sentry.io/)
 ERROR semaphore_server::actors::upstream   > authentication encountered error: upstream request returned error 401 Unauthorized
^C INFO  semaphore_server::actors::controller > SIGINT received, exiting
 INFO  actix_net::server::worker            > Shutting down worker, 0 connections
 INFO  actix_net::server::worker            > Shutting down worker, 0 connections
 INFO  actix_net::server::worker            > Shutting down worker, 0 connections
 INFO  actix_net::server::worker            > Shutting down worker, 0 connections
 INFO  actix_net::server::worker            > Shutting down worker, 0 connections
 INFO  actix_net::server::worker            > Shutting down worker, 0 connections
 INFO  actix_net::server::worker            > Shutting down worker, 0 connections
 INFO  actix_net::server::worker            > Shutting down worker, 0 connections
 INFO  semaphore_server::actors::controller > relay shutdown complete

What am I doing wrong? Do I need to register the public key somewhere on https://sentry.io?

Thank you for your help!

cannot build 0.4.x for setting up on premises for Sentry

Env:
git version 2.25.2
Python 3.7.7
rustc 1.43.1
cargo 1.43.0

Well, like it's said in the subject, here it is (neither 0.4.65 or 0.4.63 can be built)

[root@dev:src/relay]# git clone --recursive https://github.com/getsentry/relay.git relay
Cloning into 'relay'...
remote: Enumerating objects: 142, done.
remote: Counting objects: 100% (142/142), done.
remote: Compressing objects: 100% (103/103), done.
remote: Total 15862 (delta 67), reused 85 (delta 39), pack-reused 15720
Receiving objects: 100% (15862/15862), 7.66 MiB | 3.94 MiB/s, done.
Resolving deltas: 100% (10967/10967), done.
Submodule 'general/uap-core' (https://github.com/ua-parser/uap-core.git) registered for path 'relay-general/uap-core'
Cloning into '/usr/home/emz/src/relay/relay/relay-general/uap-core'...
remote: Enumerating objects: 4976, done.        
remote: Total 4976 (delta 0), reused 0 (delta 0), pack-reused 4976        
Receiving objects: 100% (4976/4976), 4.99 MiB | 3.12 MiB/s, done.
Resolving deltas: 100% (3158/3158), done.
Submodule path 'relay-general/uap-core': checked out 'ec8322ffe14f94d88131cec550705f392085a519'
[root@dev:src/relay]# 
[root@dev:relay/relay]# git checkout 0.4.65                                               
warning: unable to rmdir 'relay-general/uap-core': Directory not empty
Note: switching to '0.4.65'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at 0545005 release: 0.4.65
[root@dev:relay/relay]# cargo run --all-features -- init                                  
    Updating git repository `https://github.com/mitsuhiko/redis-rs`
error: failed to get `redis` as a dependency of package `semaphore-server v0.4.65 (/usr/home/emz/src/relay/relay/server)`

Caused by:
  failed to load source for dependency `redis`

Caused by:
  Unable to update https://github.com/mitsuhiko/redis-rs?branch=feature/cluster#ee8d309c

Caused by:
  revspec 'ee8d309cc71847cad81cd16c10426c5073dc3a2e' not found; class=Reference (4); code=NotFound (-3)
[root@dev:relay/relay]# cargo check --all --all-features
    Updating git repository `https://github.com/mitsuhiko/redis-rs`
error: failed to get `redis` as a dependency of package `semaphore-server v0.4.65 (/usr/home/emz/src/relay/relay/server)`

Caused by:
  failed to load source for dependency `redis`

Caused by:
  Unable to update https://github.com/mitsuhiko/redis-rs?branch=feature/cluster#ee8d309c

Caused by:
  revspec 'ee8d309cc71847cad81cd16c10426c5073dc3a2e' not found; class=Reference (4); code=NotFound (-3)
[root@dev:relay/relay]# git checkout 0.4.63                                               
Previous HEAD position was 0545005 release: 0.4.65
HEAD is now at 46a9eaa release: 0.4.63
[root@dev:relay/relay]# cargo check --all --all-features
    Updating git repository `https://github.com/fede1024/rust-rdkafka`
    Updating git repository `https://github.com/mitsuhiko/redis-rs`
error: failed to get `redis` as a dependency of package `semaphore-server v0.4.63 (/usr/home/emz/src/relay/relay/server)`

Caused by:
  failed to load source for dependency `redis`

Caused by:
  Unable to update https://github.com/mitsuhiko/redis-rs?branch=feature/cluster#5d2f66de

Caused by:
  revspec '5d2f66debfaf66a945d72646b5d542fd94aa5c40' not found; class=Reference (4); code=NotFound (-3)
[root@dev:relay/relay]#

Sanitation should happen before truncation

Summary

Currently, sentry tries to strip sensitive data after the server has already truncated it, leaving some truncated sensitive data not stripped.

Motivation

I rely a lot on server side filtering of sensitive data. However, there are times when sensitive data that are initially stripped are suddenly not stripped because the value became too large and some parts got truncated. The best example would be an RSA key in a dict in Python.

Say for example, I have this in a variable:

{
  "data": "some_value",
  "private_key": "-----BEGIN PRIVATE KEY-----<The private key>-----END PRIVATE KEY-----"
}

Sentry is able to clean the private_key, resulting to:

{
  "data": "some_value",
  "private_key": "-----BEGIN PRIVATE KEY-----[Filtered]-----END PRIVATE KEY-----"
}

However, if the dict gets big enough, like:

{
  "data": "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.",
  "private_key": "-----BEGIN PRIVATE KEY-----<The private key>-----END PRIVATE KEY-----"
}

When I send that to sentry, sentry stores this instead:

{
  "data": "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.",
  "private_key": "-----BEGIN PRIVATE KEY-----<The private key>-----END PRIVATE..."
}

And so, the private_key is not stripped anymore, because the identifier -----END PRIVATE KEY----- has been truncated to -----END PRIVATE...

Sentry is not skipping dummy minidump from Unreal Linux

Important Details

How are you running Sentry?

  • On-Premise docker [Version 9.1.2]
  • Saas (sentry.io)
  • Other [briefly describe your environment]

Description

Sentry is not skipping dummy minidump from Unreal Linux [Server] and not producing any meaningful error log message. On Unreal side there is no error message either as Unreal ignores error reply from the Sentry. However, the report is sane in all other cases except the minidump and could possibly be accepted.

Steps to Reproduce

  1. Run Sentry 9.1.2.
  2. Build Linux (Server in our case) with something that causes a crash and correct Sentry DSN.
  3. Run the Server and watch it crashed.

The problem is that Linux reporter in Unreal doesn't support minidumps and uses dummy minidump with 0xDEADBEEF stub inside: https://github.com/EpicGames/UnrealEngine/blob/bf95c2cbc703123e08ab54e3ceccdd47e48d224a/Engine/Source/Runtime/Core/Private/Unix/UnixPlatformCrashContext.cpp#L272

and
https://github.com/EpicGames/UnrealEngine/blob/bf95c2cbc703123e08ab54e3ceccdd47e48d224a/Engine/Source/Runtime/Core/Private/Unix/UnixPlatformCrashContext.cpp#L473

What you expected to happen

Unreal Linux report should be accepted without minidump. Dummy minidump should be skipped.

Possible Solution

In our code we have just commented out the exception, obviously, there should be a better solution:

sentry/web/api.py

# Endpoint used by the Unreal Engine 4 (UE4) Crash Reporter.
class UnrealView(StoreView):
    content_types = ('application/octet-stream', )

    def _dispatch(self, request, helper, sentry_key, project_id=None, origin=None, *args, **kwargs):
        if request.method != 'POST':
            return HttpResponseNotAllowed(['POST'])

        content_type = request.META.get('CONTENT_TYPE')
        if content_type is None or not content_type.startswith(self.content_types):
            raise APIError('Invalid Content-Type')

        request.user = AnonymousUser()

        project = self._get_project_from_id(project_id)
        helper.context.bind_project(project)

        auth = Auth({'sentry_key': sentry_key}, is_public=False)
        auth.client = 'sentry.unreal_engine'

        key = helper.project_key_from_auth(auth)
        if key.project_id != project.id:
            raise APIError('Two different projects were specified')

        helper.context.bind_auth(auth)
        return super(APIView, self).dispatch(
            request=request, project=project, auth=auth, helper=helper, key=key, **kwargs
        )

    def post(self, request, project, **kwargs):
        attachments_enabled = features.has('organizations:event-attachments',
                                           project.organization, actor=request.user)

        attachments = []
        event = {'event_id': uuid.uuid4().hex}
        try:
            unreal = process_unreal_crash(request.body, request.GET.get(
                'UserID'), request.GET.get('AppEnvironment'), event)
            process_state = unreal.process_minidump()
            if process_state:
                merge_process_state_event(event, process_state)
            else:
                apple_crash_report = unreal.get_apple_crash_report()
                if apple_crash_report:
                    merge_apple_crash_report(apple_crash_report, event)
#                else:
#                    raise APIError("missing minidump in unreal crash report")
        except (ProcessMinidumpError, Unreal4Error) as e:
            minidumps_logger.exception(e)
            raise APIError(e.message.split('\n', 1)[0])

Corresponding Dockerfile

FROM sentry:9.1.2
RUN sed -i '788,789{s/^/#/}' /usr/local/lib/python2.7/site-packages/sentry/web/api.py
WORKDIR /usr/src/sentry

Add documentation links to config file

In his great post on Sentry 10, Thomas Wunderlich mentions:

There are two sets of documentation that are useful to read, the first is the operating guidelines: https://docs.sentry.io/product/relay/operating-guidelines/,the second is the full list of config options https://docs.sentry.io/product/relay/options/. These pages are so useful that I normally add the following comment to the top of the config file:

# Please see the relevant documentation:
# Performance Tuning: https://docs.sentry.io/product/relay/operating-guidelines/
# All config options: https://docs.sentry.io/product/relay/options/

This is something our config generator in relay config init can and should do.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.