>In general, reviewers should favor approving a CL once it is in a state where it definitely improves the overall code health of the system being worked on, even if the CL isn’t perfect.
It’s a nice rule of thumb for CLs (changelists) that provide a bug fix or refactoring. But I think it’s a terribly useless rule of thumb when evaluating a CL that just implements a new feature.
Imagine some new features such as “support exporting to CSV” or “auto-generate avatars for new users”. Implementing them will necessarily add more code, and more complexity, to the codebase. And adding more complexity makes the code harder to work with – in other words, harms “the overall code health of the system”. Businesses develop new features because of the improvements to the product they bring and the reputational or monetary gains that come from that, in spite of the damage done to the codebase. The only way you could get a new-feature CL to pass by the standard you quoted (the standard of “improving the overall code health of the system being worked on”) is to refactor existing messy code written by someone else, and that would not be sustainable.
Does anyone see a way to interpret the rule, or have a preferred variation of the rule, that makes it useful for evaluating new-feature CLs?
Yeah, that was the first section I read and I raised an eyebrow, I hadn't thought of it like that yet. I can see how one would get paralyzed by a focus on perfection; I too have left idk, dozens of comments on a feature PR of a few hundred lines of code.
Mind you that was before Prettier, nowadays a lot of these niggly things are automatically identified and fixed in editors and a pre-commit hook.
Centrality.ai | Blockchain Engineers | New Zealand | ONSITE
We're a blockchain venture studio based in Auckland, New Zealand. Looking for engineers to help build out our core blockchain infrastructure on Substrate.
If writing rust for your day job, building decentralized protocols for the web 3.0, wasm virtual machines and byte code interpreters sounds like a) not gibberish and b) awesome then reach out.
Rust experience or interest to learn with some serious experience in systems level programming e.g. C/C++.
Other pros would be knowledge of cryptography, web assembly, or DLT in general.
Oh there's also Kombucha on tap and chief dog officers if you like that kind of thing.
Scanned the paper and looks like they're using keys that are < 256-bit hence the vulnerability. Also I think the encryption keys which were found vulnerable are separate from the transaction signing keys
But then the article and its citation is plain wrong. 256 bit keys(3 of them) are cited multiple times
""This is a mystery," the French researcher said. "The only possible explanation we can think of is that the designers thought this would compensate for the too small key sizes of the primes involved. But 3 primes of 256 bits are really not the same as one prime of 768 bits."
However, a public key of a length of 1024 bits may not be enough, according to Gaudry, who believes officials should use one of at least 2048 bits instead."
The paper[1] makes it much clearer. They aren't using elliptic curves, they're using prime fields with ElGamal (with a weird construction using three separate keys for some reason). The security is similar to RSA-256 (in other words, "awful") -- it makes sense that they could crack it in 20 minutes.
Why do people do weird stuff like this when there is gobs of good ECC code for things like ed25519 and ECDSA with standard curves that is easy to use and just sitting on GitHub?
Implementating complex crypto correctly is hard but its really not that tough to use common constructions in a secure way. A few days of reading can tell you how to build a cryptosystem that is at least not total holey cheese.
One theory that the paper has (in the last page) is that the reason for the construction was a consequence of Solidity only having support for 256 bit integer arithmetic. So as a workaround (to avoid writing a library that does larger bit operations) they came up with a scheme using three 256-bit keys instead.
Obviously using Curve25519 would've made it possible to have a secure setup under the "256 bit arithmetic only" constraints, but I have a feeling (assuming this theory is correct) that someone who thinks that three 256-bit keys are significantly more secure than one 256-bit key probably would've messed that up too.
I think that advice is buried in the stories the article tells, and I wish the writer had made it more clear.
I spent quite a lot of time trying to help people who were asking for general advice, and my take is that very, very few of them actually did anything with it.
Soon, I realized that answering these question privately is a complete waste of time, and switched to answering them publicly. At least then if the person ignores it, it's still there for someone else to benefit from.
Eventually, I realized that all these questions have been answered hundreds or thousands of times in the same general ways, and that anyone who cared would just use Google and find all of them. The people who are now asking the question either lack the basic awareness to use Google, or think their situation is somehow special and only very pointed advice can help them. They're wrong, of course, which means you can't really help them.
Now, I only answer questions that I feel are actually unique somehow, or that I haven't answered in a while and just want to do a little good and maybe inspire some people.
In no circumstance do I react negatively to them. I just ignore questions that bother me, rather than tell them to "Just Google It" or whatever. If they haven't figured that out, my negativity won't actually help them or anyone else.
Most of those tools are built around the "cattle not pets" idea but a PC is a pet.
Best way IMO is some dotfiles and a bash script, OS installation part is pretty quick, unless you running arch- but even that can be automated
> Most of those tools are built around the "cattle not pets" idea
That's true, but not in a way which makes them inapplicable elsewhere. They are essential to support the “cattle not pets” approach, but most of them aren't intimately tied to it.
I'm imagining the classic scene from movies where a teen boy comes to ask the dad if he can take the daughter to prom, except he just opens a pull request
With abit of elbow grease we can pick the project up again, "reputational damage" is not the end https://en.wikipedia.org/wiki/Service_recovery_paradox