Threads for wiktor

  1. 1

    Looks really nice. Is there an affordable RISC-V board that could be used for testing? Emulation is nice but seeing it live would be really cool!

    1. 2

      Just out of curiosity did anyone test how these group conference video calls work? As far as I know no other XMPP client supports them.

      1. 10

        They’re using the old Muji protocol right now. It used to have some experimental implementations, but this is maybe the first “release grade” implementation.

        Basically, it’s pure p2p. Every participant connects to every other participant and they all send all media directly to each other. It’s fine for 3 or maybe 4, but obviously not for big calls.

      1. 3

        Can someone offer a rundown of why this is interesting and whether the coreboot config that lets it boot also lets FOSS things boot?

        I’d have expected Windows 11 to boot with Coreboot just fine. The rub would seem to be getting other things to boot with the same config.

        1. 15

          To me the most interesting part of this link is the author’s bio:

          MSFT Director of OS Security.

          1. 5

            Among other things, David is the person who has been driving the effort to have CPU vendors adopt Pluton as their hardware root of trust. I think this project speaks a lot to his motivation: he wants a trustworthy boot chain, from the hardware up to whatever OS you choose to run. That’s why he’s interested in CoreBoot and it’s why he wants everyone to ship Pluton: they both provide parts of this story. This is why all of the ‘Microsoft is trying to take control of all of the things!!!l1111eleventyone’ articles about Pluton make me a bit sad.

            1. 5

              Once bitten, twice shy. Microsoft’s never apologized for their 90s attitude and business approach, nor have they demonstrably changed since then. They were found to be monopolists in both the USA and EU, and did the bare minimum to appease the courts and regulators. The original secure-boot proposals were along the lines of the illegal Wintel trust between Microsoft and Intel, and aimed to exclude other vendors from multiple end-user markets.

              1. 2

                CPU vendors adopt Pluton as their hardware root of trust

                Do you perhaps know what is the difference between Pluton and good old regular fTPM (firmware TPM implemented in the secure enclave of the CPU)? Most of the material about Pluton I found sadly doesn’t go into technical details.

                (Btw nice to see someone from Microsoft Research here, I’m continuously amazed by the work you all do!)

                1. 4

                  There are three ways of implementing a TPM:

                  • A fTPM is implemented firmware in a separate security level (e.g. TrustZone on Arm, SMM on Intel). This is a problem because it is often vulnerable to side channels and sometimes to things like power-glitching attacks that let untrusted code run in the secure mode.
                  • A separate chip. These are often just plain unreliable but even with a good implementation they are problematic because there’s no secure communication path between them and the CPU. A physical attacker can record the measurements that the CPU sends to the TPM and then fake them and request that the TPM signs things on behalf of malicious hardware / software.
                  • An on-chip (or on-package) separate core with isolated memory. There are a bunch of corner cases that can make this kind of thing difficult to get right (is the untrusted core able to attack it by adjusting power? What about timing-based attacks from an attacker on the untrusted core with a cycle-accurate view of time?)

                  Pluton is basically a good implementation of the last form. It is hardened against various kinds of attacks and it’s had people with physical access attacking the version shipped in the Xbox One for several years without success (most of them probably weren’t willing to pop the top off the SoC and directly probe individual components, but if an attacker is willing to spend that much on a targeted attack on me then I’m probably screwed anyway). It provides the key-management, signing, encryption, and random-number generation functionality that’s necessary to implement the TPM spec (it could also be used to implement other interfaces to the same underlying functionality).

                  I don’t really know why we don’t publish more docs on Pluton. My guess is that it’s because people are expected to communicate with it via some higher-level interface (such as the TPM spec or the APIs in Azure Sphere) and so they shouldn’t be exposed to the implementation details. The docs I’ve read are all marked Microsoft-super-duper-secret (or whatever the official term for this is) but they didn’t contain anything that looked like it actually was commercially sensitive: Pluton provides the set of features that I’d hope for (though, sadly, not always get) from an off-the-shelf hardware root of trust. I believe Google’s Titan core provides a very similar set of features (though I’ve not seen any detailed docs about it, so that’s largely conjecture). The exact hardware mitigations that it deploys are probably sensitive because they might help an attacker (even knowing that a particular category of attacks definitely won’t work can significantly reduce work factor).

              2. 1

                Wow. I completely missed that. Yep… that wins.

              3. 4

                I’d have expected Windows 11 to boot with Coreboot just fine.

                Honestly, based on what I’ve seen, I wouldn’t expect anything other than Linux to boot with Coreboot. It seems very much the people who’d explicitly use Coreboot only care about that.

                1. 2

                  Maybe the “11” part deserves more emphasis than I’m giving it, but I’ve never found it challenging to boot Windows. If you can make your thing look more-or-less like BIOS and handle x86 instructions, Windows gonna boot. So while we’re in violent agreement that those who go to the trouble to put Coreboot on a thing likely only care that Linux boots on the thing, “Windows boots on PC” feels very “dog bites man” even with coreboot in place. I guess it changes a bit if windows is still willing to do that handful of things it’ll only do with measured boots…

                  And I guess that’s the kernel of my question: is a Coreboot config that leaves Windows comfortable doing those things it only wants to do after it likes all the measurements also able to boot Linux?

              1. 6

                Even though I believe OpenPGP is dead (and dangerous), I’m willing to give credit where credit is due and recognize that Sequoia PGP doesn’t completely suck. sq(1) is significantly easier to use than gpg(1).

                1. 3

                  Why do you believe it’s dead (and “dangerous”)?

                    1. 3

                      It’s probably a good idea to link also to this: https://articles.59.ca/doku.php?id=pgpfan:tpp

                    2. 6

                      The cryptographic community is moving away from PGP, for a host of reasons.

                      1. The UX of GPG is a nightmare.
                      2. As a result, the GPG documentation is incredibly lengthly. The gpg(1) manpage alone is 56+ pages, while age(1) is 1+. The OpenPGP specification spans several RFCs, while the age is a single Google doc.
                      3. Until just recently, GnuPG only used weak KDFs, and it still defaults to KDF_ITERSALTED_S2K. age(1) has always used scrypt.
                      4. GnuPG’s MDC authentication is broken. age(1) ciphertext is authenticated with ChaCha20-Poly1305.
                      5. OpenPGP keys are not forward secret. There is an RFC draft (another one!), but it’s not without problems. However, age(1) keys are also not forward secret.
                      6. OpenPGP defines and supports old primitives, including RSA, DSA, MD5, SHA-1, IDEA, 3DES, CAST5, El Gamal, RIPEMD160, and many more. age(1) is highly opinionated, supporting only modern primitives of X25519, HKDF-SHA256, HMAC-SHA256, scrypt, RSAES-OAEP_SHA256, and the system CSPRNG.
                      7. OpenPGP leaks metadata. age(1) only leaks its version format and public keys of recipients.
                      8. The SKS keyservers are vulnerable to a plethora of vulnerabilities, thus killing the Web of Trust, killing the PGP Strong Set, and ultimately GnuPG ignoring all signatures coming from a keyserver. age(1) doesn’t and will not support signing or key distribution.
                      9. The goal of PGP was to protect email, and it turns out, email can’t be effectively protected. Email is fundamentally unsecurable. age(1) is strictly for encrypting files to other people (or yourself) using their (or your) public key, and that’s it.

                      GPG is fine for file encryption, although not without its warts and footguns. It really doesn’t offer you anything you can’t already do with age(1) for file encryption and ssh-keygen(1), signify(1), or minisign(1) for certificates, signatures, and verification.

                      1. 6

                        Sounds to me like mostly problems with GPG, not so much with OpenPGP.

                        Hence Sequoia.

                        1. 5

                          I don’t think they’re entirely separate. Up until Sequioa, the OpenPGP standard meant using GnuPG. It’s not uncommon for lay GnuPG users to confuse the standard with the implementation. OpenPGP = GnuPG for most of the PGP community.

                          Sure, there were other tools that weren’t frontends to GPG that implemented the OpenPGP standard, but they failed to gain any real traction from what I can see (I’m not sure PGP gained any real traction in the broader security community anyway). I think OpenBSD tried their hand at an OpenPGP implementation? I don’t recall what it is/was. I know they have signify for signing and verifying packages (which isn’t OpenPGP), but I don’t know if they implemented an encryption/decryption tool. NeoPG gave up due to the complexity of the OpenPGP standard and “competing” with GPG.

                          And as mentioned in my original reply, I really like Sequoia. It’s just unfortunate it took the EFAIL vulnerability to kind of kick OpenPGP in the ass and see if the greater PGP community can’t do much, much better. The Sequoia PGP library, the OpenPGP CA web of trust, and 3rd party online identity proofs like Keybase and Keyoxide are definitely improving the landscape. Just the fact that Sequoia is taking the good parts out of the standard, while refusing to implement the footguns and “90s crypto” is enough to take note of.

                        2. 4

                          OpenPGP defines and supports old primitives, including RSA, DSA, MD5, SHA-1, IDEA, 3DES, CAST5, El Gamal, RIPEMD160, and many more. age(1) is highly opinionated, supporting only modern primitives of X25519, HKDF-SHA256, HMAC-SHA256, scrypt, RSAES-OAEP_SHA256, and the system CSPRNG.

                          This in particular is something I hear a lot, but I don’t buy the argument that this is inherently a problem. It makes sense that you would want to be able to decrypt files from 10+ years ago without having to try and compile an ancient version of encryption software. As long as the applications and tooling you use does not use these older ciphers and primitives unless you explicitly tell it to, then I see no problem.

                          Sequoia even goes further than having sane defaults, by implementing a policy mechanism to decide which ciphers and features are allowed when invoked. This means the tool or application you are using will be able to ensure that Sequoia will not use any cipher except for the ones specified by said application/tool.

                          1. 2

                            This in particular is something I hear a lot, but I don’t buy the argument that this is inherently a problem. It makes sense that you would want to be able to decrypt files from 10+ years ago without having to try and compile an ancient version of encryption software. As long as the applications and tooling you use does not use these older ciphers and primitives unless you explicitly tell it to, then I see no problem.

                            The problem is that standard doesn’t clearly draw a line in the sand on what is safe and what isn’t. E.G., modern cryptography is moving away from RSA towards ECC, due to the footguns RSA ships that ECC does not. Standards should be expired as vulnerabilities are discovered and modern replacements are agreed upon, and software should sunset support for the expired standards at new version releases.

                            This is why age(1) is so attractive–it’s highly opinionated on its cryptographic primitives, rather than supporting cipher agility. If a catastrophic vulnerability is found in ChaCha20-Poly1305, it’s trivial for age to release a new software version that switches out ChaCha20-Poly1305 for a more secure cipher, with the clear announcement that you should migrate your old ciphertexts, and that support for older versions will no longer be supported.

                            1. 1

                              Standards should be expired as vulnerabilities are discovered and modern replacements are agreed upon, and software should sunset support for the expired standards at new version releases.

                              I’ll back this up with an example. In this issue on GitHub, Filippo proposes deprecating and/or removing from the Golang x/ libraries (which are “officially supported” but not part of the standard library).

                              • Blowfish
                              • bn256
                              • CAST
                              • MD4
                              • OTR
                              • RIPEMD160
                              • TEA / xTEA
                              • Twofish
                              • XTS
                              • OpenPGP
                          2. 2

                            It appears you threat gpg and OpenPGP as indentical. This is not the case. And se of your arguments appear to just stream from the fact that OpenPGP has a multiple decade long history. Of course you will find outdated methods here, and of course implementations still support them, because users should still be able to decrypt their old data.

                            Furthermore, I am not sure if sufficient satisfying Forward Secrecy with a heavily asynchronous communication medium (E-Mail) is possible. The conditions are different when compared with, e.g., Instant Messaging.

                            1. 2

                              Unfortunately downgrade attacks are a real and annoying thing, as well as security issues in very old and not-often-used code. Throwing out that whole part and maybe providing a “gpg_with_old_stuff” separately if you really need it may not be a bad idea.

                            2. 2

                              I definitely agree with you. But to be fair, age(1) does not have any authentication built into it. Which, while i love age in general, I think is an oversight, and why I don’t think it should be considered as a drop-in replacement for GPG for something like email encryption.

                              Also, keys are described as “ephemeral”. I don’t use GPG, but I quite like the idea of just putting a pubkey on my website and leaving it at that. Again, another reason why I don’t think you should use it for long-term email encryption.

                              Edit: I suppose I didn’t consider that some people say that you should rotate asymmetric keys frequently (e.g. SSH keypairs), in which case I suppose age’s small and ephemeral keys would probably be a plus.

                              1. 3

                                The meta-point of this post (mentioned by me in a sibling comment) is that PGP tries to do a bunch of stuff with one application, and is mediocre at most of them.

                                Back in the MC Hammer era from which PGP originates, “encryption” was its own special thing; there was one tool to send a file, or to back up a directory, and another tool to encrypt and sign a file. Modern cryptography doesn’t work like this; it’s purpose built. Secure messaging wants crypto that is different from secure backups or package signing.

                                1. 3

                                  Yeah I totally agree with that, I’m firmly in the “GPG needs to die” camp.
                                  But am I wrong in saying that the main purpose of GPG these days is [supposed to be] email encryption? My point is I don’t think age alone satisfies that.

                              2. 2

                                The UX of GPG is a nightmare.

                                Agreed but what would you expect from a software modeled after PGP 2.x released in the 90s?

                                As a result, the GPG documentation is incredibly lengthly. The gpg(1) manpage alone is 56+ pages, while age(1) is 1+. The OpenPGP specification spans several RFCs, while the age is a single Google doc.

                                You may be happy to hear that the OpenPGP specification is getting “refreshed” and consolidated: https://gitlab.com/openpgp-wg/rfc4880bis#openpgp-cryptographic-refresh-of-rfc-4880

                                For some people “google doc spec” is enough, others like legal protections that the IETF process guarantees. I think there are reasons why HTTP/2 or TLS are maintained at IETF and a google doc is not enough.

                                Until just recently, GnuPG only used weak KDFs, and it still defaults to KDF_ITERSALTED_S2K. age(1) has always used scrypt.

                                Yep, definitely. GnuPG should improve on that part. Still, storing private keys in software is a bad idea in general.

                                GnuPG’s MDC authentication is broken. age(1) ciphertext is authenticated with ChaCha20-Poly1305.

                                MDC was a product of its times and the work is underway for authenticated encryption in OpenPGP.

                                OpenPGP keys are not forward secret. There is an RFC draft (another one!), but it’s not without problems. However, age(1) keys are also not forward secret.

                                In some use-cases forward secrecy is a natural fit (like instant messaging) in others like long-time encrypted backups not so. Trivia: double-ratched protocols can be build on top of OpenPGP too: https://sequoia-pgp.gitlab.io/openpgp-dr/openpgp_dr/index.html

                                OpenPGP defines and supports old primitives, including RSA, DSA, MD5, SHA-1, IDEA, 3DES, CAST5, El Gamal, RIPEMD160, and many more. age(1) is highly opinionated, supporting only modern primitives of X25519, HKDF-SHA256, HMAC-SHA256, scrypt, RSAES-OAEP_SHA256, and the system CSPRNG.

                                Then how does encryption to SSH keys that are RSA-based work? E.g. I just tried age -R ~/.ssh/id_rsa.pub -a message and it worked just fine.

                                OpenPGP leaks metadata. age(1) only leaks its version format and public keys of recipients.

                                Interesting because OpenPGP packet containers contain version and key IDs too. And the link you added says just that so this similar to age?

                                The SKS keyservers are vulnerable to a plethora of vulnerabilities, thus killing the Web of Trust, killing the PGP Strong Set, and ultimately GnuPG ignoring all signatures coming from a keyserver. age(1) doesn’t and will not support signing or key distribution.

                                Web of Trust still works in small circles of technical people, for example see the kernel.org keysigning map. Note that even if SKS is broken it doesn’t mean that the WoT is broken since the signatures are “decentralized” (it’s possible to reconstruct it from SKS dumps). Some other distros use WoT “circles” like that too, see Arch Master Keys or Gentoo developer keys.

                                Age not supporting or even advertising any way of how keys can be retrieved or checked is avoiding an issue not a feature. I understand they don’t want to bloat the “main” project but this needs to be addressed somehow.

                                The goal of PGP was to protect email, and it turns out, email can’t be effectively protected. Email is fundamentally unsecurable. age(1) is strictly for encrypting files to other people (or yourself) using their (or your) public key, and that’s it.

                                Well, I did use age over e-mail the other day with a friend. It still leaked metadata through e-mail headers. Does it mean age is broken? Or if I say “no, PGP is only for file encryption” will the e-mail issue disappear? I don’t think so…

                                My 2 cents: PGP ecosystem has stagnated over the years. Other protocols, such as HTTP and TLS were properly upgraded to the XXI century and even got some exciting features (like Certificate Transparency). I believe it’s still possible to somehow modernize PGP and tools such as age show how it should be done. I just hope age, and signal, one-party-controlled solutions are not the last word.

                                1. 2

                                  what would you expect from a software modeled after PGP 2.x released in the 90s?

                                  Slow but serious improvements. Either by new commands and deprecation (like git switch) or by redoing the interface (ifconfig -> iproute2). It’s possible and was ignored.

                                  Then how does encryption to SSH keys that are RSA-based work?

                                  RSAES-OAEP_SHA256 was on the list.

                          1. 2

                            I think there is a typo in cyptdevice=

                            Not sure why sbctl is not mentioned and how it compares to the manual process but otherwise great post! I’ll check out bgrt_disable

                            1. 2

                              Yes, there is a typo! Thanks :)

                              Explaining secure boot signing felt out of scope for the blog post, which is more about simplifying the boot process with UEFI stubs more so then trying to cram everything into one post about a reasonable boot setup. You’ll notice that I only briefly mention the systemd-boot features along with discoverable partitions as everything would just be a huuuggee information overload.

                            1. 1

                              So… what should we use instead? WKD?

                              1. 3

                                Yes. WKD is the way to go in most circumstances but there is also a new type of keyservers that validate emails and allow key removal (e.g. due to GDPR). Check out https://keys.openpgp.org/

                                1. 1

                                  hmm great, I will have to take a look. Thanks.

                              1. 3

                                I believe Debian is one of the last bastions of the web of trust. Seems like it might fall soon. Somewhat sad to see it go.

                                1. 1

                                  While I can see that this may give such an impression at a quick glance, it’s only about package verification performed by apt. Debain maintainers and uploaders will still use OpenPGP to authenticate their artifacts. It is far from Debian abandoning OpenPGP or their set of trusted keys.

                                  1. 1

                                    Just to play devil’s advocate isn’t Debian slowly moving on replacing OpenPGP usage with their own schemes? E.g. key endorsements instead of the Web of Trust.

                                1. 3

                                  I have nothing ill to say of this project, but if you’re looking for a condemnation of the OpenPGP ecosystem, look no further than the encrypt() function definition here.

                                  /**
                                   * Encrypts message text/data with public keys, passwords or both at once. At least either encryption keys or passwords
                                   *   must be specified. If signing keys are specified, those will be used to sign the message.
                                   * @param {Object} options
                                   * @param {Message} options.message - Message to be encrypted as created by {@link createMessage}
                                   * @param {PublicKey|PublicKey[]} [options.encryptionKeys] - Array of keys or single key, used to encrypt the message
                                   * @param {PrivateKey|PrivateKey[]} [options.signingKeys] - Private keys for signing. If omitted message will not be signed
                                   * @param {String|String[]} [options.passwords] - Array of passwords or a single password to encrypt the message
                                   * @param {Object} [options.sessionKey] - Session key in the form: `{ data:Uint8Array, algorithm:String }`
                                   * @param {Boolean} [options.armor=true] - Whether the return values should be ascii armored (true, the default) or binary (false)
                                   * @param {Signature} [options.signature] - A detached signature to add to the encrypted message
                                   * @param {Boolean} [options.wildcard=false] - Use a key ID of 0 instead of the public key IDs
                                   * @param {Array<module:type/keyid~KeyID>} [options.signingKeyIDs=latest-created valid signing (sub)keys] - Array of key IDs to use for signing. Each `signingKeyIDs[i]` corresponds to `signingKeys[i]`
                                   * @param {Array<module:type/keyid~KeyID>} [options.encryptionKeyIDs=latest-created valid encryption (sub)keys] - Array of key IDs to use for encryption. Each `encryptionKeyIDs[i]` corresponds to `encryptionKeys[i]`
                                   * @param {Date} [options.date=current date] - Override the creation date of the message signature
                                   * @param {Array<Object>} [options.signingUserIDs=primary user IDs] - Array of user IDs to sign with, one per key in `signingKeys`, e.g. `[{ name: 'Steve Sender', email: 'steve@openpgp.org' }]`
                                   * @param {Array<Object>} [options.encryptionUserIDs=primary user IDs] - Array of user IDs to encrypt for, one per key in `encryptionKeys`, e.g. `[{ name: 'Robert Receiver', email: 'robert@openpgp.org' }]`
                                   * @param {Object} [options.config] - Custom configuration settings to overwrite those in [config]{@link module:config}
                                   * @returns {Promise<MaybeStream<String>|MaybeStream<Uint8Array>>} Encrypted message (string if `armor` was true, the default; Uint8Array if `armor` was false).
                                   * @async
                                   * @static
                                   */
                                  export async function encrypt({ message, encryptionKeys, signingKeys, passwords, sessionKey, armor = true, signature = null, wildcard = false, signingKeyIDs = [], encryptionKeyIDs = [], date = new Date(), signingUserIDs = [], encryptionUserIDs = [], config, ...rest }) {
                                  

                                  So simple, even Johnny can encrypt. (Surely nothing could go wrong!)

                                  Contrast this with age.

                                  1. 2

                                    age is the obvious replacement for OpenPGP, but it doesn’t have a JavaScript implementation (that I’ve found at least). Possibly a better replacement than OpenPGP.js would be TweetNaCl.js by Dmitry Chestnykh.

                                    export const encrypt = (json, key) => {
                                      const keyUint8Array = decodeBase64(key);
                                    
                                      const nonce = newNonce();
                                      const messageUint8 = decodeUTF8(JSON.stringify(json));
                                      const box = secretbox(messageUint8, nonce, keyUint8Array);
                                    
                                      const fullMessage = new Uint8Array(nonce.length + box.length);
                                      fullMessage.set(nonce);
                                      fullMessage.set(box, nonce.length);
                                    
                                      const base64FullMessage = encodeBase64(fullMessage);
                                      return base64FullMessage;
                                    };
                                    
                                    1. 1

                                      At the risk of self-promotion, I did provide a JS alternative that’s better than TweetNaCl on two fronts:

                                      1. Type-safety (keys are distinct types rather than just Uint8Arrays).
                                      2. Supports additional authenticated data (e.g. for context-binding for ciphertexts).

                                      It also handles encoding for you.

                                      1. 1

                                        Fair enough. However, to be a touch critical if I may, does Dhole Cryptography have an audit report? TweetNaCl.js was audited by Cure53 in 2017, and from the audit (also on the GitHub README):

                                        The overall outcome of this audit signals a particularly positive assessment for TweetNaCl-js, as the testing team was unable to find any security problems in the library. It has to be noted that this is an exceptionally rare result of a source code audit for any project and must be seen as a true testament to a development proceeding with security at its core.

                                        To reiterate, the TweetNaCl-js project, the source code was found to be bug-free at this point.

                                        […]

                                        In sum, the testing team is happy to recommend the TweetNaCl-js project as likely one of the safer and more secure cryptographic tools among its competition.

                                        Compare that to the audit of OpenPGP.js which appears to still have outstanding issues, or the wiki is out of date.

                                        1. 1

                                          Dhole Cryptography wraps sodium-plus, which defers to libsodium.js (or sodium-native if you install it alongside). Libsodium.js is compiled from libsodium, while sodium-native is an FFI wrapper for libsodium. Libsodium has been audited.

                                      2. 1

                                        age is the obvious replacement for OpenPGP

                                        Actually it would be more technically correct to say that age is a replacement for a subset of OpenPGP.js. For example, as far as I can see from the readme, age doesn’t sign encrypted files thus you can’t be sure who created the signed file. Age cannot be used to sign software binaries (for example). Age’s specification is a google doc compared to OpenPGP.js that is based on an IETF standard.

                                        1. 1

                                          True. age only supports encryption and decryption. It does not do any signing. For that, you should use minisign or signify.

                                          1. 1

                                            Yes, age for encryption/decryption, minisign/signifty for signing/verification. What should we use for key authentication though?

                                            OpenPGP.js allows building something like this: https://keyoxide.org/9f0048ac0b23301e1f77e994909f6bd6f80f485d where one can get more assurance that the key belongs to the person they think it should in an automatic, machine-readable way.

                                            1. 1
                                              1. 1

                                                I’m not familiar with Keyoxide, but it seems similar to Keybase and keys.pub. In practice though, the “web of trust” is broken.

                                      1. 2

                                        Does anyone have more info on the specifics of the “purposes other than what the root store is curated for” that this article doesn’t explicitly name?

                                          1. 2

                                            Thank you!

                                        1. 2

                                          Does anyone know why a GPG signing key was accessible to the CI environment in the first place? That strikes me as a little odd.

                                          1. 2

                                            I think it’s not uncommon for CI/CD systems to sign releases. It’s hard to make manual signatures with offline keys scale to really frequent releases. That being said, this is exactly why the practice is dangerous.

                                            1. 2

                                              When I set up CI/CD for a package to be published to Maven Central a few years ago, the requirement to sign gave me some anxiety from a security perspective but the benefits outweighed the risks.

                                              I wonder if there are any package management systems that support a secondary signature/attestation of the package. That is, CI/CD automation signs and releases but maintainers can also sign later as a second, human layer of authenticity.

                                              1. 1

                                                I think https://sigstore.dev/ is aiming at that kind of use case

                                                1. 1

                                                  I wonder if there are any package management systems that support a secondary signature/attestation of the package. That is, CI/CD automation signs and releases but maintainers can also sign later as a second, human layer of authenticity.

                                                  This would be really cool given that for OpenPGP it’s trivial to create multi signature file (just concatenate individual signatures). It’s also possible to notarize existing signature (signing a signature) e.g. when people want to certify that the CI signature is valid.

                                                  For builds that are completely reproducible it would be enough for the developer to sign their build and publish the signature with the artifact from the CI. Since the build is reproducible the signature would be over the same data.

                                            1. 2

                                              Code should be signed with hardware security modules (HSM)’s. Period. An HSM that is capable of code signing can be had for <100US$. Even if the pipeline builds in the cloud, it is nearly trivial to have an HSM plugged into a rack somewhere, and to leverage that to do online code signing.

                                              1. 3

                                                That requires hiring a rack, as most organisations would prefer using a VPS / Cloud infra as it is much more scalable, relocatable. I wonder if a TPM in a VPS will be an easier better solution.

                                                1. 2

                                                  Hiring a place in a rack can be done for <$50USD/mo. If you are signing code for substantial consumers/deployments, that cost will be vanishingly small. If you do not want to use any physical infrastructure, HSM’s are also available in AWS, although the cost is substantial for an individual. For an organization like HashiCorp, the cost of an AWS HSM is also vanishingly small. TPM would also definitely work, but this does require the key to be managed effectively in the clear on the internet, so some of the same exploit/supply-chain vector concerns apply if you’re using cloud vendors outside of the above offerings.

                                                  1. 1

                                                    I wonder if a TPM in a VPS will be an easier better solution.

                                                    Indeed. TPM is like a cheap, always connected HSM. Additionally with a little bit of effort one could seal the key to system configuration to protect against booting from unsupported configurations (e.g. livecd).

                                                    Additionally OpenPGP supports offline primary keys. In case the signing subkey has been compromised it can be revoked and a new one created without affecting the primary key and the key fingerprint.