{"action":"created","issue":{"url":"https://api.github.com/repos/djc/quinn/issues/94","repository_url":"https://api.github.com/repos/djc/quinn","labels_url":"https://api.github.com/repos/djc/quinn/issues/94/labels{/name}","comments_url":"https://api.github.com/repos/djc/quinn/issues/94/comments","events_url":"https://api.github.com/repos/djc/quinn/issues/94/events","html_url":"https://github.com/djc/quinn/pull/94","id":383608978,"node_id":"MDExOlB1bGxSZXF1ZXN0MjMzMDM3NjE1","number":94,"title":"Retain sealing and opening key","user":{"login":"stammw","id":6791052,"node_id":"MDQ6VXNlcjY3OTEwNTI=","avatar_url":"https://avatars3.githubusercontent.com/u/6791052?v=4","gravatar_id":"","url":"https://api.github.com/users/stammw","html_url":"https://github.com/stammw","followers_url":"https://api.github.com/users/stammw/followers","following_url":"https://api.github.com/users/stammw/following{/other_user}","gists_url":"https://api.github.com/users/stammw/gists{/gist_id}","starred_url":"https://api.github.com/users/stammw/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/stammw/subscriptions","organizations_url":"https://api.github.com/users/stammw/orgs","repos_url":"https://api.github.com/users/stammw/repos","events_url":"https://api.github.com/users/stammw/events{/privacy}","received_events_url":"https://api.github.com/users/stammw/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2018-11-22T16:50:33Z","updated_at":"2018-11-25T22:51:12Z","closed_at":null,"author_association":"CONTRIBUTOR","pull_request":{"url":"https://api.github.com/repos/djc/quinn/pulls/94","html_url":"https://github.com/djc/quinn/pull/94","diff_url":"https://github.com/djc/quinn/pull/94.diff","patch_url":"https://github.com/djc/quinn/pull/94.patch"},"body":"Here is a pretty trivial solution for #17. Is it what you expected ?\r\n\r\nSimilarly to #92, built keys and the data used to build them could be constructed wrongly by using a bad `CryptoContext { ... }`. I propose to move key and `CrytpoState` building logic into a `CryptoContext::new()` method to prevent this from happening.\r\n\r\nEverything would be easier with all the key types implementing `Clone`. I'll see what can be done on this side. But I wonder why it is not already the case?"},"comment":{"url":"https://api.github.com/repos/djc/quinn/issues/comments/441481222","html_url":"https://github.com/djc/quinn/pull/94#issuecomment-441481222","issue_url":"https://api.github.com/repos/djc/quinn/issues/94","id":441481222,"node_id":"MDEyOklzc3VlQ29tbWVudDQ0MTQ4MTIyMg==","user":{"login":"Ralith","id":104558,"node_id":"MDQ6VXNlcjEwNDU1OA==","avatar_url":"https://avatars2.githubusercontent.com/u/104558?v=4","gravatar_id":"","url":"https://api.github.com/users/Ralith","html_url":"https://github.com/Ralith","followers_url":"https://api.github.com/users/Ralith/followers","following_url":"https://api.github.com/users/Ralith/following{/other_user}","gists_url":"https://api.github.com/users/Ralith/gists{/gist_id}","starred_url":"https://api.github.com/users/Ralith/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Ralith/subscriptions","organizations_url":"https://api.github.com/users/Ralith/orgs","repos_url":"https://api.github.com/users/Ralith/repos","events_url":"https://api.github.com/users/Ralith/events{/privacy}","received_events_url":"https://api.github.com/users/Ralith/received_events","type":"User","site_admin":false},"created_at":"2018-11-25T22:51:12Z","updated_at":"2018-11-25T22:51:12Z","author_association":"COLLABORATOR","body":"Another option might be to not keep `CryptoState`s around at all; store the secrets and IVs directly in the `CryptoContext, and construct the suitable AEAD key types. You'd probably want to tweak `CryptoState::update` to replace the `&self` argument with `secret: &[u8]` to make this convenient."}}
{"actor":{"display_login":"Ralith"}}