Stefan Sperling wrote on Wed, May 15, 2019 at 07:44:41 -0400:
> On Wed, May 15, 2019 at 07:20:25AM +0100, Paul Hammant wrote:
> > Article:
> > https://www.zdnet.com/article/sha-1-collision-attacks-are-now-actually-practical-and-a-looming-danger/
> >
> > Subversion makes a SHA1 hash for each resou
On 22.05.2019 01:11, Paul Hammant wrote:
>
>
> Why a merkle tree? One of Subversion's strengths is its linear
> revision history. You could use blockchain and get financial strength
> audit ability.
>
> Blockchain is so over sold. There's a whole class of application where
> the bastard child of Gi
Why a merkle tree? One of Subversion's strengths is its linear revision
history. You could use blockchain and get financial strength audit ability.
Blockchain is so over sold. There's a whole class of application where the
bastard child of Git and Subversion would be a perfect non-repudiable and
t
Nathan Hartman wrote on Tue, 21 May 2019 13:32 +00:00:
> Why a merkle tree? One of Subversion's strengths is its linear revision
> history. You could use blockchain and get financial strength audit
> ability.
Handwave, but doesn't that basically boil down to including not
only a node-rev-id but
On Tue, May 21, 2019 at 1:06 AM Paul Hammant wrote:
> The Git folks moved to a hardened SHA1 function as an interim measure
> on the way to SHA-256 -
>
> https://github.com/git/git/blob/master/Documentation/technical/hash-function-transition.txt
>
> I think you're generally right. While I might t
The Git folks moved to a hardened SHA1 function as an interim measure
on the way to SHA-256 -
https://github.com/git/git/blob/master/Documentation/technical/hash-function-transition.txt
I think you're generally right. While I might think that an auditor
would simply be advised of the root hash for
Paul Hammant wrote on Wed, 15 May 2019 13:03 +00:00:
> Problem I'm trying to solve: In an audit situation where prior commits
> were to be analyzed the owner of the repo that was motivated enough
> could tell the auditor that black was while in respect of a certain
> historical commit. Assuming the
Yes, Subversion would remain good a keeping versions of honest development work.
Problem I'm trying to solve: In an audit situation where prior commits
were to be analyzed the owner of the repo that was motivated enough
could tell the auditor that black was while in respect of a certain
historical
Paul Hammant wrote on Wed, 15 May 2019 12:39 +00:00:
> I'm suggesting phasing out SHA1, and during a v1.x to v1.x+1 upgrade
> do a migration script for all content to gain (say) BLAKE2 hashes
> *instead*, and for that install, client's with incompatible hashing
> are rejected.
>
> There are altern
I'm suggesting phasing out SHA1, and during a v1.x to v1.x+1 upgrade
do a migration script for all content to gain (say) BLAKE2 hashes
*instead*, and for that install, client's with incompatible hashing
are rejected.
There are alternates too, where up to a moment in time a repo has
SHA1s, and then
On Wed, May 15, 2019 at 07:20:25AM +0100, Paul Hammant wrote:
> Article:
> https://www.zdnet.com/article/sha-1-collision-attacks-are-now-actually-practical-and-a-looming-danger/
>
> Subversion makes a SHA1 hash for each resource held. It is certainly
> available as part of the detail for a file/r
11 matches
Mail list logo
