{"action":"created","issue":{"url":"https://api.github.com/repos/NixOS/rfcs/issues/34","repository_url":"https://api.github.com/repos/NixOS/rfcs","labels_url":"https://api.github.com/repos/NixOS/rfcs/issues/34/labels{/name}","comments_url":"https://api.github.com/repos/NixOS/rfcs/issues/34/comments","events_url":"https://api.github.com/repos/NixOS/rfcs/issues/34/events","html_url":"https://github.com/NixOS/rfcs/pull/34","id":365167104,"node_id":"MDExOlB1bGxSZXF1ZXN0MjE5MTY5NzA3","number":34,"title":"[RFC 0034] Expression Integrity","user":{"login":"lrvick","id":69200,"node_id":"MDQ6VXNlcjY5MjAw","avatar_url":"https://avatars2.githubusercontent.com/u/69200?v=4","gravatar_id":"","url":"https://api.github.com/users/lrvick","html_url":"https://github.com/lrvick","followers_url":"https://api.github.com/users/lrvick/followers","following_url":"https://api.github.com/users/lrvick/following{/other_user}","gists_url":"https://api.github.com/users/lrvick/gists{/gist_id}","starred_url":"https://api.github.com/users/lrvick/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/lrvick/subscriptions","organizations_url":"https://api.github.com/users/lrvick/orgs","repos_url":"https://api.github.com/users/lrvick/repos","events_url":"https://api.github.com/users/lrvick/events{/privacy}","received_events_url":"https://api.github.com/users/lrvick/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":48,"created_at":"2018-09-29T21:08:02Z","updated_at":"2018-10-03T02:51:22Z","closed_at":null,"author_association":"NONE","pull_request":{"url":"https://api.github.com/repos/NixOS/rfcs/pulls/34","html_url":"https://github.com/NixOS/rfcs/pull/34","diff_url":"https://github.com/NixOS/rfcs/pull/34.diff","patch_url":"https://github.com/NixOS/rfcs/pull/34.patch"},"body":""},"comment":{"url":"https://api.github.com/repos/NixOS/rfcs/issues/comments/426495347","html_url":"https://github.com/NixOS/rfcs/pull/34#issuecomment-426495347","issue_url":"https://api.github.com/repos/NixOS/rfcs/issues/34","id":426495347,"node_id":"MDEyOklzc3VlQ29tbWVudDQyNjQ5NTM0Nw==","user":{"login":"Ekleog","id":411447,"node_id":"MDQ6VXNlcjQxMTQ0Nw==","avatar_url":"https://avatars1.githubusercontent.com/u/411447?v=4","gravatar_id":"","url":"https://api.github.com/users/Ekleog","html_url":"https://github.com/Ekleog","followers_url":"https://api.github.com/users/Ekleog/followers","following_url":"https://api.github.com/users/Ekleog/following{/other_user}","gists_url":"https://api.github.com/users/Ekleog/gists{/gist_id}","starred_url":"https://api.github.com/users/Ekleog/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Ekleog/subscriptions","organizations_url":"https://api.github.com/users/Ekleog/orgs","repos_url":"https://api.github.com/users/Ekleog/repos","events_url":"https://api.github.com/users/Ekleog/events{/privacy}","received_events_url":"https://api.github.com/users/Ekleog/received_events","type":"User","site_admin":false},"created_at":"2018-10-03T02:51:22Z","updated_at":"2018-10-03T02:51:22Z","author_association":"NONE","body":"@zimbatm \r\n\r\nI very much want nixpkgs to be completely signed as soon as possible (well, have been complaining about it in private with friends since for… a bit more than 2 years). But I do agree with @oxij: if we try to hurry things it won't be any good.\r\n\r\nIn my opinion we should start raising awareness among maintainers that it's important to sign things. I think some communications from well-known community members to the maintainers (and esp. committers) would help on this (maybe there should be a maintainer ML and a committer ML, BTW? but that's off-topic here). The important point being to always say people not to hurry, but to take their time understanding OpenPGP and how their client (likely GnuPG) work, and then to generate a key. Linking to [this page](https://riseup.net/en/security/message-security/openpgp/best-practices) (as well as others from the menu on the left) will likely help. (and maybe the two points below in my answer to @oxij)\r\n\r\nOnce people have read things, maybe tried things in private and feel confident they can actually handle OpenPGP keys safely, they should be encouraged to add their fingerprints like https://github.com/NixOS/nixpkgs/pull/47663.\r\n\r\nOnce we can see most committers have added their fingerprints, we'll be able to proceed forward. At this point in time, I guess we'll be able to see whether `git-signatures` is ready or not :)\r\n\r\n@oxij \r\n\r\n> - NixOS is not Linux, we need something like https://github.com/Ekleog/signed-git/blob/master/git-hooks/check-range-signed.sh, which, I would expect, also needs some work before it can be used by everyone,\r\n\r\nI can confirm, it needs at least:\r\n * Another pair of eyes than mine to check security\r\n * A user interface expanded to verifying fetches, as currently I've only written [a `pre_push` hook](https://github.com/Ekleog/signed-git/blob/master/git-hooks/pre-push)\r\n\r\n> But please pass everything you generate via GPG and want to publish through `gpg --list-packets` and `gpg --show-key` and read and understand all of the output! E.g. I published things I didn't want to publish to keyservers several times.\r\n\r\nWhile I can only agree it's useful for complex uses of GnuPG, I don't think there's a need for this for a workflow as simple as “generate a key, sign commits”. I think the things people mostly need to be aware of are:\r\n * Backup at least the master key **in a secure place** (and preferably encrypted, potentially with `sss` with parts of the key on papers given to your friends if you fear forgetting the encryption passphrase)\r\n * Do not sign anything you do not understand\r\n\r\n> I'm also thinking we can support not only \"change\" signature, but also \"state\" signature. I.e. a signature that says you are reasonably sure everything in the repo is good at that revision (you can still resign with a negative state if you find a problem in the history before that commit later). Paranoid people wouldn't trust these for a huge project like nixpkgs, but it should be good enough for casual users, also fast.\r\n\r\nWell, “state” signatures is more or less what I was proposing by signing every commit between “backdoor introduced” and a “backdoor removed” commits, isn't it? Except I was proposing that every commit defaults to a “safe” state, and must be individually tagged “unsafe”. Which would completely remove the need for a state machine in the signature verification code.\r\n\r\n>>  Overall, I think the cost of signing as bad-commits all the commits between a compromise and its fix isn't that high, compared to the cost in re-checking all the history on a new nixpkgs fetch.\r\n>\r\n> But it accumulates costs in git-notes branches.\r\n\r\nIndeed… though it only happens when a backdoor is introduced, so I'd hope never, so the cost in storage space wouldn't be that high.\r\n\r\nWell, unless willing to force all CVE handling through this mechanism, but… I'm not really fond of this idea. IMO CVE detection should be off-band, as when I fetch my nixpkgs I most often update to the latest version too, and latest version would likely not yet contain too many known CVEs -- to me the need for CVE tracking is mostly on a running system, to tell it to update because a CVE has been found.\r\n\r\n> It would create a lot of conflicts if random contributors would do reviews, not that big of a problem for maintainers, you would only get a conflict if two people notice a compromise at the same time, the later person will get an error on push and can then resolve as usual in git.\r\n\r\nGood point. Then, to make resolving easier, @lrvick had the good point that if each note is stored on a line, then the `cat_sort_uniq` merge strategy would actually handle the merge automatically. However, with the data format you imagine, this wouldn't be possible. I think if storing each signature on a 1-line JSON object (yeah, coming back to it, sorry ^^') it would enable both easy parsing in basically any language (split the notes at LF, send to JSON parser) and easy merging (cat_sort_uniq)."}}
{"actor":{"display_login":"Ekleog"}}