eyakubovich

In my experience, the hardest part of developing with eBPF is dealing with the multiple kernel versions and configurations that the target machines may have. It's a challenge not only because eBPF features were added gradually but because the internal data structures are not stable. While CO-RE finally makes it possible to be offset agnostic and allows for dealing with things like missing struct members, it's still very much a game of finding out when the code is deployed in the wild. Unit testing is important but I long for a way to easily test across a large matrix of kernel versions/configs (here at EdgeBit, we would be happy to pay for such a service).

100% agree. The reality is that updating a dependency always carries some risk and sometimes requires changes to code. Reducing the amount of upgrades that have to be done under a stringent SLA makes life easier. In larger orgs we’ve talked to the ratio of eng:apps can be 1:2 or worse, so ownership is harder. In addition, for a fair amount of vulnerabilities, a fix is not available. These situations require a more involved risk assessment and remediation plan (e.g. moving to an alternate dependency). We aim to reduce the toil in such cases as well.

Great feedback.

1) We want to be cautious about changing a score that someone else assigned (CVSS) but we'd like to add our insight to inform of its impact.

2) Absolutely and we'd like to bundle it with active blocking. After reviewing the CVE, we'll let the user either accept (e.g. mute) it or block that specific package from being used (e.g. for dormant ones).

3) We think our service is most useful to slightly larger orgs with dedicated security functions and bigger supply chains. We want to help slow down the fire-hose of vulnerability reports coming from the security to devs.

IIUC, Infisical uses end-to-end encryption. Does that change your attitude towards cloud-only options? I'm genuinely curios to understand how SaaS products can be made secure so people are comfortable using them for sensitive data.

Most backend services get an identity assigned to them by having a token tied to a service account. This accomplishes the same goal, just in a more secure way.

It's unclear when homomorphic encryption will be ready for prime time, especially at big tech scale. It's easier to give up the data under assurances of how exactly that data will be used. Secure enclaves (e.g. AWS nitro enclaves) can be used to offer cryptographic attestations as to what the code is doing with the user data. Practically speaking, an average user won't inspect the code, of course. But it does allow for other companies to audit and vouch for the usage.

Hi, the author of the blog post here. I wanted to point out two neat features of the Enclaver: (1) it solves the enclave image distribution problem by packaging the underlying enclave image into a Docker container so it can be pushed to any container registry and (2) it bundles in a policy enforced network proxy to make regular TCP based networking work out of the box.

> Yes, those are the cases where it isn't possible to avoid forward declarations, so it's fine to use them? But my point was that it _is_ possible to avoid them by type-punning via void*. Now, one can argue that it's unreasonably bad way to avoid them. But will a reviewer following this guide make the same assumption?

> exit runs global destructors, so if one thread calls exit while some other thread is still doing stuff, it might destroy an object that's in use, leading to explosions.

Or you can structure your code in a way that all your threads join prior to main exiting. Never call exit() or _exit() or even pthread_exit(). I think it's much cleaner. Not to mention that not every program is multi-threaded.

> It is very non-obvious which constructors will get automatically generated, because it depends on the types of the members. `Foo(Foo&& move) = default;` makes it immediately obvious.

Agreed but can you imagine what a simple

struct Point { int x, y; };

become if we were to make everything explicit?

I don't accept that any reasonable sized shop needs to subset C++ or insanity will prevail. Any particular slice of code needs to subset the language. You may have some perf sensitive code that can't afford virtual function overhead. Or some code that uses dynamically linked libraries for which RTTI may not work right (so you avoid RTTI there). Perhaps strict determinism is required and you can't use exceptions in this part of the code base.

However this is vastly different than saying that we don't want any of these features anywhere because they might not be appropriate under some conditions. I advocate education so developers can make decisions when to use and not to use certain features (same as selecting the right algorithm -- we don't ban binary search b/c it's harder to understand than linear search).

Same with the "we have tons of programmers" argument -- let's use the lowest common denominator (everything else is "fancy"/"clever") to make sure every line of code is understandable by anyone. Encourage people to learn, not everyone else to dumb down.

The trouble with "this is not the law" argument is that it's not clear how to make the judgement. The reviewer should be using the style guide during the review and should call out any violations. A restrictive guide then places a huge burden on the author to justify the deviations.

Correct, tinc is another example of a mesh overlay network. However tinc requires configuration files to be created on each host and then distributed to others. If machines are part of an etcd cluster, you can use Rudder to create a mesh without the need to create and distribute configuration files.