IRC logs for #trustable for Thursday, 2017-02-16

*** AlisonChaiken has quit IRC01:39
*** AlisonChaiken has joined #trustable04:28
*** ctbruce has joined #trustable08:28
*** ctbruce has quit IRC09:00
*** ctbruce has joined #trustable09:02
*** Kinnison has joined #trustable11:42
KinnisonI was reading and reached something which I don't quite understand...11:42
KinnisonIn We can reproduce it: / Any deployment performed must be performed by automation - it is said:11:42
KinnisonThis 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 entirety11:43
KinnisonAnd if my assumptions are close to correct, that (b) it does not seem to follow on properly.11:43
KinnisonIs anyone here able to explain that a little better to me?11:43
jmacsIt's not my document, but software includes configuration details which are specific to the deployment, so it must change11:45
KinnisonOkay, 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
jmacsOh, yes, I don't see how that's implied11:47
* Kinnison can think of a clumsy wording to bring it into line; but will ponder further on something more streamlined11:48
KinnisonSince I think it's trying to say that the implication is that whatever causes changes during deployment must be change-managed by a trustable workflow11:48
persiaI agree.  That the changes must be managed by a reusable workflow is more precise than that it must be automated.12:38
persiaAnd, yes, it isn't at all obvious how automated deployment implies non-identical deployment.12:48
paulsherwoodKinnison: i've started a mustard for that document... would you be interested to send a patch?13:08
paulsherwoods/that document/that document and more/13:08
* paulsherwood thinks, though we need to avoid having that content live in two places lest they get out of step13:10
persiaThinking 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
persiaWhile it makes sense to assert that the answer is "No", that significantly complicates storage of user data on a given system.13:15
persiaBut if the answer is "yes", how can we know that the system remains trustable after such modification?13:16
Kinnisonpersia: 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
Kinnisonpaulsherwood: I might be able to, I shall take a look at that mustard.  Is it rendered anywhere?13:17
persiaKinnison: 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
Kinnisonpersia: 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 configuration13:23
persiaTrustable 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 is13:26
persiacompatible with how we typically interact with devices.13:26
persiaAnd 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
KinnisonI 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
KinnisonSo perhaps that kind of unvalidatable but must-be-believed information falls into one of those aspects13:28
persiaThat's an excellent way to state the nature of the issue that came to my mind :)13:29
KinnisonAfter 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
KinnisonTrust always requires some bootstrapping, but constraining and properly identifying those bootstrap trust elements can be sufficient to allow one to build on top of them13:30
persiaAnd 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
KinnisonI 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 example13: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 up13:32
persiaOr "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
persiaKinnison: Apologies for taking up more of your time (when you said you didn't have it).13:33
* Kinnison assumes this channel is logged13:33
Kinnisonpersia: I find it hard to avoid a good conversation; and while they are appreciated, no apologies are necessary :-)13:33
persiaThere is a bot in the channel that claims to place logs.  We've had some log loss in the past.13:33
KinnisonMy client retains logs for now, so if these get lost I can recover them for others13:34
persiaSeveral 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
KinnisonGreat, now you've got me thinking about blockchain IRC logging13:35
persiaHmm.  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
jmacsI don't think malicious falsification of an IRC log is likely enough to need a solution13:39
persiajmacs: 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
persiaUsing 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
jmacsI don't think we need that reliance in this case13:44
KinnisonIn this case, I think we can all trust our own logs, and only need them in order to re-discuss later anyway13:45
persiaI agree.13:45
Kinnisonsince there were no decisions or actions13:45
KinnisonWell, 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 IRC15:38
*** sambishop has quit IRC16:57
*** sambishop has joined #trustable17:02
*** toscalix has joined #trustable17:02
*** ctbruce has quit IRC17:20
*** toscalix has quit IRC17:22
*** AlisonChaiken has joined #trustable18:08
*** toscalix has joined #trustable21:57
*** toscalix has quit IRC22:52

Generated by 2.14.0 by Marius Gedminas - find it at!