| *** toscalix has joined #trustable | 08:50 | |
| reiterative | I'm thinking about how to *express* the Trustable requirements for asserting the provenance of evidence e.g. how we can have confidence that the evidence showing when and by whom a file was altered has not been tamper with. | 09:59 |
|---|---|---|
| reiterative | My current attempt is "The mechanisms used to generate and store t.evidence SHOULD be designed to prevent undetected alteration or fabrication of t.evidence", but that feels weak. | 10:00 |
| reiterative | Can anyone suggest how to improve it? | 10:00 |
| reiterative | We could, for example, require that the mechanisms are made public, so that anyone can evaluate how effective they are | 10:02 |
| reiterative | Or we could have a trusted third party assert that they are effective | 10:05 |
| reiterative | But these are strategies for accomplishing a goal: how should we describe that goal? | 10:05 |
| *** mattg has joined #trustable | 10:22 | |
| *** shaunmooney has joined #trustable | 10:25 | |
| persia | I think there are two different mechanisms in place that allow us to trust presented histories. Firstly, we need attribution of the submitter. This goes back to whether folk are required to authenticate and/or whether the association between the authentication and the submission is tracked. | 10:37 |
| persia | Secondly, we probably want some complex proof-of-work applied as we stitch histories together, such that it becomes overwhelmingly expensive to falsify the information. | 10:38 |
| persia | So, if we consider a single change, there are then three relevent questions: 1) Can we know the submitter, 2) Is there some proof-of-work to demonstrate the integrity of the change (e.g. a checksum for the change content), and 3) Does the change uniquely identify any prior history? | 10:40 |
| persia | If both (2) and (3) are true, once a chained history is developed, it quickly becomes very expensive to correctly calculate all the checksums for all the elements in such a way as to be correct, or maybe that requires not only unique identification of parent but also inclusion of the parent integrity checksum in the text of the change. | 10:41 |
| persia | (1) is fundamentally hard, but if we can capture (1) in a way that then provides checksums and can be wound into the history, we end up having confidence the information hasn't been compromised (but I'm not sure I know any systems that support this today) | 10:42 |
| persia | Right, for a history to be coherent, each change must include the checksum of the parent change. In the event that this is not the point at which the change is merged into history, an additional "merge" change is required in order to include the checksum of the point of actual merge. | 10:52 |
| persia | Although that feels very merkle: in the case of subversion, each change is assigned a monotonically increasing number at the time of submission, with an internal store that indicates the change, the submitter, and the branch to which the change applies, but all of that is only captured post-merge, which complicates things. | 10:54 |
| persia | That said, falsifying subversion history is something that can be done semi-manually with effort on the order of a few seconds per revision, so maybe that doesn't qualify as a "trustable" store. | 10:55 |
| persia | I've just spoken with someone who knows a lot more about subversion than I, and confirmed that the cost of falsification of revisions in a subversion repo is on the order of the number of commits, involving the calculation of a diff and checksum for each file in each revision in the repository, but no collissions must be calculated to male the history apparently authoritative. | 11:20 |
| persia | This is in constrast to git, where one must either generate a hash collission for the commit one wishes to change in the history, or generate hash collissions for any tags one has on the repository (which is more expensive than just generating the collission for the false commit). | 11:21 |
| persia | As a result, a subversion history does not satisfy the modified (3), which either means a) such a repository cannot be evaluated or b) such a respository scores very low on a trustable metric (because the only justification for trust is trust of the curator of the repository). | 11:23 |
| persia | Given that lots of stuff uses subversion in the wild (including things some folk consider "core" to systems development), I submit that maybe we can't actually require provable integrity of history as part of the base evidence for evaluation. | 11:24 |
| reiterative | That's kind of what I was driving at: given that we can't expect *any* mechanism to give us an absolute guarantee, and many existing mechanisms will fall short of even 'making it difficult to tamper', what should we actually require? | 11:29 |
| *** toscalix has quit IRC | 12:32 | |
| *** toscalix has joined #trustable | 13:08 | |
| persia | I think we don't actually want to require anything. Rather, we want to identify a set of properties for some base elements that could be used to describe a software development process, and then develop a level of confidence in the integrity of each of them. | 14:01 |
| persia | From this, we can determine whether the tooling used allows one to make statements about process compliance, and begin to evaluate policies in terms of whether they promote trustable objectives. | 14:02 |
| persia | I have also been thinking about the representation of artifacts, and I'm increasingly convinced that they do not matter in themselves. We may produce them for a wide range of reasons, but fundamentally we are not going to be able to rely on them unless they are used to produce a change or somehow included in a vote. | 14:03 |
| persia | In the case of artifacts that are used to generate changes, they simply become artefacts of the change history, representing a snapshot summary of changes from start to some merge point in that history. | 14:05 |
| persia | In the case of artifacts that are somehow included in a vote, I'm not sure we can usefully distinguish them from any other sort of vote comment. | 14:05 |
| persia | (although I don't know if the current best practices around storing votes happens to include a way to track named artifacts: it may be that such things would be passed by reference and the integrity preserved in some other data store, into which they were injected as changes). | 14:06 |
| persia | When consuming change-driven artifacts, I expect we can rely on most sensible stores to be able to produce a bit-for-bit correct representative snapshot, so long as we have a mechanism to ensure the integrity of each change in the history and the history itself. | 14:08 |
| persia | I'm less sure how to consume artifacts that might be in votes. Most systems provide this in a machine-readable format, but most of the content is either free form or only includes structure to link particular free-form strings to particular selections of change content (e.g. comments on specific line numbers). | 14:09 |
| *** mattg has quit IRC | 14:41 | |
| *** mattg has joined #trustable | 15:04 | |
| *** bwh has joined #trustable | 15:29 | |
| toscalix | bwh: published a few weeks ago at the public mailing list of the Civil Infrastructure Platform a Linux Kernel CVE-tracker for mainline and stable branches: https://gitlab.com/cip-project/cip-kernel/cip-kernel-sec | 15:35 |
| toscalix | he joined this channel, in case you want to ask him about it. | 15:35 |
| persia | Cool. | 15:42 |
| persia | More on artifacts: one way to consider artifacts is their reproducibility: in general, when we create an artifact, it is appropriate to ensure we can reproduce it. Where we do not have a means to reproduce it directly, the artifact should be placed in a store (from which it can be reproduced, either because it is physcally present or because the store has a delta mechanism capable of reproducing the introducedd bitstream). When an artifact can be | 15:45 |
| persia | reproduced (either because in a store or because inherently reproducible), it may be appropriate to additionally cache it (to reduce the work required for reproduction). I don't think whether one caches an artifact is important in terms of evaluation of a process, so long as one is able to produce any defined artifact required for either further processing and/or evidence on request. | 15:45 |
| *** traveltissues has joined #trustable | 16:36 | |
| *** traveltissues has quit IRC | 16:41 | |
| *** traveltissues has joined #trustable | 16:44 | |
| *** coldtom has quit IRC | 18:11 | |
| *** adds68 has quit IRC | 18:11 | |
| *** shaunmooney has quit IRC | 18:11 | |
| *** ikerperez has quit IRC | 18:11 | |
| *** adds68 has joined #trustable | 18:15 | |
| *** shaunmooney has joined #trustable | 18:27 | |
| *** bwh has quit IRC | 18:38 | |
| *** paulsherwood has quit IRC | 18:38 | |
| *** reiterative has quit IRC | 19:03 | |
| *** chrispolin- has quit IRC | 19:03 | |
| *** johnward has quit IRC | 19:03 | |
| *** laurence- has quit IRC | 19:03 | |
| *** mattg has quit IRC | 19:05 | |
| *** chrispolin- has joined #trustable | 19:06 | |
| *** johnward has joined #trustable | 19:06 | |
| *** laurence- has joined #trustable | 19:06 | |
| *** reiterative has joined #trustable | 19:08 | |
| *** shaunmooney has quit IRC | 19:14 | |
| *** adds68 has quit IRC | 19:14 | |
| *** reiterative has quit IRC | 19:16 | |
| *** laurence- has quit IRC | 19:16 | |
| *** toscalix has quit IRC | 19:16 | |
| *** laurence- has joined #trustable | 19:17 | |
| *** bwh has joined #trustable | 19:18 | |
| *** reiterative has joined #trustable | 19:21 | |
| *** coldtom has joined #trustable | 19:42 | |
| *** milloni has quit IRC | 20:27 | |
| *** milloni has joined #trustable | 20:27 | |
| *** adds68 has joined #trustable | 20:58 | |
| *** traveltissues has quit IRC | 21:10 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!