In the past, while using Elm, if you wanted to support some browser API that Elm didn't support yet you would have to fallback to kernel code. What Elm wanted: a core package that provided this low-level kernel package that provided typesafety at the Elm level. But as we know, this was a pipe dream because you could never contribute to Elm unless it was from the Elm dictator itself, or from his inner circle of cool people.
It seems like Gren is already ahead of this. Gren has community members actively working on the Websocket API to provide a typesafe core package with Kernel bindings.
The question is: will Gren keep being open to contributors that can provide kernel code.
If B4nan is around here from Apify, amazing work. On Crawlee, and on MikroORM. I especially use MikroORM extensively in production. One of the best, if not the best, ORM for NodeJS.
Apparently there was a "blogpost" of a developer showing of their code, where they accidentally leaked access tokens in a piece of commented code: https://archive.ph/mP3bh
This is completely unverified though, so take it with a grain of salt.
Assuming this unverified version of the story is true, the danger of accidentally leaking credentials in code is enormous and one of the reasons I continue to maintain and develop gitleaks. Those credentials[1] would have been caught by the gitleaks' generic rule [2]
Fantastic tool. We all know that _we_ wouldn't leak keys, but we have all been the person to 'rm -rf /' or 'delete * from prod where 1=1;', so it's just a matter of time.
Is there a plugin that streamers could use to blur suspected keys on stream? Would that be something interesting to work on do you think? (I'm not a streamer but it sounds fun)
When I was looking into the streaming side of things I set up an overlay image which could be toggled with a hotkey to hide my screen (it actually also hid my desktop scene too in case the image didn't load or whatever)
My main precaution though was separating dev/prod and never looking at prod stuff online. Worst case someone could spin up some guff in my dev/test account until I can cycle the credentials
In my case the separation also included a different system user on my computer for stream work. Possibly overkill but why risk it when the costs are so low?
I can't see myself trusting a key blurring app if I'm honest. Rather fix the issue earlier in the process than rely on something that would probably break on edge cases (word wrap enabled? Here's the key but it's in two parts, that sort of thing)
I think it would be a good tool to have, I had to contact a conference organizer once who switched tabs while sharing her screen in a recording and revealed a note in Google Keep that read "LastPass master password" xD
It doesn't help that so many tools are like "give me your secret key in plain text in the config file" without at least offering a link to a webpage on the github of how you could secure your keys and use this software
Vault is not just a drop in and go system - setting up a vault instance is an ordeal in and of itself, and the pricing for vault on hashicorp cloud is incredibly expensive. The problem with the other options is that you have to get the secrets into environment variables, or out of github/lab secrets and into your application. To use most of the services like AWS secrets manager, vault, etc, it will cost you more to manage secrets than it will to host the app on a small DO droplet for example.
Self-hosted Vault within a minimum Kubernetes cluster in GCP costs us roughly $35 a month. Maintenance effort can be neglected if not scaling. Vault has its learning curve there but I think it's totally worth it, given its secret management and API-first features integrated with many other DevOps tools.
If anyone’s looking for something more secure than vanilla env vars but simpler than Vault, you could check out EnvKey[1]. Disclaimer: I’m the founder.
It’s end-to-end encrypted, cloud or self-hosted, and very quick to integrate.
How were the words selected for the regex? It's interesting that "pass" is not there and breaks detection in your first link, but I assume they were chosen based on the statistics?
`pass` by itself might introduce false positives. `passwd` and `password` are common and more likely to be in the ROI of a secret. That said, I'm not opposed to `pass` by itself. I'll have to think about this one...
> but I assume they were chosen based on the statistics?
Nope, not statistics. Identifiers and keywords are chosen based on what I see out in the wild being a software engineer.
I don't know this guy, but how can he confirm this? does he possess any inner information? why I got the feeling that he is so eager to put a conclusion on this when it is still open for debate at this stage.
Binance is the largest cryptocurrency trading platform globally.
According to this tweet [0] they have a "threat intelligence" department that continually monitors for potential issues. It makes sense that they would be on the lookout for leaks of this nature, as they are highly dependent on correctly verifying and identifying their customers.
Starting today, this will be known as "Shanghai'd credentials" and be reason #1 why we use ephemeral credentials (e.g. AWS STS/SSO) rather than static credentials (e.g. IAM Users)
One of the major benefits of ephemeral tokens is that they become less attractive to put into the code, and more attractive to put in a config file/vault that's easier to update and keep secret. This in itself is useful because it makes it less likely that it will be in some source file someone shows, or pushed to some remote repo that at some point has permissions allowed so people can see it.
We got rid of all IAM users used by applications and moved to role-based access. Nowhere in the application do you need to enter AWS credentials. AWS SDK will attempt to discover short-lived credentials for you and will assume the role specified at the infrastructure layer, e.g. in a task definition.
same here, but we still have IAM Users for service accounts. E.g. some customers have on premise infra that needs to talk to our services of infrastructure.
Do you know a way where RBAC can be used for the above?
For us, we're using long lived credentials in this space using IAM Users but with very tightly controlled authorisations.
You add the long lived IAM user API key/secret to it and it stores it in a password protected storage (MacOS keychain or similar).
Then you invoke aws-vault with an IAM role and command, and it will handle obtaining short-lived credentials scoped to that role (including TOTP 2-factor code auth), and then run the command with those temporary credentials as env vars.
With the right AWS permissions on your user, it can also automatically rotate the IAM user API keys for you.
I like your approach. So far I used profiles extensively. AWS_PROFILE is your friend. No idea why AWS doesn't heavily promote this everywhere they can.
It can either use a secret injected into an env var to bootstrap rotating ephemeral/refresh tokens or use a role provided by the environment (which can also provide short lived tokens), depending on your runtime environment and use case (on prem, cloud, k8s, etc).
Static, long lived secrets with limited governance that have no conditional access guards are weapons of mass self destruction.
Keeping secrets in environmental variables has always seemed dodgy to me. Unless specifically cleared, they get inherited by all child processes. Maybe there are never any child processes in your application, or that could be desired behavior in some circumstances, but generally it seems like asking for trouble.
There's also the reverse issue - if they change after your process is started.
Refreshing an environment variable that has changed is (for me) a line I won't cross. Time to write the app a different way, once that becomes a concern.
Yes, but credentials should either be long lived with (very) limited scope _or_ short lived with required scope.
For example, for AWS you can create long lived credentials for users which are scoped to only allow one operation, namely obtaining a short lived token (with the aid of a hardware token such as a Yubikey) with scope to perform other operations.
You may also setup federated (trusted) relationships. For example, a GitHub Workflow can be trusted to assume an IAM role. In that scenario, there's no long lived secret in scope.
The oidc subject includes the GitHub org, repo, branch, and environment for the IAM assume role policy to match or filter.
This is not at all the takeaway from this. It's "this shitty developer should not have had access to this data in the first place". With a nuance of "this database probably shouldn't exist in this form in one place to begin with".
How you come up with a name is up to you and how you use it. Personally I would go with "July 2022 Shanghai National Police database leak" because I'm not having any conversation where a cute codename would be less confusing.
At work we codename security issues we are working on for Slack channels, etc. We use unrelated names that you could get from a name generator.
I don't believe this comment is made in good faith, there is nothing wrong with the "right" and it's senselessly adding fuel to our political division.
There is something deeply wrong with the authoritarian politics of the right and its casual use of racism to further political control.
> it's senselessly adding fuel to our political division.
This comment, whether you realize it or not, is coming from a place of extreme social privilege.
Remember that for the majority of people, politics is not a game. It is serious. People lose their rights to live the life they want all the time. Sometimes those politics turn violent and people lose everything.
I wonder if you could make a luhn-like check that would require an additional approval step to post if it comes back positive. Something like "It looks like you may be posting a secret *****. Do you wish to continue?
If vendors agreed to a common prefix on all secret key values then it'd be easy for everyone to add checks, to everything. Something like "_SECRET88_".
Of course, then your secret key checker would need to build that string by concatenating so that it wouldn't set off itself.
More and more providers have been adding unique prefixes to their tokens and access keys which makes detection much easier. Ex, GitLab adds `glpat-` to their PAT.
A project I maintain, Gitleaks, can easily detect "unique" secrets and does a pretty good job at detecting "generic" secrets too. In this case, the generic gitleaks rule would have caught the secrets [1]. You can see the full rule definition here [2] and how the rule is constructed here [3].
Unfortunately, it's not as simple as that.
Lots of secrets are "generic" (think of a DB user/password combination), meaning that you need to take into account the surrounding source code context to be able to determine if they are a "real" secret.
I was thinking about that too, but it's actually tricky, even the example given, they use the var `accessId` but you could filter for all that, even the standard ones, but you couldn't have enough confidence in it so that if someone did post with a typo or even a random var name, they would think "Okay, no warning so must be okay".
Something like giving false confidence to the user. Not the best idea.
When you do this is there a way to completely get rid of the information? Usually you can go back an look at the edit history to see the original post.
Wouldn't matter. Tons of bots are scraping every inch of the internet all the time, and if something been online for five seconds, it has been cached/stored somewhere. Always assume that anything you've put up on the internet, can forever be accessed by someone.
The only thing you can do is rotating the token/secret.
The consensus in Chinese community is while this is likely how the token got leaked, this alone isn't enough. To visit private Alibaba Cloud instance you can't just use some random IP. It's isolated from the Internet in certain way.
And we all know isolations based on network perimeter eventually falls apart, and because it encourages insecure opsec practices like this, people are going to have a big surprise when it happens.
Remember when we still used password Windows Authentication and a private shielded network you could only get into with VPN instead of public cloud services with generic access credentials. It still didn't make leaking credentials right, but it was one extra layer of protection.
> That’s why today we are announcing that for the first time we’re changing our prices to best serve you at every stage of your growth journey.
To best serve you at every stage of your growth journey it would seem. Or if you'd like a translation from stilted corporate speak into plain language: we went public and the line's gotta go up and engineers and hardware don't come cheap.
It more and more feels like going public is the big mistake in a lot of tech companies, because everything gets real squirrely after that for customers and employees.
Any more, whenever a company I use goes public or is acquired, I start looking for the egress. I'm happy that the founders of whatever it is got a nice payday, but I don't expect their creation to continue being worth using after that.
the thing is once you start private and giving options as comp, your only option is to go public eventually, or screw everyone that's every gotten options.
Profitable private companies that never want to go public can solve this by doing profit sharing with employees, but in tech there's often no profits for a very long time.
I agree. I understand pricing increases (even if I don't look forward to them) and I'm an adult, just tell me the difference in prices instead of deliberately obscuring that information. Not showing the prices smells of not standing beside your product/new pricing. I think DO is still worth it at the new prices, that said I'm having a hard time remembering when a cloud provider raised prices like this, normally the trend is down/same no?
I mean even with the price increases my little server that could that serves some basic self-hosted apps up for me still costs me less that a meal at a non-fast food restaurant. I'm sure I'm getting more utility out of that than 1 meal
How many places show a difference in their prices? How often to restaurants, stores, and other as a service companies doing that? I almost never see it. I wouldn't say they are doing something deliberate (in a negative sense). They are doing something pretty typical.
They have a table of everything listed along with a new price for it. All they would need to add is a column showing the existing price. There is a 100% chance they have a spreadsheet internally passed around with that existing price column.
Do you really believe it was a not a deliberate choice to not show the side by side comparison?
Restaurants and stores are single transactions, not ongoing subscription services.
DigitalOcean makes you dig for the price increase, which is pretty scummy. They tried to soften the blow with a new droplet which looks even worse. At the end of the day, 20% is a huge change.
I wish Shopify would hire more engineering related workers in EU. Support for European payment methods in Shopify API is horrible and I would love to put it work to get more EU payment method support in the Checkout API.
TBH, even human transcribers have their limits. I often get transcripts of my podcasts. But if I have someone with a strong accent, I’ll often skip because I know I’ll be charged for a difficult transcription especially around technical terms and I’ll still have to do a lot of cleanup.
Surely the ADA requirement isn’t for a near perfect transcript.
That actually makes me wonder re podcasts and other audio. Is there any reason they’d have a different requirement or are these lawsuits specifically about video for some reason?
> Surely the ADA requirement isn’t for a near perfect transcript.
The law requires "reasonable accommodations" to provide a equivalent experience. Expecting perfection would not be reasonable. Also with heavy accents, the hearing audience probably doesn't understand every word so if some words in the transcript were wrong, the hearing impaired have the same experience.
There's nothing special about video, the law can also require podcasts and other audio-only content to provide transcripts. But the law doesn't apply to everything and everybody, it applies to "places of public accommodation," and many podcasts are personal projects, to which it doesn't apply. The legal precedent for what is a place of public accommodation is evolving, even including anything online is not universally held, I don't know what counts; having an ad spot in a podcast is probably not sufficient to suddenly make it a business to which the law applies. It almost certainly applies to an operation like Gimlet.
And it’s possibly complicated by the fact that many podcasts don’t even carry advertising but are clearly content marketing for businesses. Mind you for SEO and other reasons, transcripts are often a good idea but probably the vast majority of even quasi-pro podcasts don’t do them.
I didn’t read the code in the post and don’t have any deep familiarity with machine learning, but I have implemented a naive bayesian classifier to do something similar for tweets. The scores you get from that method don’t add up to 1 either.
Exactly, I never would have thought I would watch so many episodes of Brazilian series and Italian series. Thanks to Netflix, I somehow found them because of recommendations.
In the past, while using Elm, if you wanted to support some browser API that Elm didn't support yet you would have to fallback to kernel code. What Elm wanted: a core package that provided this low-level kernel package that provided typesafety at the Elm level. But as we know, this was a pipe dream because you could never contribute to Elm unless it was from the Elm dictator itself, or from his inner circle of cool people.
It seems like Gren is already ahead of this. Gren has community members actively working on the Websocket API to provide a typesafe core package with Kernel bindings.
The question is: will Gren keep being open to contributors that can provide kernel code.