| 1 |
On Mon, Jun 29, 2020, at 9:34 PM, Zac Medico wrote: |
| 2 |
> On 6/29/20 7:15 PM, Sid Spry wrote: |
| 3 |
> > On Mon, Jun 29, 2020, at 9:13 PM, Sid Spry wrote: |
| 4 |
> >> Hello, |
| 5 |
> >> |
| 6 |
> >> I have some runnable pseudocode outlining a faster tree verification algorithm. |
| 7 |
> > |
| 8 |
> > Ah, right. It's worth noting that even faster than this algorithm is simply verifying |
| 9 |
> > a .tar.xz. Is that totally off the table? I realize it doesn't fit every usecase, but it |
| 10 |
> > seems to be faster in both sync and verification time. |
| 11 |
> |
| 12 |
> We've already got support for that with sync-type = webrsync. However, I |
| 13 |
> imagine sync-type = git is even better. All of the types are covered here: |
| 14 |
> |
| 15 |
> https://wiki.gentoo.org/wiki/Portage_Security |
| 16 |
|
| 17 |
I'm being warned right now that webrsync-gpg is being deprecated; I've been using |
| 18 |
it. It is, amazingly, faster than a typical rsync and may be faster than a git pull though. |
| 19 |
|
| 20 |
The issue with git is there are some analyses that indicate you shouldn't rely on git |
| 21 |
for integrity, so you are back to verifying the tree on-disk, which is slower than |
| 22 |
verifying the .tar.xz. |
| 23 |
|
| 24 |
(To clarify: Even with signed commits the commit hashes could be attacked and this |
| 25 |
is considered somewhat feasible.) |
Archives