I did not see that pull request. Note however that the pull request makes qubes-secpack depend on the blockchain in order to prove information creation *after* a certain point in time, while my suggestion was the opposite: make the blockchain depend on qubes-secpack in order to prove information creation *before* a certain point in time.
I think we should have both. Other things than just canaries can benefit from being locked into a narrow time period. Maybe it makes sense to have a folder in qubes-secpack with timing proofs. They would be of two types: * A proof of freshness, including the last 10 bitcoin block hashes. * A proof of existence, including the identifier of a bitcoin transaction that includes the hash of either the last git commit, or a more elaborate statement. IMPORTANT NOTE: As far as I understand, git tags, signed or not, are not part of the actual commits. If so, proof of existence must also include the tag signatures. Regularly making such timing proofs part of the commit chain will lock all changes in that repository into a narrow period of time. Each commit is provably created after all proofs of freshness committed before or included in it, and before all proofs of existence committed after it. Ideally, every important commit, such as a release digest or canary, should be directly preceded by, or include, a proof of freshness and directly followed by a proof of existence. On Sunday, June 4, 2017 at 6:50:57 AM UTC+2, Andrew David Wong wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 2017-06-03 10:24, Axel wrote: > > As Joanna has already noted, qubes-secpack is not advertised as > > solving all problems related to distribution security, but "the > > best we can do" currently. > > > > I'd like to suggest a practical improvement of qubes-secpack that > > I believe can protect against a (rather limited) class of threats > > including some forced private key hand-over and insider threats. > > > > *The scheme:* > > > > The idea is to publish hashes of git commits, and maybe also of > > detached signatures, to the bitcoin blockchain. This will serve as > > a reasonable secure proof that the information was created > > *before* a certain point in time. In addition to the proof of > > freshness, this locks the information into a *narrow time frame*. > > [...] > > Have you seen this? > > https://github.com/QubesOS/qubes-issues/issues/2685 > https://github.com/QubesOS/qubes-secpack/pull/15 > > - -- > Andrew David Wong (Axon) > Community Manager, Qubes OS > https://www.qubes-os.org > -----BEGIN PGP SIGNATURE----- > > iQIcBAEBCgAGBQJZM5GnAAoJENtN07w5UDAwFiAQAMbzWLx+/hIAoeh5AF5cSsRA > 1/zMy5S/CC+0zdY3APhZibIZHfEkqN3ZN9IkeccMDEjIpmAfPEOLjoRIx7pWJfl8 > nLNtxZyAZAP4zpVsg4Efw4CYk+ZRu9TAfgLjBDJbtyKf2tEhVYnv/htgpbe+dLxL > UCy6XrVNnOZThm1/c8MSe/SeP2J/2YHQFYBBlJkXTOh8K/JbwHHG2muUYZhjR/oR > bZ9Ecr5bzY48uSU7E8POB8slE/dedYYlCCb3i4LnxLCazeQPuetbatYOWEaARUdJ > MI1hnRqya1GS+oQwFetVm8pT8rymerxYgNSJZNI7bhr4fZUDVEFUnSFLJKcOmiU8 > UqigzwdfMMdZJzU+gVKooDsYlQs9loMyddLbYTUODKGTOrt/3ZD69bCU8fitFM1S > SZRvsiwQ9wPTmaFYu4FVYz1yxl1jmHrky2cWntZ4rULlb+ODzZgpIuOeDURXPnG9 > 5DTBmEoc9EK8Zmu2fVcMYOyTrl2KQ2g7nyLvjCl+hRm4VaXhf25aBjimHzWrCyg9 > 6++GuyGk4E6iJGO/umYdIg9+BfetOZSY7lcNf8EI3afQv/ORh/MM29QFplGFaoD6 > TnI+c9fhLmLK9JLoSBjAMhVt6+IvuFKlIOptLu16Xo87s1wjcdGh1fnrBctggzr2 > gE0zDuA2/SGm7mNHBy9Y > =q6rH > -----END PGP SIGNATURE----- > > -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/df384061-b35f-4cb5-8c57-f6c255724414%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
