vngzs

(2016)

I use LXD like this on NixOS. It's great for Steam, which works best on Arch Linux.

I mostly agree with the article, but the title is downright wrong.

Even a relatively literal read of the words "supply chain" is reasonably appropriate, even for FOSS. Wikipedia's current definition for supply chain is:

> In commerce, a supply chain refers to the network of organizations, people, activities, information, and resources involved in delivering a product or service to a consumer.

There's nothing in that definition that necessitates a formal agreement, support commitment, etc.

I frequently find myself advocating for better supply chain security. But if I asked developers (or their managers) to review/audit 2,000 NPM dependencies, I would almost certainly fail. No other company they know of is doing that, and asking them to start is predicated on the entire industry being wrong. That tends to be a tough sell - even though I agree with you, convincing others is a whole 'nother ball game!

What kind of arguments do the organizations you consult for find compelling? I find it extraordinarily difficult to convince others. There is a strong bias towards the status quo.

> Under the framework of that system, the funds at still belong to the customer that deposited them.

Careful. In the case of bankruptcy, you probably won't get your money back. Bloomberg Law[0]:

> An exchange going bankrupt would likely have to face Chapter 11 debtors’ rules on creditor recovery. Generally, secured creditors would be paid back first before others.

> A crypto exchange is not likely to have investor protection measures in place for cryptocurrency, though it could carry insurance policies for certain covered incidents, such as cybersecurity incident. And unless user terms specified otherwise, an investor would likely be an unsecured creditor who may not be able to recover what they’re owed.

[0]: https://news.bloomberglaw.com/securities-law/if-a-crypto-exc...

I may be misunderstanding this, but it seems like there is a mistake on the first page:

> For example, every string is an object, `str <: object`, but not every object is a string, `str ≮: object`.

Is not

    str <: object ∧ str ≮: object

a contradiction? Wouldn't `object ≮: string` be the correct representation of "not every object is a string"?

You're right - an adversary with physical access to machines running Vault can steal keys from it. An HSM is designed to survive at least temporary physical access by an adversary. And if you have management infrastructure that lets admins access the servers running Vault, then they can exfiltrate the keys (an HSM can be configured to prevent this). There exist threats that HSMs will stop that Vault simply won't stop.

But they are both systems intended to provide secure storage of key material with policy-based access to that key material. As an SSH CA, you can configure Vault to sign SSH pubkeys but never divulge the key material. Depending on your threat model, it might get you what you want for this use-case, but you should definitely be aware of the limitations of Vault's security model.

Yeah, the root is long-lived. The ones you issue to SSH to a machine are short-lived, because they're not stored in something like Vault.

Doing this without something like Vault is very difficult. Vault is designed to provide similar guarantees to an HSM (it's a service designed to make keys usable but not exfiltratable), and that's essential for any long-lived certificates.

> Second, does this guy have any actual tech knowledge at all? He doesn't list what operating system they are running or what security updates he is expecting.

"This guy": https://en.wikipedia.org/wiki/Peiter_Zatko

I've heard rumors that the new Sony cameras are better. Thanks for the suggestion; I'll check them out.

I spent some time doing press photography for concerts and couldn't imagine shooting mirrorless during a show. High-action environments demand super low-latency, high-resolution viewfinders. No mirrorless I've handled so far can keep up with an optical SLR. And the crummy digital viewfinders make low-light manual focus into a painful chore.

The closest thing I've found is the Fujifilm X-Pro 3's "hybrid" viewfinder. It has a Leica-style rangefinder that can, with the flip of a switch, convert into a digital image like every other mirrorless. It can even overlay the frame and a digital focus preview onto the analog image in the rangefinder as you move it around. It's not useful for concerts - the 23.5x15.6mm sensor is too small - but I photographed some of the the 2020 protests in NYC and the extra field of view in the rangefinder is actually an advantage in that kind of hectic environment.

Monoamine oxidase inhibitors (MAOIs) in tobacco smoke increase the effectiveness and addictiveness of nicotine, which practically means tobacco is dramatically more addictive than nicotine alone [0]. By switching to an alternative that contains nicotine while keeping physical sensations essentially unchanged, tobacco users can remove MAOIs from their system and then focus on the behavior (hand fiddling, inhaling) and chemical addiction (gradually reduce dosage) separately.

Beyond that, vaping is so obviously safer than smoking. It strikes me as profoundly hypocritical to ban the less dangerous alternative, while keeping the unbelievably deadly cigarettes on the market.

[0]: https://www.jneurosci.org/content/25/38/8593

The subtext of the DARPA funding makes me think the purpose of this paper is to analyze whether governments can disrupt, block, or compromise cryptocurrencies. The conclusions make some more sense in that light. Still, I think they fail to address several mitigating factors for each of the issues, which weakens the overall message:

(1) Mining pools are not even remotely static. In fact, they gain/lose marketshare very quickly, and when problems are discovered, miners actually move. Therefore, it would have to be shown that these pools can be disrupted clandestinely, otherwise an attempted takeover/51% attack would just cause a rebalancing of the pools. To better understand this, it's good to visualize it; here's a graph of changes to miner pool distribution over time: [0]

(2) 51% attacks permit double-spend, but many guarantees persist in the light of 51% attacks - nobody can invent coins they don't have with a 51% attack; they can just undo transactions that were assumed to be settled [1].

(3) Software centralization and the implied lack of immutability is subject to the voting influences of node operators; maintainers can't just do whatever they want (in other words, backdoors would probably need to be bugdoors, else they would not be deployed and therefore de facto rejected). Taking Bitcoin as an example, many BIPs have been withdrawn or rejected, either early in the development process or later by the community refusing to adopt releases they don't support: [2]. And you can see this process at work in the block size debates and ultimate resolution [3].

ISP centrality and the vulnerability of the network to malicious Tor exit nodes is the most interesting point to me. Miners can go switch pools, and node operators can band together & refuse to update to new software that does things they disagree with. But can node operators/miners switch ISPs quickly and easily? Not really. There's virtually no free market competition among ISPs, so people can't freely switch ISPs if theirs starts inserting arbitrary latency into Bitcoin traffic. We probably need some ways to operate nodes/miners that are less sensitive to corrupt ISP disruption.

Encrypting BTC P2P traffic and developing strategies for operating nodes/miners behind anti-censorship software like ShadowSocks should be high-priority.

[0]: https://public.flourish.studio/visualisation/2879848/

[1]: "Even a 51% attacker cannot propose a block that takes away your ETH, because such a block would violate the protocol rules and so it would get rejected by the network. Even if 99% of the hashpower or stake wants to take away your ETH, everyone running a node would just follow the chain with the remaining 1%, because only its blocks follow the protocol rules. More generally, if you have an application on Ethereum, then a 51% attack could censor or revert it for some time, but what comes out at the end is a consistent state." - Vitalik, https://old.reddit.com/r/ethereum/comments/rwojtk/ama_we_are...

[2]: https://en.wikipedia.org/wiki/Bitcoin_Improvement_Proposals#...

[3]: https://en.bitcoin.it/wiki/Block_size_limit_controversy

This is false; some data is end-to-end encrypted, including Health and Keychain data. Photos, contacts, and Drive are "encrypted on server" which means Apple can read them.

https://support.apple.com/en-us/HT202303

With a sufficiently programmable hardware key, yes, you can back up the secrets. See an enumeration of methods in [0]. Be careful if you plan on doing this; make sure the tradeoffs make sense to you. You probably want to do the programming from an airgapped, trustworthy Linux machine.

Beware that if you do this and lose your primary key, or if it is stolen, then an attacker can impersonate you. Setting up multiple unique keys is probably more useful in general, even if it's more cumbersome.

[0]: https://dmitryfrank.com/articles/backup_u2f_token

If you're copying passwords out of a password manager and pasting them into password fields, then yes, you're getting a significant improvement to phishing protection with a hardware key. If you're using the password manager's autofill feature, and that autofill feature is bug-free, then you're not getting any additional phishing protection.

Your passwords can still be stolen, however. Any hardware authentication mechanism is going to ensure that no matter how compromised your local machine is, the worst an attacker can do is steal one active session. They can't steal the secret required to initiate any future session.

What I mean is: with modern hardware keys you literally can't trick a user into approving a remote login, or a login to a fake domain. It's not possible unless you can control the domain that the user is logging into (say you've got code execution on their machine or compromised their network and broken TLS, attacks which are significantly more complex than phishing). Hardware keys enforce that the device can only authenticate against the real domain, not a phishing domain. The core of this is a real improvement of how 2FA works at the protocol layer, rather than simply a change to how the user interacts with the device.

Hardware keys also require that the key can only authenticate a local session, so there's also no risk that your "hardware key tap" can be captured and used by a remote adversary who doesn't control the local computer.

There's a frequent misconception that hardware keys are no better than, say, a TOTP seed on a secure element of your phone.

The core practical difference between a hardware key and that TOTP code on a secure element is the hardware key, when registered with a domain, is programmed with the domain name in it. Lookalike domains - or anything besides the exact domain you registered the key with - fail to 2FA because they are unregistered. This essentially prevents (spear)phishing attacks from stealing login credentials.

Right. Some core services get this treatment, like email and important online accounts. For others I rely on reset mechanisms tied to those email accounts if I lose the primary key and haven't had the chance to register the secondary. Every few months I'll sync up anything that has been missed.

It's not perfect, but it's a hell of a lot better than TOTP.

You just register 2-3 keys. It's not so bad.

It's like a clear hood on your car. On a nice enough car, it shows the beauty of the engine. But on a cheap one ... Skeleton watches can be uniquely telling of the price of the watch.

Worth mentioning, most mechanical watches will have a sapphire back, so when you take them off you can admire the movement privately.

I like the design of Guix more than NixOS, but I haven't gotten around to actually trying it. The tricky thing about GNU distros is they often make it very difficult to install nonfree packages like Discord. I don't use proprietary software very often, but when I do I prefer to have it available in my distro's package manager.

Besides that, I look forward to giving it a chance.

You can write Chef targeting OpenBSD and run it in local mode. Get to use plain Ruby instead of a hodgepodge functional programming language. NixOS modules tend to be more "batteries included" than your average Chef cookbook, but if you stick to using native Chef resources you get something (pseudo-)declarative and powerful.

Disclaimer: I use NixOS every day and I love functional programming. But boy do I wish Nix had picked Haskell, OCaml, or Lisp instead of inventing a programming language.

I'd also like to recommend Knuth's lecture notes on mathematical writing [0].

[0]: https://jmlr.csail.mit.edu/reviewing-papers/knuth_mathematic...

On Duo, if you have multiple hardware keys registered, then you need to pick the key to use for 2FA before you get the prompt. If you pick the wrong key, it will fail. It is very easy to end up in a configuration where every time you need to perform a Duo login, you have to click 3 times to pick the right key.

Or you can skip the keys and get a mobile prompt, instantly, the moment you visit the page.

Of course, this has nothing to do with the underlying limitations of hardware keys. But vendors routinely mess up implementing them. We could really use some rock-solid open source WebAuthN implementations.

If they're willing to read a book on security design, I would recommend Security Engineering, 3rd Edition [0]. It includes a broad survey of what matters in the security space (rather than just cryptography), and generally in sufficient depth to understand how we may build secure platforms in the face of adversity.

Also, many of the chapters are available to read for free - read author's text under the cover photo.

[0]: https://www.cl.cam.ac.uk/~rja14/book.html

If you haven't, check it out from a high DPI printer. The font is much more tolerable there.

I used uBlock customization to block the font from loading to read the article.

Indeed. The author could have spent 15 minutes setting up Tailscale [0] and not expose any listening administration ports to the Internet at all. If they wanted to avoid using a hosted service, Wireguard alone is incredibly defensive against attackers who do not have access to the secret material. Tailscale basically just adds some NAT traversal [1] and OIDC login wrappers.

[0]: https://tailscale.com/

[1]: https://tailscale.com/blog/how-nat-traversal-works/

Slides: [0]

Carol is one of the authors of The Rust Programming Language [1]. This talk, targeted mainly at C programmers, motivates the development of Rust and then offers a deep dive into Rust's safety guarantees.

[0]: https://learning.acm.org/binaries/content/assets/leaning-cen...

[1]: https://doc.rust-lang.org/book/