At Volta Circuit, we specialize in developing secure and innovative smart contracts that empower users to take full control of their digital assets through enhanced self-custody solutions. We believe in providing companies with the tools and technology they need to manage access to their digital wealth with confidence and autonomy through multisig and an advanced rules engine to delegate access.
We are seeking a talented and passionate React developer with experience in decentralized applications (dApps) to join our small team. As the primary front end developer, you will play a crucial role in owning and guiding our front end architecture, ensuring that our users have a seamless and secure experience when interacting with our platform and smart contracts. Your expertise in dApp development will be invaluable in creating a user-friendly and intuitive interface that empowers users to take full control of their digital assets.
We are looking for a self-sufficient individual with excellent communication skills who can work as a self manager and as part of a team. dAPP and full stack experience, specifically with Golang and Postgresql, are a bonus as we all work across the stack (React, Golang, Postgesql, EVM, Cosmos).
If you’re interested in learning more, email us at hireme [at] voltacircuit.com.
Hi there! I'm Arron, Senior Frontend Developer with 8 Yrs of Experience | React & React Native Specialist | Formerly IBMer | Expertise in Performance Optimization & Responsive UX Design, I built and led many software apps in various industries like Social Media, Rental, Sales, Clouding, Education, so on and so forth. Now looking for a product-focused technical leadership role at an early-stage startup. Please check it out here: http://arronhensley.vzy.io/
If you are interested in me, please drop me a line! Thanks.
I couldn't bring myself to pay the premium at the time, especially with the slow rollout of the MMU. But now with multiple printers in my fleet, I might be kicking myself shortly. We all knew some of this was a possibility, unfortunately.
Just wait until their home banks interrogate them about how they want to spend their local currency they wish to withdraw or banks shut off withdrawals entirely due to systemic issues.
Bitcoin may not be the end all solution, but it's a great current option.
Some packaging ecosystems are more risky than others, primarily because they allow running arbitrary code at some point during the install cycle. Node and Python being two notable ones, especially considering how commonly they are used[1]. Others do it more safely where, at a minimum, no code can run until the library is imported and run with application code.
Depending on how and where you deploy, you can mitigate some of that by isolating the installs and not keeping sensitive information there (e.g. in a docker image).
[1] - I don't follow node/npm closely anymore, so this may have changed.
I'm not convinced of the additional danger in letting packages run code during installation. You install them because you want to use them, so the code they ship will get run anyway. Are there really common environments where the final product only gets run with less permissions than the package manager?
Most any deployment based setup will have a separation between the code that is executed on the developer's machine and the code that is run on a built application?
Yes, it is common for developers to have some unit/build testing setup available so that they can run the code locally, but even that should be done by a system that makes sure anything actually running during the test is declared as part of the project workspace.
More directly, it is common for many package managers to try and do a global install of some things. If not global for the computer, for the current user. Thankfully, this is changing a lot. (At least, I think it is?)
How does that add any danger? You're pulling in code because you want to use it. If the package is malicious and your package manager doesn't have post-install scripts, the malicious code is just going to run 5 seconds later when you import it and start working with it.
In the case of NPM with post-install scripts disabled, you'll simply get pwned when you `npm start` rather than `npm install`.
Deployments are irrelevant for this conversation; libraries get to run code there anyway. For code execution during installation to be an attack vector, you'd need an environment where npm install gets run with _more_ permissions than npm start (or the equivalent for other package managers). I can't really think of an environment where that is the case. Usually the build and package manager is more restricted than the application, not the other way around.
Right, my understanding is that this was not too uncommon for some older packages? Especially in early python, it was not too uncommon to accidentally install to the whole system, no?
The issue isn't when you get what you're wanting. The issue is when either you accidentally get something you didn't want (such as type-o squatting - a not too distant issue on PyPi) or a package was published maliciously (imagine bumping a patch version and it being compromised) - a few fairly recent issues on npm.
I agree that the happy path is ideal and hopefully the common case. Regardless, anything with access to production secrets for my team is run on the most minimal image possible (and none of those secrets are available during dependency installation and compilation).
And this is a very sensible precaution where developer environments have SSH keys and other privileged credentials available and exposed in predictable locations, ready for exfiltration over the unfiltered internet connection that developers insist on having available.
Hopefully the VM/container run environment is also in a network-isolated environment too, so it can only be accessed and invoked through the expected routes, and it can't make arbitrary network calls to external hosts that haven't been manually reviewed and approved.
The types of secrets ought to be a bit different and less consequential on a developer's machine. If they're not, that's a pretty big red flag. It's one thing to gain access to clone some repositories (e.g. ~/.ssh) but an entirely different thing to get production aws credentials. Not to mention all the other protections that should be in place that mitigate the fallout (for example: no pushes to main/master/prod branches, requiring status checks and reviews before merges, etc).
this is still true of node/npm. It's also true of Cargo (Rust), Nuget (C#), and a handful of others. I'd say it's probably the _norm_ for most ecosystems to allow some form of pre/post-install execution.
For what is worth in nix after the code is downloaded the code is built in a sandbox without network access. So one does have a viable alternative for Rust.
And is true that most package managers for popular language allow arbitrary code execution during the install process. That is how husky adds git hooks to the developers machines.
For example in Ruby I need to patch the Kafka gem, karafka because it downloads, builds and stores librdkafa.so in the gem's directory.
I understand that this as well as the husky example comes from a desire to make developer lifes easier but I'd rather we erred on the side of caution. Making sure that software builds without access to the network and without being able to modify your system (ej. Adding files to $HOME)
They did a live stream this morning and said they've already crossed the six figure mark on the initial private/soft launch. I was pretty surprised by that, as similarly I questioned the market.
Agreed, this has been a really fun experience to follow. I know these last couple will continue to be engaging, but I hope there's something else in the future from the author!
I find that I really appreciate the explicit rather than the implicit comparisons (requiring `===` in js), especially picking up a new program or coming back to one after some time away. I view it like a database - do I really want multiple ways to show a value is empty? For something like a Boolean you have: `false`, `true` and `null` as valid values (trilean?) that now have to be handled.
I wasn't aware that Prusa is floundering and wouldn't have minded a little more development there. However it wouldn't surprise me as when I was shopping for my latest 3d printer replacement it was too easy to choose something else. For the price of the Mk4 most of the market is within the same budget (many options arguably better and more capable).
Isn't that a myopic view? While sure, if someone is forever depressed they may not help others (beyond sharing their experience others may relate to). Imagine the people that are in a rough place for a period that come out the other side. I hope those types engage today and share as things change.
It can definitely be more harmful than helpful for some. If you want get bummed out, search out forums for those that were broken up with ("lost my ex"). There are many support forums for such things with people that have been active for _years_ after their breakup. At a certain point they are just ruminating on their pain.
Romantic rejection is one of the most personal and emotional things most people will experience, and having a support network is important for moving on. But something goes haywire for some people given an infinite source of "support" online - unlike with real social connections, online strangers won't tire of you discussing your breakup, so you can do it probably forever, constantly freshening the pain, and peering into everyone elses story for insight on your own...and never move on.
At Volta Circuit, we specialize in developing secure and innovative smart contracts that empower users to take full control of their digital assets through enhanced self-custody solutions. We believe in providing companies with the tools and technology they need to manage access to their digital wealth with confidence and autonomy through multisig and an advanced rules engine to delegate access.
We are seeking a talented and passionate React developer with experience in decentralized applications (dApps) to join our small team. As the primary front end developer, you will play a crucial role in owning and guiding our front end architecture, ensuring that our users have a seamless and secure experience when interacting with our platform and smart contracts. Your expertise in dApp development will be invaluable in creating a user-friendly and intuitive interface that empowers users to take full control of their digital assets.
We are looking for a self-sufficient individual with excellent communication skills who can work as a self manager and as part of a team. dAPP and full stack experience, specifically with Golang and Postgresql, are a bonus as we all work across the stack (React, Golang, Postgesql, EVM, Cosmos).
If you’re interested in learning more, email us at hireme [at] voltacircuit.com.