34 comments

[ 2.9 ms ] story [ 97.6 ms ] thread
[flagged]
that is .. odd. Can someone please explain-like-I-am-five that the ** is going on in that forum?

huggingface links and expiring proxies get mentioned a lot

It's really hard to understand, I originally thought it was a spam link, heh.

It looks like you can somehow use Sourcegraphs "Cody" gateway to utilize Claude by Anthropic. I guess SG was rate limiting, and user HopeMan gained access to SGs admin systems and is asking people to drop their emails to get them un-rate-limited? Best I could make of the thread.

https://docs.sourcegraph.com/cody/explanations/cody_gateway

https://claude.ai/

(desuarchive seems to be a 4chan archive)

It's an archive of 4chans /g/ board. Many things are discussed, many insults are leveled.

Are you asking what desuarchive is or are you asking what 4chan is?

no - the transactions .. what are those lists of numbers being traded ? How are those valuable ? "What is going on in that forum?"

that chat environment seems to be both a cause and a result of ADHD-like existance! can I say "hellish" ?

It's an anonymous board. Those numbers are unique post ID's referenced by >>.

The thread IDs have 3 chevrons. If you wish to reply to someone, you click the "reply" button and a >>$ID is placed in the comment box.

Sourcegraph seems to have collected a bunch of these (now leaked) email addresses from signups on self-hosted instances.

I remember being very surprised when I was signed up to their mailing list after I made an account on my self-hosted instance, and I'm not sure about the ethics (and legality) of collecting these in the first place.

They need these email addresses so they can send you an automated welcome email that claims it is not automated and then ignore you when you reply.

At least that was my experience.

Hey, I run a lot of our customer outreach and experience. There is some nuance to what is / isn't automated.

When people sign up, their email is shared with our customer experience team (combo of inbound sales reps, customer engineers, and support depending on what information is shared), and then that assigned individual reaches out manually AND puts you into what is a called a 'nurture' campaign that provides helpful information, updates on Cody, etc. Those are automated unless you specifically request to talk with someone. If / when someone wants to talk to Sourcegraph, a member of our GTM team (sales / customer engineering) reaches out.

If you can provide me with your email (DM it) I can look into what happened with you and get you the help / support you need.

Otherwise, I think someone on our end just dropped the ball. Sorry about that! It happens when there is a human in the process and it isn't 100% automated. To your larger point, we agree that having a real human to interact with is important to a great experience.

Please let us know how we can help you try and use Cody!

Overall very well handled and communicated. To get 11 points out of 10 remove adjectives from communication. When people read “quickly” they don’t think “oh great they were quick, I’m going to trust them more now”, they think “communication is biased”. Just write facts (ie time stamps or if you don’t have them use “hours” or “same day”).
12 out of 10 for this very astute tip about any type of technical communication: "remove adjectives from communication".

Agree; either use facts (days, hours, etc) or nothing, but no vague adjectives.

This my new personal record (3 days) between signing up for a service and getting a notice that my email address has been leaked :D
Hey! you and me both, 4 days in my case, but it's a record for me.
> accidentally committed a code change that contained an active site-admin access token

Our regular reminder to try keep credentials and other security tokens well away from any source code where-ever possible, even if that might mean making things a touch less convenient.

I'd guess that most of us have checked in or otherwise posted a credential at some point in our careers. I've certainly done it in the past with an application DB connection string and had to do the quick reconfigure to revoke that access¹ – in that instance resolution was quick & easy but for other environments it might be a lot more admin.

Being careful isn't the solution because mistakes will always happen, making it damn near impossible to accidentally post credentials is the way to go.

--

[1] even though the repo checked into could only be accessed from within the company, and the DB instance in question was locked down so only the application servers and the limited few with access to a VPN connecting to its subnet, good practise dictated immediate full revocation just in case

I don't know but it always seems to be worded like in this instance: "...A small subset of customers’ Sourcegraph license keys may have been accessed..."

I don't buy that, it always seems to me like an attempt to downplay something.

I lead security at Sourcegraph and have been overseeing the incident investigation and resolution. To give you more specific details, I can say that we saw that the attacker viewed a page where they would have only seen the first 20 items, and we were able to determine what those were at the time of viewing because of stable sorting.
Kudos. Thanks for the good communications and security response.
That… didn’t age well
In what way? Has something else happened since?
(comment deleted)
[flagged]
That would be a solid approach to ensure that the next incident is more severe and longer lasting.
People make mistakes, get over it.
So we are expected to just shrug off a leak of PII collected from self-hosted instances?

I would normally agree with you, but this was an egregious violation of trust.

Realistically, you don't want to fire the person that makes this mistake. It pretty much is _never_ going to happen again for that employee, it's burned in their mind now.
The information that leaked was not collected from self-hosted instances. It was from Sourcegraph.com, which contains generally less sensitive information than self-hosted instances. See https://about.sourcegraph.com/blog/security-update-august-20... for full information.
Do you have a response to the current top comment of this submission?

> Sourcegraph seems to have collected a bunch of these (now leaked) email addresses from signups on self-hosted instances.

> I remember being very surprised when I was signed up to their mailing list after I made an account on my self-hosted instance, and I'm not sure about the ethics (and legality) of collecting these in the first place.

Hey, Diego Comas here, Sourcegraph's Head of Security.

The only email addresses that were exposed were those of users who have accounts on Sourcegraph.com, not those of the installers or users of Sourcegraph self-hosted or cloud instances. Note that sometimes users have accounts on both platforms, though (e.g. for license key management). And as you mention, while we do collect the email addresses of the initial installers of self-hosted instances only, for security, product, and marketing updates per our TOS and privacy policy(https://about.sourcegraph.com/terms/privacy), those email addresses were not exposed since they are not stored on Sourcegraph.com.

I think we're reading different articles, no employee leaked any PII. You're angry about something that didn't happen.
Please do not post obvious rage bait. Doing so generally does not foster fruitful debate.
yikes, can i even trust this company now
Don't ever trust a company... you're going to be disappointed every time.