Signal designs their systems from the ground up to deliver verifiable trust mechanisms (via remote attestation) along with data minimization/zero-access encryption techniques.
> It seems there is no standard proper way to store private keys.
The gold standard for this would be a Hardware Security Module (HSM), which is essentially a device that stores private keys with certain guarantees of physical security (e.g, that private key material cannot be extracted from the device once it has been generated or placed there, and the device performs operations using the key material on behalf of some client).
HSMs in various forms underpin all sorts of cryptosystems that society depends on, because securing private key material at rest is essential. You'll find them everywhere from your debit/credit card, to certificate authorities, financial institutions, defense, and your smartphone.
For your use case, I'd recommend taking a look at Yubikeys. I did a writeup a while back on how to use them to store different types of private keys for various purposes:
Though other use cases for the appliance are given, it seems primarily designed for military applications?
It's designed to military standards and to be as individually transportable as other military communications equipment:
> Department of Defense (DoD) Impact Level 5 (IL5) accreditation
> rugged and portable design that meets stringent accreditation requirements like MIL-STD-810H
> The appliance can be conveniently transported in a rugged case
> Weighing approximately 100lbs, it's human-portable, making it easy to transport and deploy in various locations.
> disaster zones, remote research stations, or long-haul trucking operations
Military operations are all three of these.
Its design enables the offline self-hosting of cloud surveillance tools:
> Google Distributed Cloud air-gapped appliance is designed to operate without any connectivity to Google Cloud or the public internet. The appliance remains fully functional in disconnected environments
> built-in AI solutions from the Google Distributed Cloud air-gapped appliance like translation, speech, and optical character recognition
I run a large Meetup group for software developers in the Tampa Bay Area [0]
We’re multi-platform, and essentially a technology vendor for other Meetup groups in Tampa ([1]). While our overall community spans ~4,000 distinct people, only ~2,300 of those are Meetup members [1],[2]
I’ve built a ton of unique integrations around Meetup, and have built a ton of custom integrations with Meetup’s API (such as [3],[4])
If you’d like to get in touch, please do send an email to the address on our GitHub org [5]. Would love to see more competition in this space!
I had a strikingly similar experience at my own university, and took things into my own hands somewhat by teaching a free, basic Git course each semester.
I've been working on Tampa Devs with the other co-founder since September of 2021, along with a group of really excellent volunteers.
We're a nonprofit that's loosely inspired by nyc's Recurse Center (https://www.recurse.com/). We host events, a mentorship program, and career development resources. All of which are free or very low cost.
Our community has grown to include thousands of local developers. It feels good to be part of something that drives a widely positive impact, especially on a local level. Anyone can do something similar no matter where they are, and I would highly recommend it.
For a cool technical angle, here's a talk I gave at a local conference on the tools we use to run our community at scale: https://go.tampa.dev/unityops.
I was about to comment something to the same effect.
Like the author, as well as many who have commented, I've long been disappointed in the gap between macOS' support for advanced use cases (which I need), and the iPad's portability (which I like).
I picked up a Surface Go 3. Having an actual desktop OS on a well-built, decently powerful (albeit hot at times) tablet struck the perfect balance for me. Wish I had done it years ago.
Honestly? It's as simple as organizing events, getting people together, and connecting them with one another. It takes some time, but the adage "If you build it, they will come" has a lot of truth to it.
Personally, I use my spare time towards organizing a group that supports and nurtures developer communities in my area [1].
My organization is itself a 501c3, and our charitable mission is to provide developers with opportunities to learn and network. We do this by organizing monthly technical meetings, networking events, career panels, and hackathons. All at no cost to our members (no fees, tickets, or dues).
We also provide support to a larger network of meetup groups in the Tampa Bay area [2]. These groups are more specialized into specific disciplines/areas of interest. Many of these died out during the pandemic so rehabilitating that scene is an important mission for us as well.
It happens my company partners with GitHub to deliver with this kind of thing. Drop us a line over at [1] and we can give you a breakdown of the different migration/deployment models.
I'm on a team that's currently shipping a Godot 3.5.1 game across Linux, macOS (universal), and Windows.
After sorting out a couple minor snags in the build process (particularly around getting cross-compilation to work on Linux in GitHub Actions, and library validation entitlements for code signing), the finished builds work wonderfully on the M1 machines we've tested with.
I’ve just released sssecrets. Sssecrets is a Ruby gem for generating secrets (like API tokens, etc) in line with best practices.
Sssecrets is a reusable implementation of GitHub's API token format (which is also used by NPM), and it's designed to make it simple for developers to issue secure secret tokens that are easy to detect when leaked. Structured Secrets are a compact format with properties that are optimized for detection with static analysis tools. This makes it possible to automatically detect when secrets are leaked in a codebase using features like GitHub Secret Scanning or GitLab Secret Detection.
A European government CA marked its signing certificates as being valid for encryption only, but no-one noticed.
Another European CA marked its signature keys as not being valid for signatures.
A different CA marked its own trusted root certificate as being invalid for certificate signing.
Another national CA distributed a certificate to be used to encrypt data for the country’s tax authority that was marked as only being usable for digital signatures but not for encryption.
Yet another CA reversed the order of the bit flags in the keyUsage due to confusion over encoding endianness, essentially setting a random keyUsage in certificates that it issued.
Another CA created a self-invalidating certificate by adding a certificate policy statement stipulating that the certificate had to be used strictly as specified in the keyUsage, and a keyUsage containing a flag indicating that the RSA encryption key could only be used for Diffie-Hellman key agreement.
I dont understand the intended target audience. Who is this for?
Most SMB leaders have enough trouble as it is keeping up with their day to day IT operations. The section at the start of the document is intended for “CEOs”, yet it’s likely impenetrable to that audience on account of the jargon while simultaneously giving advice that’s too high-level/broad to be useful.
Later parts of the document intended for technical leads are too focused on minutiae rather than outlining the overarching goals of their implementation, which loses the intended spirit of the document IMO.
For example, it’s more useful to start by outlining what these controls are trying to achieve. For example, “Ensuring business continuity after a ransomware attack” or “Protecting business assets with strong multi-factor authentication”, as opposed to throwing out specific individual technical controls without a high-level narrative to describe what you’re actually aiming for.
Similarly, I have a rough specification for something that builds much further out on this idea (towards the Keybase-style vision). Would love to get in touch.
The American engineer and supercomputer architect Seymour Cray is known to have been a hobby tunneller. Cray built an 8 by 4 feet (2.4 by 1.2 m) cedar-floored tunnel under his house, explaining that the digging helped him to think about computer designs. "While I'm digging in the tunnel, the elves will often come to me with solutions to my problem," he said.
Here’s one such example, which is also an interesting technical deep dive: https://signal.org/blog/building-faster-oram/