| 15 Jan 2022 |
 cde | I came across https://theupdateframework.io/
The Update Framework (TUF) helps developers maintain the security of software update systems, providing protection even against attackers that compromise the repository or signing keys.
| 03:42:13 |
| cde | The entire framework might be too much for us, but I was going through https://theupdateframework.io/security/ - and it seemed useful | 03:43:01 |
| cde | https://wiki.laptop.org/go/Canonical_JSON | 03:45:30 |
| cde | https://theupdateframework.io/metadata/
This is really good
The timestamp.json metadata file lists the hashes and size of the snapshot.json file. This is the first and potentially only file that needs to be downloaded when clients search for updates. It is frequently re-signed, and has a short expiration date, thus allowing clients to quickly detect if they are being prevented from obtaining the most recent metadata. An online key is generally used to automatically re-sign this file at regular intervals.
| 03:57:14 |
| 16 Jan 2022 |
|  mimi89999 left the room. | 05:34:24 |
| mimi89999 joined the room. | 05:34:47 |
 Sylvia | Does anyone speak French? Someone just made 4 topics on the forum and I think they just don't really understand how to use a forum but it's chaotic :P | 22:06:15 |
![@_oftc_Licaon_Kter[xmpp]:matrix.org](./avatar/Licaon_Kter%5Bxmpp%5D) Licaon_Kter[xmpp] | Online translators don't help? | 22:29:25 |
| Sylvia | Well they helped shape the conclusion I got to | 22:44:05 |
| 17 Jan 2022 |
 _hc | In reply to @cdesai:matrix.org
https://theupdateframework.io/metadata/
This is really good
The timestamp.json metadata file lists the hashes and size of the snapshot.json file. This is the first and potentially only file that needs to be downloaded when clients search for updates. It is frequently re-signed, and has a short expiration date, thus allowing clients to quickly detect if they are being prevented from obtaining the most recent metadata. An online key is generally used to automatically re-sign this file at regular intervals.
The Update Framework analysis papers were very helpful in the 2016 bazaar2 round of work, and writing up the security model. I can recommend them. Their software would be good to use if starting a project from scratch, but it is poorly suited for use in running projects because it has strong opinions about architecture. | 07:31:51 |
| _hc | also, I've meet with them a few times over the years, they are doing interesting stuff with reproducible builds, and follow F-Droid as well | 07:32:27 |
| cde | In reply to @eighthave:matrix.org
The Update Framework analysis papers were very helpful in the 2016 bazaar2 round of work, and writing up the security model. I can recommend them. Their software would be good to use if starting a project from scratch, but it is poorly suited for use in running projects because it has strong opinions about architecture. agree about the from scratch bit - that's why I linked to certain pages specifically, as general practices to follow, and copy if it might fit. The timestamp.json looks quite similar to the 'list of diffs' file being talked about - and also the idea I mentioned about having the client only check a tiny file all the time. | 12:56:06 |
| cde | In reply to @cdesai:matrix.org
something simple like
if (firstRun && noIndex)
minimalIndex
else
sameAsBefore
could work
jochensp: I tried to look a bit at this over the weekend and I don't think it's going to be trivial for the client :(
Won't be too much work but I wasn't able to do a quick patch either. | 12:56:53 |
 grote | I'd say we do the full v2 index first and if there's time, we can still make the client handle a reduced version. | 13:08:12 |
| _hc | I agree with grote | 13:20:09 |
| _hc | in other news, I've started pointing swap to index-v1.jar and ripping out index.xml/index.jar support | 13:20:32 |
| _hc | index.xml support is quite tangled into the code :-/ | 13:20:44 |
| _hc | I suppose that's not surprising. It'll be good to have that all out of the code base | 13:20:59 |
| grote | Hopefully the untangling doesn't tangle too much with my untangling... | 13:26:46 |
| cde | In reply to @grote:matrix.org
I'd say we do the full v2 index first and if there's time, we can still make the client handle a reduced version. agree, and hopefully that work helps in doing at least a quick proof of concept easily to see the real world benefits before committing more to it. | 13:28:33 |
| _hc | In reply to @grote:matrix.org
Hopefully the untangling doesn't tangle too much with my untangling... some inter-un-tangling is inevitable I think. Are you thinking you'd rather do the index.xml purge? | 13:43:13 |
| grote | No, as long as we don't let these refactoring linger in branches for too long, it will be fine. | 13:49:49 |
| grote | We could look into getting 1.4 out before, or make a dev branch where we merge our MRs into with the intention to merge that into master once the dust has settled. | 13:51:00 |
| _hc | yeah I was thinking a dev branch could make sense. and it would be good to get 1.4 out too | 14:01:16 |
| grote | Maybe release a new alpha now that the crash is fixed? | 14:14:09 |
| _hc | grote: you're feeling pretty good about that fix? I haven't looked at it at all | 14:16:04 |
| grote | the diff looked ok and I didn't see it crashing again | 14:16:33 |
| cde | release early, release often! | 14:28:56 |
| Licaon_Kter[xmpp] | Disable crashing build fast! | 14:40:54 |
| cde | what good is an alpha that doesn't crash once in a while ;) | 14:43:06 |
