Edit: and what’s the best practice here? Is it using a key management system of some sort? (I’m thinking of scenarios where you might need to deploy your code + secrets on a remote server, say to authenticate with a third party API)
Protecting high-value cryptocurrencies is particularly hard, and as much as crypto people like to say "not your keys, not your coins", the reality is far more nuanced, and the average person is much better off using a well-known platform like Coinbase. Even hardware wallets are not as simple as people thing to use safely.
(If you're building cryptocurrency apps, never upload wallet private keys to cloud KMSs. Instead, generate wallet keys using the KMS itself, and use those wallets for small "in-transit" funds only. Think of them like bank branches, when you manually transfer small amounts of funds securely from a set of central wallets.)
When you deal with high value amount of cryptocurrencies, you have a hardware wallet so things like these are not even possible in the first place, as the keys are safely stored in the hardware. Storing anything on disk (unencrypted at that) that corresponds to $40K is basically begging to be stolen from you.
Besides that, when you open source something that even has a chance of containing something you don't want to make public, you read through every single file before hitting publish.
> I’m thinking of scenarios where you might need to deploy your code + secrets on a remote server, say to authenticate with a third party API
Commonly you use environment variables for this. So the code references `process.env.MY_SECRET_VAR` or equivalent, and then you set that variable inside your server. That's the simplest way, then there are more complex/"secure" ways too, quick search for "secrets management" in your favorite search engine will tell you more.
There are a variety of options, depending on what type of software you're developing, how much you're willing to be locked into third party tools, and things like that.
The simplest is to just save the credentials somewhere like the user's home directory, outside of the git repo. This is what a lot of command line tools do.
Environment variables are also a popular option - most CI build systems will let you store 'secrets' that are passed into the build process as environment variables.
Larger scale projects will often end up with a configuration management mechanism, enabling 'configuration as code'. When doing this it will often be interlinked with credential management. After all, why not store the hostname of the database alongside the username and password?
If you're in a cloud environment, they will have 'instance metadata' that can (with configuration) pass cloud provider credentials into your instance. They will often provide a secret store service you can access using those credentials, and will let you authenticate to databases and blob stores and whatnot using those credentials so long as you stay within their cloud ecosystem.
Large corporations like 'credential rotation' where secrets get revoked and re-issued on a regular basis. The cloud environment can do this between your instance and their provided services - or you can do it yourself in an ad-hoc way.
All the major PC operating systems provide a secret storage function or 'keyring' although it's debatable whether it's all that different to just saving a file on disk. It used to be, back before the rise of full disk encryption though.
And of course if you're writing a mobile app, the operating system is a lot more locked down. So there you can store credentials in the system keyring and other applications can't access them.
Not even then and this is why
There are other services that manage securely saving/storing these keys rather than just hosting it on the server itself (e.g. AWS Secrets Manager)
For example most/all VPS provider allow you to give extra data to the machine; this could be the secrets directly or maybe a connection url to a local* redis server with the configs.
Or you can copy paste a file vis ssh.
*AWS-like providers allow you to also deploy private networks so that only approved services vps can access a db
@your edit: you can use environment variables for example, just don't commit your dotfile or just don't store in the same folder as the repo if you don't know what a dotfile is.
The public events API is delayed by 5 minutes[1]. Unless someone was actively scraping his profile rather than doing large scans on GitHub, this is not possible.
[1] https://docs.github.com/en/rest/activity/events?apiVersion=2...
GitHub even lets you find them easily: https://github.com/search?q=language%3ASolidity&type=users
Also, I expect anyone working on high-value systems to be under more targeted scraping.
If I may, I would posit all crypto is not a safe store of value to begin with. An EMP taking out the entire world power grid would render crypto pretty useless almost immediately, while gold will just sit there. Even paper money is resistant to decentralized unwindings as they are physical and people are conditioned from birth to accept their value.
And most of the gold owned in the world is not in someone's basement, but as a line in a database; so you can wave goodbye to that as well.
Fees are for inclusion of a transaction in a block. And some pretty clever game theory was implemented as part of eip1559 in Ethereum to make fees efficient and fair.
Some semi-centralized infrastructure and development is needed and costs money to run, but the questions unique to each circumstance are: "What do revenue and EBITA look like?" and "How efficiently are CapEx and OpEx used?"
OTOH, if a social venture nonprofit ran a coin with survival in mind rather than get-rich-quick fintech profiteering, it could make a promise to keep overhead low and any sort of profit margins for reinvestment in robustness, stability, features, and auditing controls to a small, fixed %.
We’re still doing that?
0 - https://topenddevs.com/podcasts/javascript-jabber/episodes/w...
Nope! It's going great[1]!
This repo should have had all types of static analysis running automatically.
Hell, GitHub has built in secret scanning. Apparently it was only set as the default for all new repos in March 2024[].
[] https://docs.github.com/en/code-security/secret-scanning/con...
How does the monetary value matters? A prototype is a prototype, a quick project to test some concept. If you wanna test some concept around large transfers, does that mean it's suddenly not a prototype?
> This repo should have had all types of static analysis running automatically.
Would that actually prevent this issue? So lets say they make the repository public, the static analysis tool begins screaming at the repo owner. Now, he has 2 minutes to transfer those funds somewhere (manually), before the thief automatically makes that transfer for them, to their own wallets.
Sounds like the guy just needed a hardware wallet instead of whatever they were doing. Who stores unencrypted wallet details containing $40K on disk?! Committed to git?!
Totally agree wallets with any real amount of money should probably not be on disk
Of course, an escape hatch (like adding some "I know what I am doing" tag to the commit) would be necessary but that's trivial to setup.
Ah, schadenfreude.
Cryptobros telling you never to use an exchange due to FTX and other examples, also its super easy to use...
What stupidity
You referring to your comments?
So you can still offer any random shitcoin and make money with it. Seriously, I've got the wrong job.
So when competitors, like hardhat and foundry, popped up what did they do? Used default shared accounts and keys. We reached out to let them know that users will lose funds, but all they did was add a warning in the CLI output and in docs. Devs still regularly lose funds: https://etherscan.io/address/0xf39fd6e51aad88f6f4ce6ab882727...
https://git-scm.com/docs/gitignore
And I see most professional senior devs training juniors to be more helpful... It is always a blessing to see that perpetual look of terror subside when people finally understand what they should be doing.
A company attrition rate is a reflection of hiring, training, and project management skills. If you have an IT culture problem, than it will manifest in the high-stress areas first. i.e. you are likely not going to survive as a business beyond 3 years.
Happy investing, and I hope someone returns his gambling chips. =)
