| *** AlisonChaiken has quit IRC | 01:39 | |
| *** AlisonChaiken has joined #trustable | 04:28 | |
| *** ctbruce has joined #trustable | 08:28 | |
| *** ctbruce has quit IRC | 09:00 | |
| *** ctbruce has joined #trustable | 09:02 | |
| *** Kinnison has joined #trustable | 11:42 | |
| Kinnison | Hello | 11:42 |
|---|---|---|
| Kinnison | I was reading https://gitlab.com/trustable/overview/wikis/hypothesis-for-software-to-be-trustable and reached something which I don't quite understand... | 11:42 |
| Kinnison | In We can reproduce it: / Any deployment performed must be performed by automation - it is said: | 11:42 |
| Kinnison | This implies that some trustable software does not have identical state after deployment. | 11:42 |
| * Kinnison doesn't quite understand (a) what that means in its entirety | 11:43 | |
| Kinnison | And if my assumptions are close to correct, that (b) it does not seem to follow on properly. | 11:43 |
| Kinnison | Is anyone here able to explain that a little better to me? | 11:43 |
| jmacs | It's not my document, but software includes configuration details which are specific to the deployment, so it must change | 11:45 |
| Kinnison | Okay, then it makes sense to say that trustable software may differ between deployments, but how does that follow from "any deployment performed must be performed by automation" ? | 11:46 |
| * Kinnison really likes that document otherwise; but that one bit jars :-( | 11:46 | |
| jmacs | Oh, yes, I don't see how that's implied | 11:47 |
| * Kinnison can think of a clumsy wording to bring it into line; but will ponder further on something more streamlined | 11:48 | |
| Kinnison | Since I think it's trying to say that the implication is that whatever causes changes during deployment must be change-managed by a trustable workflow | 11:48 |
| persia | I agree. That the changes must be managed by a reusable workflow is more precise than that it must be automated. | 12:38 |
| persia | And, yes, it isn't at all obvious how automated deployment implies non-identical deployment. | 12:48 |
| paulsherwood | Kinnison: i've started a mustard for that document... would you be interested to send a patch? | 13:08 |
| paulsherwood | s/that document/that document and more/ | 13:08 |
| paulsherwood | https://gitlab.com/trustable/trustable-mustard/blob/master/requirements/trustable.yaml | 13:09 |
| * paulsherwood thinks, though we need to avoid having that content live in two places lest they get out of step | 13:10 | |
| persia | Thinking more about deployments, and how that interacts with updates: do we believe it is possible to have a trustable system in which a deployment may be modified post-deployment by a non-trustable process? | 13:14 |
| persia | While it makes sense to assert that the answer is "No", that significantly complicates storage of user data on a given system. | 13:15 |
| persia | But if the answer is "yes", how can we know that the system remains trustable after such modification? | 13:16 |
| Kinnison | persia: perhaps if untrustable data is ringfenced and there are appropriate validatable requirements in place which mean that the trustable components of the system remain so in the presence of untrustable inputs? | 13:17 |
| Kinnison | paulsherwood: I might be able to, I shall take a look at that mustard. Is it rendered anywhere? | 13:17 |
| paulsherwood | https://mustard.trustable.io/trustable-mustard/HEAD/requirements | 13:18 |
| Kinnison | nice | 13:18 |
| Kinnison | thanks | 13:18 |
| paulsherwood | :) | 13:18 |
| persia | Kinnison: I think that's a sensible basis for a new stanza, to support user data. I'm still not certain what to do with personalisation data (e.g. some IaaS nodeid, received IP address, accessible ICCID, MAC, etc.) | 13:21 |
| Kinnison | persia: Mmm, runtime reconfiguration rather than deployment time reconfiguration would need further thought, sadly I'm not in a position to give it much right now; though the things which spring to mind are around trustable orchestration configuration | 13:23 |
| persia | Trustable orchestration makes sense to address some of it. The two cases I was thinking about were a) instantiating an instance in a cloud, and b) setting up a new phone. In (A), the IaaS substrate assigns information to the system and in (B), the physical substrate assigns information to the system. While it *may* be possible to construct a trustable IaaS substrate, I cannot think of any way to construct a trustable physical substrate that is | 13:26 |
| persia | compatible with how we typically interact with devices. | 13:26 |
| persia | And for both (A) and (B), there are environmental issues (like IP assignment) which fall nicely between user data (that can be ringfenced) and orchestrated configuration. | 13:28 |
| Kinnison | I think that trust has, as a core part of it, an understanding of the limits of the trust and the constraints of it. | 13:28 |
| persia | (and, while IP can be (to some degree) orchestrated by OOB trustable orchestration and static configuration, that is harder with things like ESSID) | 13:28 |
| Kinnison | So perhaps that kind of unvalidatable but must-be-believed information falls into one of those aspects | 13:28 |
| persia | That's an excellent way to state the nature of the issue that came to my mind :) | 13:29 |
| Kinnison | After all, we build trust by steps such as "Given I trust $foo, and $bar, I can trust $baz because I see how it flows" which lends one the ability to say "Given I trust that the hardware will not fake its MAC on boot, and I trust that the OS will read the MAC once and then maintain it securely, I can believe the system when it reports its MAC address" | 13:30 |
| Kinnison | Trust always requires some bootstrapping, but constraining and properly identifying those bootstrap trust elements can be sufficient to allow one to build on top of them | 13:30 |
| persia | And I suppose we can use ringfencing to assert things like "I trust the USB identifier will not be constructed in such a way as to overwrite kernel memory to cause unexpected runtime behaviour". | 13:31 |
| Kinnison | I think I'd rather say "I trust that no matter how the USB identifier is constructed, the driver will not allow it to overwrite kernel memory..." but yes, that's an extreme example | 13:32 |
| * Kinnison goes to try and make notes about the thing he came here to say, so that at some point a coherent change might turn up | 13:32 | |
| persia | Or "This (specific) device can be trusted because it has always been in environments that are trusted. If the device were to be placed somewhere where many had physical access, it may have been changed in an untrusted way (unless we have data showing otherwise). | 13:33 |
| persia | Kinnison: Apologies for taking up more of your time (when you said you didn't have it). | 13:33 |
| Kinnison | :-) | 13:33 |
| * Kinnison assumes this channel is logged | 13:33 | |
| Kinnison | persia: I find it hard to avoid a good conversation; and while they are appreciated, no apologies are necessary :-) | 13:33 |
| persia | There is a bot in the channel that claims to place logs. We've had some log loss in the past. | 13:33 |
| Kinnison | My client retains logs for now, so if these get lost I can recover them for others | 13:34 |
| persia | Several others in the channel also log, and we've relied on those to restore lost logs in the past, but since we're talking about trust :) | 13:35 |
| Kinnison | Great, now you've got me thinking about blockchain IRC logging | 13:35 |
| Kinnison | :-P | 13:35 |
| persia | Hmm. That would work. Probably needs some client support. That said, for now, I think it makes more sense to concentrate on the ability to produce trustable software, without which most trustable communications mechanisms may be suspect. | 13:37 |
| Kinnison | :-) | 13:38 |
| jmacs | I don't think malicious falsification of an IRC log is likely enough to need a solution | 13:39 |
| persia | jmacs: Depends on the context. The profession of "court reporter" is based on the idea of providing a referenceable assertion trail for contentious conversations. | 13:43 |
| persia | Using a communications mechanism that provides all parties with the ability to trust the sequence and content of statements means that we have less reliance on either a human reporter or a state to assert the reporter is accurate. | 13:43 |
| jmacs | I don't think we need that reliance in this case | 13:44 |
| Kinnison | In this case, I think we can all trust our own logs, and only need them in order to re-discuss later anyway | 13:45 |
| persia | I agree. | 13:45 |
| Kinnison | since there were no decisions or actions | 13:45 |
| Kinnison | Well, no actions other than one on me to make notes so I don't forget, which I have now done :-) | 13:45 |
| *** AlisonChaiken has quit IRC | 15:38 | |
| *** sambishop has quit IRC | 16:57 | |
| *** sambishop has joined #trustable | 17:02 | |
| *** toscalix has joined #trustable | 17:02 | |
| *** ctbruce has quit IRC | 17:20 | |
| *** toscalix has quit IRC | 17:22 | |
| *** AlisonChaiken has joined #trustable | 18:08 | |
| *** toscalix has joined #trustable | 21:57 | |
| *** toscalix has quit IRC | 22:52 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!