This repository was archived by the owner on Oct 23, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Oct 23, 2023. It is now read-only.
Invalid Sentry DSN when using a public key #569
Description
Hi,
Perhaps i do't correctly understand the notion of public DSN. When I try to use Sentry with public I got this exception:
self._client = raven.Client(CrashReport.DSN, release=__version__)
File "/site-packages/raven/base.py", line 139, in __init__
self.set_dsn(dsn, **options)
File "site-packages/raven/base.py", line 195, in set_dsn
dsn_config = raven.load(dsn, transport_registry=self._registry)
File "site-packages/raven/conf/__init__.py", line 54, in load
scope_extras = transport_registry.compute_scope(url, scope)
File "site-packages/raven/transport/registry.py", line 73, in compute_scope
return transport.compute_scope(url, scope)
File "python3.4/site-packages/raven/transport/base.py", line 57, in compute_scope
raise ValueError('Invalid Sentry DSN: %r' % url.geturl())
ValueError: Invalid Sentry DSN: 'https://aaaaaaaaaaaaaaaaa@app.getsentry.com/38482'
- Is it an issue?
- Can we distribute a desktop application including sentry private key without security issue (i don't understand what are the exact access level of an API key)?
Thanks for the help
Reacted by Alex Rothberg and Ermolay Romanov
Activity
dcramer commentedon Feb 24, 2015
Unless you're a browser-based implementation you should use the full DSN.
The security implication is only that someone can send events on your behalf, which your only resolve is to revoke the API key and ship a new one. There's no other access given by default with client keys.
jamesgorrie commentedon Mar 21, 2017
Not wanting to reopen this - but have a question:
Could we not implement similar auth that we have in client JS to the server / app implementations?
Our use case is having an open source application and we are trying our best not to have secret config anywhere.
dcramer commentedon Mar 21, 2017
There is no alternative that is secure. You just need to expose the secret and be willing to revoke it upon abuse.
aviddiviner commentedon Dec 4, 2017
@dcramer I'd like to clarify this statement:
Does this mean that events can be sent only to Sentry, or that the API key can be used to make Sentry send events to somewhere else?
Thanks for your time.
mattrobenolt commentedon Dec 4, 2017
It’s only for sending events into Sentry.
cancan101 commentedon Mar 20, 2018
I would also like to see the ability to use the public DSN with raven. I am deploying Python code to clients and would prefer to not have the full DSN in an untrusted environment. This would be conceptually the same as how I don't want the private DSN in the web bundle I send to users.
ermik commentedon Apr 27, 2018
@cancan101 I've been thinking about that myself! It seems that such scenario poses a question:
I feel that Sentry provides reasonable project/team/organization structure to allow shipping unique DSN to every consumer. May not be ideal, but this way you will see errors on per-customer, per-product basis.
cancan101 commentedon Apr 27, 2018
The issue with that is that I ship the same software / code to each so I want error reports to aggregate.
ermik commentedon Apr 27, 2018
@cancan101 and that's a feature request that would make sense. @mattrobenolt what do you think? This could be "subprojects" or "cross-project aggregation"?
cancan101 commentedon Apr 27, 2018
Is that really better than just allowing public dsn usage from python along with setting the username on the client context?
dcramer commentedon Apr 27, 2018
Heads up we are removing the secret key (its already in progress) from all SDKs. There's not enough security provided by it, and given the nature of us supporting non-server-to-server communication these days its just not worth it. As of the Sentry 9 release (currently on sentry.io) it is no longer required for any event reporting.
ermik commentedon Apr 27, 2018
If someone abuses the secret (whether it's the full DSN or the public version) — you have to revoke it. This will require all of the consumers to be updated. Common sense here, in terms of security, is that DSN must be disposable.
ermik commentedon Apr 27, 2018
@dcramer ok, can we get a blog post on that? I don't fully understand the reasoning and I am very interested in the subject.
dcramer commentedon Apr 27, 2018
@ermik it simply provides no additional security. You can have a DSN with only a public key, which is still very hard to brute force, and use that only for server-to-server communication. You can then generate a separate DSN to ship with client software, and as you mentioned, revoke when abused (or just block IPs using our tools).