| 7 Jan 2021 |
 dpc | cargo-crev is using public key crypto, so if you're going to use it only for verification somewhere you can just use --for-id argument just like it's recommended to do in the CI | 16:02:27 |
| dpc | You could generate identity in one machine, then export it to the other ones and just never enter the passphrase on them. | 16:03:30 |
| dpc | The private key is wrapped with a passphrase. | 16:03:55 |
| dpc | You could probably also replace the private key in the exported file with garbage and then it would work except you can't really ever unlock it and sign anything with such a copy of your private ID. | 16:04:39 |
| dpc | Another approach is to just generate one ID on each VM/computer, and use the security hardened ID to trust all sub-IDs, and trust the hardened ID with all the sub-IDs. Use the same git url for all IDs, and even manually copy the signing proofs from the offline hardened VM to publish them. This still makes it possible to have a compromised sub-ID, but it can then be selectively untrusted. | 16:10:19 |
| dpc | This pretty much simulates what an organization would do. | 16:11:43 |
 Martin Habovštiak (Gitter) | Thanks! I'm not sure which approach I like the most right now. If I find that some tweaks would be needed to support it better would you accept PRs for such changes? | 16:58:44 |
| dpc | Sure I would. | 16:59:04 |
| Martin Habovštiak (Gitter) | Awesome! I suspect that I will go with the former approach and perhaps make a change to not require private key at all and adding an option to export without private key | 17:00:04 |
| dpc | There's a id export (or something like that) command and id import. | 17:00:34 |
| dpc | So you could add the switch to export, and make sure import doesn't complain. We might also want to indicate that the OwnId was ... I don't even know what the right word is. | 17:01:23 |
| dpc | Neutered? | 17:01:27 |
| Martin Habovštiak (Gitter) | Yeah, that was my thinking too | 17:10:44 |
| Martin Habovštiak (Gitter) | I'm also considering making a separate tool for Qubes specifically. It can live in my repo or in the org if you like. However to make it work well, it'd be best if signing commands could redirect their operations to external programs. The receiving service would sanitize the input and show the signing request in a way that can be reliably verified (open editor/IDE in case of review) and confirmed/rejected | 17:14:34 |
| Martin Habovštiak (Gitter) | I remember Peter Todd giving a talk about issues around software verification and he happens to use Qubes and Rust too. I'll ask him if he's interested in helping. | 17:17:21 |
| dpc | Great idea. | 18:07:54 |
| dpc | Though at this level of effort you might just add pgp signing support and use a hardware key | 18:08:27 |
| 8 Jan 2021 |
| Martin Habovštiak (Gitter) | TBH I think that Qubes isolation is better design than HW key. HW key protects against stealing the key but doesn't protect against fake signatures. (Computer screen showing a different code than what's actually signed.) Qubes can protect against this reasonably well. Yes, reviewing the code in a clean VM is required and would be part of the design. | 09:17:46 |
 tao_oat | just an update: work on npm-crev is progressing, albeit not super fast! next steps are:
- generating IDs
- integration tests to make sure that
crev verify is working correctly
- pushing proof repos
- support for npm <7 and yarn
- lots more!
| 18:59:07 |
| tao_oat | there are also quite a few details (such as: how is a "pass/fail/none" result calculated) that it's probably best to keep consistent across implementations. finally, npm/yarn don't have modules like cargo seems to, so the binary for this will probably just be called npm-crev or crev unless someone has a better idea! | 19:11:51 |
| dpc | I'm very happy to hear that crev-npm is going forward! | 20:46:50 |
| dpc | What is considered pass/fail/none does not have to be the same, even between people. It's already one of the most configurable thing. Depending on someone use-case, etc. there will probably be multiple strategies and algorithms. | 20:47:35 |
| dpc | Every user gathers a graph of who trust whom, and even at that point has already subjective view of the world. Then it's up to them to determine ho much overlapping reviews etc. they require to consider something "good enough". | 20:48:40 |
| 9 Jan 2021 |
|  Jörg Sommer joined the room. | 11:15:15 |
| tao_oat | that makes a lot of sense. configurability will have to come once the basics are down, but this sounds like an important one! | 17:03:21 |
| 14 Jan 2021 |
| tao_oat | Redacted or Malformed Event | 18:39:08 |
| tao_oat | Redacted or Malformed Event | 18:40:58 |
| tao_oat | Redacted or Malformed Event | 19:06:17 |
| 20 Jan 2021 |
|  gitter-badger (The Gitter Badger) joined the room. | 06:23:19 |
|  The Astrally Forged joined the room. | 10:48:31 |
